[要約] RFC 6374は、MPLSネットワークにおけるパケットロスと遅延の測定に関する標準化された手法を提供します。このRFCの目的は、MPLSネットワークのパフォーマンスを評価し、問題を特定するためのツールを提供することです。
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 LMおよびDMプロトコルは、MPLS-TPが標準のMPLSデータプレーンに基づいているため、MPLS輸送プロファイル（MPLS-TP）に基づいて、LSP、擬似動物、およびネットワークのセクションに適用できます。MPLS-TPは[RFC5921]で定義および説明されており、MPLS-TP LSP、擬似動物、およびセクションについては[RFC5960]で詳しく説明します。MPLS-TPコンテキストでのLMおよびDMプロトコルの最小機能サブセットを記述するプロファイルは、[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メッセージレートは十分に高くなければなりません。たとえば、64バイトの最小パケットサイズの100 gbpsリンクの32ビットカウンターは、2^32 /（10^11 /（64*8））= 〜22秒でラップできます。このような条件下でLMメッセージ間隔にバインドされています。このバウンドは、チャネルのmaxlmintervalと呼ばれます。Maxlmintervalが、直接LMの場合、およびより小さなカウンターサイズの場合、より制限的な制約となることは明らかです。
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が受信した最後のLM応答に関連するデータを保持する必要があります。応答が届きます。このデータは廃棄される場合があり、次の応答が到着する前にmaxlmintervalが経過する場合、測定の基礎として使用してはなりません。この場合、明確な測定を行うことができないためです。
The foregoing discussion has assumed the counted objects are packets, but this need not be the case. In particular, octets may be counted instead. This will, of course, reduce the MaxLMInterval accordingly.
前述の議論は、カウントされたオブジェクトがパケットであると想定していますが、これは事実ではありません。特に、代わりにオクテットがカウントされる場合があります。もちろん、これにより、それに応じてmaxlmintervalが削減されます。
In addition to absolute aggregate loss counts, the individual loss counts yield other metrics, such as the average loss rate over any multiple of the measurement interval. An accurate loss rate can be determined over time even in the presence of anomalies affecting individual measurements, such as those due to packet misordering (Section 4.2.10).
絶対的な集約損失カウントに加えて、個々の損失カウントは、測定間隔の倍数にわたる平均損失率など、他のメトリックを生成します。正確な損失率は、パケットの誤用によるものなど、個々の測定に影響を与える異常が存在する場合でも、時間の経過とともに決定できます（セクション4.2.10）。
Note that an approach for conducting packet loss measurement in IP networks is documented in [RFC2680]. This approach differs from the one described here, for example by requiring clock synchronization between the measurement points and lacking support for direct-mode LM.
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.
大まかには、MPLSネットワークのチャネルは、リンク、ラベルスイッチ付きパス（LSP）[RFC3031]、または擬似ワイヤー[RFC3985]のいずれかです。リンクは双方向であり、MPLSセクションとも呼ばれます。[RFC5586]および[RFC5960]を参照してください。擬似動物は双方向です。ラベルスイッチされたパスは、単方向または双方向のいずれかです。
The LM and DM protocols discussed in this document are initiated from a single node: the querier. A query message may be received either by a single node or by multiple nodes, depending on the nature of the channel. In the latter case, these protocols provide point-to-multipoint measurement capabilities.
このドキュメントで説明されているLMおよびDMプロトコルは、単一のノード（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.
[RFC3270]および[RFC5462]で指定されているように、差別化されたサービスアーキテクチャの形式のサービス品質（QOS）機能はMPLSに適用されます。さまざまなクラスのトラフィックは、MPLSラベルスタックエントリ（LSE）の3ビットトラフィッククラス（TC）フィールドによって区別されます。遅延測定は、トラフィッククラスごとに適用され、DMメッセージに先行するG-achラベル（GAL）の上のLSEのTC値は重要です。パケットの損失は、チャネル全体または特定のトラフィッククラスのいずれかに関して測定できます。
The location of the measurement points for loss and delay within the sending and receiving nodes is implementation dependent but directly affects the nature of the measurements. For example, a sending implementation may or may not consider a packet to be "lost", for LM purposes, that was discarded prior to transmission for queuing-
送信および受信ノード内の損失と遅延の測定ポイントの位置は実装に依存しますが、測定の性質に直接影響します。たとえば、送信の実装は、LMの目的のために、キューイングの送信前に破棄されたLMの目的で、パケットを「失われた」と考える場合と見なされない場合があります。
related reasons; conversely, a receiving implementation may or may not consider a packet to be "lost", for LM purposes, if it was physically received but discarded during receive-path processing. The location of delay measurement points similarly determines what, precisely, is being measured. The principal consideration here is that the behavior of an implementation in these respects MUST be made clear to the user.
関連する理由。逆に、受信の実装は、LMの目的のために、パケットが「失われている」と見なされる場合と見なされます。遅延測定ポイントの位置は、同様に、正確に測定されているものを決定します。ここでの主な考慮事項は、これらの点で実装の動作をユーザーに明確にする必要があることです。
Equal Cost Multipath (ECMP) is the behavior of distributing packets across multiple alternate paths toward a destination. The use of ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical result of ECMP being performed on an LSP that is subject to delay measurement will be that only the delay of one of the available paths is, and can be, measured.
等しいコストマルチパス（ECMP）は、宛先に向かって複数の代替パスにわたってパケットを配布する動作です。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のツールを開発する際にこれらの同期要件を考慮し、この点でユーザーに明確にする必要があります。
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スコープをユーザーに明確にする必要があり、チャネルエンドポイントのスコープが一致するように注意する必要があります。
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ヘッダーが続きません。
The fixed-format portion of a message MAY be followed by a block of Type-Length-Value (TLV) fields. The TLV block provides an extensible way of attaching subsidiary information to LM and DM messages. Several such TLV fields are defined below.
メッセージの固定フォーマット部分の後に、タイプ長値（TLV）フィールドのブロックが続く場合があります。TLVブロックは、子会社情報をLMおよびDMメッセージに添付する拡張可能な方法を提供します。そのようなTLVフィールドのいくつかを以下に定義します。
All integer values for fields defined in this document SHALL be encoded in network byte order.
このドキュメントで定義されているフィールドのすべての整数値は、ネットワークバイト順序でエンコードされなければなりません。
The format of a Loss Measurement message, which follows the Associated Channel Header (ACH), is as follows:
関連するチャネルヘッダー（ACH）に続く損失測定メッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DFlags| OTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loss Measurement Message Format
損失測定メッセージ形式
Reserved fields MUST be set to 0 and ignored upon receipt. The possible values for the remaining fields are as follows.
予約済みフィールドは0に設定し、受領時に無視する必要があります。残りのフィールドの可能な値は次のとおりです。
Field Meaning
--------------------- -----------------------------------------------
Version Protocol version
Flags Message control flags
Control Code Code identifying the query or response type
Message Length Total length of this message in bytes
Data Format Flags Flags specifying the format of message data
(DFlags)
Origin Timestamp Format of the Origin Timestamp field
Format (OTF)
Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier
Differentiated Differentiated Services Code Point (DSCP) being
Services (DS) Field measured
Origin Timestamp 64-bit field for query message transmission
timestamp
Counter 1-4 64-bit fields for LM counter values
TLV Block Optional block of Type-Length-Value fields
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：通知 - データ形式が無効です。クエリが処理されたことを示しますが、この応答のデータフィールドの形式は一貫性がない場合があります。したがって、これらのデータフィールドを測定に使用してはなりません。
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.
セッション識別子：クエリで任意に設定し、応答でコピーされます。このフィールドは、一連のメッセージで構成される測定操作（セッションとも呼ばれます）を一意に識別します。シーケンス内のすべてのメッセージには、同じセッション識別子があります。
DS: When the T flag is set to 1, this field is set to the DSCP value [RFC3260] that corresponds to the traffic class being measured. For MPLS, where the traffic class of a channel is identified by the three-bit Traffic Class in the channel's LSE [RFC5462], this field
DS：Tフラグが1に設定されると、このフィールドは測定されているトラフィッククラスに対応するDSCP値[RFC3260]に設定されます。チャネルのトラフィッククラスがチャネルのLSE [RFC5462]の3ビットトラフィッククラスによって識別されるMPLSの場合、このフィールド
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.
そのトラフィッククラスに対応するクラスセレクターCodePoint [RFC2474]に設定する必要があります。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ビットのフィールドに書き込まれます。この場合、フィールドの高次32ビットは0に設定する必要があります。
TLV Block: Zero or more TLV fields.
TLVブロック：ゼロ以上のTLVフィールド。
The format of a Delay Measurement message, which follows the Associated Channel Header (ACH), is as follows:
関連するチャネルヘッダー（ACH）に続く遅延測定メッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイムスタンプ1-4 64ビットタイムスタンプ値TLVブロックタイプ長値フィールドのオプションブロック
Reserved fields MUST be set to 0 and ignored upon receipt. The possible values for the remaining fields are as follows.
予約済みフィールドは0に設定し、受領時に無視する必要があります。残りのフィールドの可能な値は次のとおりです。
Version: Currently set to 0.
バージョン：現在0に設定しています。
Flags: As specified in Section 3.1. The T flag in a DM message is set to 1.
フラグ：セクション3.1で指定されています。DMメッセージのTフラグは1に設定されています。
Control Code: As specified in Section 3.1.
制御コード：セクション3.1で指定されています。
Message Length: Set to the total length of this message in bytes, including the Version, Flags, Control Code, and Message Length fields as well as the TLV Block, if any.
メッセージの長さ：バージョン、フラグ、コントロールコード、メッセージの長さフィールド、およびTLVブロックがある場合など、このメッセージの全長にバイトで設定されます。
Querier Timestamp Format: The format of the timestamp values written by the querier, as specified in Section 3.4.
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ビットタイムスタンプフィールドにエンコードされます。フィールド内の残りの64 -N低次ビットは0に設定し、フィールドを読むときは無視する必要があります。
To ensure that it is possible to find an interoperable mode between implementations, it is necessary to select one timestamp format as the default. The timestamp format chosen as the default is the truncated IEEE 1588 PTP format (format code 3 in the list above); this format MUST be supported. The rationale for this choice is discussed in Appendix A. Implementations SHOULD also be capable of reading timestamps written in NTPv4 64-bit format and reconciling them internally with PTP timestamps for measurement purposes. Support for other timestamp formats is OPTIONAL.
実装間で相互運用可能なモードを見つけることができることを確認するには、デフォルトとして1つのタイムスタンプ形式を選択する必要があります。デフォルトとして選択されたタイムスタンプ形式は、切り捨てられたIEEE 1588 PTP形式（上記のリストのフォーマットコード3）です。この形式をサポートする必要があります。この選択の理論的根拠については、付録Aで説明しています。実装は、ntpv4 64ビット形式で書かれたタイムスタンプを読み取り、測定目的でPTPタイムスタンプと内部的に調整することもできます。他のタイムスタンプ形式のサポートはオプションです。
The implementation MUST make clear which timestamp formats it supports and the extent of its support for computation with and reconciliation of different formats for measurement purposes.
実装により、どのタイムスタンプがサポートするタイムスタンプ形式と、測定目的で異なる形式の計算と調整のサポートの範囲を明確にする必要があります。
The TLV Block in LM and DM messages consists of zero or more objects with the following format:
LMおよびDMメッセージのTLVブロックは、次の形式のゼロ以上のオブジェクトで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
認識されていない必須TLVオブジェクトを含むクエリメッセージを受信すると、受信者はサポートされていない必須のTLVオブジェクトエラーコードで応答する必要があります。
The types defined are as follows:
定義されたタイプは次のとおりです。
Type Definition
-------------- ---------------------------------
Mandatory
0 Padding - copy in response
1 Return Address
2 Session Query Interval
3 Loopback Request
4-126 Unallocated
127 Experimental use
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.
複数のパディングオブジェクトが存在する場合があります。その場合、それらは隣接する必要があります。パディングオブジェクトの値フィールドは任意です。
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.
アドレスファミリフィールドはアドレスのタイプを示し、「IANAアドレスファミリ番号」レジストリの割り当てられた値の1つに設定されます。
The Source and Destination Address objects indicate the addresses of the sender and the intended recipient of the message, respectively. The Source Address of a query message SHOULD be used as the destination for an out-of-band response unless some other out-of-band response mechanism has been configured, and unless a Return Address object is present, in which case the Return Address specifies the target of the response. The Return Address object MUST NOT appear in a response.
ソースおよび宛先アドレスオブジェクトは、それぞれ送信者のアドレスとメッセージの受信者のアドレスを示します。クエリメッセージのソースアドレスは、他の帯域外の応答メカニズムが構成されていない限り、および返信アドレスオブジェクトが存在しない限り、帯域外の応答メカニズムが構成されていない限り、バンド外の応答の宛先として使用する必要があります。応答のターゲットを指定します。返信アドレスオブジェクトは応答に表示されてはなりません。
The Loopback Request object, when included in a query, indicates a request that the query message be returned to the sender unmodified. This object has a Length of 0.
ループバック要求オブジェクトは、クエリに含まれている場合、クエリメッセージが変更されていない送信者に返されるという要求を示します。このオブジェクトの長さは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.
Responderから反射クエリメッセージを受け取ったときに、Querierはメッセージを再送信してはなりません。ソースアドレスオブジェクトなどの元のクエリソースを一意に識別する情報を含めることができます。クエリエは、ファーエンドによって開始されたループバッククエリから独自のループバッククエリの1つを区別できます。
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:
この時間間隔は、特定の測定セッションでの連続したクエリメッセージ間の間隔を示します。セッションクエリ間隔（SQI）オブジェクトの目的は、測定セッションのクエリと応答者がクエリレートに同意できるようにすることです。このオブジェクトを処理する手順は次のとおりです。
1. The querier notifies the responder that it wishes to be informed of the responder's minimum query interval for this session by including the SQI object in its query messages, with a Value of 0.
1. 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. QuerierがSQIオブジェクトを含む応答を受信すると、SQIオブジェクトで指定された値以上のセッションのクエリ間隔を選択し、それに応じてクエリ送信レートを調整します。選択したクエリ間隔に等しい値。これらの後続のクエリのいずれかに対する応答が受信されると、Querierは、選択されたクエリ間隔をレスポンダーに承認され、このセッションに関連付けられたクエリにSQIオブジェクトを含めることを停止する可能性があると推測します。
Similar procedures allow the query rate to be changed during the course of the session by either the querier or the responder. For example, to inform the querier of a change in the minimum supported query interval, the responder begins including a corresponding SQI object in its responses, and the querier adjusts its query rate if necessary and includes a corresponding SQI object in its queries until a response is received.
同様の手順により、セッション中にクエリエまたはレスポンダーのいずれかによってクエリレートが変更されます。たとえば、サポートされているクエリ間隔の変更をクエリエに通知するために、応答者は応答に対応するSQIオブジェクトを含めて開始し、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.
応答が要求されるセッションが開始されると、QuerierはSession Responsetimeoutと呼ばれるタイマーを初期化する必要があります。これは、セッションを放棄し、タイムアウトが発生したことをユーザーに通知する前に、クエリエが応答を待つ時間を示します。このタイマーはセッションの寿命を維持し、セッションの応答メッセージが受信されるたびにリセットされます。
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つのクラスに大きく該当します。回復が可能な一時的な例外と、セッションの終了を必要とする致命的な例外です。例外が発生した場合、レスポンダーは、それぞれ例外が過渡的または致命的であるかどうかに応じて、適切な通知またはエラー制御コードを使用して応答を生成する必要があります。Querierがエラー応答を受信すると、セッションを終了し、ユーザーに通知する必要があります。
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.
セッションを開始するとき、Querierはセッションクエリ間隔メカニズム（セクション3.5.4）を使用して、相互に快適なクエリレートをレスポンダーと確立する必要があります。レスポンダーは、レート制限メカニズムを採用して、過度の量のクエリメッセージを受信する可能性を防ぐ必要があります。
An LM operation for a particular channel consists of sending a sequence (LM[1], LM[2], ...) of LM query messages over the channel at a specific rate and processing the responses received, if any. As described in Section 2.2, the packet loss associated with the channel during the operation is computed as a delta between successive messages; these deltas can be accumulated to obtain a running total of the packet loss for the channel or be used to derive related metrics such as the average loss rate.
特定のチャネルのLM操作は、特定のレートでチャネル上のLMクエリメッセージのシーケンス（LM [1]、LM [2]、...）の送信と、受け取った応答（ある場合）の処理で構成されます。セクション2.2で説明されているように、操作中のチャネルに関連するパケット損失は、連続したメッセージ間のデルタとして計算されます。これらのデルタを蓄積して、チャネルのパケット損失の合計を実行するか、平均損失率などの関連するメトリックを導出するために使用できます。
The query message transmission rate MUST be sufficiently high, given the LM message counter size (which can be either 32 or 64 bits) and the speed and minimum packet size of the underlying channel, that the ambiguity condition noted in Section 2.2 cannot arise. In evaluating this rate, the implementation SHOULD assume that the counter size is 32 bits unless explicitly configured otherwise or unless (in the case of a bidirectional channel) all local and remote interfaces involved in the LM operation are known to be 64-bit-capable, which can be inferred from the value of the X flag in an LM response.
LMメッセージカウンターサイズ（32または64ビットのいずれか）と基礎となるチャネルの速度と最小パケットサイズを考えると、クエリメッセージの伝送速度は十分に高くなければなりません。このレートを評価する際に、実装は、LM操作に関与するすべてのローカルおよびリモートインターフェイスが64ビット対応であることが知られている場合、または明示的に構成されていない限り、または明示的に構成されていない限り、カウンターサイズが32ビットであると想定する必要があります。、LM応答のXフラグの値から推測できます。
When transmitting an LM Query, the Version field MUST be set to 0. The R flag MUST be set to 0. The T flag SHALL be set to 1 if, and only if, the measurement is specific to a particular traffic class, in which case the DS field SHALL identify that traffic class.
LMクエリを送信する場合、バージョンフィールドを0に設定する必要があります。Rフラグを0に設定する必要があります。Tフラグは、測定が特定のトラフィッククラスに固有の場合にのみ1に設定する必要があります。ケースDSフィールドは、トラフィッククラスを特定するものとします。
The X flag MUST be set to 1 if the transmitting interface writes 64-bit LM counters and otherwise MUST be set to 0 to indicate that 32-bit counters are written. The B flag SHALL be set to 1 to indicate that the counter fields contain octet counts or to 0 to indicate packet counts.
送信インターフェイスが64ビットLMカウンターを書き込む場合は、Xフラグを1に設定する必要があります。Bフラグは、カウンターフィールドにオクテットカウントが含まれていることを示すために1に設定する必要があります。
The Control Code field MUST be set to one of the values for Query messages listed in Section 3.1; if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: In-band Response Requested).
制御コードフィールドは、セクション3.1にリストされているクエリメッセージの値の1つに設定する必要があります。チャネルが単方向である場合、このフィールドを0x0に設定してはなりません（クエリ：インバンド応答が要求されます）。
The Session Identifier field can be set arbitrarily.
セッション識別子フィールドは任意に設定できます。
The Origin Timestamp field SHALL be set to the time at which this message is transmitted, and the Origin Timestamp Format field MUST be set to indicate its format, according to Section 3.4.
Origin Timestampフィールドは、このメッセージが送信される時間に設定され、セクション3.4に従って、その形式を示すようにオリジンタイムスタンプ形式のフィールドを設定する必要があります。
The Counter 1 field SHOULD be set to the total count of units (packets or octets, according to the B flag) transmitted over the channel prior to this LM Query, or to 0 if this is the beginning of a measurement session for which counter data is not yet available. The Counter 2 field MUST be set to 0. If a response was previously received in this measurement session, the Counter 1 and Counter 2 fields of the most recent such response MAY be copied to the Counter 3 and Counter 4 fields, respectively, of this query; otherwise, the Counter 3 and Counter 4 fields MUST be set to 0.
カウンター1フィールドは、このLMクエリの前にチャネル上に送信されたユニットの合計カウント（パケットまたはオクテット）に設定する必要があります。まだ利用できません。カウンター2フィールドは0に設定する必要があります。この測定セッションで応答が以前に受信された場合、最新のそのような応答のカウンター1とカウンター2フィールドは、これのカウンター3とカウンター4フィールドにそれぞれコピーできます。クエリ;それ以外の場合、カウンター3とカウンター4フィールドは0に設定する必要があります。
Upon receipt of an LM Query message, the Counter 2 field SHOULD be set to the total count of units (packets or octets, according to the B flag) received over the channel prior to this LM Query. If the receiving interface writes 32-bit LM counters, the X flag MUST be set to 0.
LMクエリメッセージを受信すると、このLMクエリの前にチャネル上で受け取ったユニットの合計カウント（パケットまたはオクテット）に設定する必要があります。受信インターフェイスが32ビットLMカウンターを書き込む場合、Xフラグを0に設定する必要があります。
At this point, the LM Query message must be inspected. If the Control Code field is set to 0x2 (No Response Requested), an LM Response message MUST NOT be transmitted. If the Control Code field is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band Response Requested), then an in-band or out-of-band response, respectively, SHOULD be transmitted unless this has been prevented by an administrative, security, or congestion control mechanism.
この時点で、LMクエリメッセージを検査する必要があります。制御コードフィールドが0x2に設定されている場合（応答は要求されません）、LM応答メッセージを送信してはなりません。制御コードフィールドが0x0（インバンド応答が要求された）または0x1（帯域外応答が要求されている）に設定されている場合、これがそれぞれ帯域または帯域外の応答を送信する必要があります。管理、セキュリティ、または混雑制御メカニズムによって防止されます。
In the case of a fatal exception that prevents the requested measurement from being made, the error SHOULD be reported, via either a response, if one was requested, or else as a notification to the user.
要求された測定が行われるのを防ぐ致命的な例外の場合、要求された場合、またはユーザーへの通知として、応答を介してエラーを報告する必要があります。
When constructing a Response to an LM Query, the Version field MUST be set to 0. The R flag MUST be set to 1. The value of the T flag MUST be copied from the LM Query.
LMクエリへの応答を構築する場合、バージョンフィールドを0に設定する必要があります。Rフラグを1に設定する必要があります。Tフラグの値はLMクエリからコピーする必要があります。
The X flag MUST be set to 0 if the transmitting interface writes 32-bit LM counters; otherwise, its value MUST be copied from the LM Query. The B flag MUST be copied from the LM Query.
送信インターフェイスが32ビットLMカウンターを書き込む場合、Xフラグを0に設定する必要があります。それ以外の場合、その値はLMクエリからコピーする必要があります。Bフラグは、LMクエリからコピーする必要があります。
The Session Identifier, Origin Timestamp, and Origin Timestamp Format fields MUST be copied from the LM Query. The Counter 1 and Counter 2 fields from the LM Query MUST be copied to the Counter 3 and Counter 4 fields, respectively, of the LM Response.
セッション識別子、オリジンタイムスタンプ、およびオリジンタイムスタンプ形式のフィールドは、LMクエリからコピーする必要があります。LMクエリからのカウンター1およびカウンター2フィールドは、LM応答のカウンター3とカウンター4フィールドにそれぞれコピーする必要があります。
The Control Code field MUST be set to one of the values for Response messages listed in Section 3.1. The value 0x10 (Unspecified Error) SHOULD NOT be used if one of the other more specific error codes is applicable.
制御コードフィールドは、セクション3.1にリストされている応答メッセージの値の1つに設定する必要があります。他のより具体的なエラーコードのいずれかが適用できる場合、値0x10（不特定エラー）は使用しないでください。
If the response is transmitted in-band, the Counter 1 field SHOULD be set to the total count of units transmitted over the channel prior to this LM Response. If the response is transmitted out-of-band, the Counter 1 field MUST be set to 0. In either case, the Counter 2 field MUST be set to 0.
応答がバンド内で送信される場合、このLM応答の前に、チャネル上に送信されるユニットの合計カウントにカウンター1フィールドを設定する必要があります。応答が帯域外に送信される場合、カウンター1フィールドを0に設定する必要があります。どちらの場合も、カウンター2フィールドを0に設定する必要があります。
Upon in-band receipt of an LM Response message, the Counter 2 field is set to the total count of units received over the channel prior to this LM Response. If the receiving interface writes 32-bit LM counters, the X flag is set to 0. (Since the life of the LM message in the network has ended at this point, it is up to the receiver whether these final modifications are made to the packet. If the message is to be forwarded on for external post-processing (Section 2.9.7), then these modifications MUST be made.)
LM応答メッセージを受け取ると、カウンター2フィールドは、このLM応答の前にチャネル上で受信したユニットの合計カウントに設定されます。受信インターフェイスが32ビットLMカウンターを書き込む場合、Xフラグは0に設定されています（ネットワーク内のLMメッセージの寿命がこの時点で終了したため、これらの最終的な変更が行われるかどうかは受信者次第です。パケット。メッセージが外部後処理のために転送される場合（セクション2.9.7）、これらの変更を行う必要があります。）
Upon out-of-band receipt of an LM Response message, the Counter 1 and Counter 2 fields MUST NOT be used for purposes of loss measurement.
LM応答メッセージを帯域外に受信すると、カウンター1とカウンター2フィールドを、損失測定の目的に使用してはなりません。
If the Control Code in an LM Response is anything other than 0x1 (Success), the counter values in the response MUST NOT be used for purposes of loss measurement. If the Control Code indicates an error condition, or if the response message is invalid, the LM operation MUST be terminated and an appropriate notification to the user generated.
LM応答の制御コードが0x1以外のものである場合（成功）、応答のカウンター値は、損失測定の目的に使用してはなりません。制御コードがエラー条件を示した場合、または応答メッセージが無効である場合、LM操作を終了し、生成されたユーザーに適切な通知を終了する必要があります。
Calculation of packet loss is carried out according to the procedures in Section 2.2. The X flag in an LM message informs the device performing the calculation whether to perform 32-bit or 64-bit arithmetic. If the flag value is equal to 1, all interfaces involved in the LM operation have written 64-bit counter values, and 64-bit
セクション2.2の手順に従って、パケット損失の計算が実行されます。LMメッセージのXフラグは、32ビットまたは64ビットの算術を実行するかどうかを計算を実行するデバイスに通知します。フラグ値が1に等しい場合、LM操作に関与するすべてのインターフェイスに64ビットのカウンター値と64ビットが書かれています
arithmetic can be used. If the flag value is equal to 0, at least one interface involved in the operation has written a 32-bit counter value, and 32-bit arithmetic is carried out using the low-order 32 bits of each counter value.
算術を使用できます。フラグ値が0に等しい場合、操作に関与する少なくとも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フラグのセマンティクスにより、すべてのデバイスがカウンターサイズのサポートに関係なく相互運用できることに注意してください。したがって、実装は、このフラグの値に基づいてエラー応答を生成してはなりません。
The TC field of the LSE corresponding to the channel (e.g., LSP) being measured SHOULD be set to a traffic class equal to or better than the best TC within the measurement scope to minimize the chance of out-of-order conditions.
測定されているチャネル（例：LSP）に対応するLSEのTCフィールドは、測定範囲内で最適なTC以上のトラフィッククラスに設定する必要があります。
By default, direct LM MUST exclude packets transmitted and received over the Generic Associated Channel (G-ACh). An implementation MAY provide the means to alter the direct LM scope to include some or all G-ACh messages. Care must be taken when altering the LM scope to ensure that both endpoints are in agreement.
デフォルトでは、Direct LMは、汎用関連チャネル（G-ach）を介して送信および受信されたパケットを除外する必要があります。実装は、直接LMスコープを変更して、一部またはすべてのG-achメッセージを含める手段を提供する場合があります。両方のエンドポイントが一致していることを確認するために、LMスコープを変更するときは注意が必要です。
In the case of inferred LM, the packets counted for LM consist of test messages generated for this purpose, or of some other class of packets deemed to provide a good proxy for data packets flowing over the channel. The specification of test protocols and proxy packets is outside the scope of this document, but some guidelines are discussed below.
推定LMの場合、LMにカウントされるパケットは、この目的のために生成されたテストメッセージ、またはチャネル上に流れるデータパケットの優れたプロキシを提供するとみなされる他のクラスのパケットで構成されています。テストプロトコルとプロキシパケットの仕様は、このドキュメントの範囲外ですが、いくつかのガイドラインについては以下に説明します。
An identifier common to both the test or proxy messages and the LM messages may be required to make correlation possible. The combined value of the Session Identifier and DS fields SHOULD be used for this purpose when possible. That is, test messages in this case will include a 32-bit field that can carry the value of the combined Session Identifier + DS field present in LM messages. When TC-specific LM is conducted, the DS field of the LSE in the label stack of a test message corresponding to the channel (e.g., LSP) over which the message is sent MUST correspond to the DS value in the associated LM messages.
テストメッセージまたはプロキシメッセージとLMメッセージの両方に共通する識別子は、相関を可能にするために必要な場合があります。セッション識別子とDSフィールドの合計値は、可能であればこの目的に使用する必要があります。つまり、この場合のテストメッセージには、LMメッセージに存在する複合セッション識別子DSフィールドの値を運ぶことができる32ビットフィールドが含まれます。TC固有のLMを実行すると、メッセージが送信されるチャネル（例えば、LSP）に対応するテストメッセージのラベルスタックのLSEのDSフィールドは、関連するLMメッセージのDS値に対応する必要があります。
A separate test message protocol SHOULD include a timeout value in its messages that informs the responder when to discard any state associated with a specific test.
個別のテストメッセージプロトコルには、特定のテストに関連する状態を廃棄するタイミングをレスポンダーに通知するタイムアウト値をメッセージに含める必要があります。
Because an LM operation consists of a message sequence with state maintained from one message to the next, LM is subject to the effects of lost messages and misordered packets in a way that DM is not. Because this state exists only on the querier, the handling of these conditions is, strictly speaking, a local matter. This section, however, presents recommended procedures for handling such conditions. Note that in the absence of ECMP, packet misordering within a traffic class is a relatively rare event.
LM操作は、あるメッセージから次のメッセージに維持されている状態を持つメッセージシーケンスで構成されているため、LMは、DMがそうでない方法で失われたメッセージと誤ったパケットの効果の影響を受けます。この状態はクエリエにのみ存在するため、これらの条件の取り扱いは、厳密に言えば、地元の問題です。ただし、このセクションでは、そのような条件を処理するための推奨手順を示します。ECMPがない場合、トラフィッククラス内でのパケットの誤用は比較的まれなイベントであることに注意してください。
The first kind of anomaly that may occur is that one or more LM messages may be lost in transit. The effect of such loss is that when an LM Response is next received at the querier, an unambiguous interpretation of the counter values it contains may be impossible, for the reasons described at the end of Section 2.2. Whether this is so depends on the number of messages lost and the other variables mentioned in that section, such as the LM message rate and the channel parameters.
発生する可能性のある最初の種類の異常は、輸送中に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.
実装は、間隔が測定不能と見なされる単一の計算で測定された失われたパケットの上限を示すしきい値を特定する必要があります。これは「maxlmintervallossしきい値」と呼ばれます。このしきい値は、チャネルが間隔で送信できる最大数（またはバイト）よりも高くないはずであることは明らかですが、それは低い場合があります。測定不可能な間隔に遭遇すると、LM状態（つまり、受信した最後のLMメッセージのデータ値）を破棄する必要があります。
With regard to lost LM messages, the MaxLMInterval (see Section 2.2) indicates the maximum amount of time that can elapse before the LM state is discarded. If some messages are lost, but a message is
LMメッセージの紛失に関しては、Maxlminterval（セクション2.2を参照）は、LM状態が破棄される前に経過する可能性のある最大時間を示しています。いくつかのメッセージが失われたが、メッセージは
subsequently received within MaxLMInterval, its timestamp or sequence number will quantify the loss, and it MAY still be used for measurement, although the measurement interval will in this case be longer than usual.
その後、maxlminterval内で受信され、そのタイムスタンプまたはシーケンス数は損失を定量化し、測定に使用される可能性がありますが、この場合は通常よりも長くなります。
If an LM message is received that has a timestamp less than or equal to the timestamp of the last LM message received, this indicates that an exception has occurred, and the current interval SHOULD be considered unmeasurable unless the implementation has some other way of handling this condition.
最後のLMメッセージのタイムスタンプ以下のタイムスタンプが受信されたLMメッセージが受信された場合、これは例外が発生したことを示し、実装にこれを処理する他の方法がない限り、現在の間隔は測定不能と見なされるべきです。調子。
When transmitting a DM Query, the Version and Reserved fields MUST be set to 0. The R flag MUST be set to 0, the T flag MUST be set to 1, and the remaining flag bits MUST be set to 0.
DMクエリを送信する場合、バージョンと予約フィールドを0に設定する必要があります。Rフラグを0に設定する必要があり、tフラグを1に設定する必要があり、残りのフラグビットは0に設定する必要があります。
The Control Code field MUST be set to one of the values for Query messages listed in Section 3.1; if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: In-band Response Requested).
制御コードフィールドは、セクション3.1にリストされているクエリメッセージの値の1つに設定する必要があります。チャネルが単方向である場合、このフィールドを0x0に設定してはなりません（クエリ：インバンド応答が要求されます）。
The Querier Timestamp Format field MUST be set to the timestamp format used by the querier when writing timestamp fields in this message; the possible values for this field are listed in Section 3.4. The Responder Timestamp Format and Responder's Preferred Timestamp Format fields MUST be set to 0.
このメッセージにタイムスタンプフィールドを書く際に、クエリエが使用するタイムスタンプ形式に設定する必要があります。このフィールドの可能な値は、セクション3.4にリストされています。応答者のタイムスタンプ形式とレスポンダーの優先タイムスタンプ形式フィールドは、0に設定する必要があります。
The Session Identifier field can be set arbitrarily. The DS field MUST be set to the traffic class being measured.
セッション識別子フィールドは任意に設定できます。DSフィールドは、測定されているトラフィッククラスに設定する必要があります。
The Timestamp 1 field SHOULD be set to the time at which this DM Query is transmitted, in the format indicated by the Querier Timestamp Format field. The Timestamp 2 field MUST be set to 0. If a response was previously received in this measurement session, the Timestamp 1 and Timestamp 2 fields of the most recent such response MAY be copied to the Timestamp 3 and Timestamp 4 fields, respectively, of this query; otherwise, the Timestamp 3 and Timestamp 4 fields MUST be set to 0.
タイムスタンプ1フィールドは、クエリエタイムスタンプ形式のフィールドで示される形式で、このDMクエリが送信される時間に設定する必要があります。タイムスタンプ2フィールドは0に設定する必要があります。この測定セッションで応答が以前に受信された場合、最新の応答のタイムスタンプ1とタイムスタンプ2フィールドは、これのタイムスタンプ3とタイムスタンプ4フィールドにそれぞれコピーできます。クエリ;それ以外の場合、タイムスタンプ3およびタイムスタンプ4フィールドは0に設定する必要があります。
Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be set to the time at which this DM Query was received.
DMクエリメッセージを受信すると、このDMクエリが受信された時間にタイムスタンプ2フィールドを設定する必要があります。
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クエリメッセージを検査する必要があります。制御コードフィールドが0x2に設定されている場合（応答は要求されません）、DM応答メッセージを送信してはなりません。制御コードフィールドが0x0（インバンド応答が要求された）または0x1（帯域外応答が要求されている）に設定されている場合、これがそれぞれ帯域または帯域外の応答を送信する必要があります。管理、セキュリティ、または混雑制御メカニズムによって防止されます。
In the case of a fatal exception that prevents the requested measurement from being made, the error SHOULD be reported, via either a response, if one was requested, or else as a notification to the user.
要求された測定が行われるのを防ぐ致命的な例外の場合、要求された場合、またはユーザーへの通知として、応答を介してエラーを報告する必要があります。
When constructing a Response to a DM Query, the Version and Reserved fields MUST be set to 0. The R flag MUST be set to 1, the T flag MUST be set to 1, and the remaining flag bits MUST be set to 0.
DMクエリへの応答を構築する場合、バージョンと予約フィールドを0に設定する必要があります。Rフラグは1に設定する必要があり、tフラグは1に設定する必要があり、残りのフラグビットは0に設定する必要があります。
The Session Identifier and Querier Timestamp Format (QTF) fields MUST be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4 fields, respectively, of the DM Response.
セッション識別子およびクエリエタイムスタンプ形式（QTF）フィールドは、DMクエリからコピーする必要があります。DMクエリからのタイムスタンプ1およびタイムスタンプ2フィールドは、DM応答のTimestamp 3とTimestamp 4フィールドにそれぞれコピーする必要があります。
The Responder Timestamp Format (RTF) field MUST be set to the timestamp format used by the responder when writing timestamp fields in this message, i.e., Timestamp 4 and (if applicable) Timestamp 1; the possible values for this field are listed in Section 3.4. Furthermore, the RTF field MUST be set equal to either the QTF or the RPTF field. See Section 4.3.5 for guidelines on the selection of the value for this field.
このメッセージでタイムスタンプフィールド、つまりタイムスタンプ4および（該当する場合）タイムスタンプ1を記述する際に、レスポンダーがレスポンダーが使用するタイムスタンプ形式に設定する必要があります。このフィールドの可能な値は、セクション3.4にリストされています。さらに、RTFフィールドは、QTFまたはRPTFフィールドのいずれかに等しく設定する必要があります。このフィールドの値の選択に関するガイドラインについては、セクション4.3.5を参照してください。
The Responder's Preferred Timestamp Format (RPTF) field MUST be set to one of the values listed in Section 3.4 and SHOULD be set to indicate the timestamp format with which the responder can provide the best accuracy for purposes of delay measurement.
Responderの優先タイムスタンプ形式（RPTF）フィールドは、セクション3.4にリストされている値の1つに設定する必要があり、レスポンダーが遅延測定の目的で最良の精度を提供できるタイムスタンプ形式を示すように設定する必要があります。
The Control Code field MUST be set to one of the values for Response messages listed in Section 3.1. The value 0x10 (Unspecified Error) SHOULD NOT be used if one of the other more specific error codes is applicable.
制御コードフィールドは、セクション3.1にリストされている応答メッセージの値の1つに設定する必要があります。他のより具体的なエラーコードのいずれかが適用できる場合、値0x10（不特定エラー）は使用しないでください。
If the response is transmitted in-band, the Timestamp 1 field SHOULD be set to the time at which this DM Response is transmitted. If the response is transmitted out-of-band, the Timestamp 1 field MUST be set to 0. In either case, the Timestamp 2 field MUST be set to 0.
応答がバンド内で送信される場合、タイムスタンプ1フィールドは、このDM応答が送信される時間に設定する必要があります。応答が帯域外に送信される場合、タイムスタンプ1フィールドを0に設定する必要があります。どちらの場合も、タイムスタンプ2フィールドを0に設定する必要があります。
If the response is transmitted in-band and the Control Code in the message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields MUST have the same format, which will be the format indicated in the Responder Timestamp Format field.
応答がバンド内で送信され、メッセージの制御コードが0x1（成功）の場合、タイムスタンプ1とタイムスタンプ4フィールドには同じ形式が必要です。
Upon in-band receipt of a DM Response message, the Timestamp 2 field is set to the time at which this DM Response was received. (Since the life of the DM message in the network has ended at this point, it is up to the receiver whether this final modification is made to the packet. If the message is to be forwarded on for external post-processing (Section 2.9.7), then these modifications MUST be made.)
DM応答メッセージを受信すると、Timestamp 2フィールドは、このDM応答が受信された時間に設定されます。（ネットワーク内のDMメッセージの寿命がこの時点で終了したため、この最終的な変更がパケットに対して行われるかどうかは受信者次第です。7）、これらの変更を行う必要があります。）
Upon out-of-band receipt of a DM Response message, the Timestamp 1 and Timestamp 2 fields MUST NOT be used for purposes of delay measurement.
DM応答メッセージを帯域外に受信すると、タイムスタンプ1およびタイムスタンプ2フィールドは、遅延測定の目的に使用してはなりません。
If the Control Code in a DM Response is anything other than 0x1 (Success), the timestamp values in the response MUST NOT be used for purposes of delay measurement. If the Control Code indicates an error condition, or if the response message is invalid, the DM operation MUST be terminated and an appropriate notification to the user generated.
DM応答の制御コードが0x1以外のもの（成功）以外の場合、応答のタイムスタンプ値を遅延測定の目的に使用してはなりません。制御コードがエラー条件を示した場合、または応答メッセージが無効である場合、DM操作を終了し、生成されたユーザーに適切な通知を終了する必要があります。
In case either the querier or the responder in a DM transaction is capable of supporting multiple timestamp formats, it is desirable to determine the optimal format for purposes of delay measurement on a particular channel. The procedures for making this determination SHALL be as follows.
DMトランザクションのクエリエまたはレスポンダーのいずれかが複数のタイムスタンプ形式をサポートできる場合、特定のチャネルでの遅延測定の目的で最適な形式を決定することが望ましいです。この決定を行う手順は次のとおりです。
Upon sending an initial DM Query over a channel, the querier sets the Querier Timestamp Format (QTF) field to its preferred timestamp format.
チャネル上で最初のDMクエリを送信すると、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).
応答の制御コードは0x1（成功）に設定してはなりません。エラー条件が発生していない限り、制御コードは0x2（通知 - データ形式が無効）に設定する必要があります。
Upon receiving a DM Response, the querier knows from the RTF field in the message whether the responder is capable of supporting its preferred timestamp format: if it is, the RTF will be equal to the QTF. The querier also knows the responder's preferred timestamp format from the RPTF field. The querier can then decide whether to retain its current QTF or to change it and repeat the negotiation procedures.
DM応答を受信すると、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フィールドに対応する値に設定する必要があります。
The combined LM/DM message defined in Section 3.3 allows loss and delay measurement to be carried out simultaneously. This message SHOULD be treated as an LM message that happens to carry additional timestamp data, with the timestamp fields processed as per delay measurement procedures.
セクション3.3で定義されているLM/DMメッセージの組み合わせにより、損失と遅延測定を同時に実行できます。このメッセージは、遅延測定手順に従ってタイムスタンプフィールドが処理され、追加のタイムスタンプデータを掲載するLMメッセージとして扱う必要があります。
This section summarizes the requirements placed on implementations for capabilities disclosure. The purpose of these requirements is to ensure that end users have a clear understanding of implementation
このセクションでは、機能の洞察力の実装に配置された要件をまとめたものです。これらの要件の目的は、エンドユーザーが実装を明確に理解できるようにすることです
capabilities and characteristics that have a direct impact on how loss and delay measurement mechanisms function in specific situations. Implementations are REQUIRED to state:
特定の状況で損失と遅延測定メカニズムがどのように機能するかに直接影響を与える能力と特性。実装は、次のように述べる必要があります。
o METRICS: Which of the following metrics are supported: packet loss, packet throughput, octet loss, octet throughput, average loss rate, one-way delay, round-trip delay, two-way channel delay, packet delay variation.
o メトリック：パケット損失、パケットスループット、オクテット損失、オクテットスループット、平均損失率、一元配置遅延、往復遅延、双方向チャネル遅延、パケット遅延変動。
o MP-LOCATION: The location of loss and delay measurement points with respect to other stages of packet processing, such as queuing.
o MPロケーション：キューイングなどのパケット処理の他の段階に関する損失および遅延測定ポイントの位置。
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操作などの持続的な測定操作を実行する場合、Querierは失われた測定メッセージの数（応答が受信されないクエリ）の数に注意し、対応する測定メッセージの損失のしきい値を設定する必要があります。このしきい値を超えた場合、測定操作は、可能性のある混雑状態を悪化させないように停止する必要があります。この停止には、条件を調査して修正できるように、ユーザーに適切な通知を添付する必要があります。
From the receiver perspective, the main consideration is the possibility of receiving an excessive quantity of measurement messages. An implementation SHOULD employ a mechanism such as rate-limiting to guard against the effects of this case.
受信機の観点から、主な考慮事項は、過剰な量の測定メッセージを受信する可能性です。実装は、このケースの影響を防ぐためにレート制限などのメカニズムを採用する必要があります。
The measurement protocols described in this document are intended to serve as infrastructure to support a wide range of higher-level monitoring and diagnostic applications, from simple command-line
このドキュメントで説明されている測定プロトコルは、Simple Command-lineからの幅広い高レベルの監視および診断アプリケーションをサポートするインフラストラクチャとして機能することを目的としています。
diagnostic tools to comprehensive network performance monitoring and analysis packages. The specific mechanisms and considerations for protocol configuration, initialization, and reporting thus depend on the nature of the application.
包括的なネットワークパフォーマンスの監視および分析パッケージへの診断ツール。したがって、プロトコルの構成、初期化、およびレポートの特定のメカニズムと考慮事項は、アプリケーションの性質に依存します。
In the case of on-demand diagnostics, the diagnostic application may provide parameters such as the measurement type, the channel, the query rate, and the test duration when initiating the diagnostic; results and exception conditions are then reported directly to the application. The system may discard the statistics accumulated during the test after the results have been reported or retain them to provide a historical measurement record.
オンデマンド診断の場合、診断アプリケーションは、診断を開始する際の測定タイプ、チャネル、クエリレート、テスト期間などのパラメーターを提供する場合があります。その後、結果と例外条件がアプリケーションに直接報告されます。システムは、結果が報告された後にテスト中に蓄積された統計を破棄するか、履歴測定記録を提供するためにそれらを保持する場合があります。
Alternatively, measurement configuration may be supplied as part of the channel configuration itself in order to support continuous monitoring of the channel's performance characteristics. In this case, the configuration will typically include quality thresholds depending on the service level agreement, the crossing of which will trigger warnings or alarms, and result reporting and exception notification will be integrated into the system-wide network management and reporting framework.
または、チャネルのパフォーマンス特性の継続的な監視をサポートするために、測定構成自体の一部として測定構成を提供することもできます。この場合、構成には通常、サービスレベルの契約に応じて品質のしきい値が含まれ、その交差は警告またはアラームをトリガーし、結果レポートと例外通知はシステム全体のネットワーク管理とレポートフレームワークに統合されます。
This document describes procedures for the measurement of performance metrics over a pre-existing MPLS path (a pseudowire, LSP, or section). As such, it assumes that a node involved in a measurement operation has previously verified the integrity of the path and the identity of the far end using existing MPLS mechanisms such as Bidirectional Forwarding Detection (BFD) [RFC5884]; tools, techniques, and considerations for securing MPLS paths are discussed in detail in [RFC5920].
このドキュメントでは、既存のMPLSパス（擬似化、LSP、またはセクション）を介したパフォーマンスメトリックの測定の手順について説明します。そのため、測定操作に関与するノードが、双方向転送検出（BFD）[RFC5884]などの既存のMPLSメカニズムを使用して、パスの整合性と遠端のアイデンティティを以前に検証したことを前提としています。MPLSパスを保護するためのツール、技術、および考慮事項については、[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.
そのようなメカニズムが利用できない場合、および測定操作のセキュリティが懸念される場合、このドキュメントで指定されたチャネルタイプでの一般的な関連チャネルメッセージの受信を無効にする必要があります。実装は、チャンネルごとのプロトコルごとにこれらのプロトコルを無効にする機能を提供する必要があります。
Even when the identity of the far end has been verified, the measurement protocols remain vulnerable to injection and man-in-the-middle attacks. The impact of such an attack would be to compromise the quality of performance measurements on the affected path. An attacker positioned to disrupt these measurements is, however, capable of causing much greater damage by disrupting far more critical elements of the network such as the network control plane or user traffic flows. At worst, a disruption of the measurement protocols would interfere with the monitoring of the performance
遠端のアイデンティティが検証されている場合でも、測定プロトコルは注射および中間攻撃に対して脆弱なままです。このような攻撃の影響は、影響を受ける経路でのパフォーマンス測定の質を損なうことです。ただし、これらの測定を破壊するために位置する攻撃者は、ネットワーク制御プレーンやユーザートラフィックフローなど、ネットワークのはるかに重要な要素を破壊することにより、はるかに大きな損害を引き起こすことができます。最悪の場合、測定プロトコルの混乱はパフォーマンスの監視を妨げます
aspects of the service level agreement associated with the path; the existence of such a disruption would imply that a serious breach of basic path integrity had already occurred.
パスに関連するサービスレベル契約の側面。そのような混乱の存在は、基本的な経路の完全性の深刻な違反がすでに発生していることを意味します。
If desired, such attacks can be mitigated by performing basic validation and sanity checks, at the querier, of the counter or timestamp fields in received measurement response messages. The minimal state associated with these protocols also limits the extent of measurement disruption that can be caused by a corrupt or invalid message to a single query/response cycle.
必要に応じて、そのような攻撃は、受信した測定応答メッセージのカウンターまたはタイムスタンプフィールドの基本的な検証と正気チェックを実行することで軽減できます。これらのプロトコルに関連する最小状態は、単一のクエリ/応答サイクルへの破損したメッセージまたは無効なメッセージによって引き起こされる可能性のある測定破壊の程度も制限します。
Cryptographic mechanisms capable of signing or encrypting the contents of the measurement packets without degrading the measurement performance are not currently available. In light of the preceding discussion, the absence of such cryptographic mechanisms does not raise significant security issues.
測定パフォーマンスを分解せずに測定パケットの内容に署名または暗号化できる暗号化メカニズムは現在利用できません。前述の議論に照らして、そのような暗号化メカニズムがないことは、重大なセキュリティの問題を提起しません。
Users concerned with the security of out-of-band responses over IP networks SHOULD employ suitable security mechanisms such as IPsec [RFC4301] to protect the integrity of the return path.
IPネットワークを介したバンド外の応答のセキュリティに関係するユーザーは、リターンパスの整合性を保護するために、IPSEC [RFC4301]などの適切なセキュリティメカニズムを採用する必要があります。
Per this document, IANA has completed the following actions:
このドキュメントに従って、IANAは次のアクションを完了しました。
o Allocation of Channel Types in the "PW Associated Channel Type" registry
o 「PW関連チャネルタイプ」レジストリでのチャネルタイプの割り当て
o Creation of a "Measurement Timestamp Type" registry
o 「測定タイムスタンプタイプ」レジストリの作成
o Creation of an "MPLS Loss/Delay Measurement Control Code" registry
o 「MPLS損失/遅延測定制御コード」レジストリの作成
o Creation of an "MPLS Loss/Delay Measurement Type-Length-Value (TLV) Object" registry
o 「MPLS損失/遅延測定型型（TLV）オブジェクト」レジストリの作成
As per the IANA considerations in [RFC5586], IANA has allocated the following Channel Types in the "PW Associated Channel Type" registry:
[RFC5586]のIANAの考慮事項に従って、IANAは「PW関連チャネルタイプ」レジストリで次のチャネルタイプを割り当てました。
Value Description TLV Follows Reference
------ ---------------------------------------- ----------- ---------
0x000A MPLS Direct Loss Measurement (DLM) No RFC 6374
0x000B MPLS Inferred Loss Measurement (ILM) No RFC 6374
0x000C MPLS Delay Measurement (DM) No RFC 6374
0x000D MPLS Direct Loss and Delay Measurement No RFC 6374
(DLM+DM)
0x000E MPLS Inferred Loss and Delay Measurement No RFC 6374
(ILM+DM)
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。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「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。、および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。、および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。、および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。、および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。、および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。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、1999年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP 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。および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。および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。、および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。、およびL. Andersson、「MPLSネットワークでの等しいコストマルチパス治療を回避」、BCP 128、RFC 4928、2007年6月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「双方向活性測定プロトコル（TWAMP）」、RFC 5357、2008年10月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481] Morton、A。およびB. Claise、「パケット遅延変動適用ステートメント」、RFC 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。、および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。、および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。、および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推奨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