RFC 9951 - Export of Delay Performance Metrics in IP Flow Information Export (IPFIX) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9951.html
タイトル : RFC 9951 - IP フロー情報エクスポート (IPFIX) での遅延パフォーマンスメトリックのエクスポート
翻訳編集 : 自動生成

[要約] RFC 9951は、IPFIX（IPフロー情報エクスポート）を使用して、ネットワーク内の中継ノードやカプセル化解除ノードでの遅延パフォーマンスメトリックをエクスポートするための情報要素を規定しています。オンパス遅延測定の結果を効率的に収集・転送する手段を提供し、ネットワークの品質監視やトラブルシューティングにおける可視性を向上させます。

Internet Engineering Task Force (IETF)                           T. Graf
Request for Comments: 9951                                      Swisscom
Category: Standards Track                                      B. Claise
ISSN: 2070-1721                                                   Huawei
                                                           A. Huang-Feng
                                                               INSA-Lyon
                                                              April 2026

Export of Delay Performance Metrics in IP Flow Information Export (IPFIX)

IP フロー情報エクスポート (IPFIX) での遅延パフォーマンスメトリックのエクスポート

Abstract

概要

This document specifies new IP Flow Information Export (IPFIX) Information Elements to export the On-Path delay at each Operations, Administration, and Maintenance (OAM) transit and decapsulating nodes. The On-Path delay is defined as the delay between the OAM header encapsulating node and each OAM header transit and OAM header decapsulating nodes. This delay measurement is computed by an On-Path Telemetry protocol and is exported by the IPFIX process.

このドキュメントでは、各運用、管理、保守 (OAM) 中継ノードおよびカプセル化解除ノードでのオンパス遅延をエクスポートするための新しい IP フロー情報エクスポート (IPFIX) 情報要素を指定します。オンパス遅延は、OAM ヘッダーのカプセル化ノードと、各 OAM ヘッダー通過ノードおよび OAM ヘッダーのカプセル化解除ノード間の遅延として定義されます。この遅延測定値は、オンパステレメトリプロトコルによって計算され、IPFIX プロセスによってエクスポートされます。

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 7841.

このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9951.

この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9951 で入手できます。

Copyright Notice

著作権表示

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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコードコンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンステキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。

   1.  Introduction
   2.  Terminology
   3.  Solution
   4.  Performance Metrics
     4.1.  IP One-Way Delay Hybrid Type I Performance Metrics
       4.1.1.  Summary
       4.1.2.  Description
       4.1.3.  Reference
       4.1.4.  Change Controller
       4.1.5.  Version of Registry Format
     4.2.  Metric Definition
       4.2.1.  Reference Definition
       4.2.2.  Fixed Parameters
     4.3.  Method of Measurement
       4.3.1.  Reference Methods
       4.3.2.  Packet Stream Generation
       4.3.3.  Traffic Filtering (Observation) Details
       4.3.4.  Sampling Distribution
       4.3.5.  Runtime Parameters and Data Format
       4.3.6.  Roles
     4.4.  Output
       4.4.1.  Type
       4.4.2.  Reference Definition
       4.4.3.  Administrative Items
       4.4.4.  Comments and Remarks
   5.  Use Cases
   6.  IANA Considerations
     6.1.  Performance Metrics
     6.2.  IPFIX Entities
       6.2.1.  pathDelayMeanDeltaMicroseconds
       6.2.2.  pathDelayMinDeltaMicroseconds
       6.2.3.  pathDelayMaxDeltaMicroseconds
       6.2.4.  pathDelaySumDeltaMicroseconds
   7.  Operational Considerations
     7.1.  Time Accuracy
     7.2.  Mean Delay
     7.3.  Reduced-Size Encoding
     7.4.  Measurement Interval
     7.5.  In-Packet OAM Application
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Appendix A.  IPFIX Encoding Examples
     A.1.  Aggregated On-Path Delay Examples
       A.1.1.  Template Record and Data Set with Mean Delta
       A.1.2.  Template Record and Data Set with Sum Delta
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

Network operators usually maintain statistical views of delay across their networks to support diagnostics and performance analysis. These views assist in identifying the location, extent, and potential causes of abnormal delay affecting specific customer traffic or services. To achieve this, delay-related metrics need to be reported from devices covering both data and control planes. Further, in order to understand which customers are affected, delay-related metrics need to be reported in the context of the customer data plane. This correlation enables the detection of changes in forwarding paths, such as updated intermediate hops or interfaces, and of the resulting impact on delay experienced by customer traffic.

ネットワークオペレータは通常、診断とパフォーマンス分析をサポートするために、ネットワーク全体の遅延に関する統計ビューを維持します。これらのビューは、特定の顧客のトラフィックやサービスに影響を与える異常な遅延の場所、範囲、および潜在的な原因を特定するのに役立ちます。これを実現するには、データプレーンとコントロールプレーンの両方をカバーするデバイスから遅延関連のメトリクスを報告する必要があります。さらに、どの顧客が影響を受けるかを理解するために、遅延関連の指標を顧客データプレーンのコンテキストで報告する必要があります。この相関関係により、更新された中間ホップやインターフェイスなどの転送パスの変更と、その結果として顧客トラフィックが経験する遅延への影響を検出できます。

Delay measurements in the network are computed using an On-Path Telemetry protocol, which inserts metadata into the data-plane packet when entering the monitored domain [RFC9232]. To compute delay measurements, the On-Path Telemetry protocol inserts a timestamp reference when entering the OAM encapsulating node. Implementation examples are In situ Operations, Administration, and Maintenance (IOAM) [RFC9197] or Enhanced Alternate Marking [ENH-ALT-MARKING].

ネットワーク内の遅延測定は、監視対象ドメインに入るときにデータプレーンパケットにメタデータを挿入するオンパステレメトリプロトコルを使用して計算されます [RFC9232]。遅延測定値を計算するために、オンパステレメトリプロトコルは、OAM カプセル化ノードに入るときにタイムスタンプ参照を挿入します。実装例は、In situ Operations, Administration, and Maintenance (IOAM) [RFC9197] または Enhanced Alternate Marking [ENH-ALT-MARKING] です。

Two modes of On-Path Telemetry are generally recognized: passport mode, in which only the OAM header decapsulating node of the OAM domain reports metrics; and postcard mode, in which OAM header transit nodes also export On-Path Telemetry data. Both modes enable exposure of per-hop performance metrics, including delay accumulation. The approach defined in this document is primarily applicable to postcard mode.

一般に、オンパステレメトリには 2 つのモードが認識されています。1 つはパスポートモードで、OAM ドメインの OAM ヘッダーのカプセル化解除ノードのみがメトリックを報告します。ポストカードモードでは、OAM ヘッダー中継ノードもオンパステレメトリデータをエクスポートします。どちらのモードでも、遅延の累積を含むホップごとのパフォーマンスメトリクスを公開できます。このドキュメントで定義されているアプローチは、主にポストカードモードに適用できます。

To enable the export of the delay-related metrics via IPFIX [RFC7011], this document defines four new IPFIX Information Elements (IEs), exposing the On-Path delay on OAM header transit and decapsulating nodes, following the principles of postcard mode.

IPFIX [RFC7011] を介した遅延関連メトリクスのエクスポートを可能にするために、この文書は 4 つの新しい IPFIX 情報要素 (IE) を定義し、ポストカードモードの原則に従って、OAM ヘッダー通過およびカプセル化解除ノードでのオンパス遅延を公開します。

This enables the computation of delay metrics (minimum, maximum, and mean) directly on the OAM header transit and decapsulating node, allowing aggregation within the Flow Record.

これにより、OAM ヘッダー通過およびカプセル化解除ノード上で直接遅延メトリック (最小、最大、平均) を計算できるようになり、フローレコード内での集約が可能になります。

As these IEs represent performance metrics, they are also registered in the IANA "Performance Metrics Registry" [IANA-PERF-METRIC] in accordance with [RFC8911].

これらの IE はパフォーマンスメトリックを表すため、[RFC8911] に従って IANA "パフォーマンスメトリックレジストリ" [IANA-PERF-METRIC] にも登録されます。

2. Terminology

2. 用語

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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。

This document defines the following terms:

この文書では次の用語を定義します。

OAM Header Encapsulating Node:

OAM ヘッダーカプセル化ノード:

Receives the IP packets, encapsulates the packets with an OAM header, and adds the timestamp into the OAM header.

IP パケットを受信し、OAM ヘッダーでパケットをカプセル化し、OAM ヘッダーにタイムスタンプを追加します。

OAM Header Transit Node:

OAM ヘッダー中継ノード:

Receives the IP packets, then measures the delay between the timestamp in the packet and the timestamp when the packet was received.

IP パケットを受信し、パケット内のタイムスタンプとパケット受信時のタイムスタンプ間の遅延を測定します。

OAM Header Decapsulating Node:

OAM ヘッダーのカプセル化解除ノード:

Receives the IP packets, computes the delay between the timestamp in the packet and the timestamp when the packet was received, and removes the OAM header from the packet.

IP パケットを受信し、パケット内のタイムスタンプとパケット受信時のタイムスタンプ間の遅延を計算し、パケットから OAM ヘッダーを削除します。

This document makes use of the terms defined in [RFC7011], [RFC8911] and [RFC7799].

この文書では、[RFC7011]、[RFC8911]、および [RFC7799] で定義された用語を使用します。

