3. Solution

この節では IPFIX delay performance metric export の RFC テキストを保持し, On-Path Telemetry, OAM nodes, Flow Records, performance metric IDs 27-30, IPFIX Information Elements 530-533, IANA registrations, operational guidance, encoding examples を扱う.

RFC 原文

3.  Solution

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

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

     +=============================+================================+
     | 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

   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.

                          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

   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.

   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.

   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.