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
Abstract
抽象
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks.
多くのサービスプロバイダのサービスレベル契約（SLA）を測定し、パケット損失及び一方向と双方向の遅延、ならびに遅延変動およびチャネルスループットなどの関連メトリックのパフォーマンス・メトリックを監視する能力に依存します。この測定機能は、それによって、計画、トラブルシューティング、およびネットワークパフォーマンスの評価を容易にする、そのネットワークの性能特性に大きな可視性をオペレータに提供します。この文書では、MPLSネットワークにおけるこれらのパフォーマンス・メトリックの効率的かつ正確な測定を可能にするために、プロトコルメカニズムを指定します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6374.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6374で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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:
この文書は、二つの密接に関連するプロトコル、パケットロス測定（LM）用とパケット遅延測定（DM）のための1つを指定します。これらのプロトコルは、次の特性や能力を持っています：
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).
LMおよびDMプロトコルは、MPLS汎用関連するチャネル（G-ACH）[RFC5586]で動作し、ラベル上の損失、遅延、および関連する指標の測定をサポートOパスを交換（の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.
クエリア - - LMおよびDMプロトコルは、単一のノードを可能にする双方向の測定のための単純なクエリ/応答モデルを使用oを両方向における損失や遅延を測定します。
o The LM and DM protocols use query messages for unidirectional loss and delay measurement. The measurement can be carried out either at the downstream node(s) or at the querier if an out-of-band return path is available.
O LMとDMプロトコルは、一方向の損失や遅延測定のためのクエリーメッセージを使用しています。測定は、下流ノード（単数または複数）で、またはアウトオブバンドリターンパスが利用可能である場合クエリアのいずれかで行うことができます。
o The LM and DM protocols do not require that the transmit and receive interfaces be the same when performing bidirectional measurement.
O LMおよびDMプロトコルがその送信を必要と双方向測定を行う際のインタフェースが同じで受信しません。
o The DM protocol is stateless.
O DMプロトコルはステートレスです。
o The LM protocol is "almost" stateless: loss is computed as a delta between successive messages, and thus the data associated with the last message received must be retained.
oをLMプロトコルは、「ほぼ」ステートレスれる：損失は、連続メッセージ間のデルタとして計算され、したがって、最後に受信したメッセージに関連付けられたデータが保持されなければなりません。
o The LM protocol can perform two distinct kinds of loss measurement: it can measure the loss of specially generated test messages in order to infer the approximate data-plane loss level (inferred measurement) or it can directly measure data-plane packet loss (direct measurement). Direct measurement provides perfect loss accounting, but may require specialized hardware support and is only applicable to some LSP types. Inferred measurement provides only approximate loss accounting but is generally applicable.
O LMプロトコルは、損失測定の二つの異なる種類を実行することができる：近似データプレーン損失レベル（推論計測）を推測するために、それが特別に生成されたテストメッセージの損失を測定することができるか、直接データプレーンパケット損失を測定することができる（直接測定）。直接測定は完璧な損失の会計を提供していますが、特殊なハードウェアのサポートを必要とするかもしれないし、いくつかのLSPタイプにのみ適用されます。推論された測定値はおおよその損失の会計を提供していますが、一般的に適用可能です。
The direct LM method is also known as "frame-based" in the context of Ethernet transport networks [Y.1731]. Inferred LM is a generalization of the "synthetic" measurement approach currently in development for Ethernet networks, in the sense that it allows test messages to be decoupled from measurement messages.
直接LM法は、「フレームベースの」イーサネット・トランスポート・ネットワーク[Y.1731]の文脈におけるとして知られています。推論LMは、テストメッセージは測定メッセージから分離することを可能にするという意味で、現在のイーサネットネットワークの開発における「合成」測定アプローチの一般化です。
o The LM protocol supports measurement in terms of both packet counts and octet counts.
O LMプロトコルは、パケット数およびオクテット数の両面で測定をサポートしています。
o The LM protocol supports both 32-bit and 64-bit counters.
O LMプロトコルは、32ビットと64ビットの両方のカウンタをサポートします。
o The LM protocol can be used to measure channel throughput as well as packet loss.
O LMプロトコルは、チャネルスループット、並びにパケット損失を測定するために使用することができます。
o The DM protocol supports multiple timestamp formats, and provides a simple means for the two endpoints of a bidirectional connection to agree on a preferred format. This procedure reduces to a triviality for implementations supporting only a single timestamp format.
O DMプロトコルは、複数のタイムスタンプフォーマットをサポートし、双方向接続の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.
この図は、2つのノードAとBとの間の双方向チャネルを示し、そして動作はBに送信クエリメッセージから成るA.で行われる測定動作に関連付けられた時間基準点T1-T4を示し、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は、順方向チャネル上のパケット損失を測定し、へのチャネル上の時間T1の前に送信されたパケットのカウントを含むそれぞれがBに対する損失測定（LM）クエリメッセージを送信することにより、方向を逆に配置することができますB（A_TxP）。メッセージがBに到達すると、それは2つの値を追加し、裏面にメッセージを反映する：パケットの数はA（B_RxP）からチャネルを介して前の時間T2に受信されたパケットのカウントがするチャネルを介して前の時間T3に送信します（B_TxP）。応答が到達したとき、それは第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における送信数とB（またはその逆）で受信カウントが最初のメッセージの時間で同期されないこと、及びカウンタラップの効果を制限するので、損失がメッセージ間のデルタの形で計算されます。 。
To measure at A the delay over the channel to B, a Delay Measurement (DM) query message is sent from A to B containing a timestamp recording the instant at which it is transmitted, i.e., T1. When the message reaches B, a timestamp is added recording the instant at which it is received (T2). The message can now be reflected from B to A, with B adding its transmit timestamp (T3) and A adding its receive timestamp (T4). These four timestamps enable A to compute the one-way delay in each direction, as well as the two-way delay for the channel. The one-way delay computations require that the clocks of A and B be synchronized; mechanisms for clock synchronization are outside the scope of this document.
AにBへのチャネル上の遅延を測定するために、遅延測定（DM）クエリメッセージは、それが送信される瞬間、すなわち、T1を記録するタイムスタンプを含むAからBに送信されます。メッセージがBに到達すると、タイムスタンプは、受信された瞬間（T2）を記録添加します。メッセージは、現在Bは、その送信タイムスタンプ（T3）を添加し、その受信タイムスタンプ（T4）を加えると、BからAに反映させることができます。これら四つのタイムスタンプは、各方向における一方向遅延、ならびにチャネルに対する双方向の遅延を計算することができます。一方向遅延計算は、AとBのクロックが同期されることを必要とします。クロック同期のためのメカニズムは、この文書の範囲外です。
Suppose a bidirectional channel exists between the nodes A and B. The objective is to measure at A the following two quantities associated with the channel:
双方向チャネルを目的は、チャネルに関連付けられた次の二つの量で測定することであるノードAとBとの間に存在すると仮定する。
A_TxLoss (transmit loss): the number of packets transmitted by A over the channel but not received at B;
A_TxLoss（損失送信）チャネルを介しによって送信されたパケットの数が、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:
これは（LM [2]、... LM [1]）は、指定された速度で、チャネルを介してLMクエリーメッセージのシーケンスの送信で構成され、Aにおける損失測定（LM）演算を開始することによって達成されます。 1として、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]：このメッセージが送信される時間の前にチャネルを介してAによって送信されたパケットの総数。
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]はこの応答を受信した時にチャネルを介してAによって受信されたパケットの合計数は、（メッセージ自体を除きます）。
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]と損失A_RxLossを受信[N-1、N]メッセージLM [N-1]とLMによってマークされた測定間隔内の[N]は次のようにすることによって計算されます。
A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
A_TxLoss [N-1、N] =（A_TxP [N] - A_TxP [N-1]） - （B_RxP [N] - B_RxP [N-1]）A_RxLoss [N-1、N] =（B_TxP [N] - B_TxP [N-1]） - （A_RxP [N] - A_RxP [N-1]）
where the arithmetic is modulo the counter size.
ここで、算術カウンタ・サイズを法とされています。
(Strictly speaking, it is not necessary that the fourth count, A_RxP[n], actually be written in the message, but this is convenient for some implementations and useful if the message is to be forwarded on to an external measurement system.)
（厳密に言えば、第4カウント、A_RxP [n]は、実際にメッセージに書き込まれるが、メッセージは、外部測定システムに転送する場合、これはいくつかの実装のために便利で有用であること。必要はありません）
The derived values
得られた値
A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ...
A_TxLoss = A_TxLoss [1,2] + A_TxLoss [2,3] +···
A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ...
A_RxLoss = A_RxLoss [1,2] + A_RxLoss [2,3] +···
are updated each time a response to an LM message is received and processed, and they represent the total transmit and receive loss over the channel since the LM operation was initiated.
LMメッセージに対する応答が受信され処理されるたびに更新され、それらは、総送信を表し、LM動作が開始されてからチャネルを介して損失を受けます。
When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n], the possibility of counter wrap must be taken into account. For example, consider the values of the A_TxP counter at sequence numbers n-1 and n. Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a value equal to or greater than A_TxP[n-1], the computation of an unambiguous A_TxLoss[n-1,n] value will be impossible. Therefore, the LM message rate MUST be sufficiently high, given the counter size and the speed and minimum packet size of the underlying channel, that this condition cannot arise. For example, a 32-bit counter for a 100-Gbps link with a minimum packet size of 64 bytes can wrap in 2^32 / (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on the LM message interval under such conditions. This bound will be referred to as the MaxLMInterval of the channel. It is clear that the MaxLMInterval will be a more restrictive constraint in the case of direct LM and for smaller counter sizes.
値A_TxLoss [N-1、N]とA_RxLoss [N-1、N]を計算するとき、カウンタラップの可能性が考慮されなければなりません。例えば、シーケンス番号N-1及びNにA_TxPカウンタの値を考えます。 A_TxPあれば明らか値は不可能であろう[N-1、N] [n]は0にラップさせ、次いでA_TxP以上の値を超え[N-1]、明白A_TxLossの計算。したがって、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.
このセクションで説明損失測定手法は、具体的にはAに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.
双方向チャネルは、例えば、（MaxLMInterval以下だけ時間的に分離された）任意の二つのLM応答メッセージを与え、カウンタ値の差は、単位の数が正常に送信され、タイムスタンプの間隔で受信クエリアを伝えます。絶対的なスループットは、データ送信ユニットとデータユニットの数が受信される絶対的な送達スループットの数で提供されます。スループットレートは、単位時間あたりに送信または受信されたデータ単位の数です。
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との間に存在すると仮定する。
o The one-way delay associated with the forward (A to B) direction of the channel;
チャンネルの順方向（Bに対してA方向）に関連付けられた一方向遅延O。
o The one-way delay associated with the reverse (B to A) direction of the channel;
逆（AにB）チャネルの方向に関連付けられた一方向遅延O。
o The two-way delay (A to B to A) associated with the channel.
チャネルに関連付けられた（AとBのA）双方向遅延O。
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 endpoint B. The "round-trip delay" is described in [RFC2681] and includes in addition any delay associated with remote endpoint processing.
パケットネットワークの一方向遅延メトリックは、[RFC2679]に記載されています。双方向の遅延の場合には、関心の2つの可能性のある指標が実際にあります。 「双方向チャネル遅延」は、各方向における一方向遅延の合計であり、チャネル自体の遅延を反映する関係なく、処理遅延のリモートエンドポイント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.)
（厳密に言えば、第四のタイムスタンプ、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)
双方向チャネル遅延=（T4 - T1） - （T3 - T2）
and the round-trip delay as
そして、ラウンドトリップ遅延など
round-trip delay = T4 - T1.
往復遅延時間= T4 - T1。
If the clocks of A and B are known at A to be synchronized, then both one-way delay values, as well as the two-way channel delay, can be computed at A as
A及びBのクロックが同期されるようにAで知られている場合、両方の一方向遅延値、ならびに双方向チャネル遅延は、Aように計算することができます。
forward one-way delay = T2 - T1
フォワード一方向遅延= T2 - T1
reverse one-way delay = T4 - T3
T3 - 一方向遅延= T4を逆
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.
場合とからチャネル（B1、...、Bk）の（ここでB2、...、Bkのは、ポイント・ツー・マルチポイントの場合をいう）、すなわち、一方向LSP、LM及びDMで、単方向であります測定はA.で...、Bkの代わりに、B1で行うことができます。
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からの応答が、...、AへのBkが生成されないことを除いて、双方向チャンネルに対して使用されるのと同じ手順を行うことによって達成されます。代わりに、各端末ノードBはである、それは前述のように、本質的に同じ方法でチャネルに関連付けられた受信損失を計算するために、受信したLMメッセージでA_TxPとB_RxP値を使用します。
B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
B_RxLoss [N-1、N] =（A_TxP [N] - A_TxP [N-1]） - （B_RxP [N] - B_RxP [N-1]）
For DM, of course, only the forward one-way delay can be measured and the clock synchronization requirement applies.
DMの場合は、当然のことながら、前方にのみ一方向遅延を測定することができ、クロック同期要件が適用されます。
Alternatively, if an out-of-band channel from a terminal node B back to A is available, the LM and DM message responses can be communicated to A via this channel so that the measurements can be carried out at A.
バックAに終端ノードBからの帯域外チャンネルが使用可能である場合あるいは、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及びBは、同一のメッセージ・フローに基づいて、損失または遅延測定を行います。このことによりA.によって学習と同等の情報とBを提供する、そうでなければ使用されない次のクエリの第三及び第四のスロットへの応答メッセージからコピーすることを第三及び第四のカウンタまたはタイムスタンプ値を規定することによって達成されます。
The dyadic procedure has the advantage of halving the number of messages required for both A and B to perform a given kind of measurement, but comes at the expense of each node's ability to control its own measurement process independently, and introduces additional operational complexity into the measurement protocols. The quantity of measurement traffic is also expected to be low relative to that of user traffic, particularly when 64-bit counters are used for LM. Consequently, this document does not specify a dyadic operational mode. However, it is still possible, and may be useful, for A to perform the extra copy, thereby providing additional information to B even when its participation in the measurement process is passive.
ダイアディック手順は、測定の特定の種類を実行するためにAとBの両方のために必要なメッセージの数を半分にする利点を有するが、独立して、独自の測定プロセスを制御するために、各ノードの能力を犠牲にして、そして中に追加の操作の複雑さを導入します測定プロトコル。測定トラフィックの量はまた、64ビットカウンタはLMのために使用される場合は特に、ユーザトラフィックのに対して低いことが予想されます。したがって、この文書は、ダイアディック動作モードを指定しません。しかし、それはまだ可能であり、そしてAは、余分なコピーを実行し、それによって、測定プロセスへの参加が受動的であっても、Bに追加情報を提供するために、有用であり得ます。
Some bidirectional channels may be placed into a loopback state such that messages are looped back to the sender without modification. In this situation, LM and DM procedures can be used to carry out measurements associated with the circular path. This is done by generating "queries" with the Response flag set to 1.
いくつかの双方向チャネルは、メッセージを変更せずに送信者にループバックされるようにループバック状態に置くことができます。この状況では、LMとDM手順は円形経路に関連付けられた測定を実行するために使用することができます。これは1に設定応答フラグに「クエリ」を生成することによって行われます。
For LM, the loss computation in this case is:
LMのために、この場合の損失の計算は次のとおりです。
A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
A_Loss [N-1、N] =（A_TxP [N] - A_TxP [N-1]） - （A_RxP [N] - A_RxP [N-1]）
For DM, the round-trip delay is computed. In this case, however, the remote endpoint processing time component reflects only the time required to loop the message from channel input to channel output.
DMの場合は、往復遅延が計算されます。しかし、この場合には、リモートエンドポイント処理時間成分は、チャネル出力にチャネル入力からループにメッセージを必要とされる唯一の時間を反映しています。
A number of additional considerations apply in practice to the measurement methods summarized above.
追加の考慮事項の数は、上記に要約測定方法に実際に適用されます。
There are several types of channels in MPLS networks over which loss and delay measurement may be conducted. The channel type may restrict the kinds of measurement that can be performed. In all cases, LM and DM messages flow over the MPLS Generic Associated Channel (G-ACh), which is described in detail in [RFC5586].
損失および遅延測定を実施することができる上にMPLSネットワークにおけるチャネルのいくつかの種類があります。チャネルタイプを行うことができる測定の種類を制限することができます。全ての場合において、LM及びDMメッセージは、[RFC5586]に詳細に記載されているMPLS汎用関連するチャネル（G-ACH）、上を流れます。
Broadly, a channel in an MPLS network may be either a link, a Label Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are bidirectional and are also referred to as MPLS sections; see [RFC5586] and [RFC5960]. Pseudowires are bidirectional. Label Switched Paths may be either unidirectional or bidirectional.
広義には、MPLSネットワーク内のチャネルは、リンク、ラベルスイッチパス（LSP）[RFC3031]、または疑似回線[RFC3985]のいずれであってもよいです。リンクは双方向であり、また、MPLSのセクションと呼ばれています。 [RFC5586]と[RFC5960]を参照してください。疑似回線は双方向です。ラベルスイッチパスは、単方向または双方向のいずれであってもよいです。
The LM and DM protocols discussed in this document are initiated from a single node: the querier. A query message may be received either by a single node or by multiple nodes, depending on the nature of the channel. In the latter case, these protocols provide point-to-multipoint measurement capabilities.
クエリア：本書で論じLMおよびDMプロトコルは、単一のノードから開始されます。照会メッセージは、チャネルの性質に応じて、単一のノードによって、または複数のノードのいずれかによって受信されてもよいです。後者の場合には、これらのプロトコルは、ポイントツーマルチポイント測定能力を提供します。
Quality of Service (QoS) capabilities, in the form of the Differentiated Services architecture, apply to MPLS as specified in [RFC3270] and [RFC5462]. Different classes of traffic are distinguished by the three-bit Traffic Class (TC) field of an MPLS Label Stack Entry (LSE). Delay measurement applies on a per-traffic-class basis, and the TC values of LSEs above the G-ACh Label (GAL) that precedes a DM message are significant. Packet loss can be measured with respect either to the channel as a whole or to a specific traffic class.
[RFC3270]と[RFC5462]で指定されているサービスの品質は（QoS）の機能は、差別化サービスアーキテクチャの形で、MPLSに適用されます。トラフィックの異なるクラスは、MPLSラベルスタックエントリ（LSE）の3ビットのトラフィッククラス（TC）フィールドによって区別されます。遅延測定ごとのトラフィッククラスに基づいて適用され、DMメッセージの前にG-ACHラベル（GAL）上記小売り供給者の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- 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目的のために、それはqueuing-関連する理由のために、送信前に廃棄し、「失われた」ことにパケットを考慮してもしなくてもよいです。逆に、受信実装は、または、それが物理的に受信パスを処理中に受信したが廃棄された場合、パケットは、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]に記載されています。 ECMPの典型的な結果は、測定値が利用可能なパスのうちの一つの遅延のみであることであろう遅延させる対象となるLSP上で実行され、そして、測定することができます。
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メッセージ自体の両方を誤った順序の可能性を増加させます。そのようなmisorderingsは測定不能区間を作成し、従って損失測定の精度を劣化させる傾向があります。 ECMPの影響は考慮されないことができるすべての使用可能なパス、代替パスのうちの1つまたは複数の損失特性をプローブするためにテストパケットを特別に構成されていない限り、追加の警告と、推論LMについて類似しています。
In the case of an LSP, it may be desirable to measure the loss or delay to or from an intermediate node as well as between LSP endpoints. This can be done in principle by setting the Time to Live (TTL) field in the outer LSE appropriately when targeting a measurement message to an intermediate node. This procedure may fail, however, if hardware-assisted measurement is in use, because the processing of the packet by the intermediate node occurs only as the result of TTL expiry, and the handling of TTL expiry may occur at a later processing stage in the implementation than the hardware-assisted measurement function. The motivation for conducting measurements to intermediate nodes is often an attempt to localize a problem that has been detected on the LSP. In this case, if intermediate nodes are not capable of performing hardware-assisted measurement, a less accurate -- but usually sufficient -- software-based measurement can be conducted instead.
LSPの場合には、LSPエンドポイントとの間の損失や遅延の中間ノードへ又はから同様に測定することが望ましい場合があります。これは、中間ノードに測定メッセージをターゲットとする場合、適切に外LSEに（TTL）フィールドを生存時間を設定することにより、原理的に行うことができます。中間ノードによるパケットの処理のみTTLの期限切れの結果として発生するためのハードウェア支援型測定が、使用されている場合、この手順は、しかし、失敗する可能性があり、およびTTLの期限切れの処理はの後の処理段階で起こり得ますハードウェア支援測定機能よりも実装。中間ノードに測定を行うための動機は、多くの場合、LSP上で検出された問題を局所化するための試みです。この場合、中間ノードは、ハードウェア支援測定を実行することができない、それほど正確 - 通常は十分 - ソフトウェアベースの測定の代わりに行うことができます。
The overview of the bidirectional measurement process presented in Section 2 is also applicable when the transmit and receive interfaces at A or B differ from one another. Some additional considerations, however, do apply in this case:
場合送信項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.
この文書で指定されたLMプロトコルは、32ビットと64ビットの両方のカウンタサイズをサポートするが、LM動作に関与最大4つのインターフェイスのいずれかの32ビット・カウンタの使用は、32ビットのLMの計算になりますOチャネルの両方の方向。
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.
直接の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ラベルが存在しないのいずれかであるか、または固有の送信ノードを識別することができない場合には適用することは困難または不可能であり得ることです。最後から二番目のホップポッピング（PHP）をLSPに使用され、とは対照的に、第二の場合は、一般的にラベル配布プロトコル（LDP）[RFC5036]に基づいて、LSPのために保持し、例えば、トラフィックエンジニアリングの拡張に基づくものれるとき最初のケースが起こりリソース予約プロトコル（RSVP-TE）[RFC3209]に。受信機はそれらをカウントする、またはLMメッセージに関連付けられたソース及びLSPコンテキストを推論するために、特定のソースと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またはパケットのために構築および使用されるいずれかのパケットであってもよいです。
The synchronization conditions discussed above for direct LM also apply to inferred LM, the only difference being that the required synchronization is now between the LM counters and the test message generation process. Protocol and application designers MUST take these synchronization requirements into account when developing tools for inferred LM, and make their behavior in this regard clear to the user.
直接LMはまた、推論LMに適用するための上述した同期条件は、唯一の違いは、必要な同期は、LMカウンタとテストメッセージ生成プロセスの間になっていることです。プロトコルおよびアプリケーション設計者が推測されたLMのためのツールを開発する際に考慮にこれらの同期要件を取り、ユーザーへの明確なこの点で彼らの行動をしなければなりません。
Inferred LM provides only an approximate view of the loss level associated with a channel, but is typically applicable even in cases where direct LM is not.
推論LMは、チャネルに関連する損失レベルのみ近似ビューを提供するが、直接LMがない場合であっても一般的に適用可能です。
In the case of direct LM, where data-plane packets are counted, there are different possibilities for which kinds of packets are included in the count and which are excluded. The set of packets counted for LM is called the "loss measurement scope". As noted above, one factor affecting the LM scope is whether all data packets are counted or only those belonging to a particular traffic class. Another is whether various "auxiliary" flows associated with a data channel are counted, such as packets flowing over the G-ACh. Implementations MUST make their supported LM scopes clear to the user, and care must be taken to ensure that the scopes of the channel endpoints agree.
データプレーンパケットがカウントされるダイレクトLMの場合には、パケットの種類は、カウントに含まれているため、除外された異なる可能性があります。 LMをカウントするパケットのセットは、「損失の測定範囲」と呼ばれます。上述したように、LMの範囲に影響を与える要因の一つは、すべてのデータ・パケットをカウントまたは、特定のトラフィッククラスに属するものであるかどうかです。別のは、G-ACH上を流れるパケットとして、カウントされたデータチャネルに関連する種々の「補助」が流れるかどうかです。実装は、ユーザーに明確に自分のサポートLMスコープを作成しなければならない、とケアは、チャネルのエンドポイントのスコープが同意するように注意する必要があります。
The delay measurement procedures described in this document are designed to facilitate hardware-assisted measurement and to function in the same way whether or not such hardware assistance is used. The measurement accuracy will be determined by how closely the transmit and receive timestamps correspond to actual packet departure and arrival times.
本書で説明した遅延測定手順は、ハードウェア支援測定を容易にするために、そのようなハードウェア支援を使用するかどうかと同じ方法で機能するように設計されています。測定精度は、送信および受信タイムスタンプは、実際のパケットの出発と到着時間に対応する方法を密接にすることによって決定されるであろう。
As noted in Section 2.4, measurement of one-way delay requires clock synchronization between the devices involved, while two-way delay measurement does not involve direct comparison between non-local timestamps and thus has no synchronization requirement. The measurement accuracy will be limited by the quality of the local clock and, in the case of one-way delay measurement, by the quality of the synchronization.
2.4節で述べたように、一方向遅延の測定は、双方向の遅延測定は、非ローカルタイムスタンプ間の直接比較を伴わない一方で、関係するデバイス間のクロック同期を必要とするので、何の同期要件を持っていません。測定精度は、ローカルクロックの品質によってと、一方向遅延測定の場合には、同期の品質によって制限されます。
There are two significant timestamp formats in common use: the timestamp format of the Network Time Protocol (NTP), described in [RFC5905], and the timestamp format used in the IEEE 1588 Precision Time Protocol (PTP) [IEEE1588].
[RFC5905]に記載のネットワークタイムプロトコル（NTP）のタイムスタンプ形式、およびIEEE 1588高精度時間プロトコル（PTP）[IEEE1588]で使用されるタイムスタンプ形式：2つの一般的な使用における有意なタイムスタンプ形式があります。
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メッセージを含むパケットは、スタックの底部にG-ACHラベル（GAL）と、MPLSラベルスタックを含んでいます。 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）が推定される損失測定（ILM）MPLS遅延測定（DM）が直接損失をMPLSおよび遅延測定（DLM + DM）が推定される損失や遅延測定（ILM + DM）をMPLS MPLS
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.
フラグ：Flagsフィールドのフォーマットは以下の通りです。
+-+-+-+-+
|R|T|0|0|
+-+-+-+-+
Loss Measurement Message Flags
損失測定のメッセージフラグ
The meanings of the flag bits are:
フラグビットの意味は次のとおりです。
R: Query/Response indicator. Set to 0 for a Query and 1 for a Response.
R：クエリ/レスポンスのインジケーター。応答のためのクエリのための0と1に設定します。
T: Traffic-class-specific measurement indicator. Set to 1 when the measurement operation is scoped to packets of a particular traffic class (DSCP value), and 0 otherwise. When set to 1, the DS field of the message indicates the measured traffic class.
T：トラフィック・クラス固有の測定指標。測定動作は、特定のトラフィッククラス（DSCP値）のパケットにスコープされたときに1にセットされ、そうでなければ0。 1に設定すると、メッセージのDSフィールドは、測定されたトラフィッククラスを示します。
0: Set to 0.
0：0に設定します。
Control Code: Set as follows according to whether the message is a Query or a Response as identified by the R flag.
制御コード：メッセージクエリまたはRフラグによって識別される応答であるか否かに応じて以下のように設定。
For a Query:
クエリの場合：
0x0: In-band Response Requested. Indicates that this query has been sent over a bidirectional channel and the response is expected over the same channel.
0x0の：要求されたインバンド対応。このクエリは、双方向チャネルを介して送信されてきたとの応答が同じチャネル上で期待されていることを示します。
0x1: Out-of-band Response Requested. Indicates that the response should be sent via an out-of-band channel.
0x1の：応答要求されたアウトオブバンド。応答は、アウトオブバンドチャネルを介して送られるべきであることを示します。
0x2: No Response Requested. Indicates that no response to the query should be sent. This mode can be used, for example, if all nodes involved are being controlled by a Network Management System.
0x2の：応答が要求されません。問い合わせへの応答が送信されないことを示します。関係するすべてのノードがネットワーク管理システムによって制御されている場合は、このモードでは、例えば、使用することができます。
For a Response:
応答のために：
Codes 0x0-0xF are reserved for non-error responses. Error response codes imply that the response does not contain valid measurement data.
非エラー応答のために予約されている0x0-0xFコード。エラー応答コードが応答が有効な測定データが含まれていないことを示唆しています。
0x1: Success. Indicates that the operation was successful.
0x1の：成功。操作が成功したことを示します。
0x2: Notification - Data Format Invalid. Indicates that the query was processed, but the format of the data fields in this response may be inconsistent. Consequently, these data fields MUST NOT be used for measurement.
0x2の：通知 - 無効なデータ形式。クエリが処理されましたが、この応答のデータフィールドのフォーマットが一致しないことがあることを示します。したがって、これらのデータフィールドは、測定のために使用してはいけません。
0x3: Notification - Initialization in Progress. Indicates that the query was processed but this response does not contain valid measurement data because the responder's initialization process has not completed.
0x3の：通知 - 進行中の初期化。クエリが処理されたことを示しますが、応答者の初期化処理が完了していないため、この応答は、有効な測定データが含まれていません。
0x4: Notification - Data Reset Occurred. Indicates that the query was processed, but a reset has recently occurred that may render the data in this response inconsistent relative to earlier responses.
0x4の：通知 - データのリセットが発生しました。クエリが処理されたことを示しますが、リセットは最近、それは以前の回答に比べて一貫性のないこの応答でデータをレンダリングすることが発生しました。
0x5: Notification - Resource Temporarily Unavailable. Indicates that the query was processed, but resources were unavailable to complete the requested measurement and that, consequently, this response does not contain valid measurement data.
0x5：通知 - リソース一時的に利用できません。クエリが処理されたことを示しますが、リソースが要求された測定を完了するために利用できなかった、それは、結果的に、この応答は、有効な測定データが含まれていません。
0x10: Error - Unspecified Error. Indicates that the operation failed for an unspecified reason.
0x10の：エラー - 未指定のエラー。操作は、不特定の理由で失敗したことを示します。
0x11: Error - Unsupported Version. Indicates that the operation failed because the protocol version supplied in the query message is not supported.
0x11を：エラー - サポートされていないバージョン。クエリメッセージで提供されたプロトコルのバージョンがサポートされていないため、操作が失敗したことを示します。
0x12: Error - Unsupported Control Code. Indicates that the operation failed because the Control Code requested an operation that is not available for this channel.
0x12を：エラー - サポートされていない制御コード。制御コードは、このチャンネルでは使用できません操作を要求したため、操作が失敗したことを示します。
0x13: Error - Unsupported Data Format. Indicates that the operation failed because the data format specified in the query is not supported.
0x13に：エラー - サポートされていないデータフォーマット。クエリで指定されたデータ形式がサポートされていないため、操作が失敗したことを示します。
0x14: Error - Authentication Failure. Indicates that the operation failed because the authentication data supplied in the query was missing or incorrect.
0x14の：エラー - 認証失敗。クエリで供給された認証データが欠落または不正確であったため、操作が失敗したことを示します。
0x15: Error - Invalid Destination Node Identifier. Indicates that the operation failed because the Destination Node Identifier supplied in the query is not an identifier of this node.
0x15の：エラー - 無効な宛先ノード識別子。クエリに供給された宛先ノード識別子は、このノードの識別子でないため、操作が失敗したことを示しています。
0x16: Error - Connection Mismatch. Indicates that the operation failed because the channel identifier supplied in the query did not match the channel over which the query was received.
0x16：エラー - 接続の不一致。クエリで供給されるチャネル識別子は、クエリを受信した上でのチャネルと一致しなかったため、操作が失敗したことを示します。
0x17: Error - Unsupported Mandatory TLV Object. Indicates that the operation failed because a TLV Object received in the query and marked as mandatory is not supported.
0x17の：エラー - サポートされていない必須のTLVオブジェクト。 TLVオブジェクトがクエリで受信し、サポートされていない必須としてマークされているため、操作が失敗したことを示します。
0x18: Error - Unsupported Query Interval. Indicates that the operation failed because the query message rate exceeded the configured threshold.
0x18の：エラー - サポートされていないクエリー間隔。クエリメッセージレートが設定したしきい値を超えたため、操作が失敗したことを示します。
0x19: Error - Administrative Block. Indicates that the operation failed because it has been administratively disallowed.
0x19：エラー - 管理ブロック。それは管理上禁止されているため、操作が失敗したことを示します。
0x1A: Error - Resource Unavailable. Indicates that the operation failed because node resources were not available.
0x1A：エラー - リソース使用不可。ノードのリソースが利用できなかったため、操作が失敗したことを示します。
0x1B: Error - Resource Released. Indicates that the operation failed because node resources for this measurement session were administratively released.
0x1B：エラー - リソースがリリース。この測定セッションのためのノードのリソースが管理リリースされたため、操作が失敗したことを示します。
0x1C: Error - Invalid Message. Indicates that the operation failed because the received query message was malformed.
0x1cに：エラー - 無効なメッセージ。受信したクエリメッセージが不正な形式であるため、操作が失敗したことを示します。
0x1D: Error - Protocol Error. Indicates that the operation failed because a protocol error was found in the received query message.
0x1Dの：エラー - プロトコルエラー。プロトコルエラーを受信したクエリメッセージで発見されたため、操作が失敗したことを示します。
Message Length: Set to the total length of this message in bytes, including the Version, Flags, Control Code, and Message Length fields as well as the TLV Block, if any.
メッセージ長：もしあれば、バージョン、フラグ、制御コード、およびメッセージ長のフィールドだけでなく、TLVブロックを含め、バイト単位でこのメッセージの合計の長さに設定してください。
DFlags: The format of the DFlags field is shown below.
DFlags：DFlagsフィールドのフォーマットを以下に示します。
+-+-+-+-+
|X|B|0|0|
+-+-+-+-+
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ビット）のカウンタ値の使用を示しています。作成時に1に初期化する（そして送信の前に）LMクエリと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：オクテット（バイト）数。 1に設定すると、カウンタ1-4のフィールドはオクテット数を表すことを示しています。オクテットカウントはLMスコープ（セクション2.9.9）内のすべてのパケットに適用され、チャネルを介して送信または受信されたパケットのオクテット数は、そのパケットの全長を含む（しかし、ヘッダ、ラベル、またはチャネルのフレーミングを除外します自体）。 0に設定すると、カウンタ1-4のフィールドはパケット数を表すことを示しています。
0: Set to 0.
0：0に設定します。
Origin Timestamp Format: The format of the Origin Timestamp field, as specified in Section 3.4.
原産地タイムスタンプ形式：起源タイムスタンプフィールドの形式、3.4節に指定されています。
Session Identifier: Set arbitrarily in a query and copied in the response, if any. This field uniquely identifies a measurement operation (also called a session) that consists of a sequence of messages. All messages in the sequence have the same Session Identifier.
セッション識別子：クエリで任意に設定してあれば、応答にコピーされました。このフィールドは、一意のメッセージのシーケンスからなる（また、セッションと呼ばれる）の測定動作を識別する。シーケンス内のすべてのメッセージは、同じセッション識別子を持っています。
DS: When the T flag is set to 1, this field is set to the DSCP value [RFC3260] that corresponds to the traffic class being measured. For MPLS, where the traffic class of a channel is identified by the three-bit Traffic Class in the channel's LSE [RFC5462], this field
DS：Tフラグが1に設定されている場合、このフィールドは、測定されるトラフィッククラスに対応するDSCP値[RFC3260]に設定されています。チャネルのトラフィッククラスは、チャネルの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.
そのトラフィッククラスに対応するクラスセレクタコードポイント[RFC2474]に設定する必要があります。 Tフラグが0に設定されている場合、このフィールドの値は任意であり、フィールドは、セッション識別子の一部と考えることができます。
Origin Timestamp: Timestamp recording the transmit time of the query message.
起源のタイムスタンプ：タイムスタンプは、クエリメッセージの送信時間を記録します。
Counter 1-4: Referring to Section 2.2, when a query is sent from A, Counter 1 is set to A_TxP and the other counter fields are set to 0. When the query is received at B, Counter 2 is set to B_RxP. At this point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4, and re-initializes Counter 1 and Counter 2 to 0. When B transmits the response, Counter 1 is set to B_TxP. When the response is received at A, Counter 2 is set to A_RxP.
カウンタ1-4：2.2節、クエリがAから送信されると、カウンタ1はA_TxPに設定され、クエリがBで受信されると、他のカウンタフィールドが0に設定され、カウンタ2はB_RxPに設定されているを参照します。 Bは、カウンタ1がB_TxPに設定されている応答を送信すると、この時点で、Bコピーカウンタ4のカウンタ3のカウンタ1とカウンタ2、カウンタ1と0にカウンタ2を再初期化します。応答が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ビット・カウンタの値がカウンタフィールドのいずれかに書き込まれると、その値は、フィールドの下位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.
クエリアタイムスタンプフォーマット：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：クエリはA、タイムスタンプ1から送信されるセクション2.4を参照すると、T1に設定され、クエリがBで受信されると、他のタイムスタンプ・フィールドが0に設定され、タイムスタンプ2がT2に設定されています。 Bは、タイムスタンプ1がT3に設定されている応答を送信すると、この時点で、タイムスタンプ3及びタイムスタンプ4のタイムスタンプ2、及びBにコピースタンプ1タイムスタンプ1と0のタイムスタンプ2を再初期化します。応答が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のためのOTFの役割と起源タイムスタンプフィールドはここでそれぞれQTFタイムスタンプ1つのフィールドによって再生されることを除いて、LM及びDMメッセージフォーマットの対応するフィールドと同じ意味を有します。
The following timestamp format field values are specified in this document:
次のタイムスタンプのフォーマットフィールドの値は、この文書で指定されています。
0: Null timestamp format. This value is a placeholder indicating that the timestamp field does not contain a meaningful timestamp.
0：ヌルタイムスタンプ形式。この値は、タイムスタンプフィールドは、意味のあるタイムスタンプを含んでいないことを示すプレースホルダです。
1: Sequence number. This value indicates that the timestamp field is to be viewed as a simple 64-bit sequence number. This provides a simple solution for applications that do not require a real absolute timestamp, but only an indication of message ordering; an example is LM exception detection.
1：シーケンス番号。この値は、タイムスタンプフィールドは、単純な64ビットのシーケンス番号としてみなされるべきであることを示しています。これは、実際の絶対的なタイムスタンプを必要としないアプリケーションのための簡単な解決策はなく、メッセージの順序の表示のみを提供します。例では、LM例外の検出です。
2: Network Time Protocol version 4 64-bit timestamp format [RFC5905]. This format consists of a 32-bit seconds field followed by a 32-bit fractional seconds field, so that it can be regarded as a fixed-point 64-bit quantity.
2：ネットワーク・タイム・プロトコルバージョン4 64ビットのタイムスタンプ形式[RFC5905]。それは、固定小数点64ビット量とみなすことができるように、このフォーマットは、32ビットの小数秒フィールドに続く、32ビットの秒フィールドから成ります。
3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time Protocol timestamp format [IEEE1588]. This truncated format consists of a 32-bit seconds field followed by a 32-bit nanoseconds field, and is the same as the IEEE 1588v1 timestamp format.
3：下位IEEE 1588から2008（1588v2）高精度時間プロトコルのタイムスタンプ形式の64ビット[IEEE1588]。この切り捨てられた形式は、32ビットのナノ秒フィールドに続く、32ビットの秒フィールドで構成されており、IEEE 1588v1タイムスタンプフォーマットと同じです。
Timestamp formats of n < 64 bits in size SHALL be encoded in the 64-bit timestamp fields specified in this document using the n high-order bits of the field. The remaining 64 - n low-order bits in the field SHOULD be set to 0 and MUST be ignored when reading the field.
n個のタイムスタンプフォーマット<サイズは64ビットフィールドのN個の上位ビットを使用して、この文書で指定された64ビットのタイムスタンプフィールドで符号化されます。残り64 - 分野におけるn下位ビットが0に設定されるべきであり、フィールドを読み取るときに無視しなければなりません。
To ensure that it is possible to find an interoperable mode between implementations, it is necessary to select one timestamp format as the default. The timestamp format chosen as the default is the truncated IEEE 1588 PTP format (format code 3 in the list above); this format MUST be supported. The rationale for this choice is discussed in Appendix A. Implementations SHOULD also be capable of reading timestamps written in NTPv4 64-bit format and reconciling them internally with PTP timestamps for measurement purposes. Support for other timestamp formats is OPTIONAL.
実装間の相互運用可能なモードを見つけることが可能であることを確実にするために、デフォルトとして1つのタイムスタンプ・フォーマットを選択する必要があります。デフォルトとして選択されたタイムスタンプ形式は切り捨てられ、IEEE1588 PTP形式（上記リスト形式コード3）です。このフォーマットをサポートしなければなりません。この選択のための理論的根拠はまた、NTPv4 64ビットのフォーマットで記述されたタイムスタンプを読み取り、測定目的のためにPTPタイムスタンプと内部それらを両立することが可能であるべきで付録A.実装において議論されています。他のタイムスタンプ形式のサポートは任意です。
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
オプション128パディング - 応答129宛先アドレス130の送信元アドレス131から254未割り当て255実験的使用にはコピーしないでください
The two padding objects permit the augmentation of packet size; this is mainly useful for delay measurement. The type of padding indicates whether the padding supplied by the querier is to be copied to, or omitted from, the response. Asymmetrical padding may be useful when responses are delivered out-of-band or when different maximum transmission unit sizes apply to the two components of a bidirectional channel.
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.
複数のパディングオブジェクトは、それらが隣接している必要があり、その場合に存在してもよいです。パディングオブジェクトのValueフィールドは任意です。
The addressing objects have the following format:
アドレス指定のオブジェクトの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addressing Object Format
オブジェクトフォーマットへの対応
The Address Family field indicates the type of the address, and it SHALL be set to one of the assigned values in the "IANA Address Family Numbers" registry.
アドレスファミリフィールドは、アドレスの種類を示し、それは「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.
SourceとDestination Addressオブジェクトは、それぞれ、送信者のアドレスとメッセージの目的の受信者を示しています。いくつかの他の帯域外応答機構が構成されていない限り、および住所オブジェクトが存在しない限り、住所その場合、クエリメッセージの送信元アドレスはアウトオブバンド応答の宛先として使用されてください応答のターゲットを指定します。住所オブジェクトが応答に現れてはいけません。
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.
バックレスポンダからの反射クエリメッセージを受信すると、クエリアは、メッセージを再送信してはいけません。一意に、ソースアドレスオブジェクトとして、元のクエリのソースを識別する情報は、遠端によって開始されたループバッククエリから独自のループバッククエリのいずれかを区別するためにクエリアを可能にするために含めることができます。
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.
セッション問合せ間隔オブジェクトのValueフィールドは、ミリ秒単位で時間間隔を指定する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.クエリアは、それが0の値で、そのクエリメッセージでSQIオブジェクトを含めることによって、このセッションのために応答者の最低限のクエリ間隔を知らせることを望んでいることを応答者に通知します。
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.
レスポンダが0の値を持つSQIオブジェクトを含むクエリを受け取ると2、レスポンダは、このセッションのためにサポートする最小クエリー間隔に設定された値と対応してSQIオブジェクトを含みます。
3. When the querier receives a response that includes an SQI object, it selects a query interval for the session that is greater than or equal to the Value specified in the SQI object and adjusts its query transmission rate accordingly, including in each subsequent query an SQI object with a Value equal to the selected query interval. Once a response to one of these subsequent queries has been received, the querier infers that the responder has been apprised of the selected query interval and MAY then stop including the SQI object in queries associated with this session.
3.クエリアがSQIオブジェクトを含む応答を受信すると、それは後続の各クエリANを含め、以上SQIオブジェクトで指定された値に等しく、それに応じてクエリ送信レートを調整するセッションのクエリー間隔を選択します選択されたクエリの間隔に等しい値を持つSQIオブジェクト。これらの後続のクエリのいずれかに対する応答を受信した後、クエリアは、応答者が選択したクエリー間隔を知らされており、このセッションに関連するクエリでSQIオブジェクトを含む停止してもよいことを推論します。
Similar procedures allow the query rate to be changed during the course of the session by either the querier or the responder. For example, to inform the querier of a change in the minimum supported query interval, the responder begins including a corresponding SQI object in its responses, and the querier adjusts its query rate if necessary and includes a corresponding SQI object in its queries until a response is received.
同様の手順は、クエリ率がクエリアまたは応答のいずれかによって、セッションの途中で変更することができます。たとえば、サポートされる最小クエリ間隔の変化のクエリアに通知するために、レスポンダは、その応答に対応するSQIオブジェクトを含む始まり、クエリアは、必要に応じて、そのクエリーレートを調整し、応答まで、クエリに対応するSQIオブジェクトを含みます受信されました。
Shorter query intervals (i.e., higher query rates) provide finer measurement granularity at the expense of additional load on measurement endpoints and the network; see Section 6 for further discussion.
短いクエリ間隔（すなわち、より高いクエリ率）測定エンドポイントとネットワーク上の追加の負荷を犠牲にしてより細かい粒度測定を提供します。さらなる議論については、セクション6を参照してください。
A loss or delay measurement operation, also called a session, is controlled by the querier and consists of a sequence of query messages associated with a particular channel and a common set of measurement parameters. If the session parameters include a response request, then the receiving node or nodes will (under normal conditions) generate a response message for each query message received, and these responses are also considered part of the session. All query and response messages in a session carry a common session identifier.
また、セッションと呼ばれる損失や遅延測定動作は、クエリアによって制御され、特定のチャンネル及び測定パラメータの共通セットに関連した照会メッセージのシーケンスで構成されています。セッションパラメータは、応答要求を含む場合には、受信ノードまたはノードは、（通常の条件下で）受信された各クエリメッセージに対する応答メッセージを生成し、これらの応答は、セッションの一部とみなされます。セッションのすべてのクエリおよび応答メッセージは、共通のセッション識別子を運びます。
Measurement sessions are initiated at the discretion of the network operator and are terminated either at the operator's request or as the result of an error condition. A session may be as brief as a single message exchange, for example when a DM query is used by the operator to "ping" a remote node, or it may extend throughout the lifetime of the channel.
測定セッションは、ネットワークオペレータの裁量で開始され、オペレータの要求に応じてまたはエラー状態の結果としてのいずれかで終了します。 DMクエリーをオペレータに「ピング」リモート・ノードによって使用される場合、セッションは、例えば、単一のメッセージ交換と同じくらい簡単であってもよいし、チャネルの寿命にわたって延びていてもよいです。
When a session is initiated for which responses are requested, the querier SHOULD initialize a timer, called the SessionResponseTimeout, that indicates how long the querier will wait for a response before abandoning the session and notifying the user that a timeout has occurred. This timer persists for the lifetime of the session and is reset each time a response message for the session is received.
セッションがどの応答が要求されるため、クエリアタイマーを初期化する必要が開始されると、クエリアがセッションを放棄し、タイムアウトが発生したことをユーザに通知する前に応答を待機する時間を示しSessionResponseTimeoutと呼ばれます。このタイマーは、セッションの存続期間を通じて持続し、セッションの応答メッセージが受信されるたびにリセットされます。
When a query message is received that requests a response, a variety of exceptional conditions may arise that prevent the responder from generating a response that contains valid measurement data. Such conditions fall broadly into two classes: transient exceptions from which recovery is possible and fatal exceptions that require termination of the session. When an exception arises, the responder SHOULD generate a response with an appropriate Notification or Error control code according to whether the exception is, respectively, transient or fatal. When the querier receives an Error response, the session MUST be terminated and the user informed.
クエリメッセージが応答を要求し、その受信した場合、例外条件の様々な有効な測定データを含む応答を生成からの応答を妨げること生じる可能性があります。可能な回復から過渡例外とセッションの終了を必要と致命的な例外：そのような条件は、2つのクラスに広く落ちます。例外が発生した場合、応答者は例外が、それぞれ、一時的または致命的であるかどうかに応じて、適切な通知やエラー制御コードで応答を生成する必要があります。クエリアがエラー応答を受信すると、セッションが終了し、利用者に通知しなければなりません。
A common example of a transient exception occurs when a new session is initiated and the responder requires a period of time to become ready before it can begin providing useful responses. The response control code corresponding to this situation is Notification -
新しいセッションが開始されたときの過渡例外の一般的な例が発生し、それが有益な応答を提供を開始する前に、応答者は、準備になるために一定の時間を要します。このような状況に対応する応答制御コードが通知されます -
Initialization in Progress. Typical examples of fatal exceptions are cases where the querier has requested a type of measurement that the responder does not support or where a query message is malformed.
進行中の初期化。致命的な例外の典型的な例は、クエリアが応答者がサポートしていないか、クエリメッセージが不正な形式であるところ、測定の種類を要求した例です。
When initiating a session, the querier SHOULD employ the Session Query Interval mechanism (Section 3.5.4) to establish a mutually agreeable query rate with the responder. Responders SHOULD employ rate-limiting mechanisms to guard against the possibility of receiving an excessive quantity of query messages.
セッションを開始すると、クエリアは、応答者と相互に合意クエリ率を確立するため、セッションクエリー間隔メカニズム（セクション3.5.4）を採用すべきです。応答は、クエリメッセージの過剰を受ける可能性を防ぐためにレート制限メカニズムを採用するべきです。
An LM operation for a particular channel consists of sending a sequence (LM[1], LM[2], ...) of LM query messages over the channel at a specific rate and processing the responses received, if any. As described in Section 2.2, the packet loss associated with the channel during the operation is computed as a delta between successive messages; these deltas can be accumulated to obtain a running total of the packet loss for the channel or be used to derive related metrics such as the average loss rate.
特定の速度でチャネルを介してLMクエリーメッセージの特定のチャネルのための動作シーケンスを送信することから成るLM（LM [1] LM [2]、...）及び応答を処理し、もしあれば、受信しました。 2.2節で説明したように、動作中のチャネルに関連付けられたパケット損失は、連続したメッセージとの間の差分として計算されます。これらのデルタは、チャネルのパケット損失の累計を取得するために蓄積することができ、またはそのような平均損失率と関連するメトリックを導出するために使用されます。
The query message transmission rate MUST be sufficiently high, given the LM message counter size (which can be either 32 or 64 bits) and the speed and minimum packet size of the underlying channel, that the ambiguity condition noted in Section 2.2 cannot arise. In evaluating this rate, the implementation SHOULD assume that the counter size is 32 bits unless explicitly configured otherwise or unless (in the case of a bidirectional channel) all local and remote interfaces involved in the LM operation are known to be 64-bit-capable, which can be inferred from the value of the X flag in an LM response.
クエリメッセージ送信速度が曖昧条件が発生しないことができ、セクション2.2で述べたことは、（32または64ビットであることができる）LMメッセージカウンタサイズと速度と下層のチャネルの最小パケットサイズを考えると、十分に高くなければなりません。この速度を評価する際に、実装は、明示的又は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クエリを送信する場合、Versionフィールドは0に設定しなければなりませんRフラグは、Tフラグがあれば1に設定されると、測定が特定のトラフィッククラスに対して特異的であるのみならば、ここで0に設定しなければなりませんケース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カウンタを書き込み、それ以外の場合は32ビットカウンタが書き込まれることを示すために0に設定する必要がある場合Xフラグが1に設定しなければなりません。 Bフラグがカウンタフィールドがオクテット数を含むことを示すために、または0にパケット数を示すために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に記載されているクエリメッセージの値のいずれかに設定する必要があります。 （：インバンド応答要求されたクエリが）チャンネルが一方向である場合、このフィールドは0x0に設定してはいけません。
The Session Identifier field can be set arbitrarily.
セッション識別子フィールドを任意に設定することができます。
The Origin Timestamp field SHALL be set to the time at which this message is transmitted, and the Origin Timestamp Format field MUST be set to indicate its format, according to Section 3.4.
オリジンタイムスタンプフィールドは、このメッセージが送信された時刻に設定される、オリジンタイムスタンプ形式フィールドは、セクション3.4によれば、そのフォーマットを示すように設定されなければなりません。
The Counter 1 field SHOULD be set to the total count of units (packets or octets, according to the B flag) transmitted over the channel prior to this LM Query, or to 0 if this is the beginning of a measurement session for which counter data is not yet available. The Counter 2 field MUST be set to 0. If a response was previously received in this measurement session, the Counter 1 and Counter 2 fields of the most recent such response MAY be copied to the Counter 3 and Counter 4 fields, respectively, of this query; otherwise, the Counter 3 and Counter 4 fields MUST be set to 0.
これは、測定セッションの開始である場合、カウンタ1フィールドは、または0にLMクエリの前にチャネルを介して送信（Bフラグに応じて、パケットまたはオクテット）単位の総数に設定されるべきカウンタデータ用まだ利用できません。応答が以前にこの測定セッション中に受信された場合、カウンタ2フィールドは、最も最近、このような応答のカウンタ1とカウンタ2フィールドはこの、それぞれ、カウンタ3とカウンタ4つのフィールドにコピーされてもよく、0に設定しなければなりませんクエリ;そうでない場合は、カウンタ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 Queryメッセージを受信すると、カウンタ2フィールドは、（Bフラグに応じて、パケットまたはオクテット）単位の合計数に設定されてくださいこの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 Queryメッセージを検査しなければなりません。制御コードフィールドが（応答が要求されていない）を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クエリに対する応答を構築する場合、Versionフィールドは、Rフラグは、Tフラグの値は、LMクエリからコピーしなければなりません1に設定しなければなりません0に設定しなければなりません。
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に記載されている応答メッセージのためのいずれかの値に設定しなければなりません。他のより具体的なエラーコードのいずれかが適用された場合に値が0x10（予期しないエラー）が使用されるべきではありません。
If the response is transmitted in-band, the Counter 1 field SHOULD be set to the total count of units transmitted over the channel prior to this LM Response. If the response is transmitted out-of-band, the Counter 1 field MUST be set to 0. In either case, the Counter 2 field MUST be set to 0.
応答は、帯域内送信される場合、カウンタ1フィールド前、このLM応答にチャネルを介して送信単位の総数に設定されるべきです。応答が帯域外送信される場合、カウンタ1フィールドは、いずれの場合に0に設定しなければなりません、カウンタ2フィールドが0に設定しなければなりません。
Upon in-band receipt of an LM Response message, the Counter 2 field is set to the total count of units received over the channel prior to this LM Response. If the receiving interface writes 32-bit LM counters, the X flag is set to 0. (Since the life of the LM message in the network has ended at this point, it is up to the receiver whether these final modifications are made to the packet. If the message is to be forwarded on for external post-processing (Section 2.9.7), then these modifications MUST be made.)
LM応答メッセージの帯域受信時に、カウンタ2フィールドは、このLM応答に先立ってチャネルを介して受信ユニットの総数に設定されています。受信インターフェースは、32ビットLMカウンタを書き込む場合、Xフラグ（0に設定されているネットワーク内のLMメッセージの寿命はこの時点で終了しているので、これらの最終的な修正がになされているかどうかを受信機までですパケット。メッセージは、これらの修正がなされなければならない、外部の後処理（セクション2.9.7）のために転送される場合）。
Upon out-of-band receipt of an LM Response message, the Counter 1 and Counter 2 fields MUST NOT be used for purposes of loss measurement.
LM応答メッセージのアウトオブバンド受信すると、カウンタ1及びカウンタ2のフィールドは、損失測定のために使用してはいけません。
If the Control Code in an LM Response is anything other than 0x1 (Success), the counter values in the response MUST NOT be used for purposes of loss measurement. If the Control Code indicates an error condition, or if the response message is invalid, the LM operation MUST be terminated and an appropriate notification to the user generated.
LM応答して制御コードは0x1（成功）以外の場合は、応答のカウンタ値は、損失測定の目的のために使用してはいけません。制御コードは、エラー状態を示し、又は応答メッセージが無効な場合、LM動作を終了しなければならなくて、ユーザーに適切な通知を生成した場合。
Calculation of packet loss is carried out according to the procedures in Section 2.2. The X flag in an LM message informs the device performing the calculation whether to perform 32-bit or 64-bit arithmetic. If the flag value is equal to 1, all interfaces involved in the LM operation have written 64-bit counter values, and 64-bit 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.
パケット損失の計算は、セクション2.2の手順に従って行われます。 LMメッセージにおけるXフラグは、32ビットまたは64ビット演算を実行するかどうかの計算を行う装置に通知します。フラグの値が1に等しい場合、LMの操作に関与するすべてのインターフェースは、64ビットカウンタ値が書き込まれており、64ビット演算を使用することができます。フラグの値が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.
デフォルトでは、直接のLMは、ジェネリック関連するチャネル（G-ACH）を介して送信し、受信したパケットを除外する必要があります。実装は、一部またはすべてのG-AChのメッセージを含めるように直接LMの範囲を変更する手段を提供することができます。両方のエンドポイントが一致していることを確認するために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を行う場合、チャネルに対応するテストメッセージのラベルスタックにLSEのDSフィールドは、（例えば、LSP）メッセージが送信される、関連する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動作は次の1つのメッセージから維持状態とメッセージシーケンスから成るので、LMはDMではないような方法で失われたメッセージとmisorderedパケットの影響を受けます。この状態でのみクエリアに存在するため、これらの条件の取り扱いは、厳密には、ローカルの問題を話しています。このセクションでは、しかし、そのような状態を処理するための推奨手順を説明します。 ECMPが存在しない場合に、トラフィッククラス内のパケット誤った順序は比較的稀な事象であることに注意してください。
The first kind of anomaly that may occur is that one or more LM messages may be lost in transit. The effect of such loss is that when an LM Response is next received at the querier, an unambiguous interpretation of the counter values it contains may be impossible, for the reasons described at the end of Section 2.2. Whether this is so depends on the number of messages lost and the other variables mentioned in that section, such as the LM message rate and the channel parameters.
起こり得る異常の最初の種類は、一つ以上のLMメッセージが転送中に失われる可能性があることです。このような損失の影響は、それが含まれているカウンタ値の明確な解釈は、2.2節の最後で説明した理由のため、不可能であってもよい、LM応答は次クエリアで受信されたときということです。これがそうであるかどうかは、失われたメッセージと、そのような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に対する応答[N]は前LMに対応する[N-1]を受信するようにLMメッセージは、輸送中misorderedされることです。典型的な実装では、効果が失われたメッセージの場合と同じになるように、[N-1] LMする遅い応答を廃棄します。
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メッセージに対してmisorderedている可能性にさらされます。この条件は、100の送信回数で、例えば、もたらすことができると101の対応する受信回数がここでの効果は、所与の測定間隔のA_TxLoss [N-1、N]の値は、（例えば）であるように見えるということです非常に（そうでない場合は極端に）大。 LMメッセージはパケットの一部よりも早く到着した他の場合は、単に失われたとしてカウントされ、これらのパケットになります。
An implementation SHOULD identify a threshold value that indicates the upper bound of lost packets measured in a single computation beyond which the interval is considered unmeasurable. This is called the "MaxLMIntervalLoss threshold". It is clear that this threshold should be no higher than the maximum number of packets (or bytes) the channel is capable of transmitting over the interval, but it may be lower. Upon encountering an unmeasurable interval, the LM state (i.e., data values from the last LM message received) SHOULD be discarded.
実装は、間隔が測定不可能であると考えられるそれを超える単一の計算で測定された失われたパケットの上限を示すしきい値を識別すべきです。これは、「MaxLMIntervalLossしきい値」と呼ばれています。なお、この閾値はパケット（またはバイト）チャネル間隔にわたって送信することができるの最大数よりも高くてはならないことは明らかであるが、それは低くてもよいです。測定不能期間に遭遇すると、LM状態（すなわち、受信された最後のLMメッセージからデータ値）が廃棄されるべきです。
With regard to lost LM messages, the MaxLMInterval (see Section 2.2) indicates the maximum amount of time that can elapse before the LM state is discarded. If some messages are lost, but a message is 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.
失われたLMメッセージに関しては、MaxLMIntervalは（2.2節を参照）LM状態が破棄される前に経過できる時間の最大量を示しています。一部のメッセージが失われますが、メッセージがその後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クエリ、バージョンを送信し、予約フィールドは、Rフラグが0に設定しなければなりません0に設定する必要がある場合、Tフラグが1に設定しなければなりません、そして、残りのフラグビットを0に設定しなければなりません。
The Control Code field MUST be set to one of the values for Query messages listed in Section 3.1; if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: In-band Response Requested).
制御コードフィールドは、セクション3.1に記載されているクエリメッセージの値のいずれかに設定する必要があります。 （：インバンド応答要求されたクエリが）チャンネルが一方向である場合、このフィールドは0x0に設定してはいけません。
The Querier Timestamp Format field MUST be set to the timestamp format used by the querier when writing timestamp fields in this message; the possible values for this field are listed in Section 3.4. The Responder Timestamp Format and Responder's Preferred Timestamp Format fields MUST be set to 0.
クエリアタイムスタンプ形式のフィールドは、このメッセージにタイムスタンプフィールドを書くクエリアによって使用されるタイムスタンプのフォーマットに設定しなければなりません。このフィールドに指定可能な値は、3.4節に記載されています。レスポンダタイムスタンプの書式とレスポンダの優先タイムスタンプ形式のフィールドは0に設定しなければなりません。
The Session Identifier field can be set arbitrarily. The DS field MUST be set to the traffic class being measured.
セッション識別子フィールドを任意に設定することができます。 DSフィールドは、測定されるトラフィッククラスに設定しなければなりません。
The Timestamp 1 field SHOULD be set to the time at which this DM Query is transmitted, in the format indicated by the Querier Timestamp Format field. The Timestamp 2 field MUST be set to 0. If a response was previously received in this measurement session, the Timestamp 1 and Timestamp 2 fields of the most recent such response MAY be copied to the Timestamp 3 and Timestamp 4 fields, respectively, of this query; otherwise, the Timestamp 3 and Timestamp 4 fields MUST be set to 0.
タイムスタンプフィールド1はクエリアタイムスタンプ形式フィールドで指定した形式で、このDMクエリが送信された時刻に設定されるべきです。応答が以前にこの測定セッション中に受信された場合にタイムスタンプ2フィールドは、タイムスタンプ1は、0に設定しなければならなくて、最も最近、このような応答のタイムスタンプ2のフィールドは、この、それぞれ、タイムスタンプ3及びタイムスタンプ4つのフィールドにコピーすることができますクエリ;そうでない場合、タイムスタンプ3及びタイムスタンプ4つのフィールドは0に設定しなければなりません。
Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be set to the time at which this DM Query was received.
DMクエリメッセージを受信すると、タイムスタンプ2フィールドは、このDMクエリを受信した時刻に設定されるべきです。
At this point, the DM Query message must be inspected. If the Control Code field is set to 0x2 (No Response Requested), a DM Response message MUST NOT be transmitted. If the Control Code field is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band Response Requested), then an in-band or out-of-band response, respectively, SHOULD be transmitted unless this has been prevented by an administrative, security, or congestion control mechanism.
この時点で、DMのクエリメッセージを検査しなければなりません。制御コードフィールドが（応答が要求されていない）を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応答の、それぞれ、タイムスタンプ3及びタイムスタンプ4フィールドにコピーする必要があります。
The Responder Timestamp Format (RTF) field MUST be set to the timestamp format used by the responder when writing timestamp fields in this message, i.e., Timestamp 4 and (if applicable) Timestamp 1; the possible values for this field are listed in Section 3.4. Furthermore, the RTF field MUST be set equal to either the QTF or the RPTF field. See Section 4.3.5 for guidelines on the selection of the value for this field.
レスポンダタイムスタンプ・フォーマット（RTF）フィールドがこのメッセージにタイムスタンプフィールドを書き込むときにレスポンダによって使用されるタイムスタンプ形式に設定しなければならない、即ち、タイムスタンプ4及び（該当する場合）、タイムスタンプ1。このフィールドに指定可能な値は、3.4節に記載されています。また、RTFフィールドがQTF又はRPTFフィールドのいずれかに等しく設定されなければなりません。このフィールドの値の選択に関するガイドラインについては、セクション4.3.5を参照してください。
The Responder's Preferred Timestamp Format (RPTF) field MUST be set to one of the values listed in Section 3.4 and SHOULD be set to indicate the timestamp format with which the responder can provide the best accuracy for purposes of delay measurement.
レスポンダの優先タイムスタンプ形式（RPTF）フィールドは、3.4節に列挙された値のいずれかに設定しなければならなくて、レスポンダは、遅延測定のために最高の精度を提供可能なタイムスタンプ形式を示すように設定されるべきです。
The Control Code field MUST be set to one of the values for Response messages listed in Section 3.1. The value 0x10 (Unspecified Error) SHOULD NOT be used if one of the other more specific error codes is applicable.
制御コードフィールドは、セクション3.1に記載されている応答メッセージのためのいずれかの値に設定しなければなりません。他のより具体的なエラーコードのいずれかが適用された場合に値が0x10（予期しないエラー）が使用されるべきではありません。
If the response is transmitted in-band, the Timestamp 1 field SHOULD be set to the time at which this DM Response is transmitted. If the response is transmitted out-of-band, the Timestamp 1 field MUST be set to 0. In either case, the Timestamp 2 field MUST be set to 0.
応答は、帯域内送信される場合、タイムスタンプ1フィールドは、このDM応答が送信された時刻に設定されるべきです。応答が帯域外送信される場合、タイムスタンプ1フィールドは、いずれの場合に0に設定しなければなりません、タイムスタンプ2フィールドが0に設定しなければなりません。
If the response is transmitted in-band and the Control Code in the message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields MUST have the same format, which will be the format indicated in the Responder Timestamp Format field.
応答は、メッセージ内のインバンドおよび制御コード送信された場合は0x1（成功）であり、その後、タイムスタンプ1及びタイムスタンプ4のフィールドは、レスポンダタイムスタンプ形式フィールドで指定した形式であろうと同じフォーマットを有していなければなりません。
Upon in-band receipt of a DM Response message, the Timestamp 2 field is set to the time at which this DM Response was received. (Since the life of the DM message in the network has ended at this point, it is up to the receiver whether this final modification is made to the packet. If the message is to be forwarded on for external post-processing (Section 2.9.7), then these modifications MUST be made.)
DM応答メッセージの帯域受信時に、タイムスタンプ2フィールドは、このDM応答を受信した時刻に設定されています。ネットワーク内のDMメッセージの寿命はこの時点で終了しているので（それは、この最終的な修正がパケットに対して行われているかどうかを受信機までである。メッセージは、外部の後処理（セクション2.9のために転送される場合。 7）、これらの修正はなされなければなりません。）
Upon out-of-band receipt of a DM Response message, the Timestamp 1 and Timestamp 2 fields MUST NOT be used for purposes of delay measurement.
DM応答メッセージのアウトオブバンド受信すると、タイムスタンプ1及びタイムスタンプ2のフィールドは、遅延測定のために使用してはいけません。
If the Control Code in a DM Response is anything other than 0x1 (Success), the timestamp values in the response MUST NOT be used for purposes of delay measurement. If the Control Code indicates an error condition, or if the response message is invalid, the DM operation MUST be terminated and an appropriate notification to the user generated.
DM応答の制御コードは、0x1の（成功）以外の場合は、応答のタイムスタンプ値は、遅延測定の目的のために使用してはいけません。制御コードは、エラー状態を示し、又は応答メッセージが無効である場合、DM動作を終了しなければならなくて、ユーザーに適切な通知を生成した場合。
In case either the querier or the responder in a DM transaction is capable of supporting multiple timestamp formats, it is desirable to determine the optimal format for purposes of delay measurement on a particular channel. The procedures for making this determination SHALL be as follows.
クエリアまたはDMトランザクションにおける応答のいずれかが複数のタイムスタンプ・フォーマットをサポートすることができる場合には、特定のチャネル上の遅延測定の目的のために最適な形式を決定することが望ましいです。次のようにこの決定を行うための手順がなければなりません。
Upon sending an initial DM Query over a channel, the querier sets the Querier Timestamp Format (QTF) field to its preferred timestamp format.
チャネルを介して初期のDMクエリを送信すると、クエリアは、その好ましいタイムスタンプ形式にクエリアタイムスタンプ形式（QTF）フィールドを設定します。
Upon receiving any DM Query message, the responder determines whether it is capable of writing timestamps in the format specified by the QTF field. If so, the Responder Timestamp Format (RTF) field is set equal to the QTF field. If not, the RTF field is set equal to the Responder's Preferred Timestamp Format (RPTF) field.
任意DMクエリメッセージを受信すると、レスポンダは、QTFフィールドによって指定された形式でタイムスタンプを書き込むことが可能であるか否かを判断します。もしそうであれば、レスポンダタイムスタンプ・フォーマット（RTF）フィールドはQTFフィールドに等しく設定されます。そうでない場合、RTFフィールドは、レスポンダの優先タイムスタンプフォーマット（RPTF）フィールドに等しく設定されます。
The process of changing from one timestamp format to another at the responder may result in the Timestamp 1 and Timestamp 4 fields in an in-band DM Response having different formats. If this is the case, 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).
レスポンダに別のタイムスタンプ形式から変更する処理は、異なるフォーマットを有する帯域内DM応答のタイムスタンプ1及びタイムスタンプ4フィールドをもたらすことができます。このような場合は、応答して制御コードは0x1（成功）に設定してはいけません。エラー状態が発生した場合を除き、コントロールコードを0x2（ - データフォーマット無効通知）に設定しなければなりません。
Upon receiving a DM Response, the querier knows from the RTF field in the message whether the responder is capable of supporting its preferred timestamp format: if it is, the RTF will be equal to the QTF. The querier also knows the responder's preferred timestamp format from the RPTF field. The querier can then decide whether to retain its current QTF or to change it and repeat the negotiation procedures.
DMレスポンスを受信すると、クエリアは、レスポンダは、その好ましいタイムスタンプ形式をサポートすることができるかどうかのメッセージでRTFフィールドから知っている：それがある場合、RTFはQTFに等しくなります。クエリアはまたRPTFフィールドからの応答の優先タイムスタンプ形式を知っています。クエリアは、その現在のQTFを保持するか、それを変更し、交渉の手順を繰り返すかどうかを決定することができます。
When an implementation supports only one timestamp format, the procedures above reduce to the following simple behavior:
実装は唯一のタイムスタンプ形式をサポートしている場合は、上記の手順は、次のような単純な動作に減らします。
o All DM Queries are transmitted with the same QTF;
OすべてのDMのクエリは、同じQTFで送信されます。
o All DM Responses are transmitted with the same RTF, and the RPTF is always set equal to the RTF;
OすべてDM応答は同じRTFで送信され、そしてRPTFは常にRTFに等しく設定されています。
o All DM Responses received with RTF not equal to QTF are discarded;
O 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-LOCATION：そのようなキューイングのようなパケット処理の他の段階に対して損失及び遅延測定点の位置。
o CHANNEL-TYPES: The types of channels for which LM and DM are supported, including LSP types, pseudowires, and sections (links).
Oチャネル-TYPES：LSPタイプ、スードワイヤ、およびセクション（リンク）を含むLMとDMがサポートされているチャネルのタイプ。
o QUERY-RATE: The minimum supported query intervals for LM and DM sessions, both in the querier and responder roles.
OのQUERY-RATE：LMとDMセッションでサポートされる最小のクエリ間隔、クエリアおよびレスポンダーの役割の両方で。
o LOOP: Whether loopback measurement (Section 2.8) is supported.
Oループ：ループバック測定（2.8節）がサポートされているかどうか。
o LM-TYPES: Whether direct or inferred LM is supported, and for the latter, which test protocols or proxy message types are supported.
直接または推論LMがサポートされるかどうか、および試験プロトコルまたはプロキシメッセージタイプがサポートされ、後者の場合：LM-TYPES O。
o LM-COUNTERS: Whether 64-bit counters are supported.
LM-COUNTERS O：64ビットカウンタがサポートされているかどうか。
o LM-ACCURACY: The expected measurement accuracy levels for the supported forms of LM, and the expected impact of exception conditions such as lost and misordered messages.
O LM精度：LMのサポートされているフォームの予想される測定精度レベル、及びそのような失われたとmisorderedメッセージなどの例外条件の予想される影響。
o LM-SYNC: The implementation's behavior in regard to the synchronization conditions discussed in Section 2.9.8.
O LM-SYNC：セクション2.9.8で説明した同期条件に関しては実装の振る舞い。
o LM-SCOPE: The supported LM scopes (Sections 2.9.9 and 4.2.8).
O LM-SCOPE：サポートLMスコープ（セクション2.9.9および4.2.8）。
o DM-ACCURACY: The expected measurement accuracy levels for the supported forms of DM.
O DM精度：DMのサポートされている形態の予想測定精度レベル。
o DM-TS-FORMATS: The supported timestamp formats and the extent of support for computation with and reconciliation of different formats.
入出力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メッセージまたはmisorderedパケットなどの例外的な状況の場合の損失情報に大きなギャップに変換します。
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動作として持続測定動作を行う際、クエリアは、失われた測定メッセージ（応答が受信されなかっされたクエリ）の番号をメモを取り、対応する測定メッセージ損失しきい値を設定する必要があります。このしきい値を超えた場合、測定動作が可能な輻輳状態を悪化させないように中断されるべきです。条件を調査し、修正することができるように、この懸濁液は、ユーザーに適切な通知を伴うべきである（SHOULD）。
From the receiver perspective, the main consideration is the possibility of receiving an excessive quantity of measurement messages. An implementation SHOULD employ a mechanism such as rate-limiting to guard against the effects of this case.
受信機の観点から、主な考慮事項は、測定メッセージの過剰を受ける可能性があります。実装は、この場合の影響を防ぐため、このような速度制限などの機構を採用するべきです。
The measurement protocols described in this document are intended to serve as infrastructure to support a wide range of higher-level monitoring and diagnostic applications, from simple command-line diagnostic tools to comprehensive network performance monitoring and analysis packages. The specific mechanisms and considerations for protocol configuration, initialization, and reporting thus depend on the nature of the application.
本書で説明した測定プロトコルは、包括的なネットワークパフォーマンスの監視および分析パッケージへの単純なコマンドライン診断ツールから、より高いレベルの監視および診断アプリケーションの広い範囲をサポートするためのインフラストラクチャとして機能するように意図されています。プロトコル構成、初期化、及び従って報告するための特定のメカニズムと考慮事項は、アプリケーションの性質に依存します。
In the case of on-demand diagnostics, the diagnostic application may provide parameters such as the measurement type, the channel, the query rate, and the test duration when initiating the diagnostic; results and exception conditions are then reported directly to the application. The system may discard the statistics accumulated during the test after the results have been reported or retain them to provide a historical measurement record.
オンデマンド診断の場合、診断アプリケーションは、測定の種類、チャンネル、クエリーレート、および診断を開始する試験期間などのパラメータを提供することができます。その結果、例外条件は、アプリケーションに直接報告されています。システムは、結果が報告された後にテスト中に蓄積された統計データを破棄するか、履歴測定記録を提供するためにそれらを保持することができます。
Alternatively, measurement configuration may be supplied as part of the channel configuration itself in order to support continuous monitoring of the channel's performance characteristics. In this case, the configuration will typically include quality thresholds depending on the service level agreement, the crossing of which will trigger warnings or alarms, and result reporting and exception notification will be integrated into the system-wide network management and reporting framework.
代替的に、測定構成は、チャネルのパフォーマンス特性の連続的な監視をサポートするために、チャネル構成自体の一部として供給されてもよいです。この場合、構成は、典型的には、サービスレベル契約に応じて品質しきい値を含むであろう、との交差は、警告または警報をトリガする、と報告し、例外通知がシステム全体のネットワーク管理および報告フレームワークに統合される結果。
This document describes procedures for the measurement of performance metrics over a pre-existing MPLS path (a pseudowire, LSP, or section). As such, it assumes that a node involved in a measurement operation has previously verified the integrity of the path and the identity of the far end using existing MPLS mechanisms such as Bidirectional Forwarding Detection (BFD) [RFC5884]; tools, techniques, and considerations for securing MPLS paths are discussed in detail in [RFC5920].
この文書は、既存のMPLSパス（疑似回線、LSP、またはセクション）上のパフォーマンス・メトリックを測定するための手順を記載しています。このように、測定動作に関与するノードは、以前の経路とそのような双方向フォワーディング検出（BFD）[RFC5884]などの既存のMPLSメカニズムを使用して遠端のアイデンティティの完全性を検証したことを前提とし、 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.
遠端の身元が確認された場合でも、測定プロトコルは、注射やman-in-the-middle攻撃に対して脆弱残ります。このような攻撃の影響は、影響を受けるパス上のパフォーマンス測定の品質を妥協することであろう。これらの測定値を破壊するように配置さ攻撃者は、ネットワーク制御プレーンまたはユーザトラフィックフローのように、しかし、ネットワークのはるかに重要な要素を破壊することによってはるかに大きなダメージを与えることが可能です。最悪の場合、測定プロトコルの破壊は、パスに関連付けられたサービスレベル契約のパフォーマンスの側面の監視を妨害します。こうした混乱の存在は、基本的なパスの整合性の重大な違反が既に発生していたことを暗示します。
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
「PW関連するチャンネルタイプ」レジストリ内のチャネルタイプのOの割り当て
o Creation of a "Measurement Timestamp Type" registry
O創造「計測タイムスタンプの種類」のレジストリ
o Creation of an "MPLS Loss/Delay Measurement Control Code" registry
「MPLS損失/遅延測定制御コード」レジストリの創造O
o Creation of an "MPLS Loss/Delay Measurement Type-Length-Value (TLV) Object" registry
Oの創造 "MPLS損失/遅延測定のType-Length-Value（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.
Typeフィールドの範囲は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損失/遅延測定制御コード」レジストリを作成しました。このレジストリは、次のようにフォーマットおよび初期割り当てと、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.
応答コードセクションの0xFの非エラー応答コードのために予約されている - IANAの値は0x0であることが示されました。
The range of the Code field is 0 - 255.
255 - Codeフィールドの範囲は0です。
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.
255 - Typeフィールドの範囲は0です。
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ワーキンググループの多くの参加者に感謝したいです。著者は、スループット測定用LMメッセージを使用してのアイデアのためのリンダ・ダンバーに、多くの有用な思考や議論のためのアレクサンダーVainshtein、ロア・アンダーソン、と高木浩之に特別な感謝を提供し、そしてベン・ニーヴン・ジェンキンス、マルク・Lasserre、ベンMack-へ彼らの貴重なコメントのためのクレーン。
[IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", March 2008.
[IEEE1588] IEEE、2008年3月「ネットワーク計測・制御システムのための高精度クロック同期プロトコルのために1588年から2008年IEEE規格」。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（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]アンデション、L.およびR. Asatiは、 "マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ： "EXPトラフィッククラス "フィールド"、RFC 5462、2009年2月" フィールドに改名します"。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]ボッチ、M.、Vigoureux、M.、およびS.ブライアント、 "MPLSジェネリック関連チャンネル"、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]ミルズ、D.、マーティン、J.、バーバンク、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]グロスマン、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]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、RFC 3985、2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、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.、カープ、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]ツバメ、G.、ブライアント、S.、およびL.アンダーソン、 "MPLSネットワークにおけるイコールコストマルチパス治療の回避"、BCP 128、RFC 4928、2007年6月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、Minei、I.、およびB.トーマス、 "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]ヘダーヤト、K.、Krzanowski、R.、モートン、A.、ヤム、K.、およびJ. Babiarz、 "双方向アクティブ測定プロトコル（TWAMP）"、RFC 5357、2008年10月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481]モートン、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]アガルワル、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、RFC 5884、2010年6月 "MPLSラベルの双方向フォワーディング検出（BFD）はパス（LSPを）交換しました"。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]牙、L.、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、RFC 5920、2010年7月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]ボッチ、M.、ブライアント、S.、フロスト、D.、Levrau、L.、およびL.バーガー、 "トランスポートネットワークにおけるMPLSのための枠組み"、RFC 5921、2010年7月。
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960]フロスト、D.、ブライアント、S.、およびM.ボッチは、RFC 5960、2010年8月、 "MPLS交通は、データプレーンのアーキテクチャプロフィール"。
[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]フロスト、D.、エド。 、RFC 6375、2011年9月およびS.ブライアント、エド。、「MPLSベースのトランスポートネットワークのパケットロスや遅延測定プロファイル」。
[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月。
Appendix A. Default Timestamp Format Rationale
付録A.デフォルトのタイムスタンプ形式根拠
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高精度時間プロトコル（PTP）のタイムスタンプの仕様につながっています。 NTPは、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
メールアドレス：danfrost@cisco.com
Stewart Bryant Cisco Systems
スチュワートブライアントシスコシステムズ
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com