The following terms are used as defined in [RFC7011]:

次の用語は、[RFC7011] で定義されているように使用されます。

* Collector

* コレクタ

* Exporter

* 輸出者

* Flow

* 流れ

* Flow Record

* フローレコード

* IPFIX

* IPFIX Information Elements (IEs)

* IPFIX 情報要素 (IE)

* Observation Point

* 観測点

The following terms are used as defined in [RFC8911]:

次の用語は、[RFC8911] で定義されているように使用されます。

* Performance Metric

* パフォーマンス指標

* Performance Metrics Registry

* パフォーマンスメトリックレジストリ

* Registered Performance Metric

* 登録されたパフォーマンス指標

The following term is used as defined in Section 3.8 of [RFC7799]:

次の用語は、[RFC7799] のセクション 3.8 で定義されているように使用されます。

* Hybrid Type I

* ハイブリッドタイプI

3. Solution

3. 解決

In line with the guidelines for Registered Performance Metric requesters and reviewers [RFC8911], each metric is specified with its required characteristics (e.g., Identifier, Name, URI, Status, Requester, Revision, Description) to ensure comparability of measurement results across implementations and environments. These characteristics are registered in the IANA "Performance Metrics Registry" [IANA-PERF-METRIC]. Metric naming follows the "MetricType_Method_SubTypeMethod_... Spec_Units_Output" convention defined in Section 7.1.2 of [RFC8911].

登録パフォーマンスメトリクスのリクエスタおよびレビューアのためのガイドライン [RFC8911] に沿って、各メトリクスは、実装および環境間での測定結果の比較可能性を確保するために、必要な特性 (例: 識別子、名前、URI、ステータス、リクエスタ、リビジョン、説明) とともに指定されます。これらの特性は、IANA「パフォーマンスメトリクスレジストリ」[IANA-PERF-METRIC] に登録されています。メトリクスの命名は、[RFC8911] のセクション 7.1.2 で定義されている "MetricType_Method_SubTypeMethod_... Spec_Units_Output" 規則に従います。

This document defines the following performance metrics and IPFIX Information Elements:

このドキュメントでは、次のパフォーマンスメトリックと IPFIX 情報要素を定義します。

     +=============================+================================+
     | Performance Metric          | IPFIX Information Element      |
     +=============================+================================+
     | OWDelay_HybridType1_I       | pathDelayMeanDeltaMicroseconds |
     | P_RFC9951_Seconds_Mean (27) | (530)                          |
     +-----------------------------+--------------------------------+
     | OWDelay_HybridType1_I       | pathDelayMinDeltaMicroseconds  |
     | P_RFC9951_Seconds_Min (28)  | (531)                          |
     +-----------------------------+--------------------------------+
     | OWDelay_HybridType1_I       | pathDelayMaxDeltaMicroseconds  |
     | P_RFC9951_Seconds_Max (29)  | (532)                          |
     +-----------------------------+--------------------------------+
     | OWDelay_HybridType1_I       | pathDelaySumDeltaMicroseconds  |
     | P_RFC9951_Seconds_Sum (30)  | (533)                          |
     +-----------------------------+--------------------------------+

Table 1: Mapping Between IPFIX IEs and Performance Metrics

表 1: IPFIX IE とパフォーマンスメトリック間のマッピング

Assuming time synchronization on devices, the delay is measured by calculating the difference between the timestamp imposed with On-Path Telemetry in the packet at an OAM header encapsulating node and the timestamp exported in the IPFIX Flow Record from the OAM header transit and OAM header decapsulating nodes. The lowest, highest, mean, and the sum of measured path delay can be exported, thanks to the different IPFIX IE specifications.

デバイスでの時刻同期を想定すると、遅延は、OAM ヘッダーのカプセル化ノードでパケット内のオンパステレメトリによって適用されたタイムスタンプと、OAM ヘッダーの転送ノードおよび OAM ヘッダーのカプセル化解除ノードから IPFIX フローレコードでエクスポートされたタイムスタンプとの差を計算することによって測定されます。さまざまな IPFIX IE 仕様により、測定されたパス遅延の最小値、最大値、平均値、および合計をエクスポートできます。

                          On-Path Telemetry Domain
                 .........................................
                 .                                       .
                 .    D1                                 .
                 . x------->                              .
                 .                                       .
                 .          D2                           .
                 . x-------------------->                .
                 .                                       .
                 .                  D3                   .
                 . x---------------------------------->  .
                 .                                       .
   (H1) -----> (R0) ------> (R1) ------> (R2) -------> (R3) -----> (H2)
   Host 1  Encapsulating   Transit      Transit   Decapsulating  Host 2
               Node         Node 1       Node 2        Node
                 .                                       .
                 .                                       .
                 .........................................

Figure 1: Delay Use Case: Packets Flow from Host 1 to Host 2

図 1: 遅延の使用例: ホスト 1 からホスト 2 へのパケットフロー

In the use case shown in Figure 1, using On-Path Telemetry to export the delay metrics, the node R1 exports the delay D1, the node R2 exports the delay D2, and the OAM header decapsulating node R3 exports the total delay D3 for the same flow using IPFIX.

図 1 に示すユースケースでは、オンパステレメトリを使用して遅延メトリックをエクスポートし、ノード R1 は遅延 D1 をエクスポートし、ノード R2 は遅延 D2 をエクスポートし、OAM ヘッダーのカプセル化解除ノード R3 は IPFIX を使用して同じフローの合計遅延 D3 をエクスポートします。

This solution enables the computation of delay metrics (minimum, maximum, and mean) directly on the OAM header transit and decapsulating node, allowing aggregation within the Flow Record. This reduces both export bandwidth and processing requirements on the Collector. To compute these metrics locally, the Exporter's Metering Process must perform per-packet caching and processing, particularly when computing mean delay under Flow Aggregation [RFC7015]. A less computationally intensive alternative is to export the sum of delays, allowing the Collector to compute the mean via a simple division using the packet count.

このソリューションにより、OAM ヘッダーの中継およびカプセル化解除ノード上で直接遅延メトリック (最小、最大、平均) を計算できるようになり、フローレコード内での集約が可能になります。これにより、エクスポート帯域幅とコレクタでの処理要件の両方が軽減されます。これらのメトリクスをローカルで計算するには、特にフロー集約 [RFC7015] に基づいて平均遅延を計算する場合、エクスポーターのメータリングプロセスはパケットごとのキャッシュと処理を実行する必要があります。計算量の少ない代替方法は、遅延の合計をエクスポートし、コレクタがパケット数を使用した単純な除算によって平均を計算できるようにすることです。

In contrast, if no delay processing occurs on the OAM header transit or decapsulating node, each packet must be exported as an individual Flow Record, including timestamp information, as specified in [IPFIX-ALT-MARK]. The Collector must then compute the delay metrics and reconstruct the aggregated Flow Record accordingly.

対照的に、OAM ヘッダー通過ノードまたはカプセル化解除ノードで遅延処理が発生しない場合、[IPFIX-ALT-MARK] で指定されているように、タイムスタンプ情報を含む各パケットを個別のフローレコードとしてエクスポートする必要があります。次に、コレクターは遅延メトリックを計算し、それに応じて集約されたフローレコードを再構築する必要があります。

4. Performance Metrics

4. パフォーマンス指標

This section defines four new performance metrics following the template defined in Section 11 of [RFC8911].

このセクションでは、[RFC8911] のセクション 11 で定義されたテンプレートに従って、4 つの新しいパフォーマンスメトリックを定義します。

4.1. IP One-Way Delay Hybrid Type I Performance Metrics

4.1. IP 一方向遅延ハイブリッドタイプ I のパフォーマンスメトリック

This section specifies four performance metrics for the Hybrid Type I assessment of IP One-Way Delay; they have been registered in the IANA "Performance Metrics Registry" [IANA-PERF-METRIC].

このセクションでは、IP 一方向遅延のハイブリッドタイプ I 評価の 4 つのパフォーマンスメトリックを指定します。それらは IANA「パフォーマンスメトリクスレジストリ」[IANA-PERF-METRIC] に登録されています。

All column entries besides the Identifier, Name, URI, Description, Reference Description (Output only) categories are the same; thus, this section defines four closely related performance metrics. As a result, IANA has assigned corresponding URIs to each of the four registered performance metrics.

識別子、名前、URI、説明、参照説明 (出力のみ) カテゴリ以外のすべての列エントリは同じです。したがって、このセクションでは、密接に関連する 4 つのパフォーマンス指標を定義します。その結果、IANA は、登録された 4 つのパフォーマンスメトリクスのそれぞれに対応する URI を割り当てました。

4.1.1. Summary

4.1.1. まとめ

This category includes multiple indexes of the registered performance metrics: the Identifier and Metric Name.

このカテゴリには、登録されたパフォーマンスメトリックの複数のインデックス (識別子とメトリック名) が含まれます。

4.1.1.1. ID (Identifier)

4.1.1.1. ID（識別子）

IANA has allocated the numeric Identifiers 27, 28, 29, and 30 for the four Named Metric Entries in the following section.

IANA は、次のセクションの 4 つの名前付きメトリクスエントリに数値識別子 27、28、29、および 30 を割り当てました。

4.1.1.2. Name

4.1.1.2. 名前

27:

OWDelay_HybridType1_IP_RFC9951_Seconds_Mean

28:

OWDelay_HybridType1_IP_RFC9951_Seconds_Min

29:

OWDelay_HybridType1_IP_RFC9951_Seconds_Max

30:

OWDelay_HybridType1_IP_RFC9951_Seconds_Sum

4.1.1.3. URI

URI:

<https://www.iana.org/assignments/performance-metrics/ OWDelay_HybridType1_IP_RFC9951_Seconds_Mean>

<https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC9951_Seconds_Mean>

URI:

<https://www.iana.org/assignments/performance-metrics/ OWDelay_HybridType1_IP_RFC9951_Seconds_Min>

<https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC9951_Seconds_Min>

URI:

<https://www.iana.org/assignments/performance-metrics/ OWDelay_HybridType1_IP_RFC9951_Seconds_Max>

<https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC9951_Seconds_Max>

URI:

<https://www.iana.org/assignments/performance-metrics/ OWDelay_HybridType1_IP_RFC9951_Seconds_Sum>

<https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_IP_RFC9951_Seconds_Sum>

4.1.2. Description

4.1.2. 説明

OWDelay_HybridType1_IP_RFC9951_Seconds_Mean:

This metric assesses the mean of one-way delays of all successfully forwarded IP packets constituting a single Flow. The measurement of one-way delay is based on a single Observation Point [RFC7011] somewhere in the network.

このメトリクスは、単一のフローを構成する、正常に転送されたすべての IP パケットの一方向遅延の平均を評価します。一方向遅延の測定は、ネットワーク内のどこかにある単一の観測ポイント [RFC7011] に基づいています。

OWDelay_HybridType1_IP_RFC9951_Seconds_Min:

This metric assesses the minimum of one-way delays of all successfully forwarded IP packets constituting a single Flow. The measurement of one-way delay is based on a single Observation Point [RFC7011] somewhere in the network.

このメトリクスは、単一のフローを構成する、正常に転送されたすべての IP パケットの一方向遅延の最小値を評価します。一方向遅延の測定は、ネットワーク内のどこかにある単一の観測ポイント [RFC7011] に基づいています。

OWDelay_HybridType1_IP_RFC9951_Seconds_Max:

This metric assesses the maximum of one-way delays of all successfully forwarded IP packets constituting a single Flow. The measurement of one-way delay is based on a single Observation Point [RFC7011] somewhere in the network.

このメトリクスは、単一のフローを構成する、正常に転送されたすべての IP パケットの一方向遅延の最大値を評価します。一方向遅延の測定は、ネットワーク内のどこかにある単一の観測ポイント [RFC7011] に基づいています。

OWDelay_HybridType1_IP_RFC9951_Seconds_Sum:

This metric assesses the sum of one-way delays of all successfully forwarded IP packets constituting a single Flow. The measurement of one-way delay is based on a single Observation Point [RFC7011] somewhere in the network.

このメトリクスは、単一のフローを構成する、正常に転送されたすべての IP パケットの一方向遅延の合計を評価します。一方向遅延の測定は、ネットワーク内のどこかにある単一の観測ポイント [RFC7011] に基づいています。

4.1.3. Reference

4.1.3. 参照

RFC 9951

4.1.4. Change Controller

4.1.4. コントローラーの変更

IETF

4.1.5. Version of Registry Format

4.1.5. レジストリ形式のバージョン

1.0

4.2. Metric Definition

4.2. メトリクスの定義

This category includes columns to prompt the entry of all necessary details related to the metric definition, including the immutable document reference and values of input factors, called "Fixed Parameters".

このカテゴリには、「固定パラメータ」と呼ばれる、不変のドキュメント参照や入力要素の値など、メトリック定義に関連するすべての必要な詳細の入力を求める列が含まれています。

4.2.1. Reference Definition

4.2.1. 参照定義

See [RFC6049] and [RFC7679] in the Normative References (Section 9.1).

規範的参照 (セクション 9.1) の [RFC6049] および [RFC7679] を参照してください。

Section 3.4 of [RFC7679] provides the reference definition of the singleton (single value) one-way delay metric. Section 4.4 of [RFC7679] provides the reference definition expanded to cover a multi-value sample. Note that terms such as "singleton" and "sample" are defined in Section 11 of [RFC2330].

[RFC7679] のセクション 3.4 は、シングルトン (単一値) 一方向遅延メトリックの参照定義を提供します。[RFC7679] のセクション 4.4 は、複数値サンプルをカバーするために拡張された参照定義を提供します。「シングルトン」や「サンプル」などの用語は [RFC2330] のセクション 11 で定義されていることに注意してください。

With the Observation Point [RFC7011] typically located between the hosts participating in the IP Flow, the one-way delay metric requires one individual measurement between the Observation Point and sourcing host, such that the Spatial Composition [RFC6049] of the measurements yields a one-way delay singleton.

観測ポイント [RFC7011] は通常、IP フローに参加しているホスト間に位置し、一方向遅延メトリックには観測ポイントとソースホストの間の 1 つの個別の測定が必要です。そのため、測定の空間構成 [RFC6049] によって一方向遅延シングルトンが得られます。

This document specifies how to export the performance metric using IPFIX.

このドキュメントでは、IPFIX を使用してパフォーマンスメトリックをエクスポートする方法を指定します。

4.2.2. Fixed Parameters

4.2.2. 固定パラメータ

None

なし

4.3. Method of Measurement

4.3. 測定方法

This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations.

このカテゴリには、RFC の関連セクションへの参照と、実装方法を明確にするために必要な補足情報の列が含まれています。

4.3.1. Reference Methods

4.3.1. 参照方法

The foundational methodology for this metric is defined in Section 4 of [RFC7323] using the Timestamps option with modifications that allow application at a mid-path Observation Point [RFC7011].

このメトリクスの基本的な方法論は、[RFC7323] のセクション 4 で定義されており、タイムスタンプオプションを使用して、パスの途中の観測ポイント [RFC7011] での適用を可能にする修正が加えられています。

4.3.2. Packet Stream Generation

4.3.2. パケットストリームの生成

This is the time when the packet is being received at the OAM header encapsulating node. The timestamp format depends on the On-Path Telemetry implementation. For IOAM, Section 4.4.1 of [RFC9197] describes the supported timestamps. Sections 4.4.2.3 and 4.4.2.4 of [RFC9197] describe where the timestamp is being inserted. For the Enhanced Alternate Marking Method, Section 2 of [ENH-ALT-MARKING] and Section 3.2 of [RFC9947] define the supported timestamp encodings and granularity.

これは、パケットが OAM ヘッダーカプセル化ノードで受信されている時間です。タイムスタンプの形式は、オンパステレメトリの実装によって異なります。IOAM については、[RFC9197] のセクション 4.4.1 にサポートされるタイムスタンプが記載されています。[RFC9197] のセクション 4.4.2.3 および 4.4.2.4 では、タイムスタンプが挿入される場所について説明しています。拡張代替マーキング方法については、[ENH-ALT-MARKING] のセクション 2 および [RFC9947] のセクション 3.2 で、サポートされるタイムスタンプエンコーディングと粒度が定義されています。

4.3.3. Traffic Filtering (Observation) Details

4.3.3. トラフィックフィルタリング（観測）の詳細

Runtime Parameters (in the following sections) may be used for Traffic Filtering.

実行時パラメータ (以下のセクション) は、トラフィックフィルタリングに使用できます。

4.3.4. Sampling Distribution

4.3.4. サンプリング分布

This metric requires a partial sample of all packets that qualify according to the Traffic Filter criteria.

このメトリクスには、トラフィックフィルター基準に従って条件を満たすすべてのパケットの部分サンプルが必要です。

4.3.5. Runtime Parameters and Data Format

4.3.5. 実行時パラメータとデータ形式

Runtime Parameters are input factors that must be determined, configured into a measurement system, and reported with the results for the context to be complete.

実行時パラメータは、コンテキストを完成させるために決定され、測定システムに設定され、結果とともに報告される必要がある入力要素です。

The Hybrid Type I metering parameters must be reported to provide the complete measurement context. As an example, if the IPFIX Metering Process is used, then the IPFIX Metering Process parameters (IPFIX Template Record, potential traffic filters, and potential sampling method and parameters) that generate the Flow Records must be reported to provide the complete measurement context. At a minimum, the following fields are required:

完全な測定コンテキストを提供するには、ハイブリッドタイプ I 測定パラメータを報告する必要があります。例として、IPFIX メータリングプロセスが使用されている場合、完全な測定コンテキストを提供するには、フローレコードを生成する IPFIX メータリングプロセスパラメータ (IPFIX テンプレートレコード、潜在的なトラフィックフィルタ、および潜在的なサンプリング方法とパラメータ) を報告する必要があります。少なくとも次のフィールドが必要です。

Src:

The IP address of the host in the host A Role (format ipv4- address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC9911]).

ホスト A の役割におけるホストの IP アドレス (IPv4 の場合は ipv4-address-no-zone 値、IPv6 の場合は ipv6-address-no-zone 値の形式。[RFC9911] のセクション 4 を参照)。

Dst:

The IP address of the host in the host B Role (format ipv4- address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC9911]).

ホスト B の役割のホストの IP アドレス (IPv4 の場合は ipv4-address-no-zone 値、IPv6 の場合は ipv6-address-no-zone 値の形式。[RFC9911] のセクション 4 を参照)。

T0:

