Export of Delay
Performance Metrics in IP Flow Information eXport (IPFIX)SwisscomBinzring 17Zurich8045Switzerlandthomas.graf@swisscom.comHuaweibenoit.claise@huawei.comINSA-LyonLyonFrancealex.huang-feng@insa-lyon.frThis 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.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.With On-Path Telemetry, described in the
Network Telemetry Framework and applied in In Situ Operations, Administration, and Maintenance
(IOAM) Deployment and Alternate Marking Deployment
Framework, the path delay between two endpoints is measured by
inserting a timestamp in the packet.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.In order to export the delay-related metrics via IPIFX , 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 , they must be
registered in the "IANA Performance
Metric Registry.Following the guidelines for Registered Performance Metric Requesters
and Reviewers , the different characteristics of
the performance metrics (Identifier, Name, URI, Status, Requester,
Revision, Revision Date, Description, etc.) must be clearly specified in
the "IANA Performance Metric
Registry 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 ).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. .
. .
. D2 .
. x--------------------> .
. .
. D3 .
. x-----------------------------------> .
. .
(H1) ------ (R1) ------- (R2) ------- (R3) -------- (R4) ------ (H2)
Host 1 Encapsulating Transit Transit Decapsulating Host 2
Node Node 1 Node 2 Node
. .
. .
.........................................
]]>In the usecase shown in 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.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.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
when, and only when,
they appear in all capitals, as shown here.This document makes use of the terms defined in and .The following terms are used as defined in :IPFIXIPFIX Information Elements (IEs)FlowFlow RecordExporterThe following terms are used as defined in :Performance MetricRegistered Performance MetricPerformance Metrics RegistryThe following terms are used as defined in :Encapsulating nodeTransit nodeDecapsulating nodeThe following terms are used as defined in :Hybrid Type I PassiveThis section defines the new performance metrics following the
template defined in .IANA Note (to be removed): RFC 8192 Section 4 was taken a guiding
example.This section specifies four performance metrics for the Hybrid Type
I Passive assessment of IP One-Way Delay, to be registered in the
"IANA Performance Metric
Registry.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.This category includes multiple indexes of the registered
performance metrics: the element Identifier and Metric Name.IANA has allocated the numeric Identifiers TBD1, TBD2, TBD3,
and TBD4 for the four Named Metric Entries in the following
section.RFC EDITOR NOTE: please replace TBD1, TBD2, TBD3, and TBD4.TBD1:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_MeanTBD2:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_MinTBD3:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_MaxTBD4:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_SumRFC EDITOR NOTE: please replace [RFC-to-be].URI: URI: URI: URI: RFC EDITOR NOTE: please replace TBD1, TBD2, TBD3, and TBD4.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.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.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.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.IETF1.0This 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".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>. Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC
6049, DOI 10.17487/RFC6049, January 2011,
<https://www.rfc-editor.org/info/rfc6049>.
provides the reference definition of the singleton (single value)
one-way delay metric. provides the reference definition expanded to
cover a multi-value sample. Note that terms such as "singleton" and
"sample" are defined in .With the OP 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 of
the measurements yields a one-way delay singleton.This document specifies how to export the performance metric
using IPFIX.NoneThis category includes columns for references to relevant sections
of the RFC(s) and any supplemental information needed to ensure an
unambiguous method for implementations.The foundational methodology for this metric is defined in using the
Timestamps option with modifications that allow application at a
mid-path OP .The timestamp when the packet is being received at OAM
encapsulating node. Format depends on On-Path Telemetry
implementation. For IOAM, 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, describes
timestamp encoding and granularity.Runtime Parameters (in the following sections) may be used for
Traffic Filtering.This metric requires a partial sample of all packets that qualify
according to the Traffic Filter criteria.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: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 ).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 ).T time, the start of a measurement interval
(format "date/time" as specified in ; see also "date-and-time"
in ). The
UTC Time Zone is required by . 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.A time, the end of a measurement interval
(format "date/time" as specified in ; see also "date-and-time"
in ). The
UTC Time Zone is required by . When T0 is "all-zeros",
an ending time and date is ignored and Tf is interpreted as the
duration of the measurement interval.Launches an IP packet to start the
Flow.Receives the IP packet to start the
Flow.Receives the IP Flow packets
and encapsulates the timestamp into the packet.Receives the IP Flow packets and
measures the delay between the timestamp in the packet and the
timestamp when the packet was received.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.This category specifies all details of the output of measurements
using the metric.OWDelay Types are discussed in the subsections below.For all output types:The one-way delay
of one IP packet is a SingletonFor each <statistic> Singleton one of the following
subsections applies.Similar to , 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:See
for details on the conditional distribution to exclude undefined
values of delay, and see for background on this analysis choice.See
for details on calculating this statistic; see also .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,
)
with a resolution of 0.000000001 seconds (1.0 ns), and
with lossless conversion to/from the 64-bit NTP timestamp as
per .Similar to , 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:See
for details on the conditional distribution to exclude undefined
values of delay, and see for background on this analysis choice.See
for details on calculating this statistic; see also .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,
)
with a resolution of 0.000000001 seconds (1.0 ns), and
with lossless conversion to/from the 64-bit NTP timestamp as
per .Similar to , 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:See
for details on the conditional distribution to exclude undefined
values of delay, and see for background on this analysis choice.See
for a closely related method for calculating this statistic; see
also .
The formula is as follows:= FiniteDelay[n] for all n
]]>where all packets n = 1 through N have finite singleton
delays.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,
)
with a resolution of 0.000000001 seconds (1.0 ns), and
with lossless conversion to/from the 64-bit NTP timestamp as
per .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
for details on the conditional distribution to exclude undefined
values of delay, and see for background on this analysis choice.See
for details on calculating this statistic. However in this case
FiniteDelay or MaxDelay MAY be used.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,
)
with a resolution of 0.000000001 seconds (1.0 ns), and
with lossless conversion to/from the 64-bit NTP timestamp as
per .MeanMinMaxSumThe one-way delay of the IP Flow singleton is expressed in
seconds.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 , can be used for synchronizing the clocks of
the monitored nodes.CurrentThis RFCRFC EDITOR NOTE: please replace This RFC text by the RFC issued
from this document1.0RFC DatenoneThis section specifies the following new IPFIX IEs: 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).
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).
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).
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).The measured On-Path delay can be aggregated with Flow Aggregation as
defined in to the following device and
control-plane dimensions to determine:With node id and egressInterface(14), on which node which logical
egress interfaces have been contributing to how much delay.With node id and egressPhysicalInterface(253), on which node
which physical egress interfaces have been contributing to how much
delay.With ipNextHopIPv4Address(15) or ipNextHopIPv6Address(62), the
forwarding path to which next-hop IP contributed to how much
delay.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.BGP communities 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.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.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).This document requests IANA to add four new performance metrics
under the "Performance Metrics" registry with
the four templates defined in Section 3.This document requests IANA to register new IPFIX IEs (see table 3)
under the "IPFIX Information Elements" registry available at "IANA IP
Flow Information Export (IPFIX) Entities Registry and assign
the following initial code points.Note to the RFC-Editor:Please replace TBD5 - TBD8 with the values allocated by
IANAPlease replace all instances of [RFC-to-be] in this section
with the RFC number assigned to this document
Name:
pathDelayMeanDeltaMicroseconds
ElementID:
TBD5
Description:
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
Abstract Data Type:
unsigned32
Data Type Semantics:
deltaCounter
Reference:
[RFC-to-be]
Additional Information:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean in
the IANA Performance Metric Registry.
Name:
pathDelayMinDeltaMicroseconds
ElementID:
TBD6
Description:
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.
Abstract Data Type:
unsigned32
Data Type Semantics:
deltaCounter
Reference:
[RFC-to-be]
Additional Information:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min in
the IANA Performance Metric Registry.
Name:
pathDelayMaxDeltaMicroseconds
ElementID:
TBD7
Description:
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.
Abstract Data Type:
unsigned32
Data Type Semantics:
deltaCounter
Reference:
[RFC-to-be]
Additional Information:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max in
the IANA Performance Metric Registry.
Name:
pathDelaySumDeltaMicroseconds
ElementID:
TBD8
Description:
This Information Element 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), according to
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum in the
IANA Performance Metric Registry.
Abstract Data Type:
unsigned64
Data Type Semantics:
deltaCounter
Reference:
[RFC-to-be]
Additional Information:
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum in
the IANA Performance Metric Registry.
The same recommendation as defined in for IPFIX applies in terms of
clock precision to this document as well.The mean (average) path delay can be calculated by dividing the
pathDelaySumDeltaMicroseconds(TBD8) by the packetDeltaCount(2) at the
IPFIX data collection in order to offload the IPFIX Exporter from
calculating the mean for every Flow at export time.Unsigned64 has been chosen as type for
pathDelaySumDeltaMicroseconds to support cases with large delay
numbers and where many packets are being accounted. 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 may be applied to reduce network
bandwidth between the IPFIX Exporter and Collector if unsigned32 would
be large enough without wrapping around.The delay metrics are computed for the Flow Record life time. For
long-running Flow, we might miss the temporal distribution of the
delay (for example, a longer delay only at the beginning of Flow). If
this is an operational problem, the IPFIX Metering Process might be
configured with a smaller expiration timeout (see Section 5.1.1. Flow
Expiration).Multiple methods can be used to compute the delay performance
metrics defined in this document. Some examples of such methods are
IOAM and Enhanced Alternate Marking .For IOAM, these performance metrics can be computed using the
Edge-to-Edge and the Direct Exporting Option-Type.IOAM Edge-to-Edge Option-Type, as described in , can use the bits 2 and 3. In
this case, timestamps are encoded as defined in Section 4.4.2.3 and
4.4.2.4 of . This timestamp can be used to
compute the delay between the encapsulating node and the decapsulating
node.IOAM Direct Exporting Option-Type, as described in , can use the Extension-Flag defined in to insert a timestamp in
the encapsulating node. The timestamp is encoded as defined in Section
4.4.2.3 and 4.4.2.4 of . This timestamp can be
used to compute the delay between the inserted timestamp and the
transit and decapsulating node.For the Enhanced Alternate Marking Method,
defines that, within the metaInfo, a nanosecond timestamp can be
encoded in the encapsulating node and be read at the intermediate and
decapsulating node to calculate the on-path delay. defines how this can be applied to the IPv6
data-plane and defines
how this can be applied to the Segment Routing Header in SRv6.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.For example, exporting delay metrics may make attacks possible for
the receiver of this information; this would otherwise only be possible
for direct observers of the reported Flows along the data path.The underlying protocol used to exchange the information described
here must therefore apply appropriate procedures to guarantee the
integrity and confidentiality of the exported information. These
protocols are defined in separate documents, specifically the IPFIX
protocol document .Note to the RFC-Editor: Please remove this section before
publishing.INSA Lyon implemented the following IEs as part of a prototype in
the FD.io VPP (Vector Packet Processing) platform:pathDelayMeanDeltaMicrosecondspathDelayMaxDeltaMicrosecondspathDelayMinDeltaMicrosecondspathDelaySumDeltaMicrosecondsThe open source code can be obtained here: and was validated at the IETF 116
hackathon.Huawei implemented the following IEs as part of a a production
implementation in the VRP platform:pathDelayMeanDeltaMicrosecondspathDelayMaxDeltaMicrosecondspathDelayMinDeltaMicrosecondspathDelaySumDeltaMicrosecondsThe implementation was validated at the IETF 116 hackathon.NTT Com implemented the following IEs in the Fluvia Exporter:pathDelayMeanDeltaMicrosecondspathDelayMaxDeltaMicrosecondspathDelayMinDeltaMicrosecondspathDelaySumDeltaMicrosecondsThe open source code can be obtained here: and was validated at the IETF 118 hackathon.Paolo Lucente implemented the IE pathDelayMeanDeltaMicroseconds by
dividing IE pathDelaySumDeltaMicroseconds by IE packetDeltaCount in
the open source Network Telemetry data collection project pmacct.The source code can be obtained here: and was validated at the IETF 116
hackathon.The authors would like to thank Al Morton (Rest in Peace Al), Justin
Iurman, Giuseppe Fioccola and Yannick Buchs 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 his very detailed feedback.IANA Performance Metric RegistryIANA IP Flow Information Export (IPFIX) Entities
RegistryINSA Lyon, FD.io VPP implementationNTT Com, Fluvia ExporterPaolo Lucente, Pmacct open source Network Telemetry Data
CollectionThis appendix represents two different encodings for the newly
introduced IEs. Taking Figure 1 from Section 1 as topology example.
Below example Table 4 shows the aggregated delay with ingressInterface,
egressInterface, destinationIPv6Address and srhActiveSegmentIPv6.With encoding in Figure 2, the mean (average) path delay is
calculated on the exporting node.Ingress interface => ingressInterfaceEgress interface => egressInterfaceIPv6 destination address => destinationIPv6AddressActive SRv6 Segment => srhIPv6ActiveSegmentPacket Delta Count => packetDeltaCountMinimum One-Way Delay => pathDelayMinDeltaMicroseconds
(TBD6)Maximum One-Way Delay => pathDelayMaxDeltaMicroseconds
(TBD7)Mean One-Way Delay => pathDelayMeanDeltaMicroseconds
(TBD5)The data set is represented as follows:With encoding in Figure 4, the mean (average) path delay is
calculated on the IPFIX data collection.Ingress interface => ingressInterfaceEgress interface => egressInterfaceIPv6 destination address => destinationIPv6AddressActive SRv6 Segment => srhIPv6ActiveSegmentPacket Delta Count => packetDeltaCountMinimum One-Way Delay => pathDelayMinDeltaMicroseconds
(TBD6)Maximum One-Way Delay => pathDelayMaxDeltaMicroseconds
(TBD7)Sum of One-Way Delay => pathDelaySumDeltaMicroseconds
(TBD8)The data set is represented as follows: