-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-ietf-opsawg-ipfix-on-path-telemetry-13.xml
1547 lines (1221 loc) · 65.5 KB
/
draft-ietf-opsawg-ipfix-on-path-telemetry-13.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-opsawg-ipfix-on-path-telemetry-13"
ipr="trust200902">
<front>
<title abbrev="Delay Performance Metrics for IPFIX">Export of Delay
Performance Metrics in IP Flow Information eXport (IPFIX)</title>
<author fullname="Thomas Graf" initials="T" surname="Graf">
<organization>Swisscom</organization>
<address>
<postal>
<street>Binzring 17</street>
<city>Zurich</city>
<code>8045</code>
<country>Switzerland</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Benoit Claise" initials="B" surname="Claise">
<organization>Huawei</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Alex Huang Feng" initials="A." surname="Huang Feng">
<organization>INSA-Lyon</organization>
<address>
<postal>
<street/>
<city>Lyon</city>
<region/>
<code/>
<country>France</country>
</postal>
<phone/>
<facsimile/>
<email>[email protected]</email>
<uri/>
</address>
</author>
<date day="31" month="August" year="2024"/>
<abstract>
<t>This document specifies new IP Flow Information Export (IPFIX)
Information Elements to export the On-Path Telemetry measured delay on
the OAM transit and decapsulating nodes.</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>Network operators usually gather and maintain some forms of
statistical delay view of their networks (or segments of their
networks). That view is meant to help understanding where in the
network, for which customer traffic or services, how much, and why
abnormal delay is being accumulated. To that aim, delay-related data
need to be reported from devices covering both data and control planes.
In order to understand which customer traffic is affected, delay-related
data need to be reported into customer data-plane context. That enables
network operators to quickly identify when the control-plane updates the
current path with a different set of intermediate hops (that is, a
change of the forwarding path) and interfaces, how the path delay
changes for which customer traffic.</t>
<t>With On-Path Telemetry, described in the <xref target="RFC9232">
Network Telemetry Framework</xref> and applied in <xref
target="RFC9378"> In Situ Operations, Administration, and Maintenance
(IOAM) Deployment</xref> and <xref
target="I-D.ietf-ippm-alt-mark-deployment">Alternate Marking Deployment
Framework</xref>, the path delay between two endpoints is measured by
inserting a timestamp in the packet.</t>
<t>At least two modes of On-Path Telemetry can be distinguished.
Passport mode, where only the last hop in the forwarding path of the
On-Path Telemetry domain exposes all the metrics, and postcard mode,
where the metrics are also exposed in transit nodes. In both modes the
forwarding path exposes performance metrics allowing to determine how
much delay has been accumulated on which hop. The proposal in this
document makes more sense for the postcard mode.</t>
<t>In order to export the delay-related metrics via IPIFX <xref
target="RFC7011"/>, this document defines four new IPFIX Information
Elements (IEs), exposing the On-Path delay on OAM transit and
decapsulating nodes, following the postcard mode principles. Since these
IPFIX IEs are performance metrics <xref target="RFC8911"/>, they must be
registered in the <xref target="IANA-PERF-METRIC">"IANA Performance
Metric Registry</xref>.</t>
<t>Following the guidelines for Registered Performance Metric Requesters
and Reviewers <xref target="RFC8911"/>, the different characteristics of
the performance metrics (Identifier, Name, URI, Status, Requester,
Revision, Revision Date, Description, etc.) must be clearly specified in
the <xref target="IANA-PERF-METRIC">"IANA Performance Metric
Registry</xref> in order for the measurement results using the
Performance Metrics to be comparable even if they are performed using
different implementations and in different networks. The first
performance metric characteristic is the selection of a meaningful name,
following the "MetricType_Method_SubTypeMethod_... Spec_Units_Output"
naming convention (See <xref section="7.1.2" sectionFormat="of"
target="RFC8911"/>).</t>
<t><figure>
<artwork><![CDATA[
+------------------------------------+-------------------------------+
| Performance Metric | IPFIX Information Element |
+------------------------------------+-------------------------------+
|OWDelay_HybridType1_Passive_I |pathDelayMeanDeltaMicroseconds |
|P_RFC[RFC-to-be]_Seconds_Mean (TBD1)|(TBD5) |
+------------------------------------+-------------------------------+
|OWDelay_HybridType1_Passive_I |pathDelayMinDeltaMicroseconds |
|P_RFC[RFC-to-be]_Seconds_Min (TBD2) |(TBD6) |
+------------------------------------+-------------------------------+
|OWDelay_HybridType1_Passive_I |pathDelayMaxDeltaMicroseconds |
|P_RFC[RFC-to-be]_Seconds_Max (TBD3) |(TBD7) |
+------------------------------------+-------------------------------+
|OWDelay_HybridType1_Passive_I |pathDelaySumDeltaMicroseconds |
|P_RFC[RFC-to-be]_Seconds_Sum (TBD4) |(TBD8) |
+------------------------------------+-------------------------------+
Table 1: Mapping Between IPFIX IEs and Performance Metrics
]]></artwork>
</figure></t>
<t>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 the OAM encapsulating node and the timestamp
exported in the IPFIX flow record from the OAM transit and decapsulating
nodes. The lowest, highest, mean, and/or the sum of measured path delay
can be exported, thanks to the different IPFIX IE specifications.</t>
<figure anchor="topology"
title="Delay use case. Packets flow from host 1 to host 2.">
<artwork align="center"><![CDATA[
On-Path Telemetry Domain
.........................................
. .
. D1 .
. x------> .
. .
. D2 .
. x--------------------> .
. .
. D3 .
. x-----------------------------------> .
. .
(H1) ------ (R1) ------- (R2) ------- (R3) -------- (R4) ------ (H2)
Host 1 Encapsulating Transit Transit Decapsulating Host 2
Node Node 1 Node 2 Node
. .
. .
.........................................
]]></artwork>
</figure>
<t>In the usecase shown in <xref target="topology"/> using On-path
Telemetry to export the delay metrics, the node R2 exports the delay D1,
the node R3 exports the delay D2 and the decapsulating node R4 exports
the total delay D3 using IPFIX.</t>
<t>The advantages of this solution is that the delay metrics (min, max,
and mean) can be computed on the router, and aggregated directly within
the Flow Record, saving export bandwidth and computation on the
Collector. For the computation of the min, max, and mean delay metric to
be computed locally on the router, the exporter Metering Process
requires some local caching/processing computation (for each new packets
in the flow), specifically the mean value. A less computational heavy
solution for the router is the export of the delay sum instead of the
delay mean; on the Collector, the delay mean can easily be computed by a
single division operation (using the packet count). The alternative,
with any delay monitoring on the router, requires the export of every
single packet as a separate Flow Record, including the timestamps
information, for the Collector to compute delay metrics (min, max, and
mean) and to recompute the aggregated Flow Record.</t>
</section>
<section anchor="notation" title="Terminology">
<t>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
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
<t>This document makes use of the terms defined in <xref
target="RFC7011"/> and <xref target="RFC9378"/>.</t>
<t>The following terms are used as defined in <xref
target="RFC7011"/>:</t>
<t><list style="symbols">
<t>IPFIX</t>
<t>IPFIX Information Elements (IEs)</t>
<t>Flow</t>
<t>Flow Record</t>
<t>Exporter</t>
</list></t>
<t>The following terms are used as defined in <xref
target="RFC8911"/>:</t>
<t><list style="symbols">
<t>Performance Metric</t>
<t>Registered Performance Metric</t>
<t>Performance Metrics Registry</t>
</list></t>
<t>The following terms are used as defined in <xref section="5"
sectionFormat="of" target="I-D.ietf-opsawg-oam-characterization"/>:</t>
<t><list style="symbols">
<t>Encapsulating node</t>
<t>Transit node</t>
<t>Decapsulating node</t>
</list></t>
<t>The following terms are used as defined in <xref section="3.8"
sectionFormat="of" target="RFC7799"/>:</t>
<t><list style="symbols">
<t>Hybrid Type I Passive</t>
</list></t>
</section>
<section anchor="PM" title="Performance Metrics">
<t>This section defines the new performance metrics following the
template defined in <xref section="11" sectionFormat="of"
target="RFC8911"/>.</t>
<t>IANA Note (to be removed): RFC 8192 Section 4 was taken a guiding
example.</t>
<section anchor="ip-ow-delay-hybridtype1-passive-reg-entries"
title="IP One-Way Delay Hybrid Type I Passive Performance Metrics">
<t>This section specifies four performance metrics for the Hybrid Type
I Passive assessment of IP One-Way Delay, to be registered in the
<xref target="IANA-PERF-METRIC">"IANA Performance Metric
Registry</xref>.</t>
<t>All column entries besides the Identifier, Name, URI, Description,
Output, and Reference Method 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.</t>
<section numbered="true" title="Summary">
<t>This category includes multiple indexes of the registered
performance metrics: the element Identifier and Metric Name.</t>
<section title="ID (Identifier)">
<t>IANA has allocated the numeric Identifiers TBD1, TBD2, TBD3,
and TBD4 for the four Named Metric Entries in the following
section.</t>
<t>RFC EDITOR NOTE: please replace TBD1, TBD2, TBD3, and TBD4.</t>
</section>
<section title="Name">
<t>TBD1:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean</t>
<t>TBD2:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min</t>
<t>TBD3:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max</t>
<t>TBD4:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum</t>
<t>RFC EDITOR NOTE: please replace [RFC-to-be].</t>
</section>
<section title="URI">
<t>URI: <eref
target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean"/></t>
<t>URI: <eref
target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min"/></t>
<t>URI: <eref
target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max"/></t>
<t>URI: <eref
target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum"/></t>
<t>RFC EDITOR NOTE: please replace TBD1, TBD2, TBD3, and TBD4.</t>
</section>
</section>
<section title="Description">
<t><list style="symbols">
<t>OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean:
This metric assesses the mean of one-way delays of all
successfully forwarded IP packets constituting a single Flow. We
consider the measurement of one-way delay based on a single
Observation Point (OP) [RFC7011] somewhere in the network.</t>
<t>OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min:
This metric assesses the minimum of one-way delays of all
successfully forwarded IP packets constituting a single Flow. We
consider the measurement of one-way delay based on a single
Observation Point (OP) [RFC7011] somewhere in the network.</t>
<t>OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max:
This metric assesses the maximum of one-way delays of all
successfully forwarded IP packets constituting a single Flow. We
consider the measurement of one-way delay based on a single
Observation Point (OP) [RFC7011] somewhere in the network.</t>
<t>OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum:
This metric assesses the sum of one-way delays of all
successfully forwarded IP packets constituting a single Flow. We
consider the measurement of one-way delay based on a single
Observation Point (OP) [RFC7011] somewhere in the network.</t>
</list></t>
</section>
<section title="Change Controller">
<t>IETF</t>
</section>
<section title="Version of Registry Format">
<t>1.0</t>
</section>
</section>
<section title="Metric Definition">
<t>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".</t>
<section title="Reference Definition">
<t>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>. <xref
target="RFC7679"/></t>
<t>Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC
6049, DOI 10.17487/RFC6049, January 2011,
<https://www.rfc-editor.org/info/rfc6049>. <xref
target="RFC6049"/></t>
<t><xref section="3.4" sectionFormat="of" target="RFC7679"/>
provides the reference definition of the singleton (single value)
one-way delay metric. <xref section="4.4" sectionFormat="of"
target="RFC7679"/> provides the reference definition expanded to
cover a multi-value sample. Note that terms such as "singleton" and
"sample" are defined in <xref section="2" sectionFormat="of"
target="RFC2330"/>.</t>
<t>With the OP <xref target="RFC7011"/> typically located between
the hosts participating in the IP Flow, the one-way delay metric
requires one individual measurement between the OP and sourcing
host, such that the Spatial Composition <xref target="RFC6049"/> of
the measurements yields a one-way delay singleton.</t>
<t>This document specifies how to export the performance metric
using IPFIX.</t>
</section>
<section title="Fixed Parameters">
<t>None</t>
</section>
</section>
<section title="Method of Measurement">
<t>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.</t>
<section title="Reference Methods">
<t>The foundational methodology for this metric is defined in <xref
section="4" sectionFormat="of" target="RFC7323"/> using the
Timestamps option with modifications that allow application at a
mid-path OP <xref target="RFC7011"/>.</t>
</section>
<section title="Packet Stream Generation">
<t>The timestamp when the packet is being received at OAM
encapsulating node. Format depends on On-Path Telemetry
implementation. For IOAM, <xref section="4.4.1" sectionFormat="of"
target="RFC9197"/> describes what kind of timestamps are supported.
Section 4.4.2.3 and 4.4.2.4 describe where the timestamp is being
inserted. For the Enhanced Alternate Marking Method, <xref
section="2" sectionFormat="of"
target="I-D.zhou-ippm-enhanced-alternate-marking"/> describes
timestamp encoding and granularity.</t>
</section>
<section title="Traffic Filtering (Observation) Details">
<t>Runtime Parameters (in the following sections) may be used for
Traffic Filtering.</t>
</section>
<section title="Sampling Distribution">
<t>This metric requires a partial sample of all packets that qualify
according to the Traffic Filter criteria.</t>
</section>
<section title="Runtime Parameters and Data Format">
<t>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.</t>
<t>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:</t>
<t><list style="hanging">
<t hangText="Src:">The IP address of the host in the host A Role
(format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6; see <xref section="4"
sectionFormat="of" target="RFC6991"/>).</t>
<t hangText="Dst:">The IP address of the host in the host B Role
(format ipv4&nbhy;address-no-zone value for IPv4 or
ipv6-address-no-zone value for IPv6; see <xref section="4"
sectionFormat="of" target="RFC6991"/>).</t>
<t hangText="T0:">T time, the start of a measurement interval
(format "date/time" as specified in <xref section="5.6"
sectionFormat="of" target="RFC3339"/>; see also "date-and-time"
in <xref section="3" sectionFormat="of" target="RFC6991"/>). The
UTC Time Zone is required by <xref section="6.1"
sectionFormat="of" target="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>
<t hangText="Tf:">A time, the end of a measurement interval
(format "date/time" as specified in <xref section="5.6"
sectionFormat="of" target="RFC3339"/>; see also "date-and-time"
in <xref section="3" sectionFormat="of" target="RFC6991"/>). The
UTC Time Zone is required by <xref section="6.1"
sectionFormat="of" target="RFC2330"/>. When T0 is "all-zeros",
an ending time and date is ignored and Tf is interpreted as the
duration of the measurement interval.</t>
</list></t>
</section>
<section title="Roles">
<t><list style="hanging">
<t hangText="host A:">Launches an IP packet to start the
Flow.</t>
<t hangText="host B:">Receives the IP packet to start the
Flow.</t>
<t hangText="Encapsulating Node:">Receives the IP Flow packets
and encapsulates the timestamp into the packet.</t>
<t hangText="Transit Node:">Receives the IP Flow packets and
measures the delay between the timestamp in the packet and the
timestamp when the packet was received.</t>
<t hangText="Decapsulating Node:">Receives the IP Flow packets
and 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.</t>
</list></t>
</section>
</section>
<section title="Output">
<t>This category specifies all details of the output of measurements
using the metric.</t>
<section title="Type">
<t>OWDelay Types are discussed in the subsections below.</t>
</section>
<section title="Reference Definition">
<t>For all output types:</t>
<t><list style="hanging">
<t hangText="OWDelay_HybridType1_Passive_IP:">The one-way delay
of one IP packet is a Singleton</t>
</list></t>
<t>For each <statistic> Singleton one of the following
subsections applies.</t>
<section title="OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean">
<t>Similar to <xref section="7.4.2.2" sectionFormat="of"
target="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:</t>
<t>See <xref section="4.1" sectionFormat="of" target="RFC3393"/>
for details on the conditional distribution to exclude undefined
values of delay, and see <xref section="5" sectionFormat="of"
target="RFC6703"/> for background on this analysis choice.</t>
<t>See <xref section="4.2.2" sectionFormat="of" target="RFC6049"/>
for details on calculating this statistic; see also <xref
section="4.2.3" sectionFormat="of" target="RFC6049"/>.</t>
<t><list style="hanging">
<t hangText="Mean:">The time value of the result is expressed
in units of seconds, as a positive value of type decimal64
with fraction digits = 9 (similar to the decimal64 in YANG,
<xref section="9.3" sectionFormat="of" target="RFC6020"/>)
with a resolution of 0.000000001 seconds (1.0 ns), and
with lossless conversion to/from the 64-bit NTP timestamp as
per <xref section="6" sectionFormat="of"
target="RFC5905"/>.</t>
</list></t>
</section>
<section title="OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min">
<t>Similar to <xref section="7.4.2.3" sectionFormat="of"
target="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:</t>
<t>See <xref section="4.1" sectionFormat="of" target="RFC3393"/>
for details on the conditional distribution to exclude undefined
values of delay, and see <xref section="5" sectionFormat="of"
target="RFC6703"/> for background on this analysis choice.</t>
<t>See <xref section="4.3.2" sectionFormat="of" target="RFC6049"/>
for details on calculating this statistic; see also <xref
section="4.3.3" sectionFormat="of" target="RFC6049"/>.</t>
<t><list style="hanging">
<t hangText="Min:">The time value of the result is expressed
in units of seconds, as a positive value of type decimal64
with fraction digits = 9 (similar to the decimal64 in YANG,
<xref section="9.3" sectionFormat="of" target="RFC6020"/>)
with a resolution of 0.000000001 seconds (1.0 ns), and
with lossless conversion to/from the 64-bit NTP timestamp as
per <xref section="6" sectionFormat="of"
target="RFC5905"/>.</t>
</list></t>
</section>
<section title="OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max">
<t>Similar to <xref section="7.4.2.4" sectionFormat="of"
target="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:</t>
<t>See <xref section="4.1" sectionFormat="of" target="RFC3393"/>
for details on the conditional distribution to exclude undefined
values of delay, and see <xref section="5" sectionFormat="of"
target="RFC6703"/> for background on this analysis choice.</t>
<t>See <xref section="4.3.2" sectionFormat="of" target="RFC6049"/>
for a closely related method for calculating this statistic; see
also <xref section="4.3.3" sectionFormat="of" target="RFC6049"/>.
The formula is as follows:</t>
<t><figure>
<artwork><![CDATA[
Max = (FiniteDelay[j])
such that for some index, j, where 1 <= j <= N
FiniteDelay[j] >= FiniteDelay[n] for all n
]]></artwork>
</figure></t>
<t>where all packets n = 1 through N have finite singleton
delays.</t>
<t><list style="hanging">
<t hangText="Max:">The time value of the result is expressed
in units of seconds, as a positive value of type decimal64
with fraction digits = 9 (similar to the decimal64 in YANG,
<xref section="9.3" sectionFormat="of" target="RFC6020"/>)
with a resolution of 0.000000001 seconds (1.0 ns), and
with lossless conversion to/from the 64-bit NTP timestamp as
per <xref section="6" sectionFormat="of"
target="RFC5905"/>.</t>
</list></t>
</section>
<section title="OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum">
<t>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:</t>
<t>See <xref section="4.1" sectionFormat="of" target="RFC3393"/>
for details on the conditional distribution to exclude undefined
values of delay, and see <xref section="5" sectionFormat="of"
target="RFC6703"/> for background on this analysis choice.</t>
<t>See <xref section="4.3.5" sectionFormat="of" target="RFC6049"/>
for details on calculating this statistic. However in this case
FiniteDelay or MaxDelay MAY be used.</t>
<t><list style="hanging">
<t hangText="Sum:">The time value of the result is expressed
in units of seconds, as a positive value of type decimal64
with fraction digits = 9 (similar to the decimal64 in YANG,
<xref section="9.3" sectionFormat="of" target="RFC6020"/>)
with a resolution of 0.000000001 seconds (1.0 ns), and
with lossless conversion to/from the 64-bit NTP timestamp as
per <xref section="6" sectionFormat="of"
target="RFC5905"/>.</t>
</list></t>
</section>
<section title="Metric Units">
<t><list style="symbols">
<t>Mean</t>
<t>Min</t>
<t>Max</t>
<t>Sum</t>
</list></t>
<t>The one-way delay of the IP Flow singleton is expressed in
seconds.</t>
</section>
<section title="Calibration">
<t>A clock synchronization between the nodes of the monitored OAM
domain is needed to compute representative delay measurements at
the transit and decapsulating nodes. NTP, as defined in <xref
target="RFC5905"/>, can be used for synchronizing the clocks of
the monitored nodes.</t>
</section>
</section>
<section title="Administrative Items">
<section title="Status">
<t>Current</t>
</section>
<section title="Requester">
<t>This RFC</t>
<t>RFC EDITOR NOTE: please replace This RFC text by the RFC issued
from this document</t>
</section>
<section title="Revision">
<t>1.0</t>
</section>
<section title="Revision Date">
<t>RFC Date</t>
</section>
</section>
<section title="Comments and Remarks">
<t>none</t>
</section>
</section>
</section>
<section anchor="IE" title="IPFIX Information Elements">
<t>This section specifies the following new IPFIX IEs:<list
style="hanging">
<t hangText="pathDelayMeanDeltaMicroseconds"><vspace
blankLines="0"/> 32-bit unsigned integer that identifies the mean
path delay of all packets in the Flow, in microseconds, between the
OAM encapsulating node and the local node with the OAM domain
(either an OAM transit node or an OAM decapsulating node).</t>
<t hangText="pathDelayMinDeltaMicroseconds"><vspace blankLines="0"/>
32-bit unsigned integer that identifies the lowest path delay of all
packets in the Flow, in microseconds, between the OAM encapsulating
node and the local node with the OAM domain (either an OAM transit
node or an OAM decapsulating node).</t>
<t hangText="pathDelayMaxDeltaMicroseconds"><vspace blankLines="0"/>
32-bit unsigned integer that identifies the highest path delay of
all packets in the Flow, in microseconds, between the OAM
encapsulating node and the local node with the OAM domain (either an
OAM transit node or an OAM decapsulating node).</t>
<t hangText="pathDelaySumDeltaMicroseconds"><vspace blankLines="0"/>
64-bit unsigned integer that identifies the sum of the path delay of
all packets in the Flow, in microseconds, between the OAM
encapsulating node and the local node with the OAM domain (either an
OAM transit node or an OAM decapsulating node).</t>
</list></t>
</section>
<section anchor="Use-Cases" title="Use Cases">
<t>The measured On-Path delay can be aggregated with Flow Aggregation as
defined in <xref target="RFC7015"/> to the following device and
control-plane dimensions to determine:</t>
<t><list style="symbols">
<t>With node id and egressInterface(14), on which node which logical
egress interfaces have been contributing to how much delay.</t>
<t>With node id and egressPhysicalInterface(253), on which node
which physical egress interfaces have been contributing to how much
delay.</t>
<t>With ipNextHopIPv4Address(15) or ipNextHopIPv6Address(62), the
forwarding path to which next-hop IP contributed to how much
delay.</t>
<t>With mplsTopLabelIPv4Address(47) or destinationIPv6Address and
srhActiveSegmentIPv6(495), the forwarding path to which MPLS top
label IPv4 address or IPv6 destination address and SRv6 active
segment contributed to how much delay.</t>
<t>BGP communities <xref target="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.</t>
<t>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.</t>
</list></t>
<t>Let us consider the example depicted in Figure 1 from Section 1 as
topology example. Below example table shows the aggregated delay per
each node, ingressInterface,(10) egressInterface(14),
destinationIPv6Address(28) and srhActiveSegmentIPv6(495).</t>
<t><figure>
<artwork><![CDATA[
+-----------+-----------+------+-------------+-------------+------------+
| ingress | egress | Node | destination | srhActive | Path Delay |
| Interface | Interface | | IPv6Address | SegmentIPv6 | |
+-----------+-----------+------+-------------+-------------+------------+
| 271 | 276 | R1 | 2001:db8::2 | 2001:db8::4 | 0 us |
+-----------+-----------+------+-------------+-------------+------------+
| 301 | 312 | R2 | 2001:db8::3 | 2001:db8::4 | 22 us |
+-----------+-----------+------+-------------+-------------+------------+
| 22 | 27 | R3 | 2001:db8::4 | 2001:db8::4 | 42 us |
+-----------+-----------+------+-------------+-------------+------------+
| 852 | 854 | R4 | 2001:db8::4 | 2001:db8::4 | 122 us |
+-----------+-----------+------+-------------+-------------+------------+
Table 2: Example table of measured delay. Ascending by delay.
]]></artwork>
</figure></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section anchor="PM-IANA" title="Performance Metrics">
<t>This document requests IANA to add four new performance metrics
under the "Performance Metrics" registry <xref target="RFC8911"/> with
the four templates defined in Section 3.</t>
</section>
<section anchor="IE-IANA" title="IPFIX Entities">
<t>This document requests IANA to register new IPFIX IEs (see table 3)
under the "IPFIX Information Elements" registry <xref
target="RFC7012"/> available at <xref target="IANA-IPFIX">"IANA IP
Flow Information Export (IPFIX) Entities Registry</xref> and assign
the following initial code points.</t>
<t><figure>
<artwork><![CDATA[
+-------+--------------------------------+
|Element| Name |
| ID | |
+-------+--------------------------------+
| TBD5 | pathDelayMeanDeltaMicroseconds |
| | |
+-------+--------------------------------+
| TBD6 | pathDelayMinDeltaMicroseconds |
| | |
+-------+--------------------------------+
| TBD7 | pathDelayMaxDeltaMicroseconds |
| | |
+-------+--------------------------------+
| TBD8 | pathDelaySumDeltaMicroseconds |
| | |
+-------+--------------------------------+
Table 3: New IPFIX IEs in the "IPFIX Information Elements" Registry
]]></artwork>
</figure></t>
<t>Note to the RFC-Editor:</t>
<t><list style="symbols">
<t>Please replace TBD5 - TBD8 with the values allocated by
IANA</t>
<t>Please replace all instances of [RFC-to-be] in this section
with the RFC number assigned to this document</t>
</list></t>
<section anchor="IANApathDelayMeanDeltaMicroseconds"
title="pathDelayMeanDeltaMicroseconds">
<dl>
<dt>Name:</dt>
<dd>pathDelayMeanDeltaMicroseconds</dd>
</dl>
<dl>
<dt>ElementID:</dt>
<dd>TBD5</dd>
</dl>
<dl>
<dt>Description:</dt>
<dd>This Information Element identifies the mean path delay of all
packets in the Flow, in microseconds, between the OAM
encapsulating node and the local node with the OAM domain (either
an OAM transit node or an OAM decapsulating node), according to
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean in the
IANA Performance Metric Registry.</dd>
</dl>
<dl>
<dt>Abstract Data Type:</dt>
<dd>unsigned32</dd>
</dl>
<dl>
<dt>Data Type Semantics:</dt>
<dd>deltaCounter</dd>
</dl>
<dl>
<dt>Reference:</dt>
<dd>[RFC-to-be]</dd>
</dl>
<dl>
<dt>Additional Information:</dt>
<dd>OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean in
the IANA Performance Metric Registry.</dd>
</dl>
</section>
<section anchor="IANApathDelayMinDeltaMicroseconds"
title="pathDelayMinDeltaMicroseconds">
<dl>
<dt>Name:</dt>
<dd>pathDelayMinDeltaMicroseconds</dd>
</dl>
<dl>
<dt>ElementID:</dt>
<dd>TBD6</dd>
</dl>
<dl>
<dt>Description:</dt>
<dd>This Information Element identifies the lowest path delay of
all packets in the Flow, in microseconds, between the OAM
encapsulating node and the local node with the OAM domain (either
an OAM transit node or an OAM decapsulating node), according to
the OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min in
the IANA Performance Metric Registry.</dd>
</dl>
<dl>
<dt>Abstract Data Type:</dt>
<dd>unsigned32</dd>
</dl>
<dl>
<dt>Data Type Semantics:</dt>
<dd>deltaCounter</dd>
</dl>
<dl>
<dt>Reference:</dt>
<dd>[RFC-to-be]</dd>
</dl>
<dl>
<dt>Additional Information:</dt>
<dd>OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min in
the IANA Performance Metric Registry.</dd>
</dl>
</section>
<section anchor="IANApathDelayMaxDeltaMicroseconds"
title="pathDelayMaxDeltaMicroseconds">
<dl>
<dt>Name:</dt>
<dd>pathDelayMaxDeltaMicroseconds</dd>
</dl>
<dl>
<dt>ElementID:</dt>
<dd>TBD7</dd>
</dl>
<dl>
<dt>Description:</dt>
<dd>This Information Element identifies the highest path delay of
all packets in the Flow, in microseconds, between the OAM
encapsulating node and the local node with the OAM domain (either
an OAM transit node or an OAM decapsulating node), according to
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max in the
IANA Performance Metric Registry.</dd>
</dl>
<dl>
<dt>Abstract Data Type:</dt>
<dd>unsigned32</dd>
</dl>
<dl>
<dt>Data Type Semantics:</dt>
<dd>deltaCounter</dd>
</dl>
<dl>
<dt>Reference:</dt>
<dd>[RFC-to-be]</dd>
</dl>
<dl>
<dt>Additional Information:</dt>
<dd>OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max in
the IANA Performance Metric Registry.</dd>
</dl>
</section>
<section anchor="IANApathDelaySumDeltaMicroseconds"
title="pathDelaySumDeltaMicroseconds">
<dl>
<dt>Name:</dt>
<dd>pathDelaySumDeltaMicroseconds</dd>
</dl>
<dl>
<dt>ElementID:</dt>
<dd>TBD8</dd>
</dl>