[要約] RFC 9341は、ライブトラフィックでのパケット損失、遅延、ジッターの測定に使用されるAlternate-Marking技術を説明しています。この技術はさまざまな状況やプロトコルに適用可能であり、RFC 7799で定義された分類によっては、アプリケーションに応じてパッシブまたはハイブリッドと考えられます。
Internet Engineering Task Force (IETF) G. Fioccola, Ed.
Request for Comments: 9341 Huawei Technologies
Obsoletes: 8321 M. Cociglio
Category: Standards Track Telecom Italia
ISSN: 2070-1721 G. Mirsky
Ericsson
T. Mizrahi
T. Zhou
Huawei Technologies
December 2022
This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321.
このドキュメントでは、ライブトラフィックでパケットの損失、遅延、およびジッター測定を実行する代替マークテクニックについて説明します。この技術は、さまざまな状況およびさまざまなプロトコルに適用できます。RFC 7799で定義されている分類によると、アプリケーションに応じて受動的またはハイブリッドと見なされる可能性があります。このドキュメントは、RFC 8321を廃止します。
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 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9341.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9341で取得できます。
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Summary of Changes from RFC 8321
1.2. Requirements Language
2. Overview of the Method
3. Detailed Description of the Method
3.1. Packet-Loss Measurement
3.2. One-Way Delay Measurement
3.2.1. Single-Marking Methodology
3.2.2. Double-Marking Methodology
3.3. Delay Variation Measurement
4. Alternate-Marking Functions
4.1. Marking the Packets
4.2. Counting and Timestamping Packets
4.3. Data Collection and Correlation
5. Synchronization and Timing
6. Packet Fragmentation
7. Recommendations for Deployment
7.1. Controlled Domain Requirement
8. Compliance with Guidelines from RFC 6390
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Most Service Providers' networks carry traffic with contents that are highly sensitive to packet loss [RFC7680], delay [RFC7679], and jitter [RFC3393].
ほとんどのサービスプロバイダーのネットワークは、パケット損失[RFC7680]、遅延[RFC7679]、およびジッター[RFC3393]に非常に敏感なコンテンツを備えたトラフィックを搭載しています。
Methodologies and tools are therefore needed to monitor and accurately measure network performance, in order to constantly control the quality of experience perceived by the end customers. Performance monitoring also provides useful information for improving network management (e.g., isolation of network problems, troubleshooting, etc.).
したがって、最終的な顧客が知覚する経験の質を常に制御するために、ネットワークのパフォーマンスを監視および正確に測定するには、方法論とツールが必要です。パフォーマンス監視は、ネットワーク管理を改善するための有用な情報も提供します（たとえば、ネットワークの問題の分離、トラブルシューティングなど）。
[RFC7799] defines Active, Passive, and Hybrid Methods of Measurement. In particular, Active Methods of Measurement depend on a dedicated measurement packet stream; Passive Methods of Measurement are based solely on observations of an undisturbed and unmodified packet stream of interest; Hybrid Methods are Methods of Measurement that use a combination of Active Methods and Passive Methods.
[RFC7799]は、アクティブ、パッシブ、ハイブリッドの測定方法を定義します。特に、測定のアクティブな方法は、専用の測定パケットストリームに依存します。受動的な測定方法は、関心のない邪魔されず、変更されていないパケットストリームの観察のみに基づいています。ハイブリッド方法は、アクティブな方法と受動的方法の組み合わせを使用する測定方法です。
This document proposes a performance monitoring technique, called the "Alternate-Marking Method", which is potentially applicable to any kind of packet-based traffic, both point-to-point unicast and multicast, including Ethernet, IP, and MPLS. The method primarily addresses packet-loss measurement, but it can be easily extended to one-way or two-way delay and delay variation measurements as well.
このドキュメントは、イーサネット、IP、MPLを含むポイントツーポイントユニキャストとマルチキャストの両方のパケットベースのトラフィックに適用される可能性がある「代替マルキング方法」と呼ばれるパフォーマンス監視手法を提案します。この方法は主にパケットロス測定に対処しますが、一方向または双方向の遅延および遅延変動測定にも簡単に拡張できます。
The Alternate-Marking methodology, described in this document, allows the synchronization of the measurements at different points by dividing the packet flow into batches. So it is possible to get coherent counters and timestamps in every marking period and therefore measure the Performance Metrics for the monitored flow.
このドキュメントで説明されている代替マーキング方法論により、パケットフローをバッチに分割することにより、さまざまなポイントでの測定値を同期させることができます。したがって、すべてのマーキング期間でコヒーレントなカウンターとタイムスタンプを取得し、監視されたフローのパフォーマンスメトリックを測定することができます。
The method has been explicitly designed for Passive or Hybrid measurements as stated in [RFC8321]. But, according to the definitions of [RFC7799], the Alternate-Marking Method can be classified as Hybrid Type I. Indeed, Alternate Marking can be implemented by using reserved bits in the protocol header, and the change in value of these marking bits at the domain edges (and not along the path) is formally considered a modification of the stream of interest.
この方法は、[RFC8321]に記載されているように、受動的またはハイブリッド測定用に明示的に設計されています。しかし、[RFC7799]の定義によれば、代替マーク法はハイブリッドタイプIに分類できます。ドメインのエッジ（パスに沿っていない）は、対象の流れの修正と正式に見なされます。
It is worth mentioning that this is a methodology document, so the mechanism that can be used to transmit the counters and the timestamps is out of scope here. Additional details about the applicability of the Alternate-Marking methodology are described in [IEEE-NETWORK-PNPM].
これは方法論ドキュメントであることに言及する価値があるため、カウンターとタイムスタンプを送信するために使用できるメカニズムはここでは範囲外です。代替マーキング方法の適用性に関する追加の詳細については、[IEEE-Network-PNPM]で説明されています。
This document defines the Alternate-Marking Method, addressing ambiguities and building on its experimental phase that was based on the original specification [RFC8321].
このドキュメントでは、代替マルキング方法を定義し、元の仕様[RFC8321]に基づいた実験段階でのあいまいさと構築に対処します。
The relevant changes are:
関連する変更は次のとおりです。
* Added the recommendations about the methods to employ in case one or two flag bits are available for marking (Section 7).
* 1つまたは2つのフラグビットがマーキングに使用できる場合に使用する方法に関する推奨事項を追加しました（セクション7）。
* Changed the structure to improve the readability.
* 構造を変更して、読みやすさを向上させました。
* Removed the wording about the initial experiments of the method and considerations that no longer apply.
* 方法の最初の実験と、もはや適用されない考慮事項についての文言を削除しました。
* Extended the description of detailed aspects of the methodology, e.g., synchronization, timing, packet fragmentation, and marked and unmarked traffic handling.
* 方法論の詳細な側面の説明を拡張しました。たとえば、同期、タイミング、パケット断片化、マークされたマークのないトラフィックハンドリング。
It is important to note that all the changes are totally backward compatible with [RFC8321] and no new additional technique has been introduced in this document compared to [RFC8321].
すべての変更は[RFC8321]と完全に逆方向に互換性があり、[RFC8321]と比較してこのドキュメントに新しい追加手法が導入されていないことに注意することが重要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
In order to perform packet-loss measurements on a production traffic flow, different approaches exist. The most intuitive one consists in numbering the packets so that each router that receives the flow can immediately detect a packet that is missing. This approach, though very simple in theory, is not simple to achieve: it requires the insertion of a sequence number into each packet, and the devices must be able to extract the number and check it in real time. Such a task can be difficult to implement on live traffic: if UDP is used as the transport protocol, the sequence number is not available; on the other hand, if a higher-layer sequence number (e.g., in the RTP header) is used, extracting that information from each packet and processing it in real time could overload the device.
生産トラフィックフローでパケットロス測定を実行するために、さまざまなアプローチが存在します。最も直感的なものは、フローを受信する各ルーターが欠落しているパケットをすぐに検出できるように、パケットの番号を付けることで構成されています。このアプローチは、理論的には非常に単純ですが、達成するのは簡単ではありません。各パケットにシーケンス番号を挿入する必要があり、デバイスは数値を抽出してリアルタイムで確認できる必要があります。このようなタスクは、ライブトラフィックに実装するのが難しい場合があります。UDPが輸送プロトコルとして使用される場合、シーケンス番号は使用できません。一方、高層シーケンス番号（RTPヘッダーなど）が使用される場合、各パケットからその情報を抽出してリアルタイムで処理すると、デバイスにオーバーロードされる可能性があります。
An alternate approach is to count the number of packets sent on one end, count the number of packets received on the other end, and compare the two values. This operation is much simpler to implement, but it requires the devices performing the measurement to be in sync: in order to compare two counters, it is required that they refer exactly to the same set of packets. Since a flow is continuous and cannot be stopped when a counter has to be read, it can be difficult to determine exactly when to read the counter. A possible solution to overcome this problem is to virtually split the flow in consecutive blocks by periodically inserting a delimiter so that each counter refers exactly to the same block of packets. The delimiter could be, for example, a special packet inserted artificially into the flow. However, delimiting the flow using specific packets has some limitations. First, it requires generating additional packets within the flow and requires the equipment to be able to process those packets. In addition, the method is vulnerable to out-of-order reception of delimiting packets and, to a lesser extent, to their loss.
別のアプローチは、一方の端に送信されたパケットの数を数え、もう一方の端で受信したパケットの数をカウントし、2つの値を比較することです。この操作の実装ははるかに簡単ですが、測定を実行するデバイスを同期する必要があります。2つのカウンターを比較するには、同じパケットのセットを正確に参照する必要があります。フローは連続しており、カウンターを読み取る必要があるときに停止することはできないため、カウンターをいつ読み取るかを正確に判断することは難しい場合があります。この問題を克服する可能性のある解決策は、各カウンターが同じパケットのブロックを正確に参照できるように、デリミタを定期的に挿入することにより、連続ブロックでフローを事実上分割することです。デリミターは、たとえば、フローに人工的に挿入された特別なパケットである可能性があります。ただし、特定のパケットを使用してフローを区切るには、いくつかの制限があります。まず、フロー内で追加のパケットを生成する必要があり、これらのパケットを処理できるように機器が必要です。さらに、この方法は、描写パケットの境界外受信、およびそれほどではないが、その損失に対して脆弱です。
The method proposed in this document follows the second approach, but it doesn't use additional packets to virtually split the flow in blocks. Instead, it "marks" the packets so that the packets belonging to the same block will have the same notional "color", whilst consecutive blocks will have different colors. Each change of color represents a sort of auto-synchronization signal that enhances the consistency of measurements taken by different devices along the path.
このドキュメントで提案されている方法は2番目のアプローチに従いますが、ブロック内のフローを事実上分割するために追加のパケットを使用しません。代わりに、パケットを「マーク」して、同じブロックに属するパケットが同じ概念的な「色」になり、連続したブロックには異なる色があります。色の各変化は、パスに沿って異なるデバイスによって採取された測定の一貫性を高める一種の自動同期信号を表します。
Figure 1 represents a very simple network and shows how the method can be used to measure packet loss on different network segments: by enabling the measurement on several interfaces along the path, it is possible to perform link monitoring, node monitoring, or end-to-end monitoring. The method is flexible enough to measure packet loss on any segment of the network and can be used to isolate the faulty element.
図1は非常にシンプルなネットワークを表しており、さまざまなネットワークセグメントのパケット損失を測定するためにメソッドを使用する方法を示しています。パスに沿ったいくつかのインターフェイスでの測定を有効にすることにより、リンク監視、ノード監視、またはエンドツーを実行することができます。-監視を終了する。この方法は、ネットワークのあらゆるセグメントでパケット損失を測定するのに十分な柔軟性があり、故障した要素を分離するために使用できます。
Traffic Flow
========================================================>
+------+ +------+ +------+ +------+
---<> R1 <>-----<> R2 <>-----<> R3 <>-----<> R4 <>---
+------+ +------+ +------+ +------+
. . . . . .
. . . . . .
. <------> <-------> .
. Node Packet Loss Link Packet Loss .
. .
<--------------------------------------------------->
End-to-End Packet Loss
Figure 1: Available Measurements
図1：利用可能な測定
This section describes, in detail, how the method operates. A special emphasis is given to the measurement of packet loss, which represents the core application of the method, but applicability to delay and jitter measurements is also considered.
このセクションでは、メソッドの動作方法について詳しく説明します。メソッドのコアアプリケーションを表すパケット損失の測定に特に重点が置かれていますが、遅延およびジッター測定への適用性も考慮されます。
The basic idea is to virtually split traffic flows into consecutive blocks: each block represents a measurable entity unambiguously recognizable by all network devices along the path. By counting the number of packets in each block and comparing the values measured by different network devices along the path, it is possible to measure if packet loss occurred in any single block between any two points.
基本的なアイデアは、トラフィックフローが連続したブロックに実質的に分割されることです。各ブロックは、パスに沿ったすべてのネットワークデバイスが明確に認識できる測定可能なエンティティを表します。各ブロック内のパケットの数をカウントし、パスに沿って異なるネットワークデバイスで測定された値を比較することにより、任意の2つのポイント間の単一ブロックでパケット損失が発生したかどうかを測定することができます。
As discussed in the previous section, a simple way to create the blocks is to "color" the traffic (two colors are sufficient) so that packets belonging to alternate consecutive blocks will have different colors. Whenever the color changes, the previous block terminates and the new one begins. Hence, all the packets belonging to the same block will have the same color, and packets of different consecutive blocks will have different colors. The number of packets in each block depends on the criterion used to create the blocks:
前のセクションで説明したように、ブロックを作成する簡単な方法は、代替ブロックに属するパケットが異なる色を持つように、トラフィックを「2色で十分に色」することです。色が変わるたびに、前のブロックが終了し、新しいブロックが始まります。したがって、同じブロックに属するすべてのパケットは同じ色を持ち、異なる連続したブロックのパケットは異なる色を持ちます。各ブロックのパケットの数は、ブロックの作成に使用される基準によって異なります。
* if the color is switched after a fixed number of packets, then each block will contain the same number of packets (except for any losses); and
* 固定数のパケットの後に色が切り替えられた場合、各ブロックには同じ数のパケットが含まれます（損失を除く）。そして
* if the color is switched according to a fixed timer, then the number of packets may be different in each block depending on the packet rate.
* 固定タイマーに従って色が切り替えられている場合、パケットレートに応じて各ブロックでパケットの数が異なる場合があります。
The use of a fixed timer for the creation of blocks is REQUIRED when implementing this specification. The switching after a fixed number of packets is an additional possibility, but its detailed specification is out of scope. An example of application is in [EXPLICIT-FLOW-MEASUREMENTS].
この仕様を実装する際には、ブロックを作成するために固定タイマーの使用が必要です。固定数のパケットの後の切り替えは追加の可能性ですが、その詳細な仕様は範囲外です。アプリケーションの例は[明示的なフロー測定]にあります。
The following figure shows how a flow appears when it is split into traffic blocks with colored packets.
次の図は、色付きパケットを使用してトラフィックブロックに分割されたときのフローがどのように表示されるかを示しています。
A: packet with A coloring
B: packet with B coloring
| | | | |
| | Traffic Flow | |
------------------------------------------------------------------->
BBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA
------------------------------------------------------------------->
... | Block 5 | Block 4 | Block 3 | Block 2 | Block 1
| | | | |
Figure 2: Traffic Coloring
図2：交通着色
Figure 3 shows how the method can be used to measure link packet loss between two adjacent nodes.
図3は、2つの隣接するノード間のリンクパケット損失を測定するためにメソッドを使用する方法を示しています。
Referring to the figure, let's assume we want to monitor the packet loss on the link between two routers: router R1 and router R2. According to the method, the traffic is colored alternatively with two different colors: A and B. Whenever the color changes, the transition generates a sort of square-wave signal, as depicted in the following figure.
図を参照すると、2つのルーター間のリンクのパケット損失を監視したいと思います：ルーターR1とルーターR2。この方法によれば、トラフィックは、AとBの2つの異なる色で色付けされています。色が変化するたびに、次の図に示すように、遷移は一種の平方波信号を生成します。
Color A ----------+ +-----------+ +----------
| | | |
Color B +-----------+ +-----------+
Block n ... Block 3 Block 2 Block 1
<---------> <---------> <---------> <---------> <--------->
Traffic Flow
===========================================================>
Color ...AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA...
===========================================================>
Figure 3: Computation of Link Packet Loss
図3：リンクパケット損失の計算
Traffic coloring can be done by R1 itself if the traffic is not already colored. R1 needs two counters, C(A)R1 and C(B)R1, on its egress interface: C(A)R1 counts the packets with color A and C(B)R1 counts those with color B. As long as traffic is colored as A, only counter C(A)R1 will be incremented, while C(B)R1 is not incremented; conversely, when the traffic is colored as B, only C(B)R1 is incremented. C(A)R1 and C(B)R1 can be used as reference values to determine the packet loss from R1 to any other measurement point down the path. Router R2, similarly, will need two counters on its ingress interface, C(A)R2 and C(B)R2, to count the packets received on that interface and colored with A and B, respectively. When an A block ends, it is possible to compare C(A)R1 and C(A)R2 and calculate the packet loss within the block; similarly, when the successive B block terminates, it is possible to compare C(B)R1 with C(B)R2, and so on, for every successive block.
トラフィックがまだ着色されていない場合、トラフィックの着色はR1自体によって行うことができます。R1には2つのカウンターが必要です。C（a）R1とC（b）R1、その出口インターフェイスでは：C（a）R1は、色AとC（b）R1をカウントします。Aとして色付けされている場合、カウンターC（a）R1のみが増加しますが、C（b）R1は増加しません。逆に、トラフィックがBとして色付けされると、C（b）R1のみが増加します。C（A）R1およびC（B）R1を参照値として使用して、R1からパスの他の測定ポイントへのパケット損失を決定できます。同様に、Router R2は、そのインターフェイスで受信したパケットをカウントし、それぞれAとBで色付けされたパケットをカウントするために、その侵入インターフェイスC（A）R2およびC（B）R2に2つのカウンターが必要です。Aブロックが終了すると、C（A）R1とC（A）R2を比較して、ブロック内のパケット損失を計算することができます。同様に、連続したBブロックが終了すると、C（B）R1をC（B）R2と比較することができます。
Likewise, by using two counters on the R2 egress interface, it is possible to count the packets sent out of the R2 interface and use them as reference values to calculate the packet loss from R2 to any measurement point downstream from R2.
同様に、R2 Egressインターフェイスで2つのカウンターを使用することにより、R2インターフェイスから送信されたパケットをカウントし、R2からR2からR2から下流の任意の測定ポイントへのパケット損失を参照値として使用することができます。
The length of the blocks can be chosen large enough to simplify the collection and the comparison of measures taken by different network devices. It's preferable to read the value of the counters not immediately after the color switch: some packets could arrive out of order and increment the counter associated with the previous block (color), so it is worth waiting for some time. A safe choice is to wait L/2 time units (where L is the duration for each block) after the color switch, to read the counter of the previous color (Section 5). The drawback is that the longer the duration of the block, the less frequently the measurement can be taken.
ブロックの長さは、コレクションを簡素化するのに十分な大きさで選択でき、さまざまなネットワークデバイスが取ったメジャーの比較を行うことができます。カラースイッチの直後ではなく、カウンターの値を読み取ることが望ましいです。一部のパケットは、前のブロック（色）に関連付けられているカウンターを順番に到着し、しばらく待つ価値があります。安全な選択は、L/2時間単位（Lは各ブロックの持続時間）を待機し、前の色のカウンターを読むことです（セクション5）。欠点は、ブロックの持続時間が長くなればなるほど、測定値が少なくなることです。
Two different strategies that can be used when implementing the method are:
メソッドを実装するときに使用できる2つの異なる戦略は次のとおりです。
flow-based:
フローベース：
the flow-based strategy is used when well-defined traffic flows need to be monitored. According to this strategy, only the specified flow is colored. Counters for packet-loss measurements can be instantiated for each single flow, or for the set as a whole, depending on the desired granularity. With this approach, it is necessary to know in advance the path followed by flows that are subject to measurement. Path rerouting and traffic load balancing need to be taken into account.
明確に定義されたトラフィックフローを監視する必要がある場合、フローベースの戦略が使用されます。この戦略によれば、指定されたフローのみが色付けされています。パケット損失測定のカウンターは、目的の粒度に応じて、単一のフローごとに、またはセット全体でインスタンス化できます。このアプローチを使用すると、測定の対象となる流れの後にパスを事前に知る必要があります。パスの再ルーティングとトラフィックロードバランスを考慮する必要があります。
link-based:
リンクベース：
measurements are performed on all the traffic on a link-by-link basis. The link could be a physical link or a logical link. Counters could be instantiated for the traffic as a whole or for each traffic class (in case it is desired to monitor each class separately), but in the second case, two counters are needed for each class.
すべてのトラフィックでリンクごとに測定が実行されます。リンクは、物理的なリンクまたは論理リンクである可能性があります。カウンターは、トラフィック全体または各トラフィッククラスに対してインスタンス化できます（各クラスを個別に監視することが望ましい場合）が、2番目のケースでは、各クラスに2つのカウンターが必要です。
The flow-based strategy is REQUIRED when implementing this specification. It requires the identification of the flow to be monitored and the discovery of the path followed by the selected flow. It is possible to monitor a single flow or multiple flows grouped together, but in this case, measurement is consistent only if all the flows in the group follow the same path. Moreover, if a measurement is performed by grouping many flows, it is not possible to determine exactly which flow was affected by packet loss. In order to have measures per single flow, it is necessary to configure counters for each specific flow. Once the flow(s) to be monitored has been identified, it is necessary to configure the monitoring on the proper nodes. Configuring the monitoring means configuring the rule to intercept the traffic and configuring the counters to count the packets. To have just an end-to-end monitoring, it is sufficient to enable the monitoring on the first- and last-hop routers of the path: the mechanism is completely transparent to intermediate nodes and independent of the path followed by traffic flows. On the contrary, to monitor the flow on a hop-by-hop basis along its whole path, it is necessary to enable the monitoring on every node from the source to the destination. In case the exact path followed by the flow is not known a priori (i.e., the flow has multiple paths to reach the destination), it is necessary to enable the monitoring on every path: counters on interfaces traversed by the flow will report packet count, whereas counters on other interfaces will be null.
この仕様を実装するときは、フローベースの戦略が必要です。監視するフローの識別と、選択されたフローの後にパスの発見が必要です。単一のフローまたはグループ化された複数のフローを監視することは可能ですが、この場合、グループ内のすべてのフローが同じパスをたどる場合にのみ測定が一貫しています。さらに、多くのフローをグループ化することで測定が実行される場合、パケット損失の影響を受けるフローを正確に判断することはできません。単一のフローあたりの測定値を作成するには、特定のフローごとにカウンターを構成する必要があります。監視対象のフローが特定されたら、適切なノードで監視を構成する必要があります。監視の構成とは、トラフィックを傍受するためにルールを構成し、パケットをカウントするカウンターを構成することを意味します。エンドツーエンドのモニタリングだけを使用するには、パスのファーストホップおよびラストホップルーターでの監視を有効にするだけで十分です。メカニズムは、中間ノードに対して完全に透明であり、パスとそれに続く交通流とは無関係です。それどころか、パス全体に沿ってホップバイホップベースでフローを監視するには、ソースから宛先までのすべてのノードでの監視を有効にする必要があります。フローが続く正確なパスが先験的に不明な場合（つまり、流れには目的地に到達するための複数のパスがあります）、すべてのパスで監視を有効にする必要があります。、一方、他のインターフェイスのカウンターはヌルになります。
The same principle used to measure packet loss can be applied also to one-way delay measurement. There are two methodologies, as described hereinafter.
パケットの損失を測定するために使用されるのと同じ原理は、一元配置遅延測定にも適用できます。以下に説明するように、2つの方法論があります。
Note that, for all the one-way delay alternatives described in the next sections, by summing the one-way delays of the two directions of a path, it is always possible to measure the two-way delay (round-trip "virtual" delay). The Network Time Protocol (NTP) [RFC5905] or the IEEE 1588 Precision Time Protocol (PTP) [IEEE-1588] (as discussed in the previous section) can be used for the timestamp formats depending on the needed precision.
次のセクションで説明されているすべての一方向遅延の代替案について、パスの2つの方向の一方向の遅延を合計することにより、双方向遅延（往復「仮想」を測定することが常に可能であることに注意してください。遅れ）。ネットワークタイムプロトコル（NTP）[RFC5905]またはIEEE 1588 Precision Time Protocol（PTP）[IEEE-1588]（前のセクションで説明）は、必要な精度に応じてタイムスタンプ形式に使用できます。
The alternation of colors can be used as a time reference to calculate the delay. Whenever the color changes (which means that a new block has started), a network device can store the timestamp of the first packet of the new block; that timestamp can be compared with the timestamp of the same packet on a second router to compute packet delay. When looking at Figure 2, R1 stores the timestamp TS(A1)R1 when it sends the first packet of block 1 (A-colored), the timestamp TS(B2)R1 when it sends the first packet of block 2 (B-colored), and so on for every other block. R2 performs the same operation on the receiving side, recording TS(A1)R2, TS(B2)R2, and so on. Since the timestamps refer to specific packets (the first packet of each block), in the case where no packet loss or misordering exists, we would be sure that timestamps compared to compute delay refer to the same packets. By comparing TS(A1)R1 with TS(A1)R2 (and similarly TS(B2)R1 with TS(B2)R2, and so on), it is possible to measure the delay between R1 and R2. In order to have more measurements, it is possible to take and store more timestamps, referring to other packets within each block. The number of measurements could be increased by considering multiple packets in the block; for instance, a timestamp could be taken every N packets, thus generating multiple delay measurements. Taking this to the limit, in principle, the delay could be measured for each packet by taking and comparing the corresponding timestamps (possible but impractical from an implementation point of view).
色の代替は、遅延を計算するための時間参照として使用できます。色が変わるたびに（つまり、新しいブロックが開始されたことを意味します）、ネットワークデバイスは新しいブロックの最初のパケットのタイムスタンプを保存できます。そのタイムスタンプは、2番目のルーターの同じパケットのタイムスタンプと比較して、パケット遅延を計算できます。図2を見ると、R1は、ブロック1（A色）の最初のパケットを送信するときにタイムスタンプTS（A1）R1を保存します。TsamestAmpTS（B2）R1は、ブロック2の最初のパケットを送信するとき（B色）、その他すべてのブロックについて。R2は、受信側で同じ操作を実行し、TS（A1）R2、TS（B2）R2などを記録します。タイムスタンプは特定のパケット（各ブロックの最初のパケット）を参照しているため、パケットの損失や誤整形が存在しない場合、計算遅延と比較したタイムスタンプは同じパケットを参照していることを確認します。TS（A1）R1をTS（A1）R2（および同様にTS（B2）R1をTS（B2）R2など）と比較することにより、R1とR2の間の遅延を測定することができます。より多くの測定を行うには、各ブロック内の他のパケットを参照して、より多くのタイムスタンプを取得して保存することができます。ブロック内の複数のパケットを考慮することにより、測定数を増やすことができます。たとえば、タイムスタンプはすべてのNパケットを使用する可能性があるため、複数の遅延測定が生成されます。これを制限に導き、原則として、対応するタイムスタンプを取得して比較することにより、各パケットの遅延を測定できます（実装の観点からは可能ですが非実用的です）。
In order to coherently compare timestamps collected on different routers, the clocks on the network nodes MUST be in sync (Section 5). Furthermore, a measurement is valid only if no packet loss occurs and if packet misordering can be avoided; otherwise, the first packet of a block on R1 could be different from the first packet of the same block on R2 (for instance, if that packet is lost between R1 and R2 or it arrives after the next one). Since packet misordering is generally undetectable, it is not possible to check whether the first packet on R1 is the same on R2, and this is part of the intrinsic error in this measurement.
さまざまなルーターで収集されたタイムスタンプを一貫して比較するには、ネットワークノードのクロックを同期している必要があります（セクション5）。さらに、測定は、パケットの損失が発生しない場合のみ、パケットの誤用を回避できる場合にのみ有効です。それ以外の場合、R1のブロックの最初のパケットは、R2の同じブロックの最初のパケットとは異なる可能性があります（たとえば、そのパケットがR1とR2の間で失われるか、次のパケットの後に到着する場合）。パケットの誤用は一般に検出できないため、R1の最初のパケットがR2で同じかどうかを確認することはできません。これはこの測定の本質的なエラーの一部です。
The method previously exposed for measuring the delay is sensitive to out-of-order reception of packets. In order to overcome this problem, an approach based on the concept of mean delay can be considered. The mean delay is calculated by considering the average arrival time of the packets within a single block. The network device locally stores a timestamp for each packet received within a single block: summing all the timestamps and dividing by the total number of packets received, the average arrival time for that block of packets can be calculated. By subtracting the average arrival times of two adjacent devices, it is possible to calculate the mean delay between those nodes. This method greatly reduces the number of timestamps that have to be collected (only one per block for each network device), and it is robust to out-of-order packets with only a small error introduced in case of packet loss. But, when computing the mean delay, the measurement error could be augmented by accumulating the measurement error of a lot of packets. Additionally, it only gives one measure for the duration of the block, and it doesn't give the minimum, maximum, and median delay values [RFC6703]. This limitation could be overcome by reducing the duration of the block (for instance, from minutes to seconds), which implies a highly optimized implementation of the method. For this reason, the mean delay calculation may not be so viable in some cases.
遅延を測定するために以前に公開された方法は、パケットのオーダー外の受信に敏感です。この問題を克服するために、平均遅延の概念に基づくアプローチを考慮することができます。平均遅延は、単一のブロック内のパケットの平均到着時間を考慮することにより計算されます。ネットワークデバイスは、1つのブロック内で受信した各パケットのタイムスタンプをローカルに保存します。すべてのタイムスタンプを合計し、受け取ったパケットの総数で除算すると、そのパケットブロックの平均到着時間を計算できます。2つの隣接するデバイスの平均到着時間を差し引くことにより、それらのノード間の平均遅延を計算することができます。この方法は、収集する必要があるタイムスタンプの数（各ネットワークデバイスのブロックごとに1つだけ）を大幅に削減し、パケットの損失の場合に導入された小さなエラーのみで、オーバーオブオーダーパケットに対して堅牢です。ただし、平均遅延を計算すると、多くのパケットの測定誤差を蓄積することにより、測定誤差を補強することができます。さらに、ブロックの持続時間について1つの測定値のみを与え、最小、最大値、および中央値遅延値を与えません[RFC6703]。この制限は、ブロックの持続時間を短縮することで克服できます（たとえば、数分から秒まで）。これは、メソッドの高度に最適化された実装を意味します。このため、平均遅延計算は、場合によってはそれほど実行可能ではない場合があります。
As mentioned above, the Single-Marking methodology for one-way delay measurement has some limitations, since it is sensitive to out-of-order reception of packets, and even the mean delay calculation is limited because it doesn't give information about the delay value's distribution for the duration of the block. Actually, it may be useful to have not only the mean delay but also the minimum, maximum, and median delay values and, in wider terms, to know more about the statistical distribution of delay values. So, in order to have more information about the delay and to overcome out-of-order issues, a different approach can be introduced, and it is based on a Double-Marking methodology.
上記のように、一方向遅延測定のためのシングルマーク方法論には、パケットの障害のある受信に敏感であり、平均遅延計算でさえも限られているため、いくつかの制限があります。ブロックの期間の遅延値の分布。実際、平均遅延だけでなく、最小、最大、および中央値の遅延値もあること、そしてより広い条件で、遅延値の統計的分布についてもっと知ることが有用かもしれません。したがって、遅延に関する詳細情報を入手し、秩序外の問題を克服するために、別のアプローチを導入することができ、二重の方法論に基づいています。
Basically, the idea is to use the first marking to create the alternate flow and, within this colored flow, a second marking to select the packets for measuring delay/jitter. The first marking is needed for packet loss and may be used for mean delay measurement. The second marking creates a new set of marked packets that are fully identified over the network so that a network device can store the timestamps of these packets. These timestamps can be compared with the timestamps of the same packets on the next node to compute packet delay values for each packet. The number of measurements can be easily increased by changing the frequency of the second marking. But the frequency of the second marking must not be too high in order to avoid out-of-order issues. Between packets with the second marking, there should be an adequate time gap to avoid out-of-order issues and also to have a number of measurement packets that are rate independent. This gap may be, at the minimum, the mean network delay calculated with the previous methodology. Therefore, it is possible to choose a proper time gap to guarantee a fixed number of double-marked packets uniformly spaced in each block. If packets with the second marking are lost, it is easy to recognize the loss since the number of double-marked packets is known for each block. Based on the spacing between these packets, it can also be possible to understand which packet of the second marking sequence has been lost and perform the measurements only for the remaining packets. But this may be complicated if more packets are lost. In this case, an implementation may simply discard the delay measurements for the corrupted block and proceed with the next block.
基本的に、アイデアは最初のマーキングを使用して代替フローを作成することです。この色のフロー内で、遅延/ジッターを測定するためのパケットを選択するための2番目のマーキングです。最初のマーキングはパケット損失に必要であり、平均遅延測定に使用される場合があります。2番目のマーキングは、ネットワークデバイスがこれらのパケットのタイムスタンプを保存できるように、ネットワーク上で完全に識別されるマークされたパケットの新しいセットを作成します。これらのタイムスタンプは、次のノードの同じパケットのタイムスタンプと比較して、各パケットのパケット遅延値を計算できます。2番目のマーキングの頻度を変更することで、測定数を簡単に増やすことができます。ただし、2番目のマーキングの頻度は、秩序外の問題を回避するために高すぎてはなりません。2番目のマーキングを備えたパケットの間には、秩序外の問題を回避するための適切な時間ギャップがあり、またレート独立した測定パケットを用意する必要があります。このギャップは、少なくとも、以前の方法論で計算された平均ネットワーク遅延である可能性があります。したがって、各ブロックで均一に間隔を置いた固定数の二重マークパケットを保証するために、適切な時間ギャップを選択することができます。2番目のマーキングのパケットが失われた場合、各ブロックで二重マークされたパケットの数が知られているため、損失を認識するのは簡単です。これらのパケット間の間隔に基づいて、2番目のマーキングシーケンスのパケットが失われたパケットを理解し、残りのパケットに対してのみ測定を実行することもできます。しかし、これは、より多くのパケットが失われると複雑になる可能性があります。この場合、実装は、破損したブロックの遅延測定値を単純に破棄し、次のブロックを進めることができます。
An efficient and robust mode is to select a single packet with the second marking for each block; in this way, there is no time gap to consider between the double-marked packets to avoid their reorder. In addition, it is also easier to identify the only double-marked packet in each block and skip the delay measurement for the block if it is lost.
効率的で堅牢なモードは、各ブロックの2番目のマークを持つ単一のパケットを選択することです。このようにして、再注文を避けるために、二重マークされたパケット間で考慮すべき時間の隙間はありません。さらに、各ブロックで唯一の二重マークパケットを識別し、失われた場合はブロックの遅延測定をスキップする方が簡単です。
The Double-Marking methodology can also be used to get more statistics of delay extent data, e.g., percentiles, variance, and median delay values. Indeed, a subset of batch packets is selected for extensive delay calculation by using the second marking, and it is possible to perform a detailed analysis on these double-marked packets. It is worth noting that there are classic algorithms for median and variance calculation, but they are out of the scope of this document. The conventional range (maximum-minimum) should be avoided for several reasons, including stability of the maximum delay due to the influence by outliers. In this regard, Section 6.5 of [RFC5481] highlights how the 99.9th percentile of delay and delay variation is more helpful to performance planners.
ダブルマーク方法論を使用して、遅延範囲のデータ、たとえばパーセンタイル、分散、および遅延値の中央値の統計をより多く取得することもできます。実際、バッチパケットのサブセットは、2番目のマーキングを使用して広範な遅延計算のために選択されており、これらの二重マークパケットで詳細な分析を実行することができます。中央値と分散計算のための古典的なアルゴリズムがあることは注目に値しますが、このドキュメントの範囲外です。従来の範囲（最大最小）は、外れ値による影響による最大遅延の安定性など、いくつかの理由で避ける必要があります。この点で、[RFC5481]のセクション6.5は、遅延および遅延の変動の99.9パーセンタイルがパフォーマンスプランナーにとってどのように役立つかを強調しています。
Similar to one-way delay measurement (both for Single Marking and Double Marking), the method can also be used to measure the inter-arrival jitter. We refer to the definition in [RFC3393]. The alternation of colors, for a Single-Marking Method, can be used as a time reference to measure delay variations. In case of Double Marking, the time reference is given by the second-marked packets. Considering the example depicted in Figure 2, R1 stores the timestamp TS(A)R1 whenever it sends the first packet of a block, and R2 stores the timestamp TS(B)R2 whenever it receives the first packet of a block. The inter-arrival jitter can be easily derived from one-way delay measurement, by evaluating the delay variation of consecutive samples.
一元配置遅延測定（単一マーキングと二重マーキングの両方）と同様に、この方法は攻撃間ジッターを測定するためにも使用できます。[RFC3393]の定義を参照します。シングルマーク方法の色の代替は、遅延変動を測定するための時間参照として使用できます。二重マーキングの場合、時間参照は2番目のマークされたパケットによって与えられます。図2に示す例を考慮すると、R1は、ブロックの最初のパケットを送信するたびにタイムスタンプTS（a）R1を保存し、R2はブロックの最初のパケットを受信するたびにタイムスタンプTS（b）R2を保存します。到着間ジッターは、連続したサンプルの遅延変動を評価することにより、一元配置遅延測定から簡単に導出できます。
The concept of mean delay can also be applied to delay variation, by evaluating the average variation of the interval between consecutive packets of the flow from R1 to R2.
平均遅延の概念は、R1からR2へのフローの連続したパケット間の間隔の平均変動を評価することにより、遅延変動に適用することもできます。
The coloring operation is fundamental in order to create packet blocks and marked packets. This implies choosing where to activate the coloring and how to color the packets.
着色操作は、パケットブロックとマーク付きパケットを作成するための基本です。これは、着色地をアクティブ化する場所とパケットの色付け方法を選択することを意味します。
In case of flow-based measurements, the flow to monitor can be defined by a set of selection rules (e.g., header fields) used to match a subset of the packets; in this way, it is possible to control the number of nodes involved, the path followed by the packets, and the size of the flows. It is possible, in general, to have multiple coloring nodes or a single coloring node that is easier to manage and doesn't raise any risk of conflict. Coloring in multiple nodes can be done, and the requirement is that the coloring must change periodically between the nodes according to the timing considerations in Section 5; so every node that is designated as a measurement point along the path should be able to identify unambiguously the colored packets. Furthermore, [RFC9342] generalizes the coloring for multipoint-to-multipoint flow. In addition, it can be advantageous to color the flow as close as possible to the source because it allows an end-to-end measure if a measurement point is enabled on the last-hop router as well.
フローベースの測定の場合、モニターするフローは、パケットのサブセットを一致させるために使用される一連の選択ルール（例：ヘッダーフィールド）によって定義できます。このようにして、関連するノードの数、パケットが続くパケット、およびフローのサイズを制御することが可能です。一般に、複数の色ノードまたは管理が容易で競合のリスクを高めない単一の着色ノードを持つことが可能です。複数のノードでの着色を行うことができ、要件は、セクション5のタイミング上の考慮事項に従ってノード間で定期的に着色する必要があることです。したがって、パスに沿った測定ポイントとして指定されているすべてのノードは、色付きのパケットを明確に識別できるはずです。さらに、[RFC9342]は、マルチポイントからマルチポイントの流れの色を一般的に一般化します。さらに、ラストホップルーターでも測定ポイントが有効になっている場合にエンドツーエンドの測定値を可能にするため、ソースにできるだけ近いフローを色付けすることが有利です。
For link-based measurements, all traffic needs to be colored when transmitted on the link. If the traffic had already been colored, then it has to be re-colored because the color must be consistent on the link. This means that each hop along the path must (re-)color the traffic; the color is not required to be consistent along different links.
リンクベースの測定では、リンクに送信されたときにすべてのトラフィックを色付けする必要があります。トラフィックが既に色付けされている場合、リンクで色が一貫している必要があるため、再色にする必要があります。これは、パスに沿った各ホップがトラフィックを（再）着色する必要があることを意味します。色は、異なるリンクに沿って一貫している必要はありません。
Traffic coloring can be implemented by setting specific flags in the packet header and changing the value of that bit periodically. How to choose the marking field depends on the application and is out of scope here.
パケットヘッダーに特定のフラグを設定し、そのビットの値を定期的に変更することにより、トラフィックの着色を実装できます。マーキングフィールドを選択する方法は、アプリケーションによって異なり、ここでは範囲外です。
For flow-based measurements, assuming that the coloring of the packets is performed only by the source nodes, the nodes between source and destination (inclusive) have to count and timestamp the colored packets that they receive and forward: this operation can be enabled on every router along the path or only on a subset, depending on which network segment is being monitored (a single link, a particular metro area, the backbone, or the whole path). Since the color switches periodically between two values, two counters (one for each value) are needed for each flow and for every interface being monitored. The number of timestamps to be stored depends on the method for delay measurement that is applied. Furthermore, [RFC9342] generalizes the counting for multipoint-to-multipoint flow.
フローベースの測定では、パケットの着色がソースノードによってのみ実行されると仮定すると、ソースと宛先の間のノード（包括的）が受信および転送される色のパケットをカウントしてタイムスタンプする必要があります。パスに沿ったすべてのルーターまたはサブセット上のみ、どのネットワークセグメントが監視されているか（単一のリンク、特定のメトロエリア、バックボーン、またはパス全体）に応じて。色は2つの値間で定期的に切り替わるため、各フローと監視されるすべてのインターフェイスに対して2つのカウンター（各値に1つ）が必要です。保存されるタイムスタンプの数は、適用される遅延測定の方法によって異なります。さらに、[RFC9342]は、マルチポイントからマルチポイントの流れのカウントを一般化します。
In case of link-based measurements, the behavior is similar except that coloring, counting, and timestamping operations are performed on a link-by-link basis at each endpoint of the link.
リンクベースの測定の場合、リンクの各エンドポイントでリンクごとに着色、カウント、およびタイムスタンプの操作が実行されることを除いて、動作は類似しています。
Another important consideration is when to read the counters or when to select the packets to be double-marked for delay measurement. It involves timing aspects to consider that are further described in Section 5.
もう1つの重要な考慮事項は、カウンターを読む時期、または遅延測定のために二重マーク化されるパケットを選択するタイミングです。セクション5でさらに説明するタイミングの側面が含まれます。
The nodes enabled to perform performance monitoring collect the value of the counters and timestamps, but they are not able to directly use this information to measure packet loss and delay, because they only have their own samples.
パフォーマンス監視を実行できるノードは、カウンターとタイムスタンプの値を収集しますが、独自のサンプルしかないため、この情報を直接使用してパケットの損失と遅延を測定することはできません。
Data collection enables the transmission of the counters and timestamps as soon as it has been read. Data correlation is the mechanism to compare counters and timestamps for packet loss, delay, and delay variation calculation.
データ収集により、カウンターとタイムスタンプが読み取られるとすぐに送信できます。データ相関は、パケットの損失、遅延、および遅延の変動計算のためにカウンターとタイムスタンプを比較するメカニズムです。
There are two main possibilities to perform both data collection and correlation depending on the Alternate-Marking application and use case:
代替マークアプリケーションとユースケースに応じて、データ収集と相関の両方を実行する2つの主な可能性があります。
* Use of a centralized solution using the Network Management System (NMS) to correlate data. This can be done in Push Mode or Polling Mode. In the first case, each router periodically sends the information to the NMS; in the latter case, it is the NMS that periodically polls routers to collect information.
* ネットワーク管理システム（NMS）を使用して集中型ソリューションを使用して、データを相関させます。これは、プッシュモードまたはポーリングモードで実行できます。最初のケースでは、各ルーターは定期的に情報をNMSに送信します。後者の場合、情報を収集するためにルーターを定期的に投票するのはNMSです。
* Definition of a protocol-based distributed solution to exchange values of counters and timestamps between the endpoints. This can be done by introducing a new protocol or by extending the existing protocols (e.g., the Two-Way Active Measurement Protocol (TWAMP) as defined in [RFC5357] or the One-Way Active Measurement Protocol (OWAMP) as defined in [RFC4656]) in order to communicate the counters and timestamps between nodes.
* エンドポイント間のカウンターとタイムスタンプの値を交換するプロトコルベースの分散ソリューションの定義。これは、新しいプロトコルを導入するか、既存のプロトコル（たとえば、[RFC5357]で定義されている双方向アクティブ測定プロトコル（TWAMP）または[RFC4656で定義されている一方向アクティブ測定プロトコル（OWAM））を拡張することで実行できます。]）ノード間でカウンターとタイムスタンプを通信するため。
In the following paragraphs, an example data correlation mechanism is explained and could be used independently of the adopted solutions.
次の段落では、データ相関メカニズムの例が説明され、採用されたソリューションとは独立して使用できます。
When data is collected on the upstream and downstream nodes, e.g., packet counts for packet-loss measurement or timestamps for packet delay measurement, and is periodically reported to or pulled by other nodes or an NMS, a certain data correlation mechanism SHOULD be in use to help the nodes or NMS tell whether any two or more packet counts are related to the same block of markers or if any two timestamps are related to the same marked packet.
上流および下流のノードでデータが収集される場合、たとえばパケット損失測定またはパケット遅延測定のタイムスタンプのパケットカウント、および他のノードまたはNMSによって定期的に報告またはプルされる場合、特定のデータ相関メカニズムを使用する必要がありますノードまたはNMSが2つ以上のパケットカウントが同じマーカーのブロックに関連しているかどうか、または2つのタイムスタンプが同じマークされたパケットに関連しているかどうかを判断するため。
The Alternate-Marking Method described in this document literally splits the packets of the measured flow into different measurement blocks. An implementation MAY use a Block Number (BN) for data correlation. The BN MUST be assigned to each measurement block and associated with each packet count and timestamp reported to or pulled by other nodes or NMSs. When the nodes or NMS see, for example, the same BNs associated with two packet counts from an upstream and a downstream node, respectively, it considers that these two packet counts correspond to the same block. The assumption of this BN mechanism is that the measurement nodes are time synchronized. This requires the measurement nodes to have a certain time synchronization capability (e.g., the NTP [RFC5905] or the IEEE 1588 PTP [IEEE-1588]).
このドキュメントで説明されている代替マーク方法は、測定されたフローのパケットを異なる測定ブロックに文字通り分割します。実装は、データ相関にブロック番号（BN）を使用する場合があります。BNは、各測定ブロックに割り当てられ、各パケットカウントに関連付けられ、他のノードまたはNMSに報告またはプルされたタイムスタンプが必要です。ノードまたはNMSが、たとえば、上流ノードと下流ノードからそれぞれ2つのパケットカウントに関連付けられた同じBNSを見ると、これらの2つのパケットカウントが同じブロックに対応することを考慮します。このBNメカニズムの仮定は、測定ノードが時間同期されていることです。これには、測定ノードが特定の時間同期機能（例：NTP [RFC5905]またはIEEE 1588 PTP [IEEE-1588]）を持つ必要があります。
Color switching is the reference for all the network devices acting as measurement points, and the only requirement to be achieved is that they have to recognize the right batch along the path in order to get the related information of counters and timestamps.
カラースイッチングは、測定ポイントとして機能するすべてのネットワークデバイスの参照であり、達成すべき唯一の要件は、カウンターとタイムスタンプの関連情報を取得するためにパスに沿って正しいバッチを認識する必要があることです。
In general, clocks in network devices are not accurate and for this reason, there is a clock error between the measurement points R1 and R2. And, to implement the methodology, they must be synchronized to the same clock reference with an adequate accuracy in order to guarantee that all network devices consistently match the marking bit to the correct block. Additionally, in practice, besides clock errors, packet reordering is also common in a packet network due to equal-cost multipath (ECMP). In particular, the delay between measurement points is the main cause of out-of-order packets because each packet can be delayed differently. If the block is sufficiently large, packet reordering occurs only at the edge of adjacent blocks, and it can be easy to assign reordered packets to the right interval blocks.
一般に、ネットワークデバイスのクロックは正確ではないため、測定ポイントR1とR2の間にクロックエラーがあります。また、方法論を実装するには、すべてのネットワークデバイスがマークビットを正しいブロックに一貫して一致させることを保証するために、適切な精度で同じクロック参照に同期する必要があります。さらに、実際には、クロックエラーに加えて、パケットの並べ替えは、等しいマルチパス（ECMP）のためにパケットネットワークでも一般的です。特に、各パケットを異なる方法で遅延させることができるため、測定ポイント間の遅延は、オーダーアウトパケットの主な原因です。ブロックが十分に大きい場合、パケットの並べ替えは隣接するブロックの端でのみ発生し、並べ替えられたパケットを適切なインターバルブロックに簡単に割り当てることができます。
In summary, we need to take into account two contributions: clock error between network devices and the interval we need to wait to avoid packets being out of order because of network delay.
要約すると、2つの貢献を考慮する必要があります。ネットワークデバイスと間隔のクロックエラーと、ネットワークの遅延のためにパケットが故障しないように待つ必要がある間隔です。
The following figure explains both issues:
次の図は両方の問題を説明しています。
...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB...
|<======================================>|
| L |
...=========>|<==================><==================>|<==========...
| L/2 L/2 |
|<===>| |<===>|
d | | d
|<==========================>|
available counting interval
Figure 4: Timing Aspects
図4：タイミングの側面
where L is the time duration of each block.
ここで、Lは各ブロックの期間です。
It is assumed that all network devices are synchronized to a common reference time with an accuracy of +/- A/2. Thus, the difference between the clock values of any two network devices is bounded by A.
すべてのネットワークデバイスは、 /-a /2の精度で一般的な参照時間に同期されると想定されています。したがって、任意の2つのネットワークデバイスのクロック値の違いは、Aに制限されています。
The network delay between the network devices can be represented as a normal distribution and 99.7% of the samples are within 3 standard deviations of the average.
ネットワークデバイス間のネットワーク遅延は正規分布として表現でき、サンプルの99.7％は平均の3つの標準偏差以内です。
The guard band d is given by:
ガードバンドDは次のように与えられます。
d = A + D_avg + 3*D_stddev,
where A is the clock accuracy, D_avg is the average value of the network delay between the network devices, and D_stddev is the standard deviation of the delay.
ここで、Aはクロックの精度です。D_AVGはネットワークデバイス間のネットワーク遅延の平均値であり、D_STDDEVは遅延の標準偏差です。
The available counting interval is L - 2d, which must be > 0.
利用可能なカウント間隔はL -2Dで、> 0でなければなりません。
The condition that MUST be satisfied and is a requirement on the synchronization accuracy is:
満たさなければならない条件と同期の精度の要件は次のとおりです。
d < L/2.
This is the fundamental rule for deciding when to read the counters and when to select the packets to be double-marked; indeed, packet counters and double-marked packets MUST respectively be taken and chosen within the available counting interval that is not affected by error factors.
これは、カウンターをいつ読み取るか、いつマークされるパケットを選択するかを決定するための基本的なルールです。実際、パケットカウンターと二重マークされたパケットは、それぞれエラー係数の影響を受けない利用可能なカウント間隔内でそれぞれ採取して選択する必要があります。
If the time duration L of each block is not so small, the synchronization requirement could be satisfied even with a relatively inaccurate synchronization method.
各ブロックの期間Lがそれほど小さくない場合、比較的不正確な同期方法でも同期要件が満たされる可能性があります。
Fragmentation can be managed with the Alternate-Marking Method using the following guidance:
フラグメンテーションは、次のガイダンスを使用して、代替マーキング方法で管理できます。
Marking nodes MUST mark all fragments if there are flag bits to use (i.e., it is in the specific encapsulation), as if they were separate packets.
マーキングノードは、使用するフラグビットがある場合（つまり、特定のカプセル化にあります）、まるで個別のパケットであるかのようにマークする必要があります。
Nodes that fragment packets within the measurement domain SHOULD, if they have the capability to do so, ensure that only one resulting fragment carries the marking bit(s) of the original packet. Failure to do so can introduce errors into the measurement.
測定ドメイン内のフラグメントパケットをフラグメントパケットにするノードは、そうする機能がある場合は、結果のフラグメントが1つだけのフラグメントのみが元のパケットのマークビットを搭載していることを確認する必要があります。そうしないと、測定にエラーが導入される可能性があります。
Measurement points SHOULD simply ignore unmarked fragments and count marked fragments as full packets. However, if resources allow, measurement points MAY make note of both marked and unmarked initial fragments and only increment the corresponding counter if (a) other fragments are also marked or (b) it observes all other fragments and they are unmarked.
測定ポイントは、マークされていないフラグメントを単に無視し、マークされたフラグメントをフルパケットとしてカウントする必要があります。ただし、リソースが許可されている場合、測定ポイントは、マークされた初期フラグメントとマークのない初期フラグメントの両方に注意を払い、（a）他のフラグメントがマークされているか、（b）他のすべてのフラグメントを観察し、マークされていない場合にのみ、対応するカウンターを増分する場合があります。
The proposed approach allows the marking node to mark all the fragments except in the case of fragmentation within the network domain; in that event, it is suggested to mark only the first fragment.
提案されたアプローチにより、マーキングノードは、ネットワークドメイン内のフラグメンテーションの場合を除くすべてのフラグメントをマークすることができます。その場合、最初のフラグメントのみをマークすることが提案されています。
The methodology described in the previous sections can be applied to various performance measurement problems. The only requirement is to select and mark the flow to be monitored; in this way, packets are batched by the sender, and each batch is alternately marked such that it can be easily recognized by the receiver. [RFC8321] reports experimental examples, and [IEEE-NETWORK-PNPM] also includes some information about the deployment experience.
前のセクションで説明した方法論は、さまざまなパフォーマンス測定の問題に適用できます。唯一の要件は、監視するフローを選択してマークすることです。このようにして、パケットは送信者によってバッチされ、各バッチはレシーバーによって簡単に認識できるように交互にマークされます。[RFC8321]は実験的な例を報告し、[IEEE-Network-PNPM]には、展開体験に関する情報も含まれています。
Either one or two flag bits might be available for marking in different deployments:
1つまたは2つのフラグビットが、さまざまな展開でマークするために利用できる場合があります。
One flag:
1つのフラグ：
packet-loss measurement MUST be done as described in Section 3.1, while delay measurement MUST be done according to the Single-Marking Method described in Section 3.2.1. Mean delay (Section 3.2.1.1) MAY also be used but it could imply more computational load.
セクション3.1で説明されているように、パケット損失の測定は行う必要がありますが、セクション3.2.1で説明されている単一マーク方法に従って遅延測定を行う必要があります。平均遅延（セクション3.2.1.1）も使用できますが、より多くの計算負荷を意味する可能性があります。
Two flags:
2つのフラグ：
packet-loss measurement MUST be done as described in Section 3.1, while delay measurement MUST be done according to the Double-Marking Method as described in Section 3.2.2. In this case, Single Marking MAY also be used in combination with Double Marking, and the two approaches provide slightly different pieces of information that can be combined to have a more robust data set.
セクション3.1で説明されているように、パケット損失測定は行う必要がありますが、セクション3.2.2で説明されているように、ダブルマーク法に従って遅延測定を行う必要があります。この場合、単一のマーキングを二重マーキングと組み合わせて使用することもでき、2つのアプローチは、より堅牢なデータセットを持つために組み合わせることができるわずかに異なる情報を提供します。
There are some operational guidelines to consider for the purpose of deciding to follow the recommendations above and to use one or two flags.
上記の推奨事項に従い、1つまたは2つのフラグを使用することを決定する目的で考慮すべき運用ガイドラインがいくつかあります。
* The Alternate-Marking Method utilizes specific flags in the packet header, so an important factor is the number of flags available for the implementation. Indeed, if there is only one flag available, then there is no other way; if two flags are available, then the option with two flags is certainly more complete.
* 代替マーキング方法は、パケットヘッダーに特定のフラグを使用するため、重要な要素は、実装に利用できるフラグの数です。確かに、利用可能なフラグが1つしかない場合、他の方法はありません。2つのフラグが利用可能な場合、2つのフラグを持つオプションが確実に完全になります。
* The duration of the Alternate-Marking period affects the frequency of the measurement, and this is a parameter that can be decided on the basis of the required temporal sampling. But it cannot be freely chosen, as explained in Section 5.
* 代替マーキング期間の期間は、測定の頻度に影響し、これは必要な時間サンプリングに基づいて決定できるパラメーターです。ただし、セクション5で説明されているように、自由に選択することはできません。
* The Alternate-Marking methodologies enable packet loss, delay, and delay variation calculation, but in accordance with the method used (e.g., Single Marking or Double Marking), there is a different kind of information that can be derived. For example, to get more statistics of extent data, the option with two flags is desirable. For this reason, the type of data needed in the specific scenario is an additional element to take into account.
* 代替マーキング方法論により、パケットの損失、遅延、および遅延の変動計算が可能になりますが、使用される方法（単一マーキングや二重マーキングなど）に従って、導き出すことができる異なる種類の情報があります。たとえば、範囲データの統計を増やすためには、2つのフラグを持つオプションが望ましいです。このため、特定のシナリオで必要なデータのタイプは、考慮すべき追加要素です。
* The Alternate-Marking Methods imply different computational load depending on the method employed. Therefore, the available computational resources on the measurement points can also influence the choice. As an example, mean delay calculation may require more processing, and it may not be the best option to minimize the computational load.
* 代替マーキング方法は、採用された方法に応じて異なる計算負荷を意味します。したがって、測定ポイントで利用可能な計算リソースも選択に影響を与える可能性があります。例として、平均遅延計算にはより多くの処理が必要になる場合があり、計算負荷を最小限に抑えるための最良の選択肢ではない場合があります。
The experiment with Alternate-Marking methodologies confirmed the benefits already described in [RFC8321].
代替マーキング方法論を使用した実験により、[RFC8321]ですでに説明されているメリットが確認されました。
A deployment of the Alternate-Marking Method should also take into account how to handle and recognize marked and unmarked traffic. Since Alternate Marking normally employs a marking field that is dedicated, reserved, and included in a protocol extension, the measurement points can learn whether the measurement is activated or not by checking if the specific extension is included or not within the packets.
代替マーキング方法の展開は、マークされたマークのないトラフィックを処理および認識する方法も考慮する必要があります。代替マーキングは通常、専用、予約され、プロトコル拡張機能に含まれるマーキングフィールドを使用するため、測定ポイントは、特定の拡張がパケット内に含まれているかどうかを確認することにより、測定がアクティブ化されるかどうかを学習できます。
It is worth mentioning some related work; in particular, [IEEE-NETWORK-PNPM] explains the Alternate-Marking Method together with new mechanisms based on hashing techniques.
関連する作業に言及する価値があります。特に、[IEEE-Network-PNPM]は、ハッシュテクニックに基づいた新しいメカニズムとともに、代替マルキング方法を説明します。
The Alternate-Marking Method is an example of a solution limited to a controlled domain [RFC8799].
代替マーキング方法は、制御されたドメインに限定されたソリューションの例です[RFC8799]。
A controlled domain is a managed network that selects, monitors, and controls access by enforcing policies at the domain boundaries in order to discard undesired external packets entering the domain and to check internal packets leaving the domain. It does not necessarily mean that a controlled domain is a single administrative domain or a single organization. A controlled domain can correspond to a single administrative domain or multiple administrative domains under a defined network management. It must be possible to control the domain boundaries and use specific precautions to ensure authentication, encryption, and integrity protection if traffic traverses the Internet.
制御されたドメインは、ドメインに入る不要な外部パケットを破棄し、ドメインを離れる内部パケットをチェックするために、ドメイン境界でポリシーを実施することにより、アクセスを選択、監視、および制御する管理されたネットワークです。制御されたドメインが単一の管理ドメインまたは単一の組織であることを必ずしも意味するものではありません。制御されたドメインは、定義されたネットワーク管理下の単一の管理ドメインまたは複数の管理ドメインに対応できます。ドメインの境界を制御し、特定の注意事項を使用して、トラフィックがインターネットを横断する場合、認証、暗号化、および整合性保護を確保することが可能でなければなりません。
For security reasons, the Alternate-Marking Method MUST only be applied to controlled domains.
セキュリティ上の理由から、代替マーク法は制御ドメインにのみ適用する必要があります。
[RFC6390] defines a framework and a process for developing Performance Metrics for protocols above and below the IP layer (such as IP-based applications that operate over reliable or datagram transport protocols).
[RFC6390]は、IPレイヤーの上下のプロトコルのパフォーマンスメトリックを開発するフレームワークとプロセスを定義します（信頼性またはデータグラムの輸送プロトコルを介して動作するIPベースのアプリケーションなど）。
This document doesn't aim to propose a new Performance Metric but rather a new Method of Measurement for a few Performance Metrics that have already been standardized. Nevertheless, it's worth applying guidelines from [RFC6390] to the present document, in order to provide a more complete and coherent description of the proposed method. The mechanisms described in this document use a combination of the Performance Metric Definition template defined in Section 5.4 of [RFC6390] and the Dependencies laid out in Section 5.5 of that document.
このドキュメントは、新しいパフォーマンスメトリックを提案することではなく、すでに標準化されているいくつかのパフォーマンスメトリックの新しい測定方法を提案することを目的としています。それにもかかわらず、提案された方法のより完全で一貫性のある説明を提供するために、[RFC6390]から現在の文書にガイドラインを適用する価値があります。このドキュメントで説明されているメカニズムは、[RFC6390]のセクション5.4で定義されているパフォーマンスメトリック定義テンプレートと、そのドキュメントのセクション5.5に記載されている依存関係の組み合わせを使用します。
* Metric Name / Metric Description: as already stated, this document doesn't propose any new Performance Metrics. On the contrary, it describes a novel method for measuring packet loss [RFC7680]. The same concept, with small differences, can also be used to measure delay [RFC7679] and jitter [RFC3393]. The document mainly describes the applicability to packet-loss measurement.
* メトリック名 /メトリック説明：すでに述べたように、このドキュメントは新しいパフォーマンスメトリックを提案していません。それどころか、パケット損失を測定するための新しい方法を説明しています[RFC7680]。小さな違いのある同じ概念を使用して、遅延[RFC7679]とジッター[RFC3393]を測定するためにも使用できます。このドキュメントは、主にパケット損失測定への適用性について説明しています。
* Method of Measurement or Calculation: according to the method described in the previous sections, the number of packets lost is calculated by subtracting the value of the counter on the source node from the value of the counter on the destination node. Both counters must refer to the same color. The calculation is performed when the value of the counters is in a steady state. The steady state is an intrinsic characteristic of the marking method counters because the alternation of color makes the counter associated with a color inactive for the duration of a marking period.
* 測定方法または計算方法：前のセクションで説明した方法によると、失われたパケットの数は、宛先ノードのカウンターの値からソースノードのカウンターの値を差し引くことによって計算されます。どちらのカウンターも同じ色を参照する必要があります。カウンターの値が定常状態にある場合、計算は実行されます。定常状態は、マーキングメソッドカウンターの本質的な特性です。これは、色の交互により、マーキング期間中は色に関連するカウンターに関連付けられているためです。
* Units of Measurement: the method calculates and reports the exact number of packets sent by the source node and not received by the destination node.
* 測定単位：メソッドは、ソースノードによって送信され、宛先ノードで受信されていない正確なパケット数を計算および報告します。
* Measurement Point(s) with Potential Measurement Domain: the measurement can be performed between adjacent nodes, on a per-link basis, or along a multi-hop path, provided that the traffic under measurement follows that path. In case of a multi-hop path, the measurements can be performed both end to end and hop by hop.
* 潜在的な測定ドメインを備えた測定点：測定は、リンクごとに、またはマルチホップパスに沿って隣接するノード間で実行できます。マルチホップパスの場合、測定は端から端まで、ホップでホップの両方で実行できます。
* Measurement Timing: the method has a constraint on the frequency of measurements. This is detailed in Section 5, where it is specified that the marking period and the guard band interval are strictly related to each other to avoid out-of-order issues. That is because, in order to perform a measurement, the counter must be in a steady state, and this happens when the traffic is being colored with the alternate color.
* 測定タイミング：この方法は、測定の頻度に制約があります。これはセクション5で詳しく説明されており、マーキング期間とガードバンド間隔は、秩序外の問題を回避するために互いに厳密に関連していることが指定されています。それは、測定を実行するためには、カウンターが定常状態にある必要があり、これは交通が代替色で色付けされているときに起こるためです。
* Implementation: the method uses one or two marking bits to color the packets; this enables the use of policy configurations on the router to color the packets and accordingly configure the counter for each color. The path followed by traffic being measured should be known in advance in order to configure the counters along the path and be able to compare the correct values.
* 実装：このメソッドは、1つまたは2つのマーキングビットを使用してパケットを着色します。これにより、ルーターでポリシー構成を使用してパケットを着色し、それに応じて各色のカウンターを構成できます。パスに沿ってカウンターを構成し、正しい値を比較できるようにするために、トラフィックが測定されるパスを事前に把握する必要があります。
* Verification: the methodology has been tested and deployed experimentally in both lab and operational network scenarios performing packet loss and delay measurements on traffic patterns created by traffic generators together with precision test instruments and network emulators.
* 検証：方法論は、ラボと運用上のネットワークシナリオの両方でテストおよび展開され、トラフィックジェネレーターによって作成されたトラフィックパターンのパケット損失と遅延測定と、精密なテスト機器とネットワークエミュレーターを実行します。
* Use and Applications: the method can be used to measure packet loss with high precision on live traffic; moreover, by combining end-to-end and per-link measurements, the method is useful to pinpoint the single link that is experiencing loss events.
* 使用とアプリケーション：この方法を使用して、ライブトラフィックの精度でパケット損失を測定できます。さらに、エンドツーエンドとリンクごとの測定を組み合わせることにより、この方法は、損失イベントを経験している単一のリンクを特定するのに役立ちます。
* Reporting Model: the value of the counters has to be sent to a centralized management system that performs the calculations; such samples must contain a reference to the time interval they refer to so that the management system can perform the correct correlation. The samples have to be sent while the corresponding counter is in a steady state (within a time interval); otherwise, the value of the sample should be stored locally.
* レポートモデル：カウンターの値は、計算を実行する集中管理システムに送信する必要があります。このようなサンプルには、管理システムが正しい相関を実行できるように、参照される時間間隔への参照を含める必要があります。サンプルは、対応するカウンターが定常状態（時間間隔内）にあるときに送信する必要があります。それ以外の場合、サンプルの値はローカルに保存する必要があります。
* Dependencies: the values of the counters have to be correlated to the time interval they refer to.
* 依存関係：カウンターの値は、参照する時間間隔と相関する必要があります。
* Organization of Results: the Method of Measurement produces singletons, according to the definition of [RFC2330].
* 結果の構成：測定方法は、[RFC2330]の定義に従ってシングルトンを生成します。
* Parameters: the main parameters of the method are the information about the flow or the link to be measured, the time interval chosen to alternate the colors and to read the counters, and the type of method selected for packet-loss and delay measurements.
* パラメーター：メソッドの主なパラメーターは、測定するフローまたはリンクに関する情報、色を交互にカウンターと読み取りに選択した時間間隔、およびパケットロスと遅延測定に選択されたメソッドのタイプです。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document specifies a method to perform measurements that does not directly affect Internet security nor applications that run on the Internet. However, implementation of this method must be mindful of security and privacy concerns.
このドキュメントは、インターネットセキュリティやインターネット上で実行されるアプリケーションに直接影響しない測定を実行する方法を指定します。ただし、この方法の実装は、セキュリティとプライバシーの懸念に留意する必要があります。
There are two types of security concerns: potential harm caused by the measurements and potential harm to the measurements.
セキュリティの懸念には、測定によって引き起こされる潜在的な害と測定への潜在的な害の2つのタイプがあります。
* Harm caused by the measurement: the measurements described in this document are Passive, so there are no new packets injected into the network causing potential harm to the network itself and to data traffic. Nevertheless, the method implies modifications on the fly to a header or encapsulation of the data packets: this must be performed in a way that doesn't alter the quality of service experienced by packets subject to measurements and that preserves stability and performance of routers doing the measurements. One of the main security threats in Operations, Administration, and Maintenance (OAM) protocols is network reconnaissance; an attacker can gather information about the network performance by passively eavesdropping on OAM messages. The advantage of the methods described in this document is that the marking bits are the only information that is exchanged between the network devices. Therefore, Passive eavesdropping on data plane traffic does not allow attackers to gain information about the network performance.
* 測定によって引き起こされる害：このドキュメントで説明されている測定値は受動的であるため、ネットワークに潜在的な害を引き起こす新しいパケットがネットワークに注入されていないため、ネットワーク自体とデータトラフィックに潜在的な害を引き起こします。それにもかかわらず、この方法は、データパケットのヘッダーまたはカプセル化へのフライでの変更を意味します。これは、測定の対象となるパケットが経験するサービスの品質を変えない方法で実行する必要があり、それを行うルーターの安定性とパフォーマンスを保持します。測定。運用、管理、およびメンテナンス（OAM）プロトコルにおける主要なセキュリティの脅威の1つは、ネットワーク偵察です。攻撃者は、OAMメッセージを受動的に盗聴することにより、ネットワークのパフォーマンスに関する情報を収集できます。このドキュメントで説明されている方法の利点は、マーキングビットがネットワークデバイス間で交換される唯一の情報であることです。したがって、データプレーントラフィックを受動的に盗聴しても、攻撃者がネットワークのパフォーマンスに関する情報を取得することはできません。
* Harm to the Measurement: the measurements could be harmed by routers altering the marking of the packets or by an attacker injecting artificial traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks. Since the measurement itself may be affected by routers (or other network devices) along the path of IP packets intentionally altering the value of marking bits of packets, as mentioned above, the mechanism specified in this document can be applied just in the context of a controlled domain; thus, the routers (or other network devices) are locally administered, and this type of attack can be avoided.
* 測定への害：パケットのマーキングを変更するルーターや、人工交通を注入する攻撃者によって測定値を害する可能性があります。デジタル署名などの認証技術は、必要に応じて、注入された交通攻撃を防ぐために使用できます。測定自体は、上記のように、パケットのビットの値を意図的に変更するIPパケットのパスに沿ったルーター（または他のネットワークデバイス）の影響を受ける可能性があるため、このドキュメントで指定されているメカニズムは、Aのコンテキストで適用できます。制御ドメイン。したがって、ルーター（または他のネットワークデバイス）はローカルに管理されており、このタイプの攻撃は回避できます。
An attacker that does not belong to the controlled domain can maliciously send marked packets. However, no problems occur if Alternate Marking is not supported in the controlled domain. If Alternate Marking is supported in the controlled domain, it is necessary to keep the measurements from being affected; therefore, externally marked packets must be checked to see if they are marked and eventually filtered or cleared.
制御されたドメインに属さない攻撃者は、マークされたパケットを悪意を持って送信できます。ただし、制御されたドメインで代替マーキングがサポートされていない場合、問題は発生しません。制御されたドメインで代替マーキングがサポートされている場合、測定値が影響を受けないようにする必要があります。したがって、外部でマークされたパケットを確認して、マークが付けられ、最終的にフィルタリングまたはクリアされているかどうかを確認する必要があります。
The precondition for the application of the Alternate-Marking Method is that it MUST be applied in specific controlled domains, thus confining the potential attack vectors within the network domain. A limited administrative domain provides the network administrator with the means to select, monitor, and control the access to the network, making it a trusted domain. In this regard, it is expected to enforce policies at the domain boundaries to filter both external marked packets entering the domain and internal marked packets leaving the domain. Therefore, the trusted domain is unlikely subject to the hijacking of packets since marked packets are processed and used only within the controlled domain. But despite that, leakages may happen for different reasons, such as a failure or a fault. In this case, nodes outside the domain are expected to ignore marked packets since they are not configured to handle it and should not process it.
代替マーキング方法の適用の前提条件は、特定の制御ドメインに適用する必要があるため、ネットワークドメイン内の潜在的な攻撃ベクトルを制限することです。限られた管理ドメインは、ネットワーク管理者にネットワークへのアクセスを選択、監視、制御する手段を提供し、信頼できるドメインにします。この点で、ドメイン境界でポリシーを実施して、ドメインを入力する外部マークされたパケットとドメインを離れる内部マークされたパケットの両方をフィルタリングすることが期待されています。したがって、マークされたパケットが処理され、制御ドメイン内でのみ使用されるため、信頼できるドメインはパケットのハイジャックに対応する可能性は低いです。しかし、それにもかかわらず、障害や障害など、さまざまな理由で漏れが発生する可能性があります。この場合、ドメインの外側のノードは、それを処理するように構成されておらず、処理すべきではないため、マークされたパケットを無視すると予想されます。
It might be theoretically possible to modulate the marking to serve as a covert channel to be used by an on-path observer. This may affect both the data and management plane, but, here too, the application to a controlled domain helps to reduce the effects.
マークを調整して、パス上のオブザーバーが使用する秘密のチャネルとして機能することが理論的に可能かもしれません。これはデータと管理プレーンの両方に影響する可能性がありますが、ここでも制御されたドメインへのアプリケーションは、効果を減らすのに役立ちます。
It is worth highlighting that an attacker can't gain information about network performance from a single monitoring point; they must use synchronized monitoring points at multiple points on the path because they have to do the same kind of measurement and aggregation that Service Providers using Alternate Marking must do.
攻撃者が単一の監視ポイントからネットワークパフォーマンスに関する情報を取得できないことを強調する価値があります。代替マーキングを使用してサービスプロバイダーが行う必要があるのと同じ種類の測定と集約を行う必要があるため、パス上の複数のポイントで同期監視ポイントを使用する必要があります。
Attacks on the data collection and reporting of the statistics between the monitoring points and the NMS can interfere with the proper functioning of the system. Hence, the channels used to report back flow statistics MUST be secured.
監視ポイントとNMSの間の統計のデータ収集とレポートへの攻撃は、システムの適切な機能を妨げる可能性があります。したがって、バックフロー統計を報告するために使用されるチャネルを確保する必要があります。
The privacy concerns of network measurement are limited because the method only relies on information contained in the header or encapsulation without any release of user data. Although information in the header or encapsulation is metadata that can be used to compromise the privacy of users, the limited marking technique in this document seems unlikely to substantially increase the existing privacy risks from header or encapsulation metadata. It might be theoretically possible to modulate the marking to serve as a covert channel, but it would have a very low data rate if it is to avoid adversely affecting the measurement systems that monitor the marking.
ネットワーク測定のプライバシーの懸念は、ユーザーデータをリリースせずにヘッダーまたはカプセル化に含まれる情報にのみ依存しているため、制限されています。ヘッダーまたはカプセル化の情報は、ユーザーのプライバシーを損なうために使用できるメタデータですが、このドキュメントの限られたマーキング手法は、ヘッダーまたはカプセル化メタデータからの既存のプライバシーリスクを大幅に増加させる可能性は低いようです。秘密のチャネルとして機能するようにマーキングを変調することは理論的には可能かもしれませんが、マーキングを監視する測定システムに悪影響を与えることを避けるためには、データレートが非常に低くなります。
Delay attacks are another potential threat in the context of this document. Delay measurement is performed using a specific packet in each block, marked by a dedicated color bit. Therefore, an on-path attacker can selectively induce synthetic delay only to delay-colored packets, causing systematic error in the delay measurements. As discussed in previous sections, the methods described in this document rely on an underlying time synchronization protocol. Thus, by attacking the time protocol, an attacker can potentially compromise the integrity of the measurement. A detailed discussion about the threats against time protocols and how to mitigate them is presented in [RFC7384].
遅延攻撃は、このドキュメントのコンテキストにおけるもう1つの潜在的な脅威です。遅延測定は、専用の色ビットでマークされた各ブロックの特定のパケットを使用して実行されます。したがって、パス上の攻撃者は、合成遅延のみを選択的に誘導して遅延色のパケットを誘導し、遅延測定に系統的なエラーを引き起こす可能性があります。前のセクションで説明したように、このドキュメントで説明した方法は、基礎となる時間同期プロトコルに依存しています。したがって、TIMEプロトコルを攻撃することにより、攻撃者は測定の完全性を潜在的に損なう可能性があります。時間プロトコルに対する脅威とそれらを緩和する方法に関する詳細な議論は、[RFC7384]に示されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[EXPLICIT-FLOW-MEASUREMENTS]
Cociglio, M., Ferrieux, A., Fioccola, G., Lubashev, I.,
Bulgarella, F., Nilo, M., Hamchaoui, I., and R. Sisto,
"Explicit Flow Measurements Techniques", Work in Progress,
Internet-Draft, draft-ietf-ippm-explicit-flow-
measurements-02, 13 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
explicit-flow-measurements-02>.
[IEEE-1588]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July
2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.
[IEEE-NETWORK-PNPM]
Mizrahi, T., Navon, G., Fioccola, G., Cociglio, M., Chen,
M., and G. Mirsky, "AM-PM: Efficient Network Telemetry
using Alternate Marking", IEEE Network Vol. 33, Issue 4,
DOI 10.1109/MNET.2019.1800152, July 2019,
<https://doi.org/10.1109/MNET.2019.1800152>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
March 2009, <https://www.rfc-editor.org/info/rfc5481>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011,
<https://www.rfc-editor.org/info/rfc6390>.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View",
RFC 6703, DOI 10.17487/RFC6703, August 2012,
<https://www.rfc-editor.org/info/rfc6703>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
DOI 10.17487/RFC9342, December 2022,
<https://www.rfc-editor.org/info/rfc9342>.
The authors would like to thank Alberto Tempia Bonda, Luca Castaldelli, and Lianshu Zheng for their contribution to the experimentation of the method.
著者は、この方法の実験への貢献について、アルベルト・テンピア・ボンダ、ルカ・カスタルデッリ、リアンシュ・チャンに感謝したいと思います。
The authors would also like to thank Martin Duke and Tommy Pauly for their assistance and their detailed and precious reviews.
著者はまた、Martin DukeとTommy Paulyの支援と詳細かつ貴重なレビューに感謝したいと思います。
Xiao Min
ZTE Corp.
Email: xiao.min2@zte.com.cn
Mach(Guoyi) Chen
Huawei Technologies
Email: mach.chen@huawei.com
Alessandro Capello
Telecom Italia
Email: alessandro.capello@telecomitalia.it
Giuseppe Fioccola (editor)
Huawei Technologies
Riesstrasse, 25
80992 Munich
Germany
Email: giuseppe.fioccola@huawei.com
Mauro Cociglio
Telecom Italia
Email: mauro.cociglio@outlook.com
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Tal Mizrahi
Huawei Technologies
Email: tal.mizrahi.phd@gmail.com
Tianran Zhou
Huawei Technologies
156 Beiqing Rd.
Beijing
100095
China
Email: zhoutianran@huawei.com