[要約] RFC 6374は、MPLSネットワーク（MPLS-TPを含む）において、ラベルスイッチパス（LSP）の「パケット損失率」と「遅延特性（双方向・片方向遅延、ジッタ）」を直接測定するためのプロトコル仕様を定義しています。実際のトラフィックを用いて高精度な性能監視を行うためのメッセージ形式と手順を規定し、サービス品質（SLA）の厳格な検証とトラブルシューティングを可能にします。
Internet Engineering Task Force (IETF) D. Frost
Request for Comments: 6374 S. Bryant
Category: Standards Track Cisco Systems
ISSN: 2070-1721 September 2011
Packet Loss and Delay Measurement for MPLS Networks
MPLSネットワークのパケット損失および遅延測定
Abstract
概要
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks.
多くのサービスプロバイダーサービスレベル契約（SLA）は、パケットの損失と一方向および双方向の遅延のパフォーマンスメトリック、および遅延バリエーションやチャネルスループットなどの関連するメトリックを測定および監視する機能に依存しています。また、この測定機能は、オペレーターがネットワークのパフォーマンス特性をより大きく可視化できるため、計画、トラブルシューティング、ネットワークパフォーマンス評価を促進します。このドキュメントは、MPLSネットワークのこれらのパフォーマンスメトリックの効率的かつ正確な測定を可能にするためのプロトコルメカニズムを指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6374.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http://www.rfc-editor.org/info/rfc6374で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3 1.1. Applicability and Scope ....................................5 1.2. Terminology ................................................6 1.3. Requirements Language ......................................6 2. Overview ........................................................6 2.1. Basic Bidirectional Measurement ............................6 2.2. Packet Loss Measurement ....................................7 2.3. Throughput Measurement ....................................10 2.4. Delay Measurement .........................................10 2.5. Delay Variation Measurement ...............................12 2.6. Unidirectional Measurement ................................12 2.7. Dyadic Measurement ........................................13 2.8. Loopback Measurement ......................................13 2.9. Measurement Considerations ................................14 2.9.1. Types of Channels ..................................14 2.9.2. Quality of Service .................................14 2.9.3. Measurement Point Location .........................14 2.9.4. Equal Cost Multipath ...............................15 2.9.5. Intermediate Nodes .................................15 2.9.6. Different Transmit and Receive Interfaces ..........16 2.9.7. External Post-Processing ...........................16 2.9.8. Loss Measurement Modes .............................16 2.9.9. Loss Measurement Scope .............................18 2.9.10. Delay Measurement Accuracy ........................18 2.9.11. Delay Measurement Timestamp Format ................18 3. Message Formats ................................................19 3.1. Loss Measurement Message Format ...........................19 3.2. Delay Measurement Message Format ..........................25 3.3. Combined Loss/Delay Measurement Message Format ............27 3.4. Timestamp Field Formats ...................................28 3.5. TLV Objects ...............................................29 3.5.1. Padding ............................................30 3.5.2. Addressing .........................................31 3.5.3. Loopback Request ...................................31 3.5.4. Session Query Interval .............................32 4. Operation ......................................................33 4.1. Operational Overview ......................................33 4.2. Loss Measurement Procedures ...............................34 4.2.1. Initiating a Loss Measurement Operation ............34 4.2.2. Transmitting a Loss Measurement Query ..............34 4.2.3. Receiving a Loss Measurement Query .................35 4.2.4. Transmitting a Loss Measurement Response ...........35 4.2.5. Receiving a Loss Measurement Response ..............36 4.2.6. Loss Calculation ...................................36 4.2.7. Quality of Service .................................37 4.2.8. G-ACh Packets ......................................37
4.2.9. Test Messages ......................................37
4.2.10. Message Loss and Packet Misorder Conditions .......38
4.3. Delay Measurement Procedures ..............................39
4.3.1. Transmitting a Delay Measurement Query .............39
4.3.2. Receiving a Delay Measurement Query ................39
4.3.3. Transmitting a Delay Measurement Response ..........40
4.3.4. Receiving a Delay Measurement Response .............41
4.3.5. Timestamp Format Negotiation .......................41
4.3.5.1. Single-Format Procedures ..................42
4.3.6. Quality of Service .................................42
4.4. Combined Loss/Delay Measurement Procedures ................42
5. Implementation Disclosure Requirements .........................42
6. Congestion Considerations ......................................44
7. Manageability Considerations ...................................44
8. Security Considerations ........................................45
9. IANA Considerations ............................................46
9.1. Allocation of PW Associated Channel Types .................47
9.2. Creation of Measurement Timestamp Type Registry ...........47
9.3. Creation of MPLS Loss/Delay Measurement Control
Code Registry .............................................47
9.4. Creation of MPLS Loss/Delay Measurement TLV Object
Registry ..................................................49
10. Acknowledgments ...............................................49
11. References ....................................................49
11.1. Normative References .....................................49
11.2. Informative References ...................................50
Appendix A. Default Timestamp Format Rationale ....................52
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks.
多くのサービスプロバイダーサービスレベル契約（SLA）は、パケットの損失と一方向および双方向の遅延のパフォーマンスメトリック、および遅延バリエーションやチャネルスループットなどの関連するメトリックを測定および監視する機能に依存しています。また、この測定機能は、オペレーターがネットワークのパフォーマンス特性をより大きく可視化できるため、計画、トラブルシューティング、ネットワークパフォーマンス評価を促進します。このドキュメントは、MPLSネットワークのこれらのパフォーマンスメトリックの効率的かつ正確な測定を可能にするためのプロトコルメカニズムを指定します。
This document specifies two closely related protocols, one for packet loss measurement (LM) and one for packet delay measurement (DM). These protocols have the following characteristics and capabilities:
このドキュメントは、2つの密接に関連するプロトコルを指定します。1つはパケット損失測定（LM）、もう1つはパケット遅延測定（DM）用です。これらのプロトコルには、次の特性と機能があります。
o The LM and DM protocols are intended to be simple and to support efficient hardware processing.
o LMおよびDMプロトコルは、シンプルであり、効率的なハードウェア処理をサポートすることを目的としています。
o The LM and DM protocols operate over the MPLS Generic Associated Channel (G-ACh) [RFC5586] and support measurement of loss, delay, and related metrics over Label Switched Paths (LSPs), pseudowires, and MPLS sections (links).
o LMおよびDMプロトコルは、MPLSジェネリック関連チャネル（g-ach）[RFC5586]で動作し、ラベルスイッチドパス（LSP）、擬似化型、およびMPLSセクション（リンク）を介した損失、遅延、および関連するメトリックの測定をサポートします。
o The LM and DM protocols are applicable to the LSPs, pseudowires, and sections of networks based on the MPLS Transport Profile (MPLS-TP), because the MPLS-TP is based on a standard MPLS data plane. The MPLS-TP is defined and described in [RFC5921], and MPLS-TP LSPs, pseudowires, and sections are discussed in detail in [RFC5960]. A profile describing the minimal functional subset of the LM and DM protocols in the MPLS-TP context is provided in [RFC6375].
o The LM and DM protocols can be used both for continuous/proactive and selective/on-demand measurement.
o LMおよびDMプロトコルは、連続/予防的および選択的/オンデマンド測定の両方に使用できます。
o The LM and DM protocols use a simple query/response model for bidirectional measurement that allows a single node -- the querier -- to measure the loss or delay in both directions.
o LMおよびDMプロトコルは、単一のノード（Querier）が両方向の損失または遅延を測定できるようにする双方向測定に簡単なクエリ/応答モデルを使用します。
o The LM and DM protocols use query messages for unidirectional loss and delay measurement. The measurement can be carried out either at the downstream node(s) or at the querier if an out-of-band return path is available.
o LMおよびDMプロトコルは、単方向の損失と遅延測定のためにクエリメッセージを使用します。測定は、下流ノード（s）で、またはバンド外の戻りパスが利用可能な場合はクエリエで実行できます。
o The LM and DM protocols do not require that the transmit and receive interfaces be the same when performing bidirectional measurement.
o LMおよびDMプロトコルでは、双方向測定を実行するときに送信および受信インターフェイスが同じであることを必要としません。
o The DM protocol is stateless.
o DMプロトコルはステートレスです。
o The LM protocol is "almost" stateless: loss is computed as a delta between successive messages, and thus the data associated with the last message received must be retained.
o LMプロトコルは「ほぼ」ステートレスです。損失は連続したメッセージ間のデルタとして計算されるため、受信した最後のメッセージに関連付けられたデータを保持する必要があります。
o The LM protocol can perform two distinct kinds of loss measurement: it can measure the loss of specially generated test messages in order to infer the approximate data-plane loss level (inferred measurement) or it can directly measure data-plane packet loss (direct measurement). Direct measurement provides perfect loss accounting, but may require specialized hardware support and is only applicable to some LSP types. Inferred measurement provides only approximate loss accounting but is generally applicable.
o LMプロトコルは、2つの異なる種類の損失測定を実行できます。近似データプレーン損失レベル（推定測定）を推測するために、特別に生成されたテストメッセージの損失を測定できます。）。直接測定は完全な損失会計を提供しますが、特殊なハードウェアサポートが必要になる場合があり、一部のLSPタイプにのみ適用できます。推定測定は、おおよその損失会計のみを提供しますが、一般的に適用可能です。
The direct LM method is also known as "frame-based" in the context of Ethernet transport networks [Y.1731]. Inferred LM is a generalization of the "synthetic" measurement approach currently in development for Ethernet networks, in the sense that it allows test messages to be decoupled from measurement messages.
直接LMメソッドは、イーサネット輸送ネットワークのコンテキストで「フレームベース」としても知られています[Y.1731]。推測されたLMは、テストメッセージを測定メッセージから切り離すことができるという意味で、イーサネットネットワークの開発中の「合成」測定アプローチの一般化です。
o The LM protocol supports measurement in terms of both packet counts and octet counts.
o LMプロトコルは、パケット数とオクテットカウントの両方の点で測定をサポートしています。
o The LM protocol supports both 32-bit and 64-bit counters.
o LMプロトコルは、32ビットカウンターと64ビットカウンターの両方をサポートしています。
o The LM protocol can be used to measure channel throughput as well as packet loss.
o LMプロトコルを使用して、チャネルスループットとパケット損失を測定できます。
o The DM protocol supports multiple timestamp formats, and provides a simple means for the two endpoints of a bidirectional connection to agree on a preferred format. This procedure reduces to a triviality for implementations supporting only a single timestamp format.
o DMプロトコルは複数のタイムスタンプ形式をサポートし、双方向接続の2つのエンドポイントが優先形式に同意する簡単な手段を提供します。この手順は、単一のタイムスタンプ形式のみをサポートする実装の些細なことになります。
o The DM protocol supports varying the measurement message size in order to measure delays associated with different packet sizes.
o DMプロトコルは、異なるパケットサイズに関連する遅延を測定するために、測定メッセージサイズを変えることをサポートします。
The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way Active Measurement Protocol (TWAMP) [RFC5357] provide capabilities for the measurement of various performance metrics in IP networks. These protocols are not streamlined for hardware processing and rely on IP and TCP, as well as elements of the Network Time Protocol (NTP), which may not be available or optimized in some network environments; they also lack support for IEEE 1588 timestamps and direct-mode LM, which may be required in some environments. The protocols defined in this document thus are similar in some respects to, but also differ from, these IP-based protocols.
一元配置活性測定プロトコル（OWAMP）[RFC4656]および双方向活性測定プロトコル（TWAMP）[RFC5357]は、IPネットワークのさまざまなパフォーマンスメトリックの測定に機能を提供します。これらのプロトコルは、ハードウェア処理用に合理化されておらず、IPとTCP、および一部のネットワーク環境で利用できないか最適化されていないネットワークタイムプロトコル（NTP）の要素に依存しています。また、IEEE 1588タイムスタンプとダイレクトモードLMのサポートもありません。これは、一部の環境で必要な場合があります。したがって、このドキュメントで定義されているプロトコルは、これらのIPベースのプロトコルに対して、しかし異なる点で類似しています。
This document specifies measurement procedures and protocol messages that are intended to be applicable in a wide variety of circumstances and amenable to implementation by a wide range of hardware- and software-based measurement systems. As such, it does not attempt to mandate measurement quality levels or analyze specific end-user applications.
このドキュメントは、さまざまな状況で適用され、幅広いハードウェアおよびソフトウェアベースの測定システムによる実装に適していることを目的とした測定手順とプロトコルメッセージを指定します。そのため、測定品質レベルを義務付けたり、特定のエンドユーザーアプリケーションを分析しようとはしません。
Term Definition
----- -------------------------------------------
ACH Associated Channel Header
DM Delay Measurement
ECMP Equal Cost Multipath
G-ACh Generic Associated Channel
LM Loss Measurement
LSE Label Stack Entry
LSP Label Switched Path
NTP Network Time Protocol
OAM Operations, Administration, and Maintenance
PTP Precision Time Protocol
TC Traffic Class
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、RFC 2119 [RFC2119] で説明されているように解釈されるものとします。
This section begins with a summary of the basic methods used for the bidirectional measurement of packet loss and delay. These measurement methods are then described in detail. Finally, a list of practical considerations is discussed that may come into play to inform or modify these simple procedures. This section is limited to theoretical discussion; for protocol specifics, the reader is referred to Sections 3 and 4.
このセクションは、パケットの損失と遅延の双方向測定に使用される基本的な方法の概要から始まります。これらの測定方法については、詳細に説明します。最後に、これらの簡単な手順を通知または変更するために作用する可能性のある実用的な考慮事項のリストが議論されています。このセクションは、理論的な議論に限定されています。プロトコルの詳細については、読者はセクション3および4を参照します。
The following figure shows the reference scenario.
次の図は、参照シナリオを示しています。
T1 T2
+-------+/ Query \+-------+
| | - - - - - - - - ->| |
| A |===================| B |
| |<- - - - - - - - - | |
+-------+\ Response /+-------+
T4 T3
This figure shows a bidirectional channel between two nodes, A and B, and illustrates the temporal reference points T1-T4 associated with a measurement operation that takes place at A. The operation consists of A sending a query message to B, and B sending back a response.
この図は、AとBの2つのノード間の双方向チャネルを示しており、Aで行われる測定操作に関連する時間的基準点T1-T4を示しています。操作は、bにクエリメッセージを送信するaとBの送信で構成されています。応答。
Each reference point indicates the point in time at which either the query or the response message is transmitted or received over the channel.
各基準点は、クエリまたは応答メッセージがチャネル上で送信または受信される時点を示します。
In this situation, A can arrange to measure the packet loss over the channel in the forward and reverse directions by sending Loss Measurement (LM) query messages to B, each of which contains the count of packets transmitted prior to time T1 over the channel to B (A_TxP). When the message reaches B, it appends two values and reflects the message back to A: the count of packets received prior to time T2 over the channel from A (B_RxP) and the count of packets transmitted prior to time T3 over the channel to A (B_TxP). When the response reaches A, it appends a fourth value: the count of packets received prior to time T4 over the channel from B (A_RxP).
この状況では、Aは、bに損失測定（LM）クエリメッセージを送信することにより、順方向と逆方向のチャネル上のパケット損失を測定するように手配します。それぞれには、時間T1より前に送信されたパケットのカウントがチャネル上で送信されます。B（A_TxP）。メッセージがBに到達すると、2つの値を追加し、Aにメッセージを反映します：時間T2より前に受信したパケットのカウント（B_RxP）とチャネル上でT3より前に送信されたパケットのカウントをA（B_RxP）からカウント（B_TxP）。応答がAに達すると、4番目の値を追加します。これは、B（A_RxP）からチャネル上でT4より前に受信したパケットのカウントです。
These four counter values enable A to compute the desired loss statistics. Because the transmit count at A and the receive count at B (and vice versa) may not be synchronized at the time of the first message, and to limit the effects of counter wrap, the loss is computed in the form of a delta between messages.
これらの4つのカウンター値により、Aは目的の損失統計を計算できます。Aでの送信数とBでの受信カウント（およびその逆）は最初のメッセージの時点で同期しない可能性があり、カウンターラップの効果を制限するために、メッセージはメッセージ間のデルタの形で計算されます。。
To measure at A the delay over the channel to B, a Delay Measurement (DM) query message is sent from A to B containing a timestamp recording the instant at which it is transmitted, i.e., T1. When the message reaches B, a timestamp is added recording the instant at which it is received (T2). The message can now be reflected from B to A, with B adding its transmit timestamp (T3) and A adding its receive timestamp (T4). These four timestamps enable A to compute the one-way delay in each direction, as well as the two-way delay for the channel. The one-way delay computations require that the clocks of A and B be synchronized; mechanisms for clock synchronization are outside the scope of this document.
チャネル上のbへの遅延でAを測定するには、遅延測定（DM）クエリメッセージがAからBに送信され、それが送信される瞬間、つまりT1を記録するタイムスタンプを含みます。メッセージがBに達すると、タイムスタンプが追加され、受信した瞬間を記録します（T2）。メッセージはBからAに反映されるようになり、Bを追加して送信タイムスタンプ（T3）を追加し、受信タイムスタンプ（T4）を追加できます。これらの4つのタイムスタンプにより、Aは各方向の一元配置遅延、およびチャネルの双方向遅延を計算できます。一元配置遅延計算では、aとbのクロックを同期させる必要があります。時計同期のメカニズムは、このドキュメントの範囲外です。
Suppose a bidirectional channel exists between the nodes A and B. The objective is to measure at A the following two quantities associated with the channel:
ノードAとBの間に双方向チャネルが存在すると仮定します。目的は、チャネルに関連付けられた次の2つの量で測定することです。
A_TxLoss (transmit loss): the number of packets transmitted by A over the channel but not received at B;
A_TxLoss（送信損失）：bで送信されるが、bで受信されていないパケットの数。
A_RxLoss (receive loss): the number of packets transmitted by B over the channel but not received at A.
A_RxLoss（受信損失）：チャネル上でBによって送信されるパケットの数は、Aで受信されていません。
This is accomplished by initiating a Loss Measurement (LM) operation at A, which consists of transmission of a sequence of LM query messages (LM[1], LM[2], ...) over the channel at a specified rate, such as one every 100 milliseconds. Each message LM[n] contains the following value:
これは、Aで損失測定（LM）操作を開始することによって達成されます。これは、指定された速度でチャネル上のLMクエリメッセージ（LM [1]、LM [2]、...）のシーケンスの送信で構成されます。100ミリ秒ごとに。各メッセージlm [n]には、次の値が含まれています。
A_TxP[n]: the total count of packets transmitted by A over the channel prior to the time this message is transmitted.
A_TxP [n]：このメッセージが送信される前に、チャンネル上のパケットの合計カウント。
When such a message is received at B, the following value is recorded in the message:
このようなメッセージがBで受信されると、メッセージに次の値が記録されます。
B_RxP[n]: the total count of packets received by B over the channel at the time this message is received (excluding the message itself).
B_RxP [n]：このメッセージが受信された時点で、チャネル上でBによって受信されたパケットの合計カウント（メッセージ自体を除く）。
At this point, B transmits the message back to A, recording within it the following value:
この時点で、BはメッセージをAに送り返し、その中に次の値を記録します。
B_TxP[n]: the total count of packets transmitted by B over the channel prior to the time this response is transmitted.
B_TxP [n]：この応答が送信される前に、チャネル上にBによって送信されたパケットの合計カウント。
When the message response is received back at A, the following value is recorded in the message:
メッセージ応答がAで返信されると、メッセージに次の値が記録されます。
A_RxP[n]: the total count of packets received by A over the channel at the time this response is received (excluding the message itself).
A_RxP [n]：この応答が受信された時点で、チャネルオーバーチャネルによって受信されたパケットの合計カウント（メッセージ自体を除く）。
The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n] within the measurement interval marked by the messages LM[n-1] and LM[n] are computed by A as follows:
送信損失A_TxLoss [n-1、n]および受信lm [n-1]およびlm [n]でマークされた測定間隔内の損失A_RxLoss [n-1、n]は、次のようにaで計算されます。
A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
where the arithmetic is modulo the counter size.
算術はカウンターサイズです。
(Strictly speaking, it is not necessary that the fourth count, A_RxP[n], actually be written in the message, but this is convenient for some implementations and useful if the message is to be forwarded on to an external measurement system.)
（厳密に言えば、4番目のカウントA_RxP [n]を実際にメッセージに記述する必要はありませんが、これはいくつかの実装に便利であり、メッセージが外部測定システムに転送される場合に役立ちます。）
The derived values
派生値
A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ...
A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ...
are updated each time a response to an LM message is received and processed, and they represent the total transmit and receive loss over the channel since the LM operation was initiated.
LMメッセージへの応答が受信および処理されるたびに更新され、LM操作が開始されて以来、チャネル上の総送信および受信を表します。
When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n], the possibility of counter wrap must be taken into account. For example, consider the values of the A_TxP counter at sequence numbers n-1 and n. Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a value equal to or greater than A_TxP[n-1], the computation of an unambiguous A_TxLoss[n-1,n] value will be impossible. Therefore, the LM message rate MUST be sufficiently high, given the counter size and the speed and minimum packet size of the underlying channel, that this condition cannot arise. For example, a 32-bit counter for a 100-Gbps link with a minimum packet size of 64 bytes can wrap in 2^32 / (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on the LM message interval under such conditions. This bound will be referred to as the MaxLMInterval of the channel. It is clear that the MaxLMInterval will be a more restrictive constraint in the case of direct LM and for smaller counter sizes.
値 A_TxLoss[n-1,n] および A_RxLoss[n-1,n] を計算する際、カウンタのラップアラウンド（一巡）の可能性を考慮しなければなりません。例えば、シーケンス番号 n-1 および n における A_TxP カウンタの値を考えてみます。明らかに、A_TxP[n] が 0 にラップし、さらに A_TxP[n-1] 以上の値に達することが許容される場合、明確な A_TxLoss[n-1,n] の値を計算することは不可能になります。したがって、カウンタのサイズ、ならびに下位チャネルの速度および最小パケットサイズを考慮して、この状況が発生し得ないように、LMメッセージレートは十分に高くなければなりません (MUST)。例えば、最小パケットサイズが64バイトの 100 Gbps リンクに対する32ビットカウンタは、2^32 / (10^11 / (64*8)) = 約22秒でラップする可能性があり、したがってこれがそのような条件下でのLMメッセージ間隔の上限となります。この上限をチャネルの MaxLMInterval と呼びます。直接LMの場合、およびカウンタサイズがより小さい場合、MaxLMInterval がより厳しい制約となることは明らかです。
The loss measurement approach described in this section has the characteristic of being stateless at B and "almost" stateless at A. Specifically, A must retain the data associated with the last LM response received, in order to use it to compute loss when the next response arrives. This data MAY be discarded, and MUST NOT be used as a basis for measurement, if MaxLMInterval elapses before the next response arrives, because in this case an unambiguous measurement cannot be made.
本節で説明した損失測定アプローチは、B においてステートレスであり、A において「ほぼ」ステートレスであるという特徴を持ちます。具体的には、A は次の応答が到着した際に損失を計算するために使用できるよう、受信した最後のLM応答に関連するデータを保持しなければなりません。次の応答が到着する前に MaxLMInterval が経過した場合、このケースでは明確な測定が行えないため、このデータは破棄してもよく (MAY)、測定の基準として使用してはなりません (MUST NOT)。
The foregoing discussion has assumed the counted objects are packets, but this need not be the case. In particular, octets may be counted instead. This will, of course, reduce the MaxLMInterval accordingly.
前述の議論は、カウントされたオブジェクトがパケットであると想定していますが、これは事実ではありません。特に、代わりにオクテットがカウントされる場合があります。もちろん、これにより、それに応じてMaxLMIntervalが削減されます。
In addition to absolute aggregate loss counts, the individual loss counts yield other metrics, such as the average loss rate over any multiple of the measurement interval. An accurate loss rate can be determined over time even in the presence of anomalies affecting individual measurements, such as those due to packet misordering (Section 4.2.10).
絶対的な集約損失カウントに加えて、個々の損失カウントは、測定間隔の倍数にわたる平均損失率など、他のメトリックを生成します。正確な損失率は、パケットの誤用によるものなど、個々の測定に影響を与える異常が存在する場合でも、時間の経過とともに決定できます（セクション4.2.10）。
Note that an approach for conducting packet loss measurement in IP networks is documented in [RFC2680]. This approach differs from the one described here, for example by requiring clock synchronization between the measurement points and lacking support for direct-mode LM.
IPネットワークでパケット損失測定を実施するためのアプローチは[RFC2680]に記録されていることに注意してください。このアプローチは、測定ポイント間のクロック同期を必要とし、ダイレクトモードLMのサポートがないことにより、ここで説明したアプローチとは異なります。
If LM query messages contain a timestamp recording their time of transmission, this data can be combined with the packet or octet counts to yield measurements of the throughput offered and delivered over the channel during the interval in terms of the counted units.
LMクエリメッセージに送信時間を記録するタイムスタンプが含まれている場合、このデータをパケットまたはオクテットカウントと組み合わせて、カウントされたユニットの観点から間隔で提供されて提供されたスループットの測定値を生成できます。
For a bidirectional channel, for example, given any two LM response messages (separated in time by not more than the MaxLMInterval), the difference between the counter values tells the querier the number of units successfully transmitted and received in the interval between the timestamps. Absolute offered throughput is the number of data units transmitted and absolute delivered throughput is the number of data units received. Throughput rate is the number of data units sent or received per unit time.
たとえば、双方向チャネルの場合、2つのLM応答メッセージ（MaxLMInterval以下で時間内に分離）を与えられた場合、カウンター値の差は、タイムスタンプ間の間隔で正常に送信および受信されたユニットの数をクエリエに示します。絶対に提供されるスループットは、送信されたデータユニットの数と絶対に配信されるスループットの数は、受け取ったデータユニットの数です。スループットレートは、単位時間ごとに送信または受信したデータユニットの数です。
Just as for loss measurement, the interval counts can be accumulated to arrive at the absolute throughput of the channel since the start of the measurement operation or be used to derive related metrics such as the throughput rate. This procedure also enables out-of-service throughput testing when combined with a simple packet generator.
損失測定と同様に、間隔カウントを蓄積して、測定操作の開始からチャネルの絶対スループットに到達するか、スループットレートなどの関連するメトリックを導出するために使用できます。この手順により、単純なパケットジェネレーターと組み合わせると、サービス外のスループットテストが可能になります。
Suppose a bidirectional channel exists between the nodes A and B. The objective is to measure at A one or more of the following quantities associated with the channel:
ノードAとBの間に双方向チャネルが存在すると仮定します。目的は、チャネルに関連付けられた次の量の1つ以上で測定することです。
o The one-way delay associated with the forward (A to B) direction of the channel;
o チャネルのフォワード（AからB）方向に関連付けられた一方向遅延。
o The one-way delay associated with the reverse (B to A) direction of the channel;
o チャネルの逆（bからa）方向に関連付けられた一方向遅延。
o The two-way delay (A to B to A) associated with the channel.
o チャネルに関連付けられた双方向遅延（AからB〜A）。
The one-way delay metric for packet networks is described in [RFC2679]. In the case of two-way delay, there are actually two possible metrics of interest. The "two-way channel delay" is the sum of the one-way delays in each direction and reflects the delay of the channel itself, irrespective of processing delays within the remote
パケットネットワークの一方向遅延メトリックは[RFC2679]で説明されています。双方向の遅延の場合、実際には関心のある2つの可能性のあるメトリックがあります。「双方向チャネル遅延」は、リモート内の処理遅延に関係なく、各方向の一元配置遅延の合計であり、チャネル自体の遅延を反映しています
endpoint B. The "round-trip delay" is described in [RFC2681] and includes in addition any delay associated with remote endpoint processing.
エンドポイントB。「往復遅延」は[RFC2681]で説明されており、さらにリモートエンドポイント処理に関連付けられた遅延が含まれます。
Measurement of the one-way delay quantities requires that the clocks of A and B be synchronized, whereas the two-way delay metrics can be measured directly even when this is not the case (provided A and B have stable clocks).
一元配置遅延量の測定には、aとbのクロックを同期させる必要がありますが、双方向遅延メトリックは、そうでない場合でも直接測定できます（aとbに安定したクロックがある場合）。
A measurement is accomplished by sending a Delay Measurement (DM) query message over the channel to B that contains the following timestamp:
測定は、次のタイムスタンプを含むBにチャネルを介して遅延測定（DM）クエリメッセージを送信することによって達成されます。
T1: the time the DM query message is transmitted from A.
T1：DMクエリメッセージがAから送信される時間
When the message arrives at B, the following timestamp is recorded in the message:
メッセージがBに到着すると、次のタイムスタンプがメッセージに記録されます。
T2: the time the DM query message is received at B.
T2：DMクエリメッセージがBで受信される時間
At this point, B transmits the message back to A, recording within it the following timestamp:
この時点で、BはメッセージをAに送り返し、次のタイムスタンプを記録します。
T3: the time the DM response message is transmitted from B.
T3：DM応答メッセージがBから送信される時間
When the message arrives back at A, the following timestamp is recorded in the message:
メッセージがAに到着すると、次のタイムスタンプがメッセージに記録されます。
T4: the time the DM response message is received back at A.
T4：DM応答メッセージがAで受け取られた時間
(Strictly speaking, it is not necessary that the fourth timestamp, T4, actually be written in the message, but this is convenient for some implementations and useful if the message is to be forwarded on to an external measurement system.)
（厳密に言えば、4番目のタイムスタンプT4を実際にメッセージに書く必要はありませんが、これはいくつかの実装に便利であり、メッセージが外部測定システムに転送される場合に役立ちます。）
At this point, A can compute the two-way channel delay associated with the channel as
この時点で、Aはチャネルに関連付けられている双方向チャネル遅延を計算できます
two-way channel delay = (T4 - T1) - (T3 - T2)
and the round-trip delay as
往復遅延として
round-trip delay = T4 - T1.
往復遅延= T4 -T1。
If the clocks of A and B are known at A to be synchronized, then both one-way delay values, as well as the two-way channel delay, can be computed at A as
AとBのクロックがAで同期することがわかっている場合、双方向のチャネル遅延の両方と同様に、ASで計算できます。
forward one-way delay = T2 - T1
前方の一方向遅延= T2 -T1
reverse one-way delay = T4 - T3
逆方向遅延= T4 -T3
two-way channel delay = forward delay + reverse delay.
双方向チャネル遅延=フォワード遅延逆遅延。
Note that this formula for the two-way channel delay reduces to the one previously given, and clock synchronization is not required to compute this metric.
この双方向チャネル遅延のこの式は、以前に与えられたものに減少し、このメトリックを計算するためにクロック同期は必要ないことに注意してください。
Inter-Packet Delay Variation (IPDV) and Packet Delay Variation (PDV) [RFC5481] are performance metrics derived from one-way delay measurement and are important in some applications. IPDV represents the difference between the one-way delays of successive packets in a stream. PDV, given a measurement test interval, represents the difference between the one-way delay of a packet in the interval and that of the packet in the interval with the minimum delay.
パケット間遅延変動（IPDV）およびパケット遅延変動（PDV）[RFC5481]は、一元配置遅延測定から派生したパフォーマンスメトリックであり、一部のアプリケーションでは重要です。IPDVは、ストリーム内の連続したパケットの一元配置遅延の違いを表します。PDVは、測定テスト間隔を与えられた場合、間隔のパケットの一方向遅延と、最小遅延のある間隔のパケットの一方向遅延の差を表します。
IPDV and PDV measurements can therefore be derived from delay measurements obtained through the procedures in Section 2.4. An important point regarding delay variation measurement, however, is that it can be carried out based on one-way delay measurements even when the clocks of the two systems involved in those measurements are not synchronized with one another.
したがって、IPDVおよびPDV測定は、セクション2.4の手順を通じて得られた遅延測定から導き出すことができます。ただし、遅延変動測定に関する重要なポイントは、それらの測定に関与する2つのシステムのクロックが互いに同期されていない場合でも、一元配置遅延測定に基づいて実行できることです。
In the case that the channel from A to (B1, ..., Bk) (where B2, ..., Bk refers to the point-to-multipoint case) is unidirectional, i.e., is a unidirectional LSP, LM and DM measurements can be carried out at B1, ..., Bk instead of at A.
Aから（b1、...、bk）（b2、...、bkがポイントツーマルチポイントケースを指す）までのチャネルは単方向です。測定は、AではなくB1、...、BKで実行できます。
For LM, this is accomplished by initiating an LM operation at A and carrying out the same procedures as used for bidirectional channels, except that no responses from B1, ..., Bk to A are generated. Instead, each terminal node B uses the A_TxP and B_RxP values in the LM messages it receives to compute the receive loss associated with the channel in essentially the same way as described previously, that is:
LMの場合、これはAでLM操作を開始し、B1、...、BKからAへの応答が生成されないことを除いて、双方向チャネルに使用されるのと同じ手順を実行することによって達成されます。代わりに、各端子ノードBは、以前に記載されているのと同じ方法で、チャネルに関連する受信損失を計算するために受信するLMメッセージのA_TxPおよびB_RxP値を使用します。
B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
For DM, of course, only the forward one-way delay can be measured and the clock synchronization requirement applies.
もちろん、DMの場合、前方の一方向遅延のみを測定でき、クロック同期要件が適用されます。
Alternatively, if an out-of-band channel from a terminal node B back to A is available, the LM and DM message responses can be communicated to A via this channel so that the measurements can be carried out at A.
あるいは、端子ノードBからAに戻る帯域外チャネルが利用可能な場合、LMおよびDMメッセージの応答をこのチャネルを介してAに通信して、測定値をAで実行できるようにすることができます。
The basic procedures for bidirectional measurement assume that the measurement process is conducted by and for the querier node A. Instead, it is possible, with only minor variation of these procedures, to conduct a dyadic or "dual-ended" measurement process in which both nodes A and B perform loss or delay measurement based on the same message flow. This is achieved by stipulating that A copy the third and fourth counter or timestamp values from a response message into the third and fourth slots of the next query, which are otherwise unused, thereby providing B with equivalent information to that learned by A.
双方向測定の基本手順では、測定プロセスがクエリエノードAによって、およびクエリエノードAに対して行われると仮定します。代わりに、これらの手順のわずかな変動のみで、両方が両方であるダイアディックまたは「デュアルエンド」測定プロセスを実施することが可能です。ノードAとBは、同じメッセージフローに基づいて損失または遅延測定を実行します。これは、応答メッセージから3番目と4番目のカウンター値またはタイムスタンプの値を次のクエリの3番目と4番目のスロットにコピーすることで実現されます。
The dyadic procedure has the advantage of halving the number of messages required for both A and B to perform a given kind of measurement, but comes at the expense of each node's ability to control its own measurement process independently, and introduces additional operational complexity into the measurement protocols. The quantity of measurement traffic is also expected to be low relative to that of user traffic, particularly when 64-bit counters are used for LM. Consequently, this document does not specify a dyadic operational mode. However, it is still possible, and may be useful, for A to perform the extra copy, thereby providing additional information to B even when its participation in the measurement process is passive.
ダイアディック手順には、AとBの両方が特定の種類の測定を実行するために必要なメッセージの数を半分にするという利点がありますが、独自の測定プロセスを独立して制御する各ノードの能力を犠牲にして、追加の運用上の複雑さを導入します。測定プロトコル。特に64ビットカウンターがLMに使用される場合、測定トラフィックの量もユーザートラフィックの量と比較して低いと予想されます。したがって、このドキュメントでは、二項動作モードを指定しません。ただし、Aが追加のコピーを実行するためにはまだ可能であり、有用である可能性があり、測定プロセスへの参加が受動的であっても、Bに追加情報を提供します。
Some bidirectional channels may be placed into a loopback state such that messages are looped back to the sender without modification. In this situation, LM and DM procedures can be used to carry out measurements associated with the circular path. This is done by generating "queries" with the Response flag set to 1.
いくつかの双方向チャネルをループバック状態に配置して、メッセージが変更なしで送信者にループされるようにすることができます。この状況では、LMおよびDMの手順を使用して、円形パスに関連する測定値を実行できます。これは、応答フラグを1に設定して「クエリ」を生成することによって行われます。
For LM, the loss computation in this case is:
LMの場合、この場合の損失計算は次のとおりです。
A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
For DM, the round-trip delay is computed. In this case, however, the remote endpoint processing time component reflects only the time required to loop the message from channel input to channel output.
DMの場合、往復遅延が計算されます。ただし、この場合、リモートエンドポイント処理時間コンポーネントは、チャネル入力からチャネル出力へのメッセージをループするのに必要な時間のみを反映しています。
A number of additional considerations apply in practice to the measurement methods summarized above.
上記の測定方法には、実際には多くの追加の考慮事項が適用されます。
There are several types of channels in MPLS networks over which loss and delay measurement may be conducted. The channel type may restrict the kinds of measurement that can be performed. In all cases, LM and DM messages flow over the MPLS Generic Associated Channel (G-ACh), which is described in detail in [RFC5586].
MPLSネットワークには、損失と遅延測定が実施される可能性のあるいくつかのタイプのチャネルがあります。チャネルタイプは、実行できる測定の種類を制限する場合があります。すべての場合において、LMおよびDMメッセージは、[RFC5586]で詳細に説明されているMPLSジェネリック関連チャネル（G-CHACH）上に流れます。
Broadly, a channel in an MPLS network may be either a link, a Label Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are bidirectional and are also referred to as MPLS sections; see [RFC5586] and [RFC5960]. Pseudowires are bidirectional. Label Switched Paths may be either unidirectional or bidirectional.
The LM and DM protocols discussed in this document are initiated from a single node: the querier. A query message may be received either by a single node or by multiple nodes, depending on the nature of the channel. In the latter case, these protocols provide point-to-multipoint measurement capabilities.
このドキュメントで説明されているLMおよびDMプロトコルは、単一のノード（Querier）から開始されます。クエリメッセージは、チャネルの性質に応じて、単一のノードまたは複数のノードによって受信される場合があります。後者の場合、これらのプロトコルは、ポイントツーマルチポイント測定機能を提供します。
Quality of Service (QoS) capabilities, in the form of the Differentiated Services architecture, apply to MPLS as specified in [RFC3270] and [RFC5462]. Different classes of traffic are distinguished by the three-bit Traffic Class (TC) field of an MPLS Label Stack Entry (LSE). Delay measurement applies on a per-traffic-class basis, and the TC values of LSEs above the G-ACh Label (GAL) that precedes a DM message are significant. Packet loss can be measured with respect either to the channel as a whole or to a specific traffic class.
The location of the measurement points for loss and delay within the sending and receiving nodes is implementation dependent but directly affects the nature of the measurements. For example, a sending implementation may or may not consider a packet to be "lost", for LM purposes, that was discarded prior to transmission for queuing-
送信および受信ノード内の損失と遅延の測定ポイントの位置は実装に依存しますが、測定の性質に直接影響します。たとえば、送信の実装は、LMの目的のために、キューイングの送信前に破棄されたLMの目的で、パケットを「失われた」と考える場合と見なされない場合があります。
related reasons; conversely, a receiving implementation may or may not consider a packet to be "lost", for LM purposes, if it was physically received but discarded during receive-path processing. The location of delay measurement points similarly determines what, precisely, is being measured. The principal consideration here is that the behavior of an implementation in these respects MUST be made clear to the user.
関連する理由によるものです。逆に、受信側の実装は、LMの目的において、パケットが物理的に受信されたものの受信パスの処理中に破棄された場合に、それを「損失」とみなすこともみなさないこともあります。遅延測定ポイントの位置も同様に、正確に何が測定されているかを決定します。ここでの主な考慮事項は、これらに関する実装の動作がユーザーに対して明確にされなければならない (MUST) という点です。
Equal Cost Multipath (ECMP) is the behavior of distributing packets across multiple alternate paths toward a destination. The use of ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical result of ECMP being performed on an LSP that is subject to delay measurement will be that only the delay of one of the available paths is, and can be, measured.
等しいコストマルチパス（ECMP）は、宛先に向かって複数の代替パスにわたってパケットを配布する動作です。MPLSネットワークでのECMPの使用は、BCP 128 [RFC4928]で説明されています。遅延測定の対象となるLSPでECMPが実行されるという典型的な結果は、利用可能なパスの1つの遅延のみが測定できるということです。
The effects of ECMP on loss measurement will depend on the LM mode. In the case of direct LM, the measurement will account for any packets lost between the sender and the receiver, regardless of how many paths exist between them. However, the presence of ECMP increases the likelihood of misordering both of LM messages relative to data packets and of the LM messages themselves. Such misorderings tend to create unmeasurable intervals and thus degrade the accuracy of loss measurement. The effects of ECMP are similar for inferred LM, with the additional caveat that, unless the test packets are specially constructed so as to probe all available paths, the loss characteristics of one or more of the alternate paths cannot be accounted for.
損失測定に対するECMPの影響は、LMモードに依存します。直接LMの場合、測定値は、それらの間にいくつのパスが存在するかに関係なく、送信者と受信機の間で失われたパケットを説明します。ただし、ECMPの存在により、データパケットとLMメッセージ自体に対するLMメッセージの両方を誤用する可能性が高まります。このような誤った順序は、測定不可能な間隔を作成し、損失測定の精度を低下させる傾向があります。ECMPの効果は、推測されたLMで類似しており、利用可能なすべてのパスをプローブするためにテストパケットが特別に構築されない限り、1つ以上の代替パスの損失特性を説明できないという追加の警告があります。
In the case of an LSP, it may be desirable to measure the loss or delay to or from an intermediate node as well as between LSP endpoints. This can be done in principle by setting the Time to Live (TTL) field in the outer LSE appropriately when targeting a measurement message to an intermediate node. This procedure may fail, however, if hardware-assisted measurement is in use, because the processing of the packet by the intermediate node occurs only as the result of TTL expiry, and the handling of TTL expiry may occur at a later processing stage in the implementation than the hardware-assisted measurement function. The motivation for conducting measurements to intermediate nodes is often an attempt to localize a problem that has been detected on the LSP. In this case, if intermediate nodes are not capable of performing hardware-assisted measurement, a less accurate -- but usually sufficient -- software-based measurement can be conducted instead.
LSPの場合、LSPエンドポイント間だけでなく、中間ノードとの間での損失または遅延を測定することが望ましい場合があります。これは、測定メッセージを中間ノードにターゲットにするときに、外側LSEのライブ（TTL）フィールドを適切に設定することにより、原則として実行できます。ただし、ハードウェアアシスト測定が使用されている場合、この手順は失敗する可能性があります。これは、中間ノードによるパケットの処理がTTL有効期限の結果としてのみ発生し、TTL有効期限の処理が後の処理段階で発生する可能性があるためハードウェアアシスト測定関数よりも実装。中間ノードに測定を実行する動機は、多くの場合、LSPで検出された問題をローカライズしようとする試みです。この場合、中間ノードがハードウェアアシスト測定を実行できない場合、代わりに、より正確ではなく、通常は十分なソフトウェアベースの測定を実行できます。
The overview of the bidirectional measurement process presented in Section 2 is also applicable when the transmit and receive interfaces at A or B differ from one another. Some additional considerations, however, do apply in this case:
セクション2に示されている双方向測定プロセスの概要は、AまたはBの送信および受信インターフェイスが互いに異なる場合にも適用されます。ただし、この場合、いくつかの追加の考慮事項が適用されます。
o If different clocks are associated with transmit and receive processing, these clocks must be synchronized in order to compute the two-way delay.
o 異なるクロックが送信および受信処理に関連付けられている場合、これらのクロックは双方向遅延を計算するために同期する必要があります。
o The DM protocol specified in this document requires that the timestamp formats used by the interfaces that receive a DM query and transmit a DM response agree.
o このドキュメントで指定されたDMプロトコルでは、DMクエリを受信してDM応答を送信するインターフェイスで使用されるタイムスタンプ形式が同意する必要があります。
o The LM protocol specified in this document supports both 32-bit and 64-bit counter sizes, but the use of 32-bit counters at any of the up to four interfaces involved in an LM operation will result in 32-bit LM calculations for both directions of the channel.
o このドキュメントで指定されたLMプロトコルは、32ビットと64ビットの両方のカウンターサイズをサポートしていますが、LM操作に関与する最大4つのインターフェイスで32ビットカウンターを使用すると、両方の32ビットLM計算が発生します。チャネルの方向。
In some circumstances, it may be desirable to carry out the final measurement computation at an external post-processing device dedicated to the purpose. This can be achieved in supporting implementations by, for example, configuring the querier, in the case of a bidirectional measurement session, to forward each response it receives to the post-processor via any convenient protocol. The unidirectional case can be handled similarly through configuration of the receiver or by including an instruction in query messages for the receiver to respond out-of-band to the appropriate return address.
状況によっては、目的専用の外部後処理デバイスで最終測定計算を実行することが望ましい場合があります。これは、たとえば、双方向測定セッションの場合にクエリエを構成することにより、実装をサポートすることで実現できます。単方向のケースは、受信機の構成を通じて、または受信機のクエリメッセージに命令を適切な返品アドレスに帯域外に応答するように含めることにより、同様に処理できます。
Post-processing devices may have the ability to store measurement data for an extended period and to generate a variety of useful statistics from them. External post-processing also allows the measurement process to be completely stateless at the querier and responder.
後処理デバイスには、測定データを長期間保存し、それらからさまざまな有用な統計を生成する機能がある場合があります。また、外部後処理により、測定プロセスはクエリエとレスポンダーで完全にステートレスになります。
The summary of loss measurement at the beginning of Section 2 made reference to the "count of packets" transmitted and received over a channel. If the counted packets are the packets flowing over the channel in the data plane, the loss measurement is said to operate in "direct mode". If, on the other hand, the counted packets are selected control packets from which the approximate loss characteristics of the channel are being inferred, the loss measurement is said to operate in "inferred mode".
セクション2の開始時の損失測定の概要は、チャネルを介して送信され、受信された「パケットの数」を参照しました。カウントされたパケットがデータプレーン内のチャネル上に流れるパケットである場合、損失測定は「ダイレクトモード」で動作すると言われています。一方、カウントされたパケットが選択されたコントロールパケットである場合、チャネルのおおよその損失特性が推測されている場合、損失測定は「推測モード」で動作すると言われています。
Direct LM has the advantage of being able to provide perfect loss accounting when it is available. There are, however, several constraints associated with direct LM.
Direct LMには、利用可能なときに完全な損失会計を提供できるという利点があります。ただし、直接LMに関連するいくつかの制約があります。
For accurate direct LM to occur, packets must not be sent between the time the transmit count for an outbound LM message is determined and the time the message is actually transmitted. Similarly, packets must not be received and processed between the time an LM message is received and the time the receive count for the message is determined. If these "synchronization conditions" do not hold, the LM message counters will not reflect the true state of the data plane, with the result that, for example, the receive count of B may be greater than the transmit count of A, and attempts to compute loss by taking the difference will yield an invalid result. This requirement for synchronization between LM message counters and the data plane may require special support from hardware-based forwarding implementations.
正確な直接LMが発生するには、アウトバウンドLMメッセージの送信カウントが決定されるまでにパケットを送信してはなりません。メッセージが実際に送信されるまでです。同様に、LMメッセージが受信されるまでの間、メッセージの受信カウントが決定されるまでの間に、パケットを受信および処理する必要はありません。これらの「同期条件」が保持されない場合、LMメッセージカウンターはデータプレーンの真の状態を反映しておらず、たとえば、Bの受信数がAの送信数よりも大きく、試行差を取得して損失を計算すると、無効な結果が得られます。LMメッセージカウンターとデータプレーン間の同期に関するこの要件には、ハードウェアベースの転送の実装からの特別なサポートが必要になる場合があります。
A limitation of direct LM is that it may be difficult or impossible to apply in cases where the channel is an LSP and the LSP label at the receiver is either nonexistent or fails to identify a unique sending node. The first case happens when Penultimate Hop Popping (PHP) is used on the LSP, and the second case generally holds for LSPs based on the Label Distribution Protocol (LDP) [RFC5036] as opposed to, for example, those based on Traffic Engineering extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209]. These conditions may make it infeasible for the receiver to identify the data-plane packets associated with a particular source and LSP in order to count them, or to infer the source and LSP context associated with an LM message. Direct LM is also vulnerable to disruption in the event that the ingress or egress interface associated with an LSP changes during the LSP's lifetime.
直接LMの制限は、チャネルがLSPであり、レシーバーのLSPラベルが存在しない場合、または一意の送信ノードを識別できない場合に適用することが困難または不可能である可能性があることです。最初のケースは、最後から2番目のホップポップ（PHP）がLSPで使用され、2番目のケースは通常、ラベル分布プロトコル（LDP）[RFC5036]に基づいてLSPを保持します。リソース予約プロトコル（RSVP-TE）[RFC3209]。これらの条件により、受信者が特定のソースとLSPに関連付けられたデータプレーンパケットをカウントするために、またはLMメッセージに関連付けられたソースとLSPコンテキストを推測することを実行できなくなる可能性があります。直接LMは、LSPの寿命の間にLSPに関連するイングレスまたは出力インターフェイスが変化した場合にも、混乱に対して脆弱です。
Inferred LM works in the same manner as direct LM except that the counted packets are special control packets, called test messages, generated by the sender. Test messages may be either packets explicitly constructed and used for LM or packets with a different primary purpose, such as those associated with a Bidirectional Forwarding Detection (BFD) [RFC5884] session.
推定されたLMは、カウントされたパケットが送信者によって生成されたテストメッセージと呼ばれる特別な制御パケットであることを除いて、直接LMと同じ方法で機能します。テストメッセージは、双方向転送検出（BFD）[RFC5884]セッションに関連するものなど、LMまたは異なる主要な目的を持つLMまたはパケットに明示的に構築され、使用されるパケットのいずれかです。
The synchronization conditions discussed above for direct LM also apply to inferred LM, the only difference being that the required synchronization is now between the LM counters and the test message generation process. Protocol and application designers MUST take these synchronization requirements into account when developing tools for inferred LM, and make their behavior in this regard clear to the user.
直接LMに関して上記で議論した同期条件は推定LMにも適用され、唯一の違いは、必要な同期がLMカウンタとテストメッセージ生成プロセスとの間にあることです。プロトコルおよびアプリケーションの設計者は、推定LMのためのツールを開発する際にこれらの同期要件を考慮しなければならず (MUST)、この点に関する動作をユーザーに対して明確にしなければなりません。
Inferred LM provides only an approximate view of the loss level associated with a channel, but is typically applicable even in cases where direct LM is not.
推測されたLMは、チャネルに関連付けられた損失レベルの近似ビューのみを提供しますが、通常、直接LMがそうでない場合でも適用可能です。
In the case of direct LM, where data-plane packets are counted, there are different possibilities for which kinds of packets are included in the count and which are excluded. The set of packets counted for LM is called the "loss measurement scope". As noted above, one factor affecting the LM scope is whether all data packets are counted or only those belonging to a particular traffic class. Another is whether various "auxiliary" flows associated with a data channel are counted, such as packets flowing over the G-ACh. Implementations MUST make their supported LM scopes clear to the user, and care must be taken to ensure that the scopes of the channel endpoints agree.
データプレーンのパケットがカウントされる直接LMの場合、どのような種類のパケットがカウントに含まれ、除外されるかについて様々な可能性があります。LMのためにカウントされるパケットの集合は「損失測定スコープ」と呼ばれます。上記のように、LMスコープに影響を与える要因の1つは、すべてのデータパケットがカウントされるか、あるいは特定のトラフィッククラスに属するもののみがカウントされるかです。もう1つは、G-ACh 上を流れるパケットなど、データチャネルに関連付けられた様々な「補助」フローがカウントされるかどうかです。実装は、サポートするLMスコープをユーザーに対して明確にしなければならず (MUST)、チャネルのエンドポイント間でスコープが一致するように注意を払わなければなりません。
The delay measurement procedures described in this document are designed to facilitate hardware-assisted measurement and to function in the same way whether or not such hardware assistance is used. The measurement accuracy will be determined by how closely the transmit and receive timestamps correspond to actual packet departure and arrival times.
このドキュメントで説明されている遅延測定手順は、ハードウェア支援測定を促進し、そのようなハードウェア支援が使用されるかどうか同じ方法で機能するように設計されています。測定精度は、送信および受信のタイムスタンプが実際のパケットの出発時間と到着時間にどの程度密接に対応するかによって決定されます。
As noted in Section 2.4, measurement of one-way delay requires clock synchronization between the devices involved, while two-way delay measurement does not involve direct comparison between non-local timestamps and thus has no synchronization requirement. The measurement accuracy will be limited by the quality of the local clock and, in the case of one-way delay measurement, by the quality of the synchronization.
セクション2.4で述べたように、一元配置遅延の測定には、関与するデバイス間のクロック同期が必要ですが、双方向遅延測定には非ローカルタイムスタンプ間の直接的な比較は含まれないため、同期要件はありません。測定精度は、ローカルクロックの品質、および一元配置遅延測定の場合、同期の品質によって制限されます。
There are two significant timestamp formats in common use: the timestamp format of the Network Time Protocol (NTP), described in [RFC5905], and the timestamp format used in the IEEE 1588 Precision Time Protocol (PTP) [IEEE1588].
一般的に使用される2つの重要なタイムスタンプ形式があります。[RFC5905]で説明されているネットワークタイムプロトコル（NTP）のタイムスタンプ形式と、IEEE 1588 Precision Time Protocol（PTP）[IEEE1588]で使用されるタイムスタンプ形式です。
The NTP format has the advantages of wide use and long deployment in the Internet, and it was specifically designed to make the computation of timestamp differences as simple and efficient as possible. On the other hand, there is now also a significant deployment of equipment designed to support the PTP format.
NTP形式には、インターネットでの幅広い使用と長い展開の利点があり、タイムスタンプの違いを可能な限りシンプルで効率的に計算するように特別に設計されています。一方、PTP形式をサポートするように設計された機器の重要な展開もあります。
The approach taken in this document is therefore to include in DM messages fields that identify the timestamp formats used by the two devices involved in a DM operation. This implies that a node attempting to carry out a DM operation may be faced with the problem of computing with and possibly reconciling different timestamp formats. To ensure interoperability, it is necessary that support of at least one timestamp format is mandatory. This specification requires the support of the IEEE 1588 PTP format. Timestamp format support requirements are discussed in detail in Section 3.4.
したがって、このドキュメントで取得したアプローチは、DM操作に関与する2つのデバイスで使用されるタイムスタンプ形式を識別するDMメッセージフィールドに含めることです。これは、DM操作を実行しようとするノードが、異なるタイムスタンプ形式を計算し、場合によっては調整する問題に直面する可能性があることを意味します。相互運用性を確保するには、少なくとも1つのタイムスタンプ形式のサポートが必須である必要があります。この仕様には、IEEE 1588 PTP形式のサポートが必要です。タイムスタンプ形式のサポート要件については、セクション3.4で詳しく説明します。
Loss Measurement and Delay Measurement messages flow over the MPLS Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet containing an LM or DM message contains an MPLS label stack, with the G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by an Associated Channel Header (ACH), which identifies the message type, and the message body follows the ACH.
損失測定および遅延測定メッセージは、MPLSジェネリック関連チャネル（g-ach）[RFC5586]を介して流れます。したがって、LMまたはDMメッセージを含むパケットには、MPLSラベルスタックが含まれ、スタックの下部にG-achラベル（GAL）が含まれています。GALの後に関連するチャネルヘッダー（ACH）が続き、メッセージタイプを識別し、メッセージ本文はACHに従います。
This document defines the following ACH Channel Types:
このドキュメントは、次のACHチャネルタイプを定義しています。
MPLS Direct Loss Measurement (DLM) MPLS Inferred Loss Measurement (ILM) MPLS Delay Measurement (DM) MPLS Direct Loss and Delay Measurement (DLM+DM) MPLS Inferred Loss and Delay Measurement (ILM+DM)
MPLS直接損失測定（DLM）MPLS推定損失測定（ILM）MPLS遅延測定（DM）MPLS直接損失および遅延測定（DLM DM）MPLS推定損失および遅延測定（ILM DM）
The message formats for direct and inferred LM are identical. The formats of the DLM+DM and ILM+DM messages are also identical.
直接および推測されたLMのメッセージ形式は同一です。DLM DMおよびILM DMメッセージの形式も同一です。
For these channel types, the ACH SHALL NOT be followed by the ACH TLV Header defined in [RFC5586].
これらのチャネルタイプでは、ACH の後に [RFC5586] で定義されている ACH TLV ヘッダーを続けてはなりません (SHALL NOT)。
The fixed-format portion of a message MAY be followed by a block of Type-Length-Value (TLV) fields. The TLV block provides an extensible way of attaching subsidiary information to LM and DM messages. Several such TLV fields are defined below.
メッセージの固定フォーマット部分の後には、Type-Length-Value（TLV）フィールドのブロックが続いてもよいです (MAY)。TLVブロックは、LMおよびDMメッセージに補助情報を付加するための拡張可能な方法を提供します。そのようなTLVフィールドのいくつかを以下で定義します。
All integer values for fields defined in this document SHALL be encoded in network byte order.
本文書で定義されているフィールドのすべての整数値は、ネットワークバイトオーダーで符号化されなければなりません (SHALL)。
The format of a Loss Measurement message, which follows the Associated Channel Header (ACH), is as follows:
関連するチャネルヘッダー（ACH）に続く損失測定メッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DFlags| OTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loss Measurement Message Format
損失測定メッセージ形式
Reserved fields MUST be set to 0 and ignored upon receipt. The possible values for the remaining fields are as follows.
Reserved（予約済み）フィールドは 0 に設定されなければならず (MUST)、受信時に無視されなければなりません。残りのフィールドの取り得る値は以下の通りです。
Field Meaning
--------------------- -----------------------------------------------
Version Protocol version
Flags Message control flags
Control Code Code identifying the query or response type
Message Length Total length of this message in bytes
Data Format Flags Flags specifying the format of message data
(DFlags)
Origin Timestamp Format of the Origin Timestamp field
Format (OTF)
Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier
Differentiated Differentiated Services Code Point (DSCP) being
Services (DS) Field measured
Origin Timestamp 64-bit field for query message transmission
timestamp
Counter 1-4 64-bit fields for LM counter values
TLV Block Optional block of Type-Length-Value fields
The possible values for these fields are as follows.
これらのフィールドの可能な値は次のとおりです。
Version: Currently set to 0.
バージョン：現在0に設定しています。
Flags: The format of the Flags field is shown below.
フラグ：フラグフィールドの形式を以下に示します。
+-+-+-+-+
|R|T|0|0|
+-+-+-+-+
Loss Measurement Message Flags
損失測定メッセージフラグ
The meanings of the flag bits are:
フラグビットの意味は次のとおりです。
R: Query/Response indicator. Set to 0 for a Query and 1 for a Response.
R：クエリ/応答インジケーター。クエリの場合は0、応答の場合は1を設定します。
T: Traffic-class-specific measurement indicator. Set to 1 when the measurement operation is scoped to packets of a particular traffic class (DSCP value), and 0 otherwise. When set to 1, the DS field of the message indicates the measured traffic class.
T：トラフィッククラス固有の測定インジケーター。測定操作が特定のトラフィッククラス（DSCP値）のパケットにスコープされ、それ以外の場合は0に設定されます。1に設定すると、メッセージのDSフィールドは測定されたトラフィッククラスを示します。
0: Set to 0.
0：0に設定します。
Control Code: Set as follows according to whether the message is a Query or a Response as identified by the R flag.
コントロールコード：メッセージがRフラグで識別されたクエリまたは応答であるかどうかに従って次のように設定します。
For a Query:
クエリの場合：
0x0: In-band Response Requested. Indicates that this query has been sent over a bidirectional channel and the response is expected over the same channel.
0x0：インバンドの応答が要求されました。このクエリが双方向チャネルを介して送信され、同じチャネルで応答が予想されることを示します。
0x1: Out-of-band Response Requested. Indicates that the response should be sent via an out-of-band channel.
0x1：バンド外の応答が要求されました。応答がバンド外チャネルを介して送信されるべきであることを示します。
0x2: No Response Requested. Indicates that no response to the query should be sent. This mode can be used, for example, if all nodes involved are being controlled by a Network Management System.
0x2：応答は要求されません。クエリへの応答が送信されないことを示します。このモードは、たとえば、関係するすべてのノードがネットワーク管理システムによって制御されている場合に使用できます。
For a Response:
応答について：
Codes 0x0-0xF are reserved for non-error responses. Error response codes imply that the response does not contain valid measurement data.
コード0x0-0xfは、非誤差応答のために予約されています。エラー応答コードは、応答に有効な測定データが含まれていないことを意味します。
0x1: Success. Indicates that the operation was successful.
0x1：成功。操作が成功したことを示します。
0x2: Notification - Data Format Invalid. Indicates that the query was processed, but the format of the data fields in this response may be inconsistent. Consequently, these data fields MUST NOT be used for measurement.
0x2: 通知 - データ形式が無効です（Notification - Data Format Invalid）。クエリが処理されたものの、この応答内のデータフィールドの形式に不整合がある可能性があることを示します。したがって、これらのデータフィールドを測定に使用してはなりません (MUST NOT)。
0x3: Notification - Initialization in Progress. Indicates that the query was processed but this response does not contain valid measurement data because the responder's initialization process has not completed.
0x3：通知 - 進行中の初期化。クエリが処理されたことを示しますが、レスポンダーの初期化プロセスが完了していないため、この応答には有効な測定データが含まれていません。
0x4: Notification - Data Reset Occurred. Indicates that the query was processed, but a reset has recently occurred that may render the data in this response inconsistent relative to earlier responses.
0x4：通知 - データリセットが発生しました。クエリが処理されたことを示しますが、最近リセットが発生し、この応答のデータが以前の応答と比較して矛盾する可能性があります。
0x5: Notification - Resource Temporarily Unavailable. Indicates that the query was processed, but resources were unavailable to complete the requested measurement and that, consequently, this response does not contain valid measurement data.
0x5：通知 - リソースは一時的に利用できません。クエリが処理されたことを示しますが、要求された測定を完了するためにリソースが利用できず、その結果、この応答には有効な測定データが含まれていないことを示します。
0x10: Error - Unspecified Error. Indicates that the operation failed for an unspecified reason.
0x10：エラー - 不特定エラー。不特定の理由で操作が失敗したことを示します。
0x11: Error - Unsupported Version. Indicates that the operation failed because the protocol version supplied in the query message is not supported.
0x11：エラー - サポートされていないバージョン。クエリメッセージに提供されたプロトコルバージョンがサポートされていないため、操作が失敗したことを示します。
0x12: Error - Unsupported Control Code. Indicates that the operation failed because the Control Code requested an operation that is not available for this channel.
0x12：エラー - サポートされていないコントロールコード。制御コードがこのチャネルで利用できない操作を要求したため、操作が失敗したことを示します。
0x13: Error - Unsupported Data Format. Indicates that the operation failed because the data format specified in the query is not supported.
0x13：エラー - サポートされていないデータ形式。クエリで指定されたデータ形式がサポートされていないため、操作が失敗したことを示します。
0x14: Error - Authentication Failure. Indicates that the operation failed because the authentication data supplied in the query was missing or incorrect.
0x14：エラー - 認証障害。クエリで提供された認証データが欠落または正しくないため、操作が失敗したことを示します。
0x15: Error - Invalid Destination Node Identifier. Indicates that the operation failed because the Destination Node Identifier supplied in the query is not an identifier of this node.
0x15：エラー - 無効な宛先ノード識別子。クエリで提供された宛先ノード識別子がこのノードの識別子ではないため、操作が失敗したことを示します。
0x16: Error - Connection Mismatch. Indicates that the operation failed because the channel identifier supplied in the query did not match the channel over which the query was received.
0x16：エラー - 接続の不一致。クエリで提供されたチャネル識別子がクエリが受信されたチャネルと一致しなかったため、操作が失敗したことを示します。
0x17: Error - Unsupported Mandatory TLV Object. Indicates that the operation failed because a TLV Object received in the query and marked as mandatory is not supported.
0x18: Error - Unsupported Query Interval. Indicates that the operation failed because the query message rate exceeded the configured threshold.
0x18：エラー - サポートされていないクエリ間隔。クエリメッセージレートが構成されたしきい値を超えたため、操作が失敗したことを示します。
0x19: Error - Administrative Block. Indicates that the operation failed because it has been administratively disallowed.
0x19：エラー - 管理ブロック。操作が行政的に許可されているために操作が失敗したことを示します。
0x1A: Error - Resource Unavailable. Indicates that the operation failed because node resources were not available.
0x1a：エラー - リソースは利用できません。ノードリソースが利用できなかったため、操作が失敗したことを示します。
0x1B: Error - Resource Released. Indicates that the operation failed because node resources for this measurement session were administratively released.
0x1B：エラー - リソースがリリースされました。この測定セッションのノードリソースが管理上リリースされたため、操作が失敗したことを示します。
0x1C: Error - Invalid Message. Indicates that the operation failed because the received query message was malformed.
0x1C：エラー - 無効なメッセージ。受信したクエリメッセージが奇形であるため、操作が失敗したことを示します。
0x1D: Error - Protocol Error. Indicates that the operation failed because a protocol error was found in the received query message.
0x1D：エラー - プロトコルエラー。受信クエリメッセージでプロトコルエラーが見つかったため、操作が失敗したことを示します。
Message Length: Set to the total length of this message in bytes, including the Version, Flags, Control Code, and Message Length fields as well as the TLV Block, if any.
メッセージの長さ：バージョン、フラグ、コントロールコード、メッセージの長さフィールド、およびTLVブロックがある場合など、このメッセージの全長にバイトで設定されます。
DFlags: The format of the DFlags field is shown below.
DFLAGS：DFLAGSフィールドの形式を以下に示します。
+-+-+-+-+
|X|B|0|0|
+-+-+-+-+
Data Format Flags
データ形式フラグ
The meanings of the DFlags bits are:
DFLAGSビットの意味は次のとおりです。
X: Extended counter format indicator. Indicates the use of extended (64-bit) counter values. Initialized to 1 upon creation (and prior to transmission) of an LM Query and copied from an LM Query to an LM response. Set to 0 when the LM message is transmitted or received over an interface that writes 32-bit counter values.
X：拡張カウンターフォーマットインジケーター。拡張（64ビット）カウンター値の使用を示します。LMクエリの作成時（および送信前）に1に初期化され、LMクエリからLM応答にコピーされました。LMメッセージが32ビットのカウンター値を書き込むインターフェイスを介して送信または受信されるときに0に設定します。
B: Octet (byte) count. When set to 1, indicates that the Counter 1-4 fields represent octet counts. The octet count applies to all packets within the LM scope (Section 2.9.9), and the octet count of a packet sent or received over a channel includes the total length of that packet (but excludes headers, labels, or framing of the channel itself). When set to 0, indicates that the Counter 1-4 fields represent packet counts.
B：Octet（BYTE）カウント。1に設定すると、カウンター1-4フィールドがオクテットカウントを表すことを示します。Octetカウントは、LMスコープ内のすべてのパケット（セクション2.9.9）に適用され、チャンネルで送信または受信されたパケットのオクテットカウントには、そのパケットの全長が含まれます（ただし、チャネルのヘッダー、ラベル、またはフレーミングは除外されます。自体）。0に設定すると、カウンター1-4フィールドがパケット数を表すことを示します。
0: Set to 0.
0：0に設定します。
Origin Timestamp Format: The format of the Origin Timestamp field, as specified in Section 3.4.
Origin Timestamp形式：セクション3.4で指定されているオリジンタイムスタンプフィールドの形式。
Session Identifier: Set arbitrarily in a query and copied in the response, if any. This field uniquely identifies a measurement operation (also called a session) that consists of a sequence of messages. All messages in the sequence have the same Session Identifier.
セッション識別子：クエリで任意に設定し、応答でコピーされます。このフィールドは、一連のメッセージで構成される測定操作（セッションとも呼ばれます）を一意に識別します。シーケンス内のすべてのメッセージには、同じセッション識別子があります。
SHOULD be set to the Class Selector Codepoint [RFC2474] that corresponds to that Traffic Class. When the T flag is set to 0, the value of this field is arbitrary, and the field can be considered part of the Session Identifier.
そのトラフィッククラスに対応するクラスセレクタコードポイント [RFC2474] に設定すべきです (SHOULD)。T フラグが 0 に設定されている場合、このフィールドの値は任意であり、フィールドはセッション識別子の一部とみなすことができます。
Origin Timestamp: Timestamp recording the transmit time of the query message.
Origin Timestamp：クエリメッセージの送信時間の記録タイムスタンプ。
Counter 1-4: Referring to Section 2.2, when a query is sent from A, Counter 1 is set to A_TxP and the other counter fields are set to 0. When the query is received at B, Counter 2 is set to B_RxP. At this point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4, and re-initializes Counter 1 and Counter 2 to 0. When B transmits the response, Counter 1 is set to B_TxP. When the response is received at A, Counter 2 is set to A_RxP.
カウンター1-4：セクション2.2を参照して、aからクエリが送信される場合、カウンター1はA_TxPに設定され、他のカウンターフィールドは0に設定されます。クエリがBで受信されると、カウンター2はB_RxPに設定されます。この時点で、Bはカウンター1からカウンター3、カウンター2からカウンター4にコピーし、カウンター1とカウンター2から0を再発明します。Bが応答を送信すると、カウンター1はB_TxPに設定されます。応答がAで受信されると、カウンター2がA_RxPに設定されます。
The mapping of counter types such as A_TxP to the Counter 1-4 fields is designed to ensure that transmit counter values are always written at the same fixed offset in the packet, and likewise for receive counters. This property may be important for hardware processing.
カウンター1-4フィールドへのA_TxPなどのカウンタータイプのマッピングは、送信カウンター値が常にパケット内の同じ固定オフセットで、同様に受信カウンター用に記述されるように設計されています。このプロパティは、ハードウェア処理にとって重要かもしれません。
When a 32-bit counter value is written to one of the counter fields, that value SHALL be written to the low-order 32 bits of the field; the high-order 32 bits of the field MUST, in this case, be set to 0.
32ビットのカウンタ値がカウンタフィールドの1つに書き込まれる場合、その値はフィールドの下位32ビットに書き込まれなければなりません (SHALL)。この場合、フィールドの上位32ビットは 0 に設定されなければなりません (MUST)。
TLV Block: Zero or more TLV fields.
TLVブロック：ゼロ以上のTLVフィールド。
The format of a Delay Measurement message, which follows the Associated Channel Header (ACH), is as follows:
関連するチャネルヘッダー（ACH）に続く遅延測定メッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Delay Measurement Message Format
測定メッセージ形式の遅延
The meanings of the fields are summarized in the following table.
フィールドの意味を次の表にまとめます。
Field Meaning
--------------------- -----------------------------------------------
Version Protocol version
Flags Message control flags
Control Code Code identifying the query or response type
Message Length Total length of this message in bytes
QTF Querier timestamp format
RTF Responder timestamp format
RPTF Responder's preferred timestamp format
Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier
Differentiated Differentiated Services Code Point (DSCP) being
Services (DS) Field measured
Timestamp 1-4 64-bit timestamp values
TLV Block Optional block of Type-Length-Value fields
Reserved fields MUST be set to 0 and ignored upon receipt. The possible values for the remaining fields are as follows.
Reserved（予約済み）フィールドは 0 に設定されなければならず (MUST)、受信時に無視されなければなりません。残りのフィールドの取り得る値は以下の通りです。
Version: Currently set to 0.
バージョン：現在0に設定しています。
Flags: As specified in Section 3.1. The T flag in a DM message is set to 1.
フラグ：セクション3.1で指定されています。DMメッセージのTフラグは1に設定されています。
Control Code: As specified in Section 3.1.
制御コード：セクション3.1で指定されています。
Message Length: Set to the total length of this message in bytes, including the Version, Flags, Control Code, and Message Length fields as well as the TLV Block, if any.
メッセージの長さ：バージョン、フラグ、コントロールコード、メッセージの長さフィールド、およびTLVブロックがある場合など、このメッセージの全長にバイトで設定されます。
Querier Timestamp Format: The format of the timestamp values written by the querier, as specified in Section 3.4.
Querierタイムスタンプ形式：セクション3.4で指定されているように、クエリエによって記述されたタイムスタンプ値の形式。
Responder Timestamp Format: The format of the timestamp values written by the responder, as specified in Section 3.4.
レスポンダータイムスタンプ形式：セクション3.4で指定されているように、レスポンダーによって記述されたタイムスタンプ値の形式。
Responder's Preferred Timestamp Format: The timestamp format preferred by the responder, as specified in Section 3.4.
レスポンダーの優先タイムスタンプ形式：セクション3.4で指定されているように、レスポンダーが好むタイムスタンプ形式。
Session Identifier: As specified in Section 3.1.
セッション識別子：セクション3.1で指定されているとおり。
DS: As specified in Section 3.1.
DS：セクション3.1で指定されています。
Timestamp 1-4: Referring to Section 2.4, when a query is sent from A, Timestamp 1 is set to T1 and the other timestamp fields are set to 0. When the query is received at B, Timestamp 2 is set to T2. At this point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0. When B transmits the response, Timestamp 1 is set to T3. When the response is received at A, Timestamp 2 is set to T4. The actual formats of the timestamp fields written by A and B are indicated by the Querier Timestamp Format and Responder Timestamp Format fields respectively.
タイムスタンプ1-4：セクション2.4を参照して、クエリがAから送信される場合、タイムスタンプ1はT1に設定され、他のタイムスタンプフィールドは0に設定されます。この時点で、Bはタイムスタンプ1をタイムスタンプ3に、タイムスタンプ2からタイムスタンプ4にコピーし、タイムスタンプ1とタイムスタンプ2から0を再発明します。応答がAで受信されると、タイムスタンプ2がT4に設定されます。AとBによって記述されたタイムスタンプフィールドの実際の形式は、それぞれクエリのタイムスタンプ形式と応答者のタイムスタンプ形式のフィールドで示されています。
The mapping of timestamps to the Timestamp 1-4 fields is designed to ensure that transmit timestamps are always written at the same fixed offset in the packet, and likewise for receive timestamps. This property is important for hardware processing.
タイムスタンプ1-4フィールドへのタイムスタンプのマッピングは、送信タイムスタンプが常にパケット内の同じ固定オフセットで記述され、同様にタイムスタンプを受信するために記述されるように設計されています。このプロパティは、ハードウェア処理にとって重要です。
TLV Block: Zero or more TLV fields.
TLVブロック：ゼロ以上のTLVフィールド。
The format of a combined Loss and Delay Measurement message, which follows the Associated Channel Header (ACH), is as follows:
関連するチャネルヘッダー（ACH）に続く喪失測定メッセージと遅延測定メッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DFlags| QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loss/Delay Measurement Message Format
損失/遅延測定メッセージ形式
The fields of this message have the same meanings as the corresponding fields in the LM and DM message formats, except that the roles of the OTF and Origin Timestamp fields for LM are here played by the QTF and Timestamp 1 fields, respectively.
このメッセージのフィールドは、LMおよびDMメッセージ形式の対応するフィールドと同じ意味を持っていますが、LMのOTFおよびOrigin Timestampフィールドの役割は、それぞれQTFとTimestamp 1フィールドがプレイしていることを除きます。
The following timestamp format field values are specified in this document:
次のタイムスタンプ形式のフィールド値は、このドキュメントで指定されています。
0: Null timestamp format. This value is a placeholder indicating that the timestamp field does not contain a meaningful timestamp.
0：nullタイムスタンプ形式。この値は、タイムスタンプフィールドに意味のあるタイムスタンプが含まれていないことを示すプレースホルダーです。
1: Sequence number. This value indicates that the timestamp field is to be viewed as a simple 64-bit sequence number. This provides a simple solution for applications that do not require a real absolute timestamp, but only an indication of message ordering; an example is LM exception detection.
1：シーケンス番号。この値は、タイムスタンプフィールドが単純な64ビットシーケンス番号と見なされることを示しています。これにより、実際の絶対タイムスタンプを必要としないアプリケーションに簡単なソリューションが提供されますが、メッセージの順序付けの兆候のみが提供されます。例は、LM例外検出です。
2: Network Time Protocol version 4 64-bit timestamp format [RFC5905]. This format consists of a 32-bit seconds field followed by a 32-bit fractional seconds field, so that it can be regarded as a fixed-point 64-bit quantity.
2：ネットワークタイムプロトコルバージョン4 64ビットタイムスタンプ形式[RFC5905]。この形式は、32ビット秒フィールドで構成され、その後32ビットの分数秒フィールドが続くため、固定点64ビット数量と見なすことができます。
3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time Protocol timestamp format [IEEE1588]. This truncated format consists of a 32-bit seconds field followed by a 32-bit nanoseconds field, and is the same as the IEEE 1588v1 timestamp format.
3：IEEE 1588-2008（1588v2）の低次64ビット（1588v2）Precision Time Protocol Timestamp形式[IEEE1588]。この切り捨てられた形式は、32ビット秒フィールドで構成され、その後32ビットナノ秒フィールドが続き、IEEE 1588V1タイムスタンプ形式と同じです。
Timestamp formats of n < 64 bits in size SHALL be encoded in the 64-bit timestamp fields specified in this document using the n high-order bits of the field. The remaining 64 - n low-order bits in the field SHOULD be set to 0 and MUST be ignored when reading the field.
サイズが n < 64 ビットのタイムスタンプ形式は、フィールドの上位 n ビットを使用して、本文書で指定されている64ビットのタイムスタンプフィールド内に符号化されなければなりません (SHALL)。フィールド内の残りの 64 - n 個の下位ビットは 0 に設定されるべきであり (SHOULD)、フィールドを読み取る際には無視されなければなりません (MUST)。
To ensure that it is possible to find an interoperable mode between implementations, it is necessary to select one timestamp format as the default. The timestamp format chosen as the default is the truncated IEEE 1588 PTP format (format code 3 in the list above); this format MUST be supported. The rationale for this choice is discussed in Appendix A. Implementations SHOULD also be capable of reading timestamps written in NTPv4 64-bit format and reconciling them internally with PTP timestamps for measurement purposes. Support for other timestamp formats is OPTIONAL.
実装間で相互運用可能なモードを見つけることができるようにするために、デフォルトとして1つのタイムスタンプ形式を選択する必要があります。デフォルトとして選択されたタイムスタンプ形式は、切り詰められた IEEE 1588 PTP 形式（上記リストの形式コード3）です。この形式はサポートされなければなりません (MUST)。この選択の根拠は付録Aで説明されています。実装は、NTPv4 64ビット形式で書き込まれたタイムスタンプを読み取り、測定目的でそれらを内部的に PTP タイムスタンプと整合させることができるべきでもあります (SHOULD)。他のタイムスタンプ形式のサポートは任意です (OPTIONAL)。
The implementation MUST make clear which timestamp formats it supports and the extent of its support for computation with and reconciliation of different formats for measurement purposes.
実装は、自身がサポートするタイムスタンプ形式と、測定目的での異なる形式による計算および整合のサポートの範囲を明確にしなければなりません (MUST)。
The TLV Block in LM and DM messages consists of zero or more objects with the following format:
LMおよびDMメッセージのTLVブロックは、次の形式のゼロ以上のオブジェクトで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
TLV形式
The Type and Length fields are each 8 bits long, and the Length field indicates the size in bytes of the Value field, which can therefore be up to 255 bytes long.
タイプと長さのフィールドはそれぞれ8ビットの長さであり、長さフィールドは値フィールドのバイトのサイズを示しているため、最大255バイトの長さになります。
The Type space is divided into Mandatory and Optional subspaces:
タイプスペースは、必須のサブスペースとオプションのサブスペースに分割されます。
Type Range Semantics
-------------- ---------
0-127 Mandatory
128-255 Optional
Upon receipt of a query message including an unrecognized mandatory TLV object, the recipient MUST respond with an Unsupported Mandatory TLV Object error code.
認識されない必須（mandatory）TLVオブジェクトを含むクエリメッセージを受信した場合、受信側は「サポートされていない必須TLVオブジェクト（Unsupported Mandatory TLV Object）」エラーコードで応答しなければなりません (MUST)。
The types defined are as follows:
定義されたタイプは次のとおりです。
Type Definition
-------------- ---------------------------------
Mandatory
0 Padding - copy in response
1 Return Address
2 Session Query Interval
3 Loopback Request
4-126 Unallocated
127 Experimental use
Optional
128 Padding - do not copy in response
129 Destination Address
130 Source Address
131-254 Unallocated
255 Experimental use
The two padding objects permit the augmentation of packet size; this is mainly useful for delay measurement. The type of padding indicates whether the padding supplied by the querier is to be copied to, or omitted from, the response. Asymmetrical padding may be useful when responses are delivered out-of-band or when different maximum transmission unit sizes apply to the two components of a bidirectional channel.
2つのパディングオブジェクトは、パケットサイズの増強を可能にします。これは主に遅延測定に役立ちます。パディングの種類は、クエリエが提供するパディングが応答にコピーされるのか、それとも省略されるかを示します。非対称のパディングは、応答が帯域外に配信される場合、または異なる最大透過ユニットサイズが双方向チャネルの2つのコンポーネントに適用される場合に役立ちます。
More than one padding object MAY be present, in which case they MUST be contiguous. The Value field of a padding object is arbitrary.
複数のパディングオブジェクトが存在してもよく (MAY)、その場合それらは連続していなければなりません (MUST)。パディングオブジェクトの Value フィールドは任意です。
The addressing objects have the following format:
アドレス指定オブジェクトには、次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addressing Object Format
オブジェクト形式のアドレス指定
The Address Family field indicates the type of the address, and it SHALL be set to one of the assigned values in the "IANA Address Family Numbers" registry.
Address Family フィールドはアドレスのタイプを示し、「IANA Address Family Numbers」レジストリ内の割り当てられた値の1つに設定されなければなりません (SHALL)。
The Source and Destination Address objects indicate the addresses of the sender and the intended recipient of the message, respectively. The Source Address of a query message SHOULD be used as the destination for an out-of-band response unless some other out-of-band response mechanism has been configured, and unless a Return Address object is present, in which case the Return Address specifies the target of the response. The Return Address object MUST NOT appear in a response.
Source Address および Destination Address オブジェクトは、それぞれメッセージの送信元アドレスおよび意図された受信側アドレスを示します。他の何らかの帯域外応答メカニズムが設定されておらず、かつ Return Address オブジェクトが存在しない限り、クエリメッセージの送信元アドレスを帯域外応答の宛先として使用しなければなりません (MUST)（Return Address オブジェクトが存在する場合、そのオブジェクトで指定されたアドレスが応答の宛先を指定します）。Return Address オブジェクトは応答メッセージ内に現れてはなりません (MUST NOT)。
The Loopback Request object, when included in a query, indicates a request that the query message be returned to the sender unmodified. This object has a Length of 0.
ループバック要求オブジェクトは、クエリに含まれている場合、クエリメッセージが変更されていない送信者に返されるという要求を示します。このオブジェクトの長さは0です。
Upon receiving the reflected query message back from the responder, the querier MUST NOT retransmit the message. Information that uniquely identifies the original query source, such as a Source Address object, can be included to enable the querier to differentiate one of its own loopback queries from a loopback query initiated by the far end.
レスポンダから反射されたクエリメッセージを受信し直した際、クエリアはそのメッセージを再送信してはなりません (MUST NOT)。クエリアが自身のループバッククエリと遠隔端によって開始されたループバッククエリを区別できるようにするために、Source Address オブジェクトなど、元のクエリ送信元を一意に識別する情報を含めることができます。
This object may be useful, for example, when the querier is interested only in the round-trip delay metric. In this case, no support for delay measurement is required at the responder at all, other than the ability to recognize a DM query that includes this object and return it unmodified.
このオブジェクトは、たとえば、クエリエが往復遅延メトリックにのみ興味を持っている場合に役立つ場合があります。この場合、このオブジェクトを含むDMクエリを認識し、修正されていない返品を認識する能力を除いて、レスポンダーでは遅延測定のサポートはまったく必要ありません。
The Value field of the Session Query Interval object is a 32-bit unsigned integer that specifies a time interval in milliseconds.
セッションクエリ間隔オブジェクトの値フィールドは、ミリ秒単位での時間間隔を指定する32ビットの署名整数です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Session Query >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
< Interval (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Session Query Interval Object Format
セッションクエリ間隔オブジェクト形式
This time interval indicates the interval between successive query messages in a specific measurement session. The purpose of the Session Query Interval (SQI) object is to enable the querier and responder of a measurement session to agree on a query rate. The procedures for handling this object SHALL be as follows:
この時間間隔は、特定の測定セッションにおける連続するクエリメッセージ間の間隔を示します。Session Query Interval（SQI）オブジェクトの目的は、測定セッションのクエリアとレスポンダがクエリレートについて合意できるようにすることです。このオブジェクトを処理する手順は以下の通りとします (SHALL):
1. The querier notifies the responder that it wishes to be informed of the responder's minimum query interval for this session by including the SQI object in its query messages, with a Value of 0.
1. Querierは、値が0のクエリメッセージにSQIオブジェクトを含めることにより、このセッションのResponderの最小クエリ間隔を通知することを望んでいることをResponderに通知します。
2. When the responder receives a query that includes an SQI object with a Value of 0, the responder includes an SQI object in the response with the Value set to the minimum query interval it supports for this session.
2. Responderが0の値を持つSQIオブジェクトを含むクエリを受信すると、Responderには、このセッションでサポートする最小クエリ間隔に設定された値を持つ応答にSQIオブジェクトが含まれます。
3. When the querier receives a response that includes an SQI object, it selects a query interval for the session that is greater than or equal to the Value specified in the SQI object and adjusts its query transmission rate accordingly, including in each subsequent query an SQI object with a Value equal to the selected query interval. Once a response to one of these subsequent queries has been received, the querier infers that the responder has been apprised of the selected query interval and MAY then stop including the SQI object in queries associated with this session.
3. クエリアは、SQIオブジェクトを含む応答を受信すると、SQIオブジェクトで指定された Value 以上のセッション用クエリ間隔を選択し、それに応じてクエリ送信レートを調整し、以後の各クエリに選択されたクエリ間隔と等しい Value を持つSQIオブジェクトを含めます。これらの以後のクエリの1つに対する応答が受信されたら、クエリアはレスポンダが選択されたクエリ間隔を認識したと判断し、このセッションに関連付けられたクエリへのSQIオブジェクトの挿入を停止してもよいです (MAY)。
Similar procedures allow the query rate to be changed during the course of the session by either the querier or the responder. For example, to inform the querier of a change in the minimum supported query interval, the responder begins including a corresponding SQI object in its responses, and the querier adjusts its query rate if necessary and includes a corresponding SQI object in its queries until a response is received.
同様の手順により、セッション中にクエリエまたはレスポンダーのいずれかによってクエリレートが変更されます。たとえば、サポートされているクエリ間隔の変更をクエリエに通知するために、応答者は応答に対応するSQIオブジェクトを含めて開始し、Querierは必要に応じてクエリレートを調整し、応答までクエリに対応するSQIオブジェクトを含めます受け取られます。
Shorter query intervals (i.e., higher query rates) provide finer measurement granularity at the expense of additional load on measurement endpoints and the network; see Section 6 for further discussion.
より短いクエリ間隔（つまり、より高いクエリレート）は、測定エンドポイントとネットワークに追加の負荷を犠牲にして、より細かい測定の粒度を提供します。詳細については、セクション6を参照してください。
A loss or delay measurement operation, also called a session, is controlled by the querier and consists of a sequence of query messages associated with a particular channel and a common set of measurement parameters. If the session parameters include a response request, then the receiving node or nodes will (under normal conditions) generate a response message for each query message received, and these responses are also considered part of the session. All query and response messages in a session carry a common session identifier.
セッションとも呼ばれる損失または遅延測定操作は、クエリエによって制御され、特定のチャネルに関連付けられた一連のクエリメッセージと共通の測定パラメーターセットで構成されます。セッションパラメーターに応答要求が含まれている場合、受信ノードまたはノードは（通常の条件下で）受信する各クエリメッセージの応答メッセージを生成し、これらの応答もセッションの一部と見なされます。セッション内のすべてのクエリと応答メッセージには、共通のセッション識別子が含まれます。
Measurement sessions are initiated at the discretion of the network operator and are terminated either at the operator's request or as the result of an error condition. A session may be as brief as a single message exchange, for example when a DM query is used by the operator to "ping" a remote node, or it may extend throughout the lifetime of the channel.
測定セッションは、ネットワークオペレーターの裁量で開始され、オペレーターの要求またはエラー状態の結果として終了します。セッションは、たとえばオペレーターがリモートノードを「ping」するためにDMクエリを使用する場合、またはチャネルの寿命全体にわたって拡張される場合など、単一のメッセージ交換と同じくらい短い場合があります。
When a session is initiated for which responses are requested, the querier SHOULD initialize a timer, called the SessionResponseTimeout, that indicates how long the querier will wait for a response before abandoning the session and notifying the user that a timeout has occurred. This timer persists for the lifetime of the session and is reset each time a response message for the session is received.
応答が要求されるセッションが開始された場合、クエリアは、セッションを破棄してタイムアウトが発生したことをユーザーに通知するまでにクエリアが応答を待機する時間を示す SessionResponseTimeout と呼ばれるタイマーを初期化すべきです (SHOULD)。このタイマーはセッションの有効期間中持続し、セッションに対する応答メッセージが受信されるたびにリセットされます。
When a query message is received that requests a response, a variety of exceptional conditions may arise that prevent the responder from generating a response that contains valid measurement data. Such conditions fall broadly into two classes: transient exceptions from which recovery is possible and fatal exceptions that require termination of the session. When an exception arises, the responder SHOULD generate a response with an appropriate Notification or Error control code according to whether the exception is, respectively, transient or fatal. When the querier receives an Error response, the session MUST be terminated and the user informed.
応答を要求するクエリメッセージが受信された際、レスポンダが有効な測定データを含む応答を生成することを妨げる様々な例外条件が発生する可能性があります。そのような条件は大きく2つのクラスに分類されます。すなわち、回復が可能な一時的（transient）例外と、セッションの終了を必要とする致命的（fatal）例外です。例外が発生した場合、レスポンダは、例外がそれぞれ一時的か致命的かに応じて、適切な Notification または Error 制御コードを含む応答を生成すべきです (SHOULD)。クエリアが Error 応答を受信した場合、セッションは終了されなければならず (MUST)、ユーザーに通知されなければなりません。
A common example of a transient exception occurs when a new session is initiated and the responder requires a period of time to become ready before it can begin providing useful responses. The response control code corresponding to this situation is Notification -
一時的な例外の一般的な例は、新しいセッションが開始され、レスポンダーが有用な応答を提供する前に準備をするために期間を必要とする場合に発生します。この状況に対応する応答制御コードは通知です -
Initialization in Progress. Typical examples of fatal exceptions are cases where the querier has requested a type of measurement that the responder does not support or where a query message is malformed.
進行中の初期化。致命的な例外の典型的な例は、クエリエがレスポンダーがサポートしていないタイプの測定を要求した場合、またはクエリメッセージが奇形である場合です。
When initiating a session, the querier SHOULD employ the Session Query Interval mechanism (Section 3.5.4) to establish a mutually agreeable query rate with the responder. Responders SHOULD employ rate-limiting mechanisms to guard against the possibility of receiving an excessive quantity of query messages.
セッションを開始する際、クエリアはレスポンダとの間で相互に合意可能なクエリレートを確立するために、Session Query Interval メカニズム（セクション3.5.4）を利用すべきです (SHOULD)。レスポンダは、過度な量のクエリメッセージを受信する可能性を防ぐために、レート制限メカニズムを採用すべきです (SHOULD)。
An LM operation for a particular channel consists of sending a sequence (LM[1], LM[2], ...) of LM query messages over the channel at a specific rate and processing the responses received, if any. As described in Section 2.2, the packet loss associated with the channel during the operation is computed as a delta between successive messages; these deltas can be accumulated to obtain a running total of the packet loss for the channel or be used to derive related metrics such as the average loss rate.
特定のチャネルのLM操作は、特定のレートでチャネル上のLMクエリメッセージのシーケンス（LM [1]、LM [2]、...）の送信と、受け取った応答（ある場合）の処理で構成されます。セクション2.2で説明されているように、操作中のチャネルに関連するパケット損失は、連続したメッセージ間のデルタとして計算されます。これらのデルタを蓄積して、チャネルのパケット損失の合計を実行するか、平均損失率などの関連するメトリックを導出するために使用できます。
The query message transmission rate MUST be sufficiently high, given the LM message counter size (which can be either 32 or 64 bits) and the speed and minimum packet size of the underlying channel, that the ambiguity condition noted in Section 2.2 cannot arise. In evaluating this rate, the implementation SHOULD assume that the counter size is 32 bits unless explicitly configured otherwise or unless (in the case of a bidirectional channel) all local and remote interfaces involved in the LM operation are known to be 64-bit-capable, which can be inferred from the value of the X flag in an LM response.
LMメッセージカウンタのサイズ（32ビットまたは64ビットのいずれか）ならびに下位チャネルの速度および最小パケットサイズを考慮して、セクション2.2で指摘した曖昧さの条件が発生し得ないように、クエリメッセージの送信レートは十分に高くなければなりません (MUST)。このレートを評価する際、別途明示的に設定されている場合や、（双方向チャネルの場合に）LM操作に関与するすべてのローカルおよびリモートインターフェースが64ビット対応であることが判明している（これはLM応答内の X フラグの値から推測可能）場合を除き、実装はカウンタサイズが32ビットであると仮定すべきです (SHOULD)。
When transmitting an LM Query, the Version field MUST be set to 0. The R flag MUST be set to 0. The T flag SHALL be set to 1 if, and only if, the measurement is specific to a particular traffic class, in which case the DS field SHALL identify that traffic class.
LMクエリを送信する際、Version フィールドは 0 に設定されなければなりません (MUST)。R フラグは 0 に設定されなければなりません (MUST)。測定が特定のトラフィッククラスに固有である場合にのみ T フラグを 1 に設定しなければならず (SHALL)、その場合 DS フィールドはそのトラフィッククラスを識別しなければなりません (SHALL)。
The X flag MUST be set to 1 if the transmitting interface writes 64-bit LM counters and otherwise MUST be set to 0 to indicate that 32-bit counters are written. The B flag SHALL be set to 1 to indicate that the counter fields contain octet counts or to 0 to indicate packet counts.
送信インターフェースが64ビットのLMカウンタを書き込む場合は X フラグを 1 に設定しなければならず (MUST)、そうでない場合は32ビットのカウンタが書き込まれることを示すために 0 に設定しなければなりません (MUST)。カウンタフィールドにオクテット数が含まれることを示すには B フラグを 1 に設定し、パケット数を示すには 0 に設定しなければなりません (SHALL)。
The Control Code field MUST be set to one of the values for Query messages listed in Section 3.1; if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: In-band Response Requested).
Control Code フィールドは、セクション3.1に記載されているクエリメッセージ用の値の1つに設定されなければなりません (MUST)。チャネルが単方向である場合、このフィールドを 0x0（クエリ: インバンド応答要求）に設定してはなりません (MUST NOT)。
The Session Identifier field can be set arbitrarily.
セッション識別子フィールドは任意に設定できます。
The Origin Timestamp field SHALL be set to the time at which this message is transmitted, and the Origin Timestamp Format field MUST be set to indicate its format, according to Section 3.4.
Origin Timestamp フィールドはこのメッセージが送信された時刻に設定されなければならず (SHALL)、Origin Timestamp Format フィールドはセクション3.4に従ってその形式を示すように設定されなければなりません (MUST)。
The Counter 1 field SHOULD be set to the total count of units (packets or octets, according to the B flag) transmitted over the channel prior to this LM Query, or to 0 if this is the beginning of a measurement session for which counter data is not yet available. The Counter 2 field MUST be set to 0. If a response was previously received in this measurement session, the Counter 1 and Counter 2 fields of the most recent such response MAY be copied to the Counter 3 and Counter 4 fields, respectively, of this query; otherwise, the Counter 3 and Counter 4 fields MUST be set to 0.
Counter 1 フィールドは、このLMクエリの前にチャネル上に送信されたユニット（B フラグに応じたパケット数またはオクテット数）の総数に設定されるべきであり (SHOULD)、カウンタデータがまだ利用できない測定セッションの開始時には 0 に設定されるべきです。Counter 2 フィールドは 0 に設定されなければなりません (MUST)。この測定セッションにおいて以前に応答を受信していた場合、直近のそのような応答の Counter 1 および Counter 2 フィールドを、本クエリの Counter 3 および Counter 4 フィールドにそれぞれコピーしてもよく (MAY)、そうでない場合は Counter 3 および Counter 4 フィールドを 0 に設定しなければなりません (MUST)。
Upon receipt of an LM Query message, the Counter 2 field SHOULD be set to the total count of units (packets or octets, according to the B flag) received over the channel prior to this LM Query. If the receiving interface writes 32-bit LM counters, the X flag MUST be set to 0.
LMクエリメッセージを受信すると、Counter 2 フィールドはこのLMクエリの前にチャネル上で受信されたユニット（B フラグに応じたパケット数またはオクテット数）の総数に設定されるべきです (SHOULD)。受信インターフェースが32ビットのLMカウンタを書き込む場合、X フラグは 0 に設定されなければなりません (MUST)。
At this point, the LM Query message must be inspected. If the Control Code field is set to 0x2 (No Response Requested), an LM Response message MUST NOT be transmitted. If the Control Code field is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band Response Requested), then an in-band or out-of-band response, respectively, SHOULD be transmitted unless this has been prevented by an administrative, security, or congestion control mechanism.
この時点で、LMクエリメッセージを検査しなければなりません。Control Code フィールドが 0x2（応答要求なし）に設定されている場合、LM応答メッセージを送信してはなりません (MUST NOT)。Control Code フィールドが 0x0（インバンド応答要求）または 0x1（アウトオブバンド応答要求）に設定されている場合、管理、セキュリティ、または輻輳制御メカニズムによって妨げられない限り、それぞれインバンドまたはアウトオブバンドの応答を送信すべきです (SHOULD)。
In the case of a fatal exception that prevents the requested measurement from being made, the error SHOULD be reported, via either a response, if one was requested, or else as a notification to the user.
要求された測定の実施を妨げる致命的な例外の場合、応答が要求されていた場合は応答を介して、あるいはユーザーへの通知として、エラーが報告されるべきです (SHOULD)。
When constructing a Response to an LM Query, the Version field MUST be set to 0. The R flag MUST be set to 1. The value of the T flag MUST be copied from the LM Query.
LMクエリへの応答を構築する際、Version フィールドは 0 に設定されなければなりません (MUST)。R フラグは 1 に設定されなければなりません (MUST)。T フラグの値はLMクエリからコピーされなければなりません (MUST)。
The X flag MUST be set to 0 if the transmitting interface writes 32-bit LM counters; otherwise, its value MUST be copied from the LM Query. The B flag MUST be copied from the LM Query.
送信インターフェースが32ビットのLMカウンタを書き込む場合、X フラグは 0 に設定されなければならず (MUST)、そうでない場合はその値をLMクエリからコピーしなければなりません (MUST)。B フラグはLMクエリからコピーされなければなりません (MUST)。
The Session Identifier, Origin Timestamp, and Origin Timestamp Format fields MUST be copied from the LM Query. The Counter 1 and Counter 2 fields from the LM Query MUST be copied to the Counter 3 and Counter 4 fields, respectively, of the LM Response.
Session Identifier、Origin Timestamp、および Origin Timestamp Format フィールドは、LMクエリからコピーされなければなりません (MUST)。LMクエリの Counter 1 および Counter 2 フィールドは、LM応答の Counter 3 および Counter 4 フィールドにそれぞれコピーされなければなりません (MUST)。
The Control Code field MUST be set to one of the values for Response messages listed in Section 3.1. The value 0x10 (Unspecified Error) SHOULD NOT be used if one of the other more specific error codes is applicable.
Control Code フィールドは、セクション3.1に記載されている応答メッセージ用の値の1つに設定されなければなりません (MUST)。より具体的な他のエラーコードのいずれかが適用可能な場合、値 0x10（不特定エラー: Unspecified Error）を使用すべきではありません (SHOULD NOT)。
If the response is transmitted in-band, the Counter 1 field SHOULD be set to the total count of units transmitted over the channel prior to this LM Response. If the response is transmitted out-of-band, the Counter 1 field MUST be set to 0. In either case, the Counter 2 field MUST be set to 0.
応答がインバンドで送信される場合、Counter 1 フィールドはこのLM応答の前にチャネル上に送信されたユニットの総数に設定されるべきです (SHOULD)。応答がアウトオブバンドで送信される場合、Counter 1 フィールドは 0 に設定されなければなりません (MUST)。いずれの場合も、Counter 2 フィールドは 0 に設定されなければなりません (MUST)。
Upon in-band receipt of an LM Response message, the Counter 2 field is set to the total count of units received over the channel prior to this LM Response. If the receiving interface writes 32-bit LM counters, the X flag is set to 0. (Since the life of the LM message in the network has ended at this point, it is up to the receiver whether these final modifications are made to the packet. If the message is to be forwarded on for external post-processing (Section 2.9.7), then these modifications MUST be made.)
インバンドでのLM応答メッセージの受信時、Counter 2 フィールドはこのLM応答の前にチャネル上で受信されたユニットの総数に設定されます。受信インターフェースが32ビットのLMカウンタを書き込む場合、X フラグは 0 に設定されます。（この時点でネットワーク内におけるLMメッセージの寿命は終了しているため、これらの最終的な変更をパケットに加えるかどうかは受信側に委ねられます。メッセージを外部の後処理（セクション2.9.7）のために転送する場合は、これらの変更を行わなければなりません (MUST)。）
Upon out-of-band receipt of an LM Response message, the Counter 1 and Counter 2 fields MUST NOT be used for purposes of loss measurement.
アウトオブバンドでのLM応答メッセージの受信時、Counter 1 および Counter 2 フィールドを損失測定の目的で使用してはなりません (MUST NOT)。
If the Control Code in an LM Response is anything other than 0x1 (Success), the counter values in the response MUST NOT be used for purposes of loss measurement. If the Control Code indicates an error condition, or if the response message is invalid, the LM operation MUST be terminated and an appropriate notification to the user generated.
LM応答内の Control Code が 0x1（成功: Success）以外である場合、応答内のカウンタ値を損失測定の目的で使用してはなりません (MUST NOT)。Control Code がエラー状態を示している場合、または応答メッセージが無効である場合、LM操作は終了されなければならず (MUST)、ユーザーに対する適切な通知が生成されなければなりません。
Calculation of packet loss is carried out according to the procedures in Section 2.2. The X flag in an LM message informs the device performing the calculation whether to perform 32-bit or 64-bit arithmetic. If the flag value is equal to 1, all interfaces involved in the LM operation have written 64-bit counter values, and 64-bit
セクション2.2の手順に従って、パケット損失の計算が実行されます。LMメッセージのXフラグは、32ビットまたは64ビットの算術を実行するかどうかを計算を実行するデバイスに通知します。フラグ値が1に等しい場合、LM操作に関与するすべてのインターフェイスに64ビットのカウンター値と64ビットが書かれています
arithmetic can be used. If the flag value is equal to 0, at least one interface involved in the operation has written a 32-bit counter value, and 32-bit arithmetic is carried out using the low-order 32 bits of each counter value.
算術を使用できます。フラグ値が0に等しい場合、操作に関与する少なくとも1つのインターフェイスが32ビットのカウンター値を書き込み、各カウンター値の低次の32ビットを使用して32ビットの算術が実行されます。
Note that the semantics of the X flag allow all devices to interoperate regardless of their counter size support. Thus, an implementation MUST NOT generate an error response based on the value of this flag.
X フラグのセマンティクスにより、カウンタサイズのサポートに関係なくすべてのデバイスが相互運用できる点に注意してください。したがって、実装はこのフラグの値に基づいてエラー応答を生成してはなりません (MUST NOT)。
The TC field of the LSE corresponding to the channel (e.g., LSP) being measured SHOULD be set to a traffic class equal to or better than the best TC within the measurement scope to minimize the chance of out-of-order conditions.
測定対象のチャネル（例: LSP）に対応するLSEの TC フィールドは、順序逆転状態の発生確率を最小限に抑えるために、測定スコープ内の最良の TC と同等以上のトラフィッククラスに設定すべきです (SHOULD)。
By default, direct LM MUST exclude packets transmitted and received over the Generic Associated Channel (G-ACh). An implementation MAY provide the means to alter the direct LM scope to include some or all G-ACh messages. Care must be taken when altering the LM scope to ensure that both endpoints are in agreement.
デフォルトでは、直接LMは汎用関連チャネル（G-ACh）を介して送受信されるパケットを除外しなければなりません (MUST)。実装は、一部またはすべての G-ACh メッセージを含めるように直接LMスコープを変更する手段を提供してもよいです (MAY)。両方のエンドポイントが合意していることを確実にするために、LMスコープを変更する際には注意を払わなければなりません。
In the case of inferred LM, the packets counted for LM consist of test messages generated for this purpose, or of some other class of packets deemed to provide a good proxy for data packets flowing over the channel. The specification of test protocols and proxy packets is outside the scope of this document, but some guidelines are discussed below.
推定LMの場合、LMにカウントされるパケットは、この目的のために生成されたテストメッセージ、またはチャネル上に流れるデータパケットの優れたプロキシを提供するとみなされる他のクラスのパケットで構成されています。テストプロトコルとプロキシパケットの仕様は、このドキュメントの範囲外ですが、いくつかのガイドラインについては以下に説明します。
An identifier common to both the test or proxy messages and the LM messages may be required to make correlation possible. The combined value of the Session Identifier and DS fields SHOULD be used for this purpose when possible. That is, test messages in this case will include a 32-bit field that can carry the value of the combined Session Identifier + DS field present in LM messages. When TC-specific LM is conducted, the DS field of the LSE in the label stack of a test message corresponding to the channel (e.g., LSP) over which the message is sent MUST correspond to the DS value in the associated LM messages.
関連付け（相関）を可能にするために、テストまたはプロキシメッセージとLMメッセージの双方に共通する識別子が必要となる場合があります。可能な場合、この目的には Session Identifier および DS フィールドの組み合わせ値を使用すべきです (SHOULD)。すなわち、この場合のテストメッセージには、LMメッセージに存在する結合された Session Identifier + DS フィールドの値を運ぶことのできる32ビットフィールドが含まれます。TC固有のLMが実施される場合、メッセージが送信されるチャネル（例: LSP）に対応するテストメッセージのラベルスタック内のLSEの DS フィールドは、関連するLMメッセージ内の DS 値に対応しなければなりません (MUST)。
A separate test message protocol SHOULD include a timeout value in its messages that informs the responder when to discard any state associated with a specific test.
独立したテストメッセージプロトコルは、特定のテストに関連付けられた任意の状態をいつ破棄すべきかをレスポンダに通知するタイムアウト値を、そのメッセージに含めるべきです (SHOULD)。
Because an LM operation consists of a message sequence with state maintained from one message to the next, LM is subject to the effects of lost messages and misordered packets in a way that DM is not. Because this state exists only on the querier, the handling of these conditions is, strictly speaking, a local matter. This section, however, presents recommended procedures for handling such conditions. Note that in the absence of ECMP, packet misordering within a traffic class is a relatively rare event.
LM操作は、あるメッセージから次のメッセージに維持されている状態を持つメッセージシーケンスで構成されているため、LMは、DMがそうでない方法で失われたメッセージと誤ったパケットの効果の影響を受けます。この状態はクエリエにのみ存在するため、これらの条件の取り扱いは、厳密に言えば、地元の問題です。ただし、このセクションでは、そのような条件を処理するための推奨手順を示します。ECMPがない場合、トラフィッククラス内でのパケットの誤用は比較的まれなイベントであることに注意してください。
The first kind of anomaly that may occur is that one or more LM messages may be lost in transit. The effect of such loss is that when an LM Response is next received at the querier, an unambiguous interpretation of the counter values it contains may be impossible, for the reasons described at the end of Section 2.2. Whether this is so depends on the number of messages lost and the other variables mentioned in that section, such as the LM message rate and the channel parameters.
発生する可能性のある最初の種類の異常は、転送中に1つ以上のLMメッセージが失われる可能性があることです。このような損失の影響は、QuerierでLM応答が次に受信された場合、セクション2.2の最後で説明されている理由により、含まれるカウンター値の明確な解釈が不可能になる可能性があることです。これが失われたメッセージの数と、LMメッセージレートやチャネルパラメーターなど、そのセクションで言及されている他の変数の数に依存します。
Another possibility is that LM messages are misordered in transit, so that, for instance, the response to LM[n] is received prior to the response to LM[n-1]. A typical implementation will discard the late response to LM[n-1], so that the effect is the same as the case of a lost message.
別の可能性は、LMメッセージが転送中に誤って命令されるため、たとえばLM [n]への応答がLM [n-1]への応答の前に受信されることです。典型的な実装は、LM [n-1]に対する遅い応答を破棄するため、その効果は失われたメッセージの場合と同じです。
Finally, LM is subject to the possibility that data packets are misordered relative to LM messages. This condition can result, for example, in a transmit count of 100 and a corresponding receive count of 101. The effect here is that the A_TxLoss[n-1,n] value (for example) for a given measurement interval will appear to be extremely (if not impossibly) large. The other case, where an LM message arrives earlier than some of the packets, simply results in those packets being counted as lost.
最後に、LMは、データパケットがLMメッセージに対して誤って命令される可能性の影響を受けます。この条件は、たとえば、100の送信数と対応する受信カウント101で生じる可能性があります。ここでの効果は、特定の測定間隔のA_TxLoss [n-1、n]値（たとえば）の値（たとえば）があることです。非常に（信じられないほどではないにしても）大きい。LMメッセージが一部のパケットよりも早く到着するもう1つのケースは、それらのパケットが失われたとカウントされるだけです。
An implementation SHOULD identify a threshold value that indicates the upper bound of lost packets measured in a single computation beyond which the interval is considered unmeasurable. This is called the "MaxLMIntervalLoss threshold". It is clear that this threshold should be no higher than the maximum number of packets (or bytes) the channel is capable of transmitting over the interval, but it may be lower. Upon encountering an unmeasurable interval, the LM state (i.e., data values from the last LM message received) SHOULD be discarded.
実装は、それを超えるとインターバルが測定不能とみなされる、単一の計算で測定された損失パケットの上限を示す閾値を特定すべきです (SHOULD)。これは「MaxLMIntervalLoss 閾値」と呼ばれます。この閾値はチャネルがそのインターバルに送信可能なパケット（またはバイト）の最大数以下でなければならないことは明らかですが、それより低くても構いません。測定不能なインターバルに遭遇した場合、LM状態（すなわち受信した前回のLMメッセージからのデータ値）は破棄されるべきです (SHOULD)。
With regard to lost LM messages, the MaxLMInterval (see Section 2.2) indicates the maximum amount of time that can elapse before the LM state is discarded. If some messages are lost, but a message is
LMメッセージの紛失に関しては、MaxLMInterval（セクション2.2を参照）は、LM状態が破棄される前に経過する可能性のある最大時間を示しています。いくつかのメッセージが失われたが、メッセージは
subsequently received within MaxLMInterval, its timestamp or sequence number will quantify the loss, and it MAY still be used for measurement, although the measurement interval will in this case be longer than usual.
その後 MaxLMInterval 内で受信された場合、そのタイムスタンプまたはシーケンス番号によって損失が定量化され、この場合の測定間隔は通常より長くなるものの、依然として測定に使用してもよいです (MAY)。
If an LM message is received that has a timestamp less than or equal to the timestamp of the last LM message received, this indicates that an exception has occurred, and the current interval SHOULD be considered unmeasurable unless the implementation has some other way of handling this condition.
最後に受信したLMメッセージのタイムスタンプ以下のタイムスタンプを持つLMメッセージを受信した場合、これは例外が発生したことを示しており、実装がこの状況を処理する他の何らかの手段を持たない限り、現在のインターバルは測定不能とみなされるべきです (SHOULD)。
When transmitting a DM Query, the Version and Reserved fields MUST be set to 0. The R flag MUST be set to 0, the T flag MUST be set to 1, and the remaining flag bits MUST be set to 0.
DMクエリを送信する際、Version および Reserved フィールドは 0 に設定されなければなりません (MUST)。R フラグは 0 に設定されなければならず (MUST)、T フラグは 1 に設定されなければならず (MUST)、残りのフラグビットは 0 に設定されなければなりません (MUST)。
The Control Code field MUST be set to one of the values for Query messages listed in Section 3.1; if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: In-band Response Requested).
Control Code フィールドは、セクション3.1に記載されているクエリメッセージ用の値の1つに設定されなければなりません (MUST)。チャネルが単方向である場合、このフィールドを 0x0（クエリ: インバンド応答要求）に設定してはなりません (MUST NOT)。
The Querier Timestamp Format field MUST be set to the timestamp format used by the querier when writing timestamp fields in this message; the possible values for this field are listed in Section 3.4. The Responder Timestamp Format and Responder's Preferred Timestamp Format fields MUST be set to 0.
Querier Timestamp Format フィールドは、このメッセージ内のタイムスタンプフィールドを書き込む際にクエリアが使用するタイムスタンプ形式に設定されなければなりません (MUST)。このフィールドの取り得る値はセクション3.4に記載されています。Responder Timestamp Format および Responder's Preferred Timestamp Format フィールドは 0 に設定されなければなりません (MUST)。
The Session Identifier field can be set arbitrarily. The DS field MUST be set to the traffic class being measured.
Session Identifier フィールドは任意に設定できます。DS フィールドは、測定対象のトラフィッククラスに設定されなければなりません (MUST)。
The Timestamp 1 field SHOULD be set to the time at which this DM Query is transmitted, in the format indicated by the Querier Timestamp Format field. The Timestamp 2 field MUST be set to 0. If a response was previously received in this measurement session, the Timestamp 1 and Timestamp 2 fields of the most recent such response MAY be copied to the Timestamp 3 and Timestamp 4 fields, respectively, of this query; otherwise, the Timestamp 3 and Timestamp 4 fields MUST be set to 0.
Timestamp 1 フィールドは、Querier Timestamp Format フィールドで示された形式で、このDMクエリが送信された時刻に設定されるべきです (SHOULD)。Timestamp 2 フィールドは 0 に設定されなければなりません (MUST)。この測定セッションにおいて以前に応答を受信していた場合、直近のそのような応答の Timestamp 1 および Timestamp 2 フィールドを、本クエリの Timestamp 3 および Timestamp 4 フィールドにそれぞれコピーしてもよく (MAY)、そうでない場合は Timestamp 3 および Timestamp 4 フィールドを 0 に設定しなければなりません (MUST)。
Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be set to the time at which this DM Query was received.
DMクエリメッセージを受信すると、Timestamp 2 フィールドはこのDMクエリが受信された時刻に設定されるべきです (SHOULD)。
At this point, the DM Query message must be inspected. If the Control Code field is set to 0x2 (No Response Requested), a DM Response message MUST NOT be transmitted. If the Control Code field is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band Response Requested), then an in-band or out-of-band response, respectively, SHOULD be transmitted unless this has been prevented by an administrative, security, or congestion control mechanism.
この時点で、DMクエリメッセージを検査しなければなりません。Control Code フィールドが 0x2（応答要求なし）に設定されている場合、DM応答メッセージを送信してはなりません (MUST NOT)。Control Code フィールドが 0x0（インバンド応答要求）または 0x1（アウトオブバンド応答要求）に設定されている場合、管理、セキュリティ、または輻輳制御メカニズムによって妨げられない限り、それぞれインバンドまたはアウトオブバンドの応答を送信すべきです (SHOULD)。
In the case of a fatal exception that prevents the requested measurement from being made, the error SHOULD be reported, via either a response, if one was requested, or else as a notification to the user.
要求された測定の実施を妨げる致命的な例外の場合、応答が要求されていた場合は応答を介して、あるいはユーザーへの通知として、エラーが報告されるべきです (SHOULD)。
When constructing a Response to a DM Query, the Version and Reserved fields MUST be set to 0. The R flag MUST be set to 1, the T flag MUST be set to 1, and the remaining flag bits MUST be set to 0.
DMクエリへの応答を構築する際、Version および Reserved フィールドは 0 に設定されなければなりません (MUST)。R フラグは 1 に設定されなければならず (MUST)、T フラグは 1 に設定されなければならず (MUST)、残りのフラグビットは 0 に設定されなければなりません (MUST)。
The Session Identifier and Querier Timestamp Format (QTF) fields MUST be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4 fields, respectively, of the DM Response.
Session Identifier および Querier Timestamp Format（QTF）フィールドは、DMクエリからコピーされなければなりません (MUST)。DMクエリの Timestamp 1 および Timestamp 2 フィールドは、DM応答の Timestamp 3 および Timestamp 4 フィールドにそれぞれコピーされなければなりません (MUST)。
The Responder Timestamp Format (RTF) field MUST be set to the timestamp format used by the responder when writing timestamp fields in this message, i.e., Timestamp 4 and (if applicable) Timestamp 1; the possible values for this field are listed in Section 3.4. Furthermore, the RTF field MUST be set equal to either the QTF or the RPTF field. See Section 4.3.5 for guidelines on the selection of the value for this field.
Responder Timestamp Format（RTF）フィールドは、レスポンダがこのメッセージ内のタイムスタンプフィールド（すなわち Timestamp 4 および該当する場合は Timestamp 1）を書き込む際に使用したタイムスタンプ形式に設定されなければなりません (MUST)。このフィールドの取り得る値はセクション3.4に記載されています。さらに、RTF フィールドは QTF または RPTF フィールドのいずれかと等しく設定されなければなりません (MUST)。このフィールドの値の選択に関するガイドラインについてはセクション4.3.5を参照してください。
The Responder's Preferred Timestamp Format (RPTF) field MUST be set to one of the values listed in Section 3.4 and SHOULD be set to indicate the timestamp format with which the responder can provide the best accuracy for purposes of delay measurement.
Responder's Preferred Timestamp Format（RPTF）フィールドは、セクション3.4に記載されている値の1つに設定されなければならず (MUST)、レスポンダが遅延測定の目的において最良の精度を提供できるタイムスタンプ形式を示すように設定されるべきです (SHOULD)。
The Control Code field MUST be set to one of the values for Response messages listed in Section 3.1. The value 0x10 (Unspecified Error) SHOULD NOT be used if one of the other more specific error codes is applicable.
Control Code フィールドは、セクション3.1に記載されている応答メッセージ用の値の1つに設定されなければなりません (MUST)。より具体的な他のエラーコードのいずれかが適用可能な場合、値 0x10（不特定エラー: Unspecified Error）を使用すべきではありません (SHOULD NOT)。
If the response is transmitted in-band, the Timestamp 1 field SHOULD be set to the time at which this DM Response is transmitted. If the response is transmitted out-of-band, the Timestamp 1 field MUST be set to 0. In either case, the Timestamp 2 field MUST be set to 0.
応答がインバンドで送信される場合、Timestamp 1 フィールドはこのDM応答が送信された時刻に設定されるべきです (SHOULD)。応答がアウトオブバンドで送信される場合、Timestamp 1 フィールドは 0 に設定されなければなりません (MUST)。いずれの場合も、Timestamp 2 フィールドは 0 に設定されなければなりません (MUST)。
If the response is transmitted in-band and the Control Code in the message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields MUST have the same format, which will be the format indicated in the Responder Timestamp Format field.
応答がインバンドで送信され、かつメッセージ内の Control Code が 0x1（成功: Success）である場合、Timestamp 1 および Timestamp 4 フィールドは同一の形式を持たなければならず (MUST)、その形式は Responder Timestamp Format フィールドで示された形式となります。
Upon in-band receipt of a DM Response message, the Timestamp 2 field is set to the time at which this DM Response was received. (Since the life of the DM message in the network has ended at this point, it is up to the receiver whether this final modification is made to the packet. If the message is to be forwarded on for external post-processing (Section 2.9.7), then these modifications MUST be made.)
インバンドでのDM応答メッセージの受信時、Timestamp 2 フィールドはこのDM応答が受信された時刻に設定されます。（この時点でネットワーク内におけるDMメッセージの寿命は終了しているため、この最終的な変更をパケットに加えるかどうかは受信側に委ねられます。メッセージを外部の後処理（セクション2.9.7）のために転送する場合は、これらの変更を行わなければなりません (MUST)。）
Upon out-of-band receipt of a DM Response message, the Timestamp 1 and Timestamp 2 fields MUST NOT be used for purposes of delay measurement.
アウトオブバンドでのDM応答メッセージの受信時、Timestamp 1 および Timestamp 2 フィールドを遅延測定の目的で使用してはなりません (MUST NOT)。
If the Control Code in a DM Response is anything other than 0x1 (Success), the timestamp values in the response MUST NOT be used for purposes of delay measurement. If the Control Code indicates an error condition, or if the response message is invalid, the DM operation MUST be terminated and an appropriate notification to the user generated.
DM応答内の Control Code が 0x1（成功: Success）以外である場合、応答内のタイムスタンプ値を遅延測定の目的で使用してはなりません (MUST NOT)。Control Code がエラー状態を示している場合、または応答メッセージが無効である場合、DM操作は終了されなければならず (MUST)、ユーザーに対する適切な通知が生成されなければなりません。
In case either the querier or the responder in a DM transaction is capable of supporting multiple timestamp formats, it is desirable to determine the optimal format for purposes of delay measurement on a particular channel. The procedures for making this determination SHALL be as follows.
DMトランザクションにおいてクエリアまたはレスポンダのいずれかが複数のタイムスタンプ形式をサポートできる場合、特定のチャネルにおける遅延測定の目的で最適な形式を決定することが望ましいです。この決定を行うための手順は以下の通りとします (SHALL)。
Upon sending an initial DM Query over a channel, the querier sets the Querier Timestamp Format (QTF) field to its preferred timestamp format.
チャネル上で最初のDMクエリを送信すると、QuerierはQuerierタイムスタンプ形式（QTF）フィールドを優先タイムスタンプ形式に設定します。
Upon receiving any DM Query message, the responder determines whether it is capable of writing timestamps in the format specified by the QTF field. If so, the Responder Timestamp Format (RTF) field is set equal to the QTF field. If not, the RTF field is set equal to the Responder's Preferred Timestamp Format (RPTF) field.
DMクエリメッセージを受信すると、Responderは、QTFフィールドで指定された形式でタイムスタンプを作成できるかどうかを決定します。その場合、レスポンダータイムスタンプ形式（RTF）フィールドはQTFフィールドに等しく設定されます。そうでない場合、RTFフィールドは、Responderの優先タイムスタンプ形式（RPTF）フィールドに等しく設定されます。
The process of changing from one timestamp format to another at the responder may result in the Timestamp 1 and Timestamp 4 fields in an in-band DM Response having different formats. If this is the case,
レスポンダーであるタイムスタンプ形式から別のタイムスタンプ形式を変更するプロセスにより、タイムスタンプ1とタイムスタンプ4フィールドが異なる形式を持つバンド内DM応答のフィールドになります。このような場合は、
the Control Code in the response MUST NOT be set to 0x1 (Success). Unless an error condition has occurred, the Control Code MUST be set to 0x2 (Notification - Data Format Invalid).
応答内の Control Code は 0x1（成功: Success）に設定してはなりません (MUST NOT)。エラー状態が発生していない限り、Control Code は 0x2（通知 - データ形式が無効: Notification - Data Format Invalid）に設定されなければなりません (MUST)。
Upon receiving a DM Response, the querier knows from the RTF field in the message whether the responder is capable of supporting its preferred timestamp format: if it is, the RTF will be equal to the QTF. The querier also knows the responder's preferred timestamp format from the RPTF field. The querier can then decide whether to retain its current QTF or to change it and repeat the negotiation procedures.
DM応答を受信すると、QuerierはメッセージのRTFフィールドから、レスポンダーが優先タイムスタンプ形式をサポートできるかどうかを知っています。Querierは、RPTFフィールドからのResponderの優先タイムスタンプ形式も知っています。Querierは、現在のQTFを保持するか、変更して交渉手順を繰り返すかを決定できます。
When an implementation supports only one timestamp format, the procedures above reduce to the following simple behavior:
実装が1つのタイムスタンプ形式のみをサポートしている場合、上記の手順は次の単純な動作に減少します。
o All DM Queries are transmitted with the same QTF;
o すべてのDMクエリは、同じQTFで送信されます。
o All DM Responses are transmitted with the same RTF, and the RPTF is always set equal to the RTF;
o すべてのDM応答は同じRTFで送信され、RPTFは常にRTFに等しく設定されます。
o All DM Responses received with RTF not equal to QTF are discarded;
o QTFに等しくないRTFで受信されたすべてのDM応答は破棄されます。
o On a unidirectional channel, all DM Queries received with QTF not equal to the supported format are discarded.
o 単方向チャネルでは、QTFで受信されたすべてのDMクエリがサポートされている形式に等しくないことが破棄されます。
The TC field of the LSE corresponding to the channel (e.g., LSP) being measured MUST be set to the value that corresponds to the DS field in the DM message.
測定対象のチャネル（例: LSP）に対応するLSEの TC フィールドは、DMメッセージ内の DS フィールドに対応する値に設定されなければなりません (MUST)。
The combined LM/DM message defined in Section 3.3 allows loss and delay measurement to be carried out simultaneously. This message SHOULD be treated as an LM message that happens to carry additional timestamp data, with the timestamp fields processed as per delay measurement procedures.
セクション3.3で定義されている複合LM/DMメッセージにより、損失測定と遅延測定を同時に実行することが可能になります。このメッセージは、追加のタイムスタンプデータをたまたま運んでいるLMメッセージとして扱われるべきであり (SHOULD)、タイムスタンプフィールドは遅延測定手順に従って処理されます。
This section summarizes the requirements placed on implementations for capabilities disclosure. The purpose of these requirements is to ensure that end users have a clear understanding of implementation
このセクションでは、機能の洞察力の実装に配置された要件をまとめたものです。これらの要件の目的は、エンドユーザーが実装を明確に理解できるようにすることです
capabilities and characteristics that have a direct impact on how loss and delay measurement mechanisms function in specific situations. Implementations are REQUIRED to state:
特定の状況で損失と遅延測定メカニズムがどのように機能するかに直接影響を与える能力と特性。実装は、次の事項を明記しなければなりません (REQUIRED)。
o METRICS: Which of the following metrics are supported: packet loss, packet throughput, octet loss, octet throughput, average loss rate, one-way delay, round-trip delay, two-way channel delay, packet delay variation.
o メトリック：パケット損失、パケットスループット、オクテット損失、オクテットスループット、平均損失率、一元配置遅延、往復遅延、双方向チャネル遅延、パケット遅延変動。
o MP-LOCATION: The location of loss and delay measurement points with respect to other stages of packet processing, such as queuing.
o MPロケーション：キューイングなどのパケット処理の他の段階に関する損失および遅延測定ポイントの位置。
o CHANNEL-TYPES: The types of channels for which LM and DM are supported, including LSP types, pseudowires, and sections (links).
o チャネルタイプ：LSPタイプ、擬似動物、セクション（リンク）など、LMとDMがサポートされるチャネルのタイプ。
o QUERY-RATE: The minimum supported query intervals for LM and DM sessions, both in the querier and responder roles.
o クエリレート：クエリエとレスポンダーの両方の役割の両方で、LMおよびDMセッションの最小サポートクエリ間隔。
o LOOP: Whether loopback measurement (Section 2.8) is supported.
o ループ：ループバック測定（セクション2.8）がサポートされているかどうか。
o LM-TYPES: Whether direct or inferred LM is supported, and for the latter, which test protocols or proxy message types are supported.
o LMタイプ：直接的または推測されたLMがサポートされているかどうか、および後者の場合、どのテストプロトコルまたはプロキシメッセージタイプがサポートされています。
o LM-COUNTERS: Whether 64-bit counters are supported.
o LMカウンター：64ビットカウンターがサポートされているかどうか。
o LM-ACCURACY: The expected measurement accuracy levels for the supported forms of LM, and the expected impact of exception conditions such as lost and misordered messages.
o LM-Accuracy：LMのサポートされているフォームの予想される測定精度レベル、および失われたメッセージや誤ったメッセージなどの例外条件の予想される影響。
o LM-SYNC: The implementation's behavior in regard to the synchronization conditions discussed in Section 2.9.8.
o LM-Sync：セクション2.9.8で説明した同期条件に関する実装の動作。
o LM-SCOPE: The supported LM scopes (Sections 2.9.9 and 4.2.8).
o LMスコープ：サポートされているLMスコープ（セクション2.9.9および4.2.8）。
o DM-ACCURACY: The expected measurement accuracy levels for the supported forms of DM.
o DM-Accuracy：DMのサポートされているフォームの予想される測定精度レベル。
o DM-TS-FORMATS: The supported timestamp formats and the extent of support for computation with and reconciliation of different formats.
o DM-TSフォーマット：サポートされているタイムスタンプ形式と、さまざまな形式の計算と調整のサポートの範囲。
An MPLS network may be traffic-engineered in such a way that the bandwidth required both for client traffic and for control, management, and OAM traffic is always available. The following congestion considerations therefore apply only when this is not the case.
MPLSネットワークは、クライアントトラフィックと制御、管理、およびOAMトラフィックの両方に帯域幅が必要とするように、トラフィックエンジニアリングされている可能性があります。したがって、次の輻輳の考慮事項は、そうでない場合にのみ適用されます。
The proactive generation of Loss Measurement and Delay Measurement messages for purposes of monitoring the performance of an MPLS channel naturally results in a degree of additional load placed on both the network and the terminal nodes of the channel. When configuring such monitoring, operators should be mindful of the overhead involved and should choose transmit rates that do not stress network resources unduly; such choices must be informed by the deployment context. In case of slower links or lower-speed devices, for example, lower Loss Measurement message rates can be chosen, up to the limits noted at the end of Section 2.2.
MPLSチャネルのパフォーマンスを監視する目的で、損失測定と遅延測定メッセージのプロアクティブな生成は、自然に、チャネルのネットワークノードと端子ノードの両方にある程度の追加負荷をかけます。このような監視を構成する場合、オペレーターは関係するオーバーヘッドに留意し、ネットワークリソースを過度に強調しない送信レートを選択する必要があります。このような選択は、展開コンテキストによって通知する必要があります。たとえば、リンクが遅い場合や低速デバイスの場合、セクション2.2の最後に記載されている制限まで、低い損失測定メッセージレートを選択できます。
In general, lower measurement message rates place less load on the network at the expense of reduced granularity. For delay measurement, this reduced granularity translates to a greater possibility that the delay associated with a channel temporarily exceeds the expected threshold without detection. For loss measurement, it translates to a larger gap in loss information in case of exceptional circumstances such as lost LM messages or misordered packets.
一般に、測定メッセージレートが低いと、粒度が低下してネットワーク上の負荷が少なくなります。遅延測定の場合、この粒度の低下は、チャネルに関連する遅延が検出なしで一時的に予想されるしきい値を超える可能性が高くなります。損失測定のために、LMメッセージの紛失や誤ったパケットなどの例外的な状況がある場合、損失情報の大きなギャップに変換されます。
When carrying out a sustained measurement operation such as an LM operation or continuous proactive DM operation, the querier SHOULD take note of the number of lost measurement messages (queries for which a response is never received) and set a corresponding Measurement Message Loss Threshold. If this threshold is exceeded, the measurement operation SHOULD be suspended so as not to exacerbate the possible congestion condition. This suspension SHOULD be accompanied by an appropriate notification to the user so that the condition can be investigated and corrected.
LM操作や継続的なプロアクティブDM操作などの持続的な測定操作を実行する際、クエリアは失われた測定メッセージの数（応答が決して受信されないクエリ）に留意し、対応する Measurement Message Loss Threshold（測定メッセージ損失閾値）を設定すべきです (SHOULD)。この閾値を超えた場合、輻輳の可能性のある状態を悪化させないように測定操作を中断すべきです (SHOULD)。この中断には、状況を調査して是正できるように、ユーザーに対する適切な通知を伴うべきです (SHOULD)。
From the receiver perspective, the main consideration is the possibility of receiving an excessive quantity of measurement messages. An implementation SHOULD employ a mechanism such as rate-limiting to guard against the effects of this case.
受信側の観点からの主な考慮事項は、過度な量の測定メッセージを受信する可能性です。実装は、この状況の影響を防ぐためにレート制限などのメカニズムを採用すべきです (SHOULD)。
The measurement protocols described in this document are intended to serve as infrastructure to support a wide range of higher-level monitoring and diagnostic applications, from simple command-line
このドキュメントで説明されている測定プロトコルは、Simple Command-lineからの幅広い高レベルの監視および診断アプリケーションをサポートするインフラストラクチャとして機能することを目的としています。
diagnostic tools to comprehensive network performance monitoring and analysis packages. The specific mechanisms and considerations for protocol configuration, initialization, and reporting thus depend on the nature of the application.
包括的なネットワークパフォーマンスの監視および分析パッケージへの診断ツール。したがって、プロトコルの構成、初期化、およびレポートの特定のメカニズムと考慮事項は、アプリケーションの性質に依存します。
In the case of on-demand diagnostics, the diagnostic application may provide parameters such as the measurement type, the channel, the query rate, and the test duration when initiating the diagnostic; results and exception conditions are then reported directly to the application. The system may discard the statistics accumulated during the test after the results have been reported or retain them to provide a historical measurement record.
オンデマンド診断の場合、診断アプリケーションは、診断を開始する際の測定タイプ、チャネル、クエリレート、テスト期間などのパラメーターを提供する場合があります。その後、結果と例外条件がアプリケーションに直接報告されます。システムは、結果が報告された後にテスト中に蓄積された統計を破棄するか、履歴測定記録を提供するためにそれらを保持する場合があります。
Alternatively, measurement configuration may be supplied as part of the channel configuration itself in order to support continuous monitoring of the channel's performance characteristics. In this case, the configuration will typically include quality thresholds depending on the service level agreement, the crossing of which will trigger warnings or alarms, and result reporting and exception notification will be integrated into the system-wide network management and reporting framework.
または、チャネルのパフォーマンス特性の継続的な監視をサポートするために、測定構成自体の一部として測定構成を提供することもできます。この場合、構成には通常、サービスレベルの契約に応じて品質のしきい値が含まれ、その交差は警告またはアラームをトリガーし、結果レポートと例外通知はシステム全体のネットワーク管理とレポートフレームワークに統合されます。
This document describes procedures for the measurement of performance metrics over a pre-existing MPLS path (a pseudowire, LSP, or section). As such, it assumes that a node involved in a measurement operation has previously verified the integrity of the path and the identity of the far end using existing MPLS mechanisms such as Bidirectional Forwarding Detection (BFD) [RFC5884]; tools, techniques, and considerations for securing MPLS paths are discussed in detail in [RFC5920].
When such mechanisms are not available, and where security of the measurement operation is a concern, reception of Generic Associated Channel messages with the Channel Types specified in this document SHOULD be disabled. Implementations MUST provide the ability to disable these protocols on a per-Channel-Type basis.
そのようなメカニズムが利用できず、測定操作のセキュリティが懸念される場合、本文書で指定された Channel Type を持つ汎用関連チャネル（Generic Associated Channel）メッセージの受信は無効化されるべきです (SHOULD)。実装は、Channel Type ごとにこれらのプロトコルを無効化する機能を提供しなければなりません (MUST)。
Even when the identity of the far end has been verified, the measurement protocols remain vulnerable to injection and man-in-the-middle attacks. The impact of such an attack would be to compromise the quality of performance measurements on the affected path. An attacker positioned to disrupt these measurements is, however, capable of causing much greater damage by disrupting far more critical elements of the network such as the network control plane or user traffic flows. At worst, a disruption of the measurement protocols would interfere with the monitoring of the performance
遠端のアイデンティティが検証されている場合でも、測定プロトコルは注射および中間攻撃に対して脆弱なままです。このような攻撃の影響は、影響を受ける経路でのパフォーマンス測定の質を損なうことです。ただし、これらの測定を破壊するために位置する攻撃者は、ネットワーク制御プレーンやユーザートラフィックフローなど、ネットワークのはるかに重要な要素を破壊することにより、はるかに大きな損害を引き起こすことができます。最悪の場合、測定プロトコルの混乱はパフォーマンスの監視を妨げます
aspects of the service level agreement associated with the path; the existence of such a disruption would imply that a serious breach of basic path integrity had already occurred.
パスに関連するサービスレベル契約の側面。そのような混乱の存在は、基本的な経路の整合性の深刻な違反がすでに発生していることを意味します。
If desired, such attacks can be mitigated by performing basic validation and sanity checks, at the querier, of the counter or timestamp fields in received measurement response messages. The minimal state associated with these protocols also limits the extent of measurement disruption that can be caused by a corrupt or invalid message to a single query/response cycle.
必要に応じて、そのような攻撃は、受信した測定応答メッセージのカウンターまたはタイムスタンプフィールドの基本的な検証と正気チェックを実行することで軽減できます。これらのプロトコルに関連する最小状態は、単一のクエリ/応答サイクルへの破損したメッセージまたは無効なメッセージによって引き起こされる可能性のある測定破壊の程度も制限します。
Cryptographic mechanisms capable of signing or encrypting the contents of the measurement packets without degrading the measurement performance are not currently available. In light of the preceding discussion, the absence of such cryptographic mechanisms does not raise significant security issues.
測定パフォーマンスを分解せずに測定パケットの内容に署名または暗号化できる暗号化メカニズムは現在利用できません。前述の議論に照らして、そのような暗号化メカニズムがないことは、重大なセキュリティの問題を提起しません。
Users concerned with the security of out-of-band responses over IP networks SHOULD employ suitable security mechanisms such as IPsec [RFC4301] to protect the integrity of the return path.
IPネットワーク上でのアウトオブバンド応答のセキュリティを懸念するユーザーは、リターンパスの完全性を保護するために IPsec [RFC4301] などの適切なセキュリティメカニズムを採用すべきです (SHOULD)。
Per this document, IANA has completed the following actions:
このドキュメントに従って、IANAは次のアクションを完了しました。
o Allocation of Channel Types in the "PW Associated Channel Type" registry
o 「PW関連チャネルタイプ」レジストリでのチャネルタイプの割り当て
o Creation of a "Measurement Timestamp Type" registry
o 「測定タイムスタンプタイプ」レジストリの作成
o Creation of an "MPLS Loss/Delay Measurement Control Code" registry
o 「MPLS損失/遅延測定制御コード」レジストリの作成
o Creation of an "MPLS Loss/Delay Measurement Type-Length-Value (TLV) Object" registry
o 「MPLS損失/遅延測定型型（TLV）オブジェクト」レジストリの作成
As per the IANA considerations in [RFC5586], IANA has allocated the following Channel Types in the "PW Associated Channel Type" registry:
[RFC5586]のIANAの考慮事項に従って、IANAは「PW関連チャネルタイプ」レジストリで次のチャネルタイプを割り当てました。
Value Description TLV Follows Reference
------ ---------------------------------------- ----------- ---------
0x000A MPLS Direct Loss Measurement (DLM) No RFC 6374
0x000B MPLS Inferred Loss Measurement (ILM) No RFC 6374
0x000C MPLS Delay Measurement (DM) No RFC 6374
0x000D MPLS Direct Loss and Delay Measurement No RFC 6374
(DLM+DM)
0x000E MPLS Inferred Loss and Delay Measurement No RFC 6374
(ILM+DM)
IANA has created a new "Measurement Timestamp Type" registry, with format and initial allocations as follows:
IANAは、次のように形式と初期割り当てを備えた新しい「測定タイムスタンプタイプ」レジストリを作成しました。
Type Description Size in Bits Reference
---- ----------------------------------------- ------------ ---------
0 Null Timestamp 64 RFC 6374
1 Sequence Number 64 RFC 6374
2 Network Time Protocol version 4 64-bit 64 RFC 6374
Timestamp
3 Truncated IEEE 1588v2 PTP Timestamp 64 RFC 6374
The range of the Type field is 0-15.
タイプフィールドの範囲は0〜15です。
The allocation policy for this registry is IETF Review.
このレジストリの割り当てポリシーはIETFレビューです。
IANA has created a new "MPLS Loss/Delay Measurement Control Code" registry. This registry is divided into two separate parts, one for Query Codes and the other for Response Codes, with formats and initial allocations as follows:
IANAは、新しい「MPLS損失/遅延測定制御コード」レジストリを作成しました。このレジストリは、クエリコード用に1つは応答コード用に、もう1つはフォーマットと初期割り当てが次の2つのパーツに分かれています。
Query Codes
クエリコード
Code Description Reference
---- ------------------------------ ---------
0x0 In-band Response Requested RFC 6374
0x1 Out-of-band Response Requested RFC 6374
0x2 No Response Requested RFC 6374
Response Codes
応答コード
Code Description Reference
---- ----------------------------------- ---------
0x0 Reserved RFC 6374
0x1 Success RFC 6374
0x2 Data Format Invalid RFC 6374
0x3 Initialization in Progress RFC 6374
0x4 Data Reset Occurred RFC 6374
0x5 Resource Temporarily Unavailable RFC 6374
0x10 Unspecified Error RFC 6374
0x11 Unsupported Version RFC 6374
0x12 Unsupported Control Code RFC 6374
0x13 Unsupported Data Format RFC 6374
0x14 Authentication Failure RFC 6374
0x15 Invalid Destination Node Identifier RFC 6374
0x16 Connection Mismatch RFC 6374
0x17 Unsupported Mandatory TLV Object RFC 6374
0x18 Unsupported Query Interval RFC 6374
0x19 Administrative Block RFC 6374
0x1A Resource Unavailable RFC 6374
0x1B Resource Released RFC 6374
0x1C Invalid Message RFC 6374
0x1D Protocol Error RFC 6374
IANA has indicated that the values 0x0 - 0xF in the Response Code section are reserved for non-error response codes.
IANAは、応答コードセクションの値0x0-0xfが非誤差応答コード用に予約されていることを示しています。
The range of the Code field is 0 - 255.
コードフィールドの範囲は0〜255です。
The allocation policy for this registry is IETF Review.
このレジストリの割り当てポリシーはIETFレビューです。
IANA has created a new "MPLS Loss/Delay Measurement TLV Object" registry, with format and initial allocations as follows:
IANAは、フォーマットと初期割り当てを次のように、新しい「MPLS損失/遅延測定TLVオブジェクト」レジストリを作成しました。
Type Description Reference
---- --------------------------------- ---------
0 Padding - copy in response RFC 6374
1 Return Address RFC 6374
2 Session Query Interval RFC 6374
3 Loopback Request RFC 6374
127 Experimental use RFC 6374
128 Padding - do not copy in response RFC 6374
129 Destination Address RFC 6374
130 Source Address RFC 6374
255 Experimental use RFC 6374
IANA has indicated that Types 0-127 are classified as Mandatory, and that Types 128-255 are classified as Optional.
IANAは、タイプ0-127は必須として分類され、タイプ128-255はオプションとして分類されることを示しています。
The range of the Type field is 0 - 255.
タイプフィールドの範囲は0〜255です。
The allocation policy for this registry is IETF Review.
このレジストリの割り当てポリシーはIETFレビューです。
The authors wish to thank the many participants of the MPLS working group who provided detailed review and feedback on this document. The authors offer special thanks to Alexander Vainshtein, Loa Andersson, and Hiroyuki Takagi for many helpful thoughts and discussions, to Linda Dunbar for the idea of using LM messages for throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and Ben Mack-Crane for their valuable comments.
著者は、このドキュメントに関する詳細なレビューとフィードバックを提供してくれたMPLSワーキンググループの多くの参加者に感謝したいと考えています。著者は、多くの有益な考えや議論をしてくれたAlexander Vainshtein、Loa Andersson、およびHiroyuki Takagi、スループット測定にLMメッセージを使用するというアイデアについて、Linda Dunbarに特別な感謝を申し上げます。彼らの貴重なコメントのためにクレーン。
[IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", March 2008.
[IEEE1588] IEEE、 "1588-2008 IEEE標準ネットワーク化された測定および制御システムのための精密クロック同期プロトコルの標準"、2008年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S.、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462] Andersson, L. and R. Asati、「マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ：「Exp」フィールド「トラフィッククラス」フィールドに改名されたフィールド、RFC 5462、2009年2月。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant、「Mpls Generic Associated Channel」、RFC 5586、2009年6月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch、「ネットワーク時間プロトコルバージョン4：プロトコルとアルゴリズムの仕様」、RFC 5905、2010年6月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas、「IPPMの一方向遅延メトリック」、RFC 2679、1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas、「IPPMの一元配置パケット損失メトリック」、RFC 2680、1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、1999年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman, D.、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant, S. and P. Pate、「Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent, S. and K. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas、「一元配置活性測定プロトコル（OWAMP）」、RFC 4656、2006年9月。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson、「MPLSネットワークでの等しいコストマルチパス治療を回避」、BCP 128、RFC 4928、2007年6月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz、「双方向活性測定プロトコル（TWAMP）」、RFC 5357、2008年10月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481] Morton, A. and B. Claise、「パケット遅延変動適用ステートメント」、RFC 5481、2009年3月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang, L.、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger、「輸送ネットワークにおけるMPLのフレームワーク」、RFC 5921、2010年7月。
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960] Frost, D., Bryant, S., and M. Bocci、「MPLS輸送プロファイルデータプレーンアーキテクチャ」、RFC 5960、2010年8月。
[RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011.
[RFC6375] Frost, D., Ed. and S. Bryant, Ed.、「MPLSベースの輸送ネットワークのパケット損失および遅延測定プロファイル」、RFC 6375、2011年9月。
[Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms for Ethernet based Networks", February 2008.
[Y.1731] ITU-T Recommendation Y.1731、「イーサネットベースのネットワークのOAM機能とメカニズム」、2008年2月。
This document initially proposed the Network Time Protocol (NTP) timestamp format as the mandatory default, as this is the normal default timestamp in IETF protocols and thus would seem the "natural" choice. However, a number of considerations have led instead to the specification of the truncated IEEE 1588 Precision Time Protocol (PTP) timestamp as the default. NTP has not gained traction in industry as the protocol of choice for high-quality timing infrastructure, whilst IEEE 1588 PTP has become the de facto time transfer protocol in networks that are specially engineered to provide high-accuracy time distribution service. The PTP timestamp format is also the ITU-T format of choice for packet transport networks, which may rely on MPLS protocols. Applications such as one-way delay measurement need the best time service available, and converting between the NTP and PTP timestamp formats is not a trivial transformation, particularly when it is required that this be done in real time without loss of accuracy.
このドキュメントは、IETFプロトコルの通常のデフォルトのタイムスタンプであるため、「自然な」選択のように見えるため、最初にネットワークタイムプロトコル（NTP）タイムスタンプ形式を必須デフォルトとして提案しました。ただし、代わりに多くの考慮事項が、デフォルトとして切り捨てられたIEEE 1588 Precision Time Protocol（PTP）タイムスタンプの仕様につながりました。 IEEE 1588 PTPは、高品質のタイミングインフラストラクチャに最適なプロトコルとして、業界で牽引力を獲得していません。 PTPタイムスタンプ形式は、MPLSプロトコルに依存する可能性のあるパケットトランスポートネットワークに最適なITU-T形式でもあります。一元配置遅延測定などのアプリケーションは、利用可能な最高のタイムサービスが必要であり、NTPとPTPタイムスタンプ形式の間の変換は、特にこれを精度を失うことなくリアルタイムで行う必要がある場合は、些細な変換ではありません。
The truncated IEEE 1588 PTP format specified in this document is considered to provide a more than adequate wrap time and greater time resolution than it is expected will be needed for the operational lifetime of this protocol. By truncating the timestamp at both the high and low order bits, the protocol achieves a worthwhile reduction in system resources.
このドキュメントで指定されている切り捨てられたIEEE 1588 PTP形式は、このプロトコルの運用寿命に必要な場合よりも適切なラップ時間を提供すると考えられています。高次および低次ビットの両方でタイムスタンプを切り捨てることにより、プロトコルはシステムリソースの価値のある削減を実現します。
Authors' Addresses
著者のアドレス
Dan Frost Cisco Systems
ダンフロストシスコシステム
EMail: danfrost@cisco.com
Stewart Bryant Cisco Systems
スチュワートブライアントシスコシステム
EMail: stbryant@cisco.com