T time, the start of a measurement interval (format "date/time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC9911]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified, and Tf is to be interpreted as the duration of the measurement interval. The start time is controlled through other means.

T 時間、測定間隔の開始時刻 ([RFC3339] のセクション 5.6 で指定されている形式「日付/時刻」。[RFC9911] のセクション 3 の「日付と時刻」も参照)。UTC タイムゾーンは [RFC2330] のセクション 6.1 で要求されています。T0 が「オールゼロ」の場合、開始時間は指定されておらず、Tf は測定間隔の継続時間として解釈されます。開始時間は他の手段で制御されます。

Tf:

A time, the end of a measurement interval (format "date/time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC9911]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", an ending time and date are ignored, and Tf is interpreted as the duration of the measurement interval.

時間、測定間隔の終了（[RFC3339] のセクション 5.6 で指定されている形式「日付/時刻」。[RFC9911] のセクション 3 の「日付と時刻」も参照）。UTC タイムゾーンは [RFC2330] のセクション 6.1 で要求されています。T0 が「すべてゼロ」の場合、終了日時は無視され、Tf は測定間隔の長さとして解釈されます。

4.3.6. Roles

4.3.6. 役割

Host A:

ホスト A:

Launches an IP packet to start the Flow.

IP パケットを起動してフローを開始します。

Host B:

ホスト B:

Receives the IP packet to start the Flow.

IPパケットを受信してフローを開始します。

OAM Header Encapsulating Node:

OAM ヘッダーカプセル化ノード:

Receives the IP packets, encapsulates the packets with the OAM header, and adds the timestamp into the OAM header.

IP パケットを受信し、OAM ヘッダーでパケットをカプセル化し、OAM ヘッダーにタイムスタンプを追加します。

OAM Header Transit Node:

OAM ヘッダー中継ノード:

Receives the IP packets, measures the delay between the timestamp in the packet and the timestamp when the packet was received.

IP パケットを受信し、パケット内のタイムスタンプとパケット受信時のタイムスタンプ間の遅延を測定します。

OAM Header Decapsulating Node:

OAM ヘッダーのカプセル化解除ノード:

Receives the IP packets, computes the delay between the timestamp in the packet and the timestamp when the packet was received, and removes the OAM header from the packet.

4.4. Output

4.4. 出力

This category specifies all details of the output of measurements using the metric.

このカテゴリは、メトリックを使用した測定出力のすべての詳細を指定します。

4.4.1. Type

4.4.1. タイプ

OWDelay Types are discussed in the subsections below.

OWDelay タイプについては、以下のサブセクションで説明します。

4.4.2. Reference Definition

4.4.2. 参照定義

For all output types:

すべての出力タイプの場合:

OWDelay_HybridType1_IP:

The one-way delay of one IP packet is a singleton.

1 つの IP パケットの一方向遅延はシングルトンです。

For each <statistic> singleton, one of the following subsections applies.

各 <statistic> シングルトンに対して、次のサブセクションのいずれかが適用されます。

4.4.2.1. OWDelay_HybridType1_IP_RFC9951_Seconds_Mean

Similar to Section 7.4.2.2 of [RFC8912], the mean SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

[RFC8912] のセクション 7.4.2.2 と同様に、平均は、一方向遅延の有限値 (未定義の遅延は除外される)、つまり次のような単一の値を持つすべてのパケットの条件付き分布を使用して計算されるものとします:

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analytic choice.

未定義の遅延値を除外するための条件付き分布の詳細については、[RFC3393] のセクション 4.1 を参照してください。また、この分析上の選択の背景については、[RFC6703] のセクション 5 を参照してください。

See Section 4.2.2 of [RFC6049] for details on calculating this statistic; see also Section 4.2.3 of [RFC6049].

この統計の計算の詳細については、[RFC6049] のセクション 4.2.2 を参照してください。[RFC6049] のセクション 4.2.3 も参照してください。

Mean:

平均：

The time value of the result is expressed in units of microseconds, as a positive value of type decimal64 with fraction digits = 9 (similar to decimal64 in YANG, Section 9.3 of [RFC6020]) with a resolution of 0.001 microseconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905].

結果の時間値は、マイクロ秒単位で、小数桁 = 9 の 10 進数 64 型の正の値として表現されます (YANG の 10 進数 64、[RFC6020] のセクション 9.3 と同様)。分解能は 0.001 マイクロ秒 (1.0 ns) で、[RFC5905] のセクション 6 に従って、64 ビット NTP タイムスタンプとの間のロスレス変換が行われます。

4.4.2.2. OWDelay_HybridType1_IP_RFC9951_Seconds_Min

Similar to Section 7.4.2.3 of [RFC8912], the minimum SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

[RFC8912] のセクション 7.4.2.3 と同様に、最小値は、一方向遅延の有限値 (未定義の遅延は除外される)、つまり次のような単一の値を持つすべてのパケットの条件付き分布を使用して計算されるものとします:

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analytic choice.

See Section 4.3.2 of [RFC6049] for details on calculating this statistic; see also Section 4.3.3 of [RFC6049].

この統計の計算の詳細については、[RFC6049] のセクション 4.3.2 を参照してください。[RFC6049] のセクション 4.3.3 も参照してください。

Min:

4.4.2.3. OWDelay_HybridType1_IP_RFC9951_Seconds_Max

Similar to Section 7.4.2.4 of [RFC8912], the maximum SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

[RFC8912] のセクション 7.4.2.4 と同様に、最大値は、一方向遅延の有限値 (未定義の遅延は除外される)、つまり次のような単一の値を持つすべてのパケットの条件付き分布を使用して計算されるものとします:

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analytic choice.

See Section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic; see also Section 4.3.3 of [RFC6049]. The formula is as follows:

この統計を計算するための密接に関連した方法については、[RFC6049] のセクション 4.3.2 を参照してください。[RFC6049] のセクション 4.3.3 も参照してください。式は次のとおりです。

    Max = (FiniteDelay[j])
    such that for some index, j, where 1 <= j <= N
    FiniteDelay[j] >= FiniteDelay[n] for all n

where all packets n = 1 through N have finite singleton delays.

ここで、n = 1 ～ N のすべてのパケットには有限のシングルトン遅延があります。

Max:

4.4.2.4. OWDelay_HybridType1_IP_RFC9951_Seconds_Sum

The sum SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

合計は、一方向遅延の有限値 (未定義の遅延は除外される)、つまり次のような単一の値を持つすべてのパケットの条件付き分布を使用して計算されるものとします。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analytic choice.

See Section 4.3.5 of [RFC6049] for details on calculating this statistic; however, in this case, FiniteDelay or MaxDelay MAY be used.

この統計の計算の詳細については、[RFC6049] のセクション 4.3.5 を参照してください。ただし、この場合は、FiniteDelay または MaxDelay を使用してもよい(MAY)。

Sum:

4.4.2.5. Metric Units

4.4.2.5. メートル単位

* Mean

* 平均

* Min

* 分

* Max

* マックス

* Sum

* 和

The one-way delay of the IP Flow singleton is expressed in microseconds.

IP フローシングルトンの一方向遅延はマイクロ秒単位で表されます。

4.4.2.6. Calibration

4.4.2.6. 較正

A clock synchronization between the nodes of the monitored OAM domain is needed to compute representative delay measurements at the OAM header transit and decapsulating nodes. NTP, as defined in [RFC5905], can be used for synchronizing the clocks of the monitored nodes.

OAM ヘッダー通過ノードおよびカプセル化解除ノードでの代表的な遅延測定値を計算するには、監視対象の OAM ドメインのノード間のクロック同期が必要です。[RFC5905] で定義されている NTP は、監視対象ノードのクロックを同期するために使用できます。

4.4.3. Administrative Items

4.4.3. 管理事項

4.4.3.1. Status

4.4.3.1. 状態

Current

現在

4.4.3.2. Requester

4.4.3.2. 依頼者

RFC 9951

4.4.3.3. Revision

4.4.3.3. リビジョン

1.0

4.4.3.4. Revision Date

4.4.3.4. 改訂日

2026-04-02

4.4.4. Comments and Remarks

4.4.4. コメントと備考

None

なし

5. Use Cases

5. 使用例

The measured On-Path delay can be aggregated with Flow Aggregation as defined in [RFC7015] across the following device and control-plane dimensions [IANA-IPFIX] to determine:

測定されたオンパス遅延は、[RFC7015] で定義されているように、次のデバイスおよびコントロールプレーンのディメンション [IANA-IPFIX] にわたってフロー集約を使用して集計され、以下を決定できます。

* With node id and egressInterface(14), on which node which logical egress interfaces have been contributing to how much delay.

* ノード ID と egressInterface(14) を使用して、どのノードでどの論理出力インターフェイスがどれだけの遅延に寄与しているかを示します。

* With node id and egressPhysicalInterface(253), on which node which physical egress interfaces have been contributing to how much delay.

* ノード ID と egressPhysicalInterface(253) を使用して、どのノードのどの物理出力インターフェイスがどの程度の遅延に寄与しているかを示します。

* With ipNextHopIPv4Address(15) or ipNextHopIPv6Address(62), the forwarding path to which next-hop IP contributed to how much delay.

* ipNextHopIPv4Address(15) または ipNextHopIPv6Address(62) では、ネクストホップ IP がどの程度の遅延に寄与したかを示す転送パス。

* With mplsTopLabelIPv4Address(47) or destinationIPv6Address and srhActiveSegmentIPv6(495), the forwarding path to which MPLS top-label IPv4 address or IPv6 destination address and Segment Routing over IPv6 (SRv6) active segment contributed to how much delay.

* mplsTopLabelIPv4Address(47) または destinationIPv6Address および srhActiveSegmentIPv6(495) の場合、MPLS トップラベル IPv4 アドレスまたは IPv6 宛先アドレスと Segment Routing over IPv6 (SRv6) アクティブセグメントがどのくらいの遅延に寄与したかを示す転送パス。

* BGP communities [RFC1997] are often used for setting a path priority or service selection. With bgpDestinationExtendedCommunityList(488) or bgpDestinationCommunityList(485) or bgpDestinationLargeCommunityList(491), which group of prefixes accumulated at which node how much delay.

* BGP コミュニティ [RFC1997] は、パスの優先順位やサービスの選択を設定するためによく使用されます。bgpDestinationExtendedCommunityList(488) または bgpDestinationCommunityList(485) または bgpDestinationLargeCommunityList(491) を使用すると、どのプレフィックスのグループがどのノードでどれだけの遅延が蓄積されたか。

* With destinationIPv4Address(13), destinationTransportPort(11), protocolIdentifier(4), and sourceIPv4Address(8), or equivalent IPFIX IEs for IPv6, the forwarding path delay on each node from each IPv4 source address to a specific application in the network.

* destinationIPv4Address(13)、destinationTransportPort(11)、protocolIdentifier(4)、sourceIPv4Address(8)、または IPv6 の同等の IPFIX IE を使用すると、各 IPv4 送信元アドレスからネットワーク内の特定のアプリケーションまでの各ノード上の転送パス遅延が発生します。

Let us consider Figure 1 as a topology example. Table 2 shows the aggregated delay per each node, ingressInterface(10), egressInterface(14), destinationIPv6Address(28), and srhActiveSegmentIPv6(495) measured at ingress.

図 1 をトポロジーの例として考えてみましょう。表 2 は、入力時に測定された各ノード、ingressInterface(10)、egressInterface(14)、destinationIPv6Address(28)、および srhActiveSegmentIPv6(495) ごとの遅延の合計を示しています。

   +===========+===========+======+=============+=============+=======+
   | ingress   | egress    | Node | destination | srhActive   | Path  |
   | Interface | Interface |      | IPv6Address | SegmentIPv6 | Delay |
   +===========+===========+======+=============+=============+=======+
   | 271       | 276       | R0   |             |             | 0 µs  |
   +-----------+-----------+------+-------------+-------------+-------+
   | 301       | 312       | R1   | 2001:db8::1 | 2001:db8::3 | 22 µs |
   +-----------+-----------+------+-------------+-------------+-------+
   | 22        | 27        | R2   | 2001:db8::2 | 2001:db8::3 | 42 µs |
   +-----------+-----------+------+-------------+-------------+-------+
   | 852       | 854       | R3   | 2001:db8::3 | 2001:db8::3 | 122   |
   |           |           |      |             |             | µs    |
   +-----------+-----------+------+-------------+-------------+-------+

Table 2: Example Table of Measured Delay at Ingress, Ascending by Delay

表 2: 入力時に測定された遅延の表の例 (遅延ごとに増加)

6. IANA Considerations

6. IANAの考慮事項

6.1. Performance Metrics

6.1. パフォーマンス指標

IANA has add four new performance metrics in the "Performance Metrics Registry" [RFC8911] with the four templates defined in Section 3.

IANA は、セクション 3 で定義された 4 つのテンプレートを使用して、「パフォーマンスメトリックレジストリ」[RFC8911] に 4 つの新しいパフォーマンスメトリックを追加しました。

6.2. IPFIX Entities

6.2. IPFIXエンティティ

IANA has registered new IPFIX IEs (see Table 3) in the "IPFIX Information Elements" registry in the "IP Flow Information Export (IPFIX) Entities" registry group [IANA-IPFIX] and assigned the following code points.

IANA は、「IP フロー情報エクスポート (IPFIX) エンティティ」レジストリグループ [IANA-IPFIX] の「IPFIX 情報要素」レジストリに新しい IPFIX IE (表 3 を参照) を登録し、次のコードポイントを割り当てました。

              +===========+================================+
              | ElementID | Name                           |
              +===========+================================+
              | 530       | pathDelayMeanDeltaMicroseconds |
              +-----------+--------------------------------+
              | 531       | pathDelayMinDeltaMicroseconds  |
              +-----------+--------------------------------+
              | 532       | pathDelayMaxDeltaMicroseconds  |
              +-----------+--------------------------------+
              | 533       | pathDelaySumDeltaMicroseconds  |
              +-----------+--------------------------------+

Table 3: New IPFIX IEs in the "IPFIX Information Elements" Registry

表 3: 「IPFIX Information Elements」レジストリ内の新しい IPFIX IE

6.2.1. pathDelayMeanDeltaMicroseconds

6.2.1. pathDelayMeanDeltaマイクロ秒

Name:

名前：

pathDelayMeanDeltaMicroseconds

pathDelayMeanDeltaマイクロ秒

ElementID:

要素ID:

530

Description:

説明：

This Information Element identifies the mean path delay of all packets in the Flow, in microseconds, between an OAM header encapsulating node and the local node with the OAM domain (either an OAM header transit node or an OAM header decapsulating node), according to OWDelay_HybridType1_IP_RFC9951_Seconds_Mean in the IANA "Performance Metrics Registry".

この情報要素は、IANA「パフォーマンスメトリックレジストリ」の OWDelay_HybridType1_IP_RFC9951_Seconds_Mean に従って、OAM ヘッダーのカプセル化ノードと OAM ドメインを持つローカルノード (OAM ヘッダーの中継ノードまたは OAM ヘッダーのカプセル化解除ノードのいずれか) の間のフロー内のすべてのパケットの平均パス遅延をマイクロ秒単位で識別します。

Abstract Data Type:

抽象データ型:

unsigned32

署名なし32

Data Type Semantics:

データ型のセマンティクス:

deltaCounter

デルタカウンター

Reference:

参照：

RFC 9951

Additional Information:

追加情報：

OWDelay_HybridType1_IP_RFC9951_Seconds_Mean in the IANA "Performance Metrics Registry".

IANA「パフォーマンスメトリクスレジストリ」の OWDelay_HybridType1_IP_RFC9951_Seconds_Mean。

6.2.2. pathDelayMinDeltaMicroseconds

6.2.2. pathDelayMinDeltaマイクロ秒

Name:

名前：

pathDelayMinDeltaMicroseconds

pathDelayMinDeltaマイクロ秒

ElementID:

要素ID:

531

Description:

説明：

This Information Element identifies the lowest path delay of all packets in the Flow, in microseconds, between an OAM header encapsulating node and the local node with the OAM domain (either an OAM header transit node or an OAM header decapsulating node), according to the OWDelay_HybridType1_IP_RFC9951_Seconds_Min in the IANA "Performance Metrics Registry".

この情報要素は、IANA「パフォーマンスメトリックレジストリ」の OWDelay_HybridType1_IP_RFC9951_Seconds_Min に従って、OAM ヘッダーのカプセル化ノードと OAM ドメインを持つローカルノード (OAM ヘッダーの中継ノードまたは OAM ヘッダーのカプセル化解除ノードのいずれか) の間のフロー内のすべてのパケットの最小パス遅延をマイクロ秒単位で識別します。

Abstract Data Type:

抽象データ型:

unsigned32

署名なし32

Data Type Semantics:

データ型のセマンティクス:

deltaCounter

デルタカウンター

Reference:

参照：

RFC 9951

Additional Information:

追加情報：

OWDelay_HybridType1_IP_RFC9951_Seconds_Min in the IANA "Performance Metrics Registry".

IANA「パフォーマンスメトリクスレジストリ」の OWDelay_HybridType1_IP_RFC9951_Seconds_Min。

6.2.3. pathDelayMaxDeltaMicroseconds

6.2.3. pathDelayMaxDeltaマイクロ秒

Name:

名前：

pathDelayMaxDeltaMicroseconds

pathDelayMaxDeltaマイクロ秒

ElementID:

要素ID:

532

Description:

説明：

This Information Element identifies the highest path delay of all packets in the Flow, in microseconds, between an OAM header encapsulating node and the local node with the OAM domain (either an OAM header transit node or an OAM header decapsulating node), according to OWDelay_HybridType1_IP_RFC9951_Seconds_Max in the IANA "Performance Metrics Registry".

この情報要素は、IANA「パフォーマンスメトリックレジストリ」の OWDelay_HybridType1_IP_RFC9951_Seconds_Max に従って、OAM ヘッダーのカプセル化ノードと OAM ドメインを持つローカルノード (OAM ヘッダーの中継ノードまたは OAM ヘッダーのカプセル化解除ノードのいずれか) の間のフロー内のすべてのパケットの最大パス遅延をマイクロ秒単位で識別します。

Abstract Data Type:

抽象データ型:

unsigned32

署名なし32

Data Type Semantics:

データ型のセマンティクス:

deltaCounter

デルタカウンター

Reference:

参照：

RFC 9951

Additional Information:

追加情報：

OWDelay_HybridType1_IP_RFC9951_Seconds_Max in the IANA "Performance Metrics Registry".

IANA「パフォーマンスメトリクスレジストリ」の OWDelay_HybridType1_IP_RFC9951_Seconds_Max。

6.2.4. pathDelaySumDeltaMicroseconds

6.2.4. pathDelaySumDeltaマイクロ秒

Name:

名前：

pathDelaySumDeltaMicroseconds

pathDelaySumDeltaマイクロ秒

ElementID:

要素ID:

533

Description:

説明：

This Information Element identifies the sum of the path delay of all packets in the Flow, in microseconds, between an OAM header encapsulating node and the local node with the OAM domain (either an OAM header transit node or an OAM header decapsulating node), according to OWDelay_HybridType1_IP_RFC9951_Seconds_Sum in the IANA "Performance Metrics Registry".

この情報要素は、IANA「パフォーマンスメトリックレジストリ」の OWDelay_HybridType1_IP_RFC9951_Seconds_Sum に従って、OAM ヘッダーのカプセル化ノードと OAM ドメインを持つローカルノード (OAM ヘッダーの中継ノードまたは OAM ヘッダーのカプセル化解除ノードのいずれか) の間のフロー内のすべてのパケットのパス遅延の合計をマイクロ秒単位で識別します。

Abstract Data Type:

抽象データ型:

unsigned64

署名なし64

Data Type Semantics:

データ型のセマンティクス:

deltaCounter

デルタカウンター

Reference:

参照：

RFC 9951

Additional Information:

追加情報：

OWDelay_HybridType1_IP_RFC9951_Seconds_Sum in the IANA "Performance Metrics Registry".

IANA「パフォーマンスメトリクスレジストリ」の OWDelay_HybridType1_IP_RFC9951_Seconds_Sum。

7. Operational Considerations

7. 運用上の考慮事項

7.1. Time Accuracy

7.1. 時間精度

In terms of clock precision, the same recommendation as defined in Section 4.5 of [RFC5153] for IPFIX applies to this document as well.

クロック精度に関しては、IPFIX の [RFC5153] セクション 4.5 で定義されているのと同じ推奨事項がこの文書にも適用されます。

7.2. Mean Delay

7.2. 平均遅延

The mean (average) path delay can be calculated by dividing the pathDelaySumDeltaMicroseconds(533) by the packetDeltaCount(2) at the IPFIX data collection at the collection time instead of the IPFIX Exporter at the export time.

平均（平均）パス遅延は、エクスポート時の IPFIX エクスポーターではなく、収集時の IPFIX データ収集で pathDelaySumDeltaMicroseconds(533) を packetDeltaCount(2) で割ることによって計算できます。

7.3. Reduced-Size Encoding

7.3. 縮小サイズのエンコーディング

Unsigned64 has been chosen as the type for pathDelaySumDeltaMicroseconds to support cases with large delay numbers and where many packets are being counted. As an example, a specific Flow Record with path delay of 100 milliseconds cannot observe more than 42949 packets without overflowing the unsigned32 counter. The procedure described in Section 6.2 of [RFC7011] may be applied to reduce network bandwidth between the IPFIX Exporter and Collector if unsigned32 would be large enough without wrapping around.

遅延数が大きく、多くのパケットがカウントされるケースをサポートするために、pathDelaySumDeltaMicroseconds のタイプとして Unsigned64 が選択されています。たとえば、パス遅延が 100 ミリ秒の特定のフローレコードは、unsigned32 カウンターをオーバーフローせずに 42949 個を超えるパケットを観察できません。unsigned32 がラップアラウンドなしで十分に大きい場合、[RFC7011] のセクション 6.2 で説明されている手順を適用して、IPFIX エクスポータとコレクタの間のネットワーク帯域幅を削減できます。

7.4. Measurement Interval

7.4. 測定間隔

The delay metrics are computed for the Flow Record lifetime by comparing the OAM timestamps in each received packet with the timestamp when they were received. For a long-running Flow, the IPFIX Metering Process might miss the temporal distribution of the delay (for example, a longer delay only at the beginning of the Flow). If this is an operational problem, the IPFIX Metering Process might be configured with a smaller expiration timeout (see "Flow Expiration", Section 5.1.1 of [RFC5470]).

遅延メトリックは、受信した各パケット内の OAM タイムスタンプを受信時のタイムスタンプと比較することによって、フローレコードの有効期間に対して計算されます。長時間実行されるフローの場合、IPFIX メータリングプロセスは遅延の時間的分布を見逃す可能性があります (たとえば、フローの開始時にのみ遅延が長くなるなど)。これが運用上の問題である場合、IPFIX メータリングプロセスは有効期限タイムアウトを小さく設定できる可能性があります ([RFC5470] のセクション 5.1.1 の「フロー有効期限」を参照)。

7.5. In-Packet OAM Application

7.5. パケット内 OAM アプリケーション

Multiple methods can be used to compute the delay performance metrics defined in this document. Some examples of such methods are IOAM [RFC9197] and Enhanced Alternate Marking [ENH-ALT-MARKING].

このドキュメントで定義されている遅延パフォーマンス指標を計算するには、複数の方法を使用できます。このような方法の例としては、IOAM [RFC9197] や拡張代替マーキング [ENH-ALT-MARKING] があります。

For IOAM, these performance metrics can be computed using the Edge-to-Edge and the Direct Exporting Option-Type.

IOAM の場合、これらのパフォーマンスメトリックは、Edge-to-Edge および Direct Exporting Option-Type を使用して計算できます。

IOAM Edge-to-Edge Option-Type, as described in Section 4.6 of [RFC9197], can use bits 2 and 3. In this case, timestamps are encoded as defined in Sections 4.4.2.3 and 4.4.2.4 of [RFC9197]. This timestamp can be used to compute the delay between an OAM header encapsulating node and the decapsulating node.

IOAM Edge-to-Edge Option-Type は、[RFC9197] のセクション 4.6 で説明されているように、ビット 2 および 3 を使用できます。この場合、タイムスタンプは、[RFC9197] のセクション 4.4.2.3 および 4.4.2.4 で定義されているようにエンコードされます。このタイムスタンプは、OAM ヘッダーのカプセル化ノードとカプセル化解除ノード間の遅延を計算するために使用できます。

The IOAM Direct Exporting Option-Type, as described in [RFC9326], can use the Extension-Flag defined in [IOAM-DEX] to insert a timestamp in the OAM header encapsulating node. The timestamp is encoded as defined in Sections 4.4.2.3 and 4.4.2.4 of [RFC9197]. This timestamp can be used to compute the delay between the inserted timestamp and the OAM header transit and decapsulating node.

IOAM Direct Exporting Option-Type は、[RFC9326] で説明されているように、[IOAM-DEX] で定義されている Extension-Flag を使用して、OAM ヘッダーのカプセル化ノードにタイムスタンプを挿入できます。タイムスタンプは、[RFC9197] のセクション 4.4.2.3 および 4.4.2.4 で定義されているようにエンコードされます。このタイムスタンプは、挿入されたタイムスタンプと OAM ヘッダーの転送およびカプセル化解除ノード間の遅延を計算するために使用できます。

For the Enhanced Alternate Marking Method, Section 2 of [ENH-ALT-MARKING] and Section 3.2 of [RFC9947] define that, within the metaInfo, a nanosecond timestamp can be encoded in an OAM header encapsulating node and be read at the OAM header intermediate and decapsulating nodes to calculate the On-path delay. [RFC9343] defines how this can be applied to the IPv6 extensions header, and [RFC9947] defines how this can be applied to the SRv6 Segment Routing Header [RFC8754].

拡張代替マーキング方法については、[ENH-ALT-MARKING] のセクション 2 および [RFC9947] のセクション 3.2 では、metaInfo 内で、ナノ秒のタイムスタンプを OAM ヘッダーのカプセル化ノードでエンコードし、OAM ヘッダーの中間およびカプセル化解除ノードで読み取られて、オンパス遅延を計算できることが定義されています。[RFC9343] はこれを IPv6 拡張ヘッダーに適用する方法を定義し、[RFC9947] はこれを SRv6 セグメントルーティングヘッダー [RFC8754] に適用する方法を定義します。

Given that the delay measurements are computed with the timestamp introduced on the OAM header encapsulating node, regardless of the approach, implementations should document at which point of the forwarding plane this timestamp is introduced (e.g., the time at which the packet was received by the node, the time at which the packet was transmitted by the node, etc.). Based on this information, different actions can be taken.

遅延測定値が、アプローチに関係なく、OAM ヘッダーをカプセル化するノードに導入されたタイムスタンプを使用して計算されることを考慮すると、実装では、このタイムスタンプがフォワーディングプレーンのどの時点で導入されるかを文書化する必要があります (たとえば、パケットがノードによって受信された時刻、パケットがノードによって送信された時刻など)。この情報に基づいて、さまざまなアクションを実行できます。

8. Security Considerations

8. セキュリティに関する考慮事項

The IPFIX Information Elements introduced in this document do not directly introduce security issues. Rather, they define a set of performance metrics that may, for privacy or business issues, be considered sensitive information.

この文書で紹介されている IPFIX 情報要素は、セキュリティ上の問題を直接引き起こすものではありません。むしろ、プライバシーやビジネス上の問題で機密情報とみなされる可能性のある一連のパフォーマンス指標を定義します。

For example, exporting delay metrics may make attacks possible by the receiver of this information; otherwise, this would only be possible for direct observers of the reported Flows along the data path.

たとえば、遅延メトリクスをエクスポートすると、この情報の受信者による攻撃が可能になる可能性があります。それ以外の場合、これはデータパスに沿って報告されたフローを直接観察する人のみが可能になります。

IPFIX collectors MUST ensure that IPFIX data originates from trusted sources. Accepting IPFIX data from unauthenticated sources could lead to data spoofing, policy misapplication, or denial of service.

IPFIX コレクターは、IPFIX データが信頼できるソースからのものであることを確認しなければなりません。認証されていないソースから IPFIX データを受け入れると、データスプーフィング、ポリシーの誤適用、またはサービス拒否が発生する可能性があります。

Therefore, the underlying protocol used to exchange the information described here must apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. These protocols are defined in separate documents; specifically, see the IPFIX security considerations in Section 11 of [RFC7011]. Implementations SHOULD also refer to [BCP195] for additional details.

したがって、ここで説明する情報の交換に使用される基礎となるプロトコルは、エクスポートされた情報の完全性と機密性を保証するための適切な手順を適用する必要があります。これらのプロトコルは別の文書で定義されています。特に、[RFC7011] のセクション 11 の IPFIX セキュリティに関する考慮事項を参照してください。実装では、追加の詳細について [BCP195] も参照する必要があります (SHOULD)。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

   [BCP195]   Best Current Practice 195,
              <https://www.rfc-editor.org/info/bcp195>.
              At the time of writing, this BCP comprises the following:

              Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
              1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
              <https://www.rfc-editor.org/info/rfc8996>.

              Sheffer, Y., Saint-Andre, P., and T. Fossati,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
              2022, <https://www.rfc-editor.org/info/rfc9325>.

   [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>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [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>.

   [RFC6049]  Morton, A. and E. Stephan, "Spatial Composition of
              Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011,
              <https://www.rfc-editor.org/info/rfc6049>.

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <https://www.rfc-editor.org/info/rfc7011>.

   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
              Scheffenegger, Ed., "TCP Extensions for High Performance",
              RFC 7323, DOI 10.17487/RFC7323, September 2014,
              <https://www.rfc-editor.org/info/rfc7323>.

   [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>.

   [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>.

   [RFC8911]  Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
              Akhter, "Registry for Performance Metrics", RFC 8911,
              DOI 10.17487/RFC8911, November 2021,
              <https://www.rfc-editor.org/info/rfc8911>.

   [RFC8912]  Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
              "Initial Performance Metrics Registry Entries", RFC 8912,
              DOI 10.17487/RFC8912, November 2021,
              <https://www.rfc-editor.org/info/rfc8912>.

9.2. Informative References

9.2. 参考引用

   [ENH-ALT-MARKING]
              Zhou, T., Ed., Fioccola, G., Liu, Y., Cociglio, M., Pang,
              R., Xiong, L., Lee, S., and W. Li, "Enhanced Alternate
              Marking Method", Work in Progress, Internet-Draft, draft-
              zhou-ippm-enhanced-alternate-marking-18, 5 December 2025,
              <https://datatracker.ietf.org/doc/html/draft-zhou-ippm-
              enhanced-alternate-marking-18>.

   [IANA-IPFIX]
              IANA, "IP Flow Information Export (IPFIX) Entities",
              <https://www.iana.org/assignments/ipfix>.

   [IANA-PERF-METRIC]
              IANA, "Performance Metrics",
              <https://www.iana.org/assignments/performance-metrics>.

   [IOAM-DEX] Huang Feng, A., Francois, P., Claise, B., and T. Graf,
              "Timestamp extension for In Situ Operations,
              Administration, and Maintenance (IOAM) Direct Export",
              Work in Progress, Internet-Draft, draft-ahuang-ippm-dex-
              timestamp-ext-00, 15 February 2023,
              <https://datatracker.ietf.org/doc/html/draft-ahuang-ippm-
              dex-timestamp-ext-00>.

   [IPFIX-ALT-MARK]
              Graf, T., Fioccola, G., Zhou, T., and Y. Zhu, "IP Flow
              Information Export (IPFIX) Alternate-Marking Information
              Elements", Work in Progress, Internet-Draft, draft-ietf-
              opsawg-ipfix-alt-mark-05, 27 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              ipfix-alt-mark-05>.

   [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
              Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
              <https://www.rfc-editor.org/info/rfc1997>.

   [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>.

   [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>.

   [RFC5153]  Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P.
              Aitken, "IP Flow Information Export (IPFIX) Implementation
              Guidelines", RFC 5153, DOI 10.17487/RFC5153, April 2008,
              <https://www.rfc-editor.org/info/rfc5153>.

   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow Information Export", RFC 5470,
              DOI 10.17487/RFC5470, March 2009,
              <https://www.rfc-editor.org/info/rfc5470>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [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>.

   [RFC7015]  Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
              for the IP Flow Information Export (IPFIX) Protocol",
              RFC 7015, DOI 10.17487/RFC7015, September 2013,
              <https://www.rfc-editor.org/info/rfc7015>.

   [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>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC9197]  Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
              Ed., "Data Fields for In Situ Operations, Administration,
              and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
              May 2022, <https://www.rfc-editor.org/info/rfc9197>.

   [RFC9232]  Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
              A. Wang, "Network Telemetry Framework", RFC 9232,
              DOI 10.17487/RFC9232, May 2022,
              <https://www.rfc-editor.org/info/rfc9232>.

   [RFC9326]  Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
              Mizrahi, "In Situ Operations, Administration, and
              Maintenance (IOAM) Direct Exporting", RFC 9326,
              DOI 10.17487/RFC9326, November 2022,
              <https://www.rfc-editor.org/info/rfc9326>.

   [RFC9343]  Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate-Marking Method",
              RFC 9343, DOI 10.17487/RFC9343, December 2022,
              <https://www.rfc-editor.org/info/rfc9343>.

   [RFC9911]  Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
              DOI 10.17487/RFC9911, December 2025,
              <https://www.rfc-editor.org/info/rfc9911>.

   [RFC9947]  Fioccola, G., Zhou, T., Mishra, G., Wang, X., Zhang, G.,
              and M. Cociglio, "Application of the Alternate-Marking
              Method to the Segment Routing Header", RFC 9947,
              DOI 10.17487/RFC9947, March 2026,
              <https://www.rfc-editor.org/info/rfc9947>.

Appendix A. IPFIX Encoding Examples

付録A. IPFIX エンコーディングの例

This appendix represents two different encodings for the newly introduced IEs. Let's take Figure 1 as a topology example. Table 4 shows the aggregated delay with ingressInterface, egressInterface, destinationIPv6Address, and srhActiveSegmentIPv6.

この付録では、新しく導入された IE の 2 つの異なるエンコーディングを示します。トポロジの例として図 1 を見てみましょう。表 4 は、ingressInterface、egressInterface、destinationIPv6Address、および srhActiveSegmentIPv6 の合計遅延を示しています。

             +--------------------------------+-------------+
             | ingressInterface               | 271         |
             +--------------------------------+-------------+
             | egressInterface                | 276         |
             +--------------------------------+-------------+
             | destinationIPv6Address         | 2001:db8::3 |
             +--------------------------------+-------------+
             | srhActiveSegmentIPv6           | 2001:db8::2 |
             +--------------------------------+-------------+
             | packetDeltaCount               | 5           |
             +--------------------------------+-------------+
             | pathDelayMeanDeltaMicroseconds | 36 µs       |
             +--------------------------------+-------------+
             | pathDelayMinDeltaMicroseconds  | 22 µs       |
             +--------------------------------+-------------+
             | pathDelayMaxDeltaMicroseconds  | 74 µs       |
             +--------------------------------+-------------+

Table 4: Aggregated Delay with egressInterface and srhActiveSegmentIPv6

表 4: egressInterface と srhActiveSegmentIPv6 の合計遅延

A.1. Aggregated On-Path Delay Examples

A.1. 集約されたオンパス遅延の例

A.1.1. Template Record and Data Set with Mean Delta

A.1.1. 平均デルタを含むテンプレートレコードとデータセット

With encoding in Figure 2, the mean (average) path delay is calculated on the exporting node.

図 2 のエンコードでは、平均 (平均) パス遅延がエクスポートノードで計算されます。

* Ingress interface => ingressInterface

* 入力インターフェース => 入力インターフェース

* Egress interface => egressInterface

* 出力インターフェース => 出力インターフェース

* IPv6 destination address => destinationIPv6Address

* IPv6 宛先アドレス => destinationIPv6Address

* Active SRv6 Segment => srhActiveSegmentIPv6

* アクティブな SRv6 セグメント => srhActiveSegmentIPv6

* Packet Delta Count => packetDeltaCount

* パケットデルタ数 => packetDeltaCount

* Minimum One-Way Delay => pathDelayMinDeltaMicroseconds (531)

* 最小片道遅延 => pathDelayMinDeltaマイクロ秒 (531)

* Maximum One-Way Delay => pathDelayMaxDeltaMicroseconds (532)

* 最大片道遅延 => pathDelayMaxDeltaMicro秒 (532)

* Mean One-Way Delay => pathDelayMeanDeltaMicroseconds (530)

* 平均一方向遅延 => pathDelayMeanDeltaマイクロ秒 (530)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SET ID = 2           |       Length = 40             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID = 256        |      Field Count = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|     ingressInterface = 10   |      Field Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|     egressInterface = 14    |      Field Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| destinationIPv6Address = 28 |      Field Length = 16        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| srhActiveSegmentIPv6 = 495  |      Field Length = 16        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| packetDeltaCount = 5        |      Field Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| pathDelayMeanDelta.. = 530  |      Field Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| pathDelayMinDelta.. = 531   |      Field Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| pathDelayMaxDelta.. = 532   |      Field Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Template Record for pathDelayMeanDeltaMicroseconds

図 2: pathDelayMeanDeltaMicroseconds のテンプレートレコード

The data set is represented as follows:

データセットは次のように表されます。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         SET ID = 256          |           Length = 60         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           ingressInterface =  271                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           egressInterface =  276                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           destinationIPv6Address =                            |
   |                          ...                                  |
   |                          ...                                  |
   |                          2001:db8::2                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           srhActiveSegmentIPv6 = ...                          |
   |                          ...                                  |
   |                          ...                                  |
   |                          2001:db8::3                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           packetDeltaCount = 5                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           pathDelayMeanDeltaMicroseconds =  36                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           pathDelayMinDeltaMicroseconds =  22                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           pathDelayMaxDeltaMicroseconds =  74                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Data Set Encoding for pathDelayMeanDeltaMicroseconds

図 3: pathDelayMeanDeltaMicroseconds のデータセットエンコーディング

A.1.2. Template Record and Data Set with Sum Delta

A.1.2. テンプレートレコードと合計デルタを含むデータセット

With encoding in Figure 4, the mean (average) path delay is calculated on the IPFIX data collection.

図 4 のエンコードでは、IPFIX データ収集に基づいて平均 (平均) パス遅延が計算されます。

* Ingress interface => ingressInterface

* 入力インターフェース => 入力インターフェース

* Egress interface => egressInterface

* 出力インターフェース => 出力インターフェース

* IPv6 destination address => destinationIPv6Address

* IPv6 宛先アドレス => destinationIPv6Address

* Active SRv6 Segment => srhActiveSegmentIPv6

* アクティブな SRv6 セグメント => srhActiveSegmentIPv6

* Packet Delta Count => packetDeltaCount

* パケットデルタ数 => packetDeltaCount

* Minimum One-Way Delay => pathDelayMinDeltaMicroseconds (531)

* 最小片道遅延 => pathDelayMinDeltaマイクロ秒 (531)

* Maximum One-Way Delay => pathDelayMaxDeltaMicroseconds (532)

* 最大片道遅延 => pathDelayMaxDeltaMicro秒 (532)

* Sum of One-Way Delay => pathDelaySumDeltaMicroseconds (533)

* 片道遅延の合計 => pathDelaySumDeltaマイクロ秒 (533)

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          SET ID = 2           |       Length = 40             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Template ID = 257        |      Field Count = 8          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|     ingressInterface = 10   |      Field Length = 4         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|     egressInterface = 14    |      Field Length = 4         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| destinationIPv6Address = 28 |      Field Length = 16        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| srhActiveSegmentIPv6 = 495  |      Field Length = 16        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| packetDeltaCount = 5        |      Field Length = 4         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| pathDelayMinDelta.. = 531   |      Field Length = 4         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| pathDelayMaxDelta.. = 532   |      Field Length = 4         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| pathDelaySumDelta.. = 533   |      Field Length = 8         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Template Record for pathDelaySumDeltaMicroseconds.

図 4: pathDelaySumDeltaMicroseconds のテンプレートレコード。

The data set is represented as follows:

データセットは次のように表されます。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         SET ID = 257          |           Length = 64         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           ingressInterface =  271                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           egressInterface =  276                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           destinationIPv6Address =                            |
      |                          ...                                  |
      |                          ...                                  |
      |                          2001:db8::2                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           srhActiveSegmentIPv6 = ...                          |
      |                          ...                                  |
      |                          ...                                  |
      |                          2001:db8::3                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           packetDeltaCount = 5                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           pathDelayMinDeltaMicroseconds =  22                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           pathDelayMaxDeltaMicroseconds =  74                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           pathDelaySumDeltaMicroseconds =  180                |
      |                          ...                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Data Set Encoding for pathDelaySumDeltaMicroseconds

図 5: pathDelaySumDeltaMicroseconds のデータセットエンコーディング

Acknowledgements

謝辞

The authors would like to thank Al Morton (Rest in Peace, Al), Justin Iurman, Giuseppe Fioccola, Yannick Buchs, Menachem Dodge, Martin Duke, Behcet Sarikaya, Mahesh Jethanandani, Linda Dunbar, Deb Cooley, Mike Bishop, Tim Wicinski, Gunter Van de Velde, and Éric Vyncke for their review and valuable comments. Special thanks to Paul Aitken (as IPFIX Designated Expert), Greg Mirsky (as IP Performance Metrics Designated Expert), and to Med Boucadair for their very detailed feedback.

著者らは、レビューと貴重なコメントをくださった Al Morton (Rest in Peace, Al)、Justin Iurman、Giuseppe Fioccola、Yannick Buchs、Menachem Dodge、Martin Duke、Behcet Sarikaya、Mahesh Jethanandani、Linda Dunbar、Deb Cooley、Mike Bishop、Tim Wicinski、Gunter Van de Velde、および Éric Vyncke に感謝します。Paul Aitken (IPFIX 指定専門家として)、Greg Mirsky (IP パフォーマンスメトリクス指定専門家として)、および非常に詳細なフィードバックを提供してくれた Med Boucadair に特別に感謝します。

Authors' Addresses

著者の住所

   Thomas Graf
   Swisscom
   Binzring 17
   CH-8045 Zurich
   Switzerland
   Email: thomas.graf@swisscom.com

   Benoit Claise
   Huawei
   Email: benoit@everything-ops.net

   Alex Huang-Feng
   INSA-Lyon
   Lyon
   France
   Email: alex.huang-feng@insa-lyon.fr

RFC 9951 - Export of Delay Performance Metrics in IP Flow Information Export (IPFIX) 日本語訳

Export of Delay Performance Metrics in IP Flow Information Export (IPFIX)

IP フロー情報エクスポート (IPFIX) での遅延パフォーマンス メトリックのエクスポート

Abstract

概要

Status of This Memo

本文書の状態

Copyright Notice

著作権表示

Table of Contents

目次

1. Introduction

1. はじめに

2. Terminology

2. 用語

3. Solution

3. 解決

4. Performance Metrics

4. パフォーマンス指標

4.1. IP One-Way Delay Hybrid Type I Performance Metrics

4.1. IP 一方向遅延ハイブリッド タイプ I のパフォーマンス メトリック

4.1.1. Summary

4.1.1. まとめ

4.1.1.1. ID (Identifier)

4.1.1.1. ID（識別子）

4.1.1.2. Name

4.1.1.2. 名前

4.1.1.3. URI

4.1.1.3. URI

4.1.2. Description

4.1.2. 説明

4.1.3. Reference

4.1.3. 参照

4.1.4. Change Controller

4.1.4. コントローラーの変更

4.1.5. Version of Registry Format

4.1.5. レジストリ形式のバージョン

4.2. Metric Definition

4.2. メトリクスの定義

4.2.1. Reference Definition

4.2.1. 参照定義

4.2.2. Fixed Parameters

4.2.2. 固定パラメータ

4.3. Method of Measurement

4.3. 測定方法

4.3.1. Reference Methods

4.3.1. 参照方法

4.3.2. Packet Stream Generation

4.3.2. パケットストリームの生成

4.3.3. Traffic Filtering (Observation) Details

4.3.3. トラフィックフィルタリング（観測）の詳細

4.3.4. Sampling Distribution

4.3.4. サンプリング分布

4.3.5. Runtime Parameters and Data Format

4.3.5. 実行時パラメータとデータ形式

4.3.6. Roles

4.3.6. 役割

4.4. Output

4.4. 出力

4.4.1. Type

4.4.1. タイプ

4.4.2. Reference Definition

4.4.2. 参照定義

4.4.2.1. OWDelay_HybridType1_IP_RFC9951_Seconds_Mean

4.4.2.1. OWDelay_HybridType1_IP_RFC9951_Seconds_Mean

4.4.2.2. OWDelay_HybridType1_IP_RFC9951_Seconds_Min

4.4.2.2. OWDelay_HybridType1_IP_RFC9951_Seconds_Min

4.4.2.3. OWDelay_HybridType1_IP_RFC9951_Seconds_Max

4.4.2.3. OWDelay_HybridType1_IP_RFC9951_Seconds_Max

4.4.2.4. OWDelay_HybridType1_IP_RFC9951_Seconds_Sum

4.4.2.4. OWDelay_HybridType1_IP_RFC9951_Seconds_Sum

4.4.2.5. Metric Units

4.4.2.5. メートル単位

4.4.2.6. Calibration

4.4.2.6. 較正

4.4.3. Administrative Items

4.4.3. 管理事項

4.4.3.1. Status

4.4.3.1. 状態

4.4.3.2. Requester

IP フロー情報エクスポート (IPFIX) での遅延パフォーマンスメトリックのエクスポート

4.1. IP 一方向遅延ハイブリッドタイプ I のパフォーマンスメトリック

A.1.1. 平均デルタを含むテンプレートレコードとデータセット

A.1.2. テンプレートレコードと合計デルタを含むデータセット