| Internet-Draft | Export of On-Path Delay in IPFIX | January 2024 |
| Graf, et al. | Expires 17 July 2024 | [Page] |
This document introduces new IP Flow Information Export (IPFIX) information elements to expose the On-Path Telemetry measured delay on the IOAM transit and decapsulation nodes.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 July 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
Network operators want a statistical delay view of their networks. They want to understand where in the network, for which customer traffic, how much and why delay is being accummlated. In order to answer why and where, delay needs to be reported into device and control-plane context. In order to understand which customer traffic is affected, delay needs 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 next-hop and therefore the forwarding path changes to different nodes and interfaces, how the path delay changes for which customer traffic.¶
With On-Path Telemetry, described in the Network Telemetry Framework [RFC9232] and applied in In-situ OAM [I-D.ietf-ippm-ioam-deployment] and Alternate Marking Deployment Framework [I-D.ietf-ippm-alt-mark-deployment], the path delay between two endpoints is measured by inserting a timestamp in the packet.¶
On-Path Telemetry can be distinguished between two modes. Passport mode, [RFC9197], where only the last hop in the forwarding path of the On-Path Telemetry domain exposes all the metrics, and postcard mode, [I-D.song-ippm-postcard-based-telemetry], where the metrics are also exposed in the transit nodes. In both modes the forwarding path exposes performance metrics allowing to determine how much delay has been accumulated on which hop.¶
This document defines four new IPFIX Information Elements (IEs), exposing the On-Path delay on IOAM transit and decapsulation nodes, following the postcard mode principles. Since these IPFIX IEs are performance metrics [RFC8911], they must be registered in the "IANA Performance Metric Registry [IANA-PERF-METRIC].¶
Following the guidelines for Registered Performance Metric requesters and reviewers [RFC8911], 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 [IANA-PERF-METRIC] in order for the results of measurements using the Performance Metrics to be comparable even if they are performed by different implementations and in different networks. These characteristics start by selecting a meaningful name, following the "MetricType_Method_SubTypeMethod_... Spec_Units_Output" naming convention (See Section 7.1.2 of [RFC8911]).¶
+------------------------------------+-------------------------------+ | 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: Correspondance between IPFIX IE and Performance Metric¶
The delay is measured by calculating the difference between the timestamp imposed with On-Path Telemetry in the packet at the IOAM encapsulation node and the timestamp exported in the IPFIX flow record from the IOAM transit and decapsulation nodes. The lowest, highest, mean, and/or the sum of measured path delay can be exported, thanks to the different IPFIX IE specifications.¶
On-Path Telemetry Domain
.........................................
. .
. D1 .
. <------> .
. .
. D2 .
. <--------------------> .
. .
. D3 .
. <-----------------------------------> .
. .
(H1) ------ (R1) ------- (R2) ------- (R3) -------- (R4) ------ (H2)
Host 1 Encapsulation Transit Transit Decapsulation Host 2
Node Node 1 Node 2 Node
. .
. .
.........................................
On the usecase showed in Figure 1 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 decapsulation node R4 exports the total delay D3 using IPFIX.¶
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.¶
This document makes use of the terms defined in [RFC7011] and [I-D.ietf-ippm-ioam-deployment].¶
The following terms are used as defined in [RFC7011].¶
The following terms are used as defined in [RFC8911].¶
The following terms are used as defined in [I-D.ietf-ippm-ioam-deployment].¶
This section defines and describes the new performance metrics by applying the template defined in Section 11 of [RFC8911].¶
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 [IANA-PERF-METRIC].¶
All column entries besides the ID, Name, Description, and Output Reference Method categories are the same; thus, this section defines four closely related performance metrics. As a result, IANA has assigned corresponding URLs to each of the four registered performance metrics.¶
This category includes multiple indexes of the registered performance metrics: the element ID and Metric Name.¶
<insert a numeric Identifier, an integer, TBD>¶
IANA has allocated the numeric Identifiers TBD1-4 for the four Named Metric Entries in this section¶
TBD1: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean¶
TBD2: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min¶
TBD3: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max¶
TBD4: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum¶
URL: https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean¶
URL: https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min¶
URL: https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max¶
URL: https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum¶
This metric assesses the one-way delay of IP packets constituting a single connection between two hosts. We consider the measurement of one-way delay based on a single Observation Point (OP) [RFC7011] somewhere in the network. The output is the one-way delay for all successfully forwarded packets expressed as the <statistic> of their conditional delay distribution, where <statistic> is one of:¶
IETF¶
1.0¶
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".¶
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>. [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>. [RFC6049]¶
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 2 of [RFC2330].¶
With the OP [RFC7011] typically located between the hosts participating in the IP connection, the one-way delay metric requires one individual measurement between the OP and sourcing host, such that the Spatial Composition [RFC6049] of the measurements yields a one-way delay singleton.¶
Traffic Filters:¶
IPv4 header values: DSCP: Set to 0 IPv6 header values: DSCP: Set to 0 Hop Count: Set to 255 Flow Label: Set to 0 Extension Headers: None¶
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.¶
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 OP [RFC7011].¶
N/A¶
The Fixed Parameters above give a portion of the Traffic Filter. Other aspects will be supplied as Runtime Parameters (below).¶
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 the measurement system, and reported with the results for the context to be complete.¶
The hybrid type I metering parameters must 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 used, potential traffic filters, and potential sampling method and parameters) that generates the flow records must be reported to provide the complete measurement context.¶
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:¶
For each <statistic> Singleton one of the following subsections applies.¶
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 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 analysis choice.¶
See section 4.2.2 of [RFC6049] for details on calculating this statistic; see also section 4.2.3 of [RFC6049].¶
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 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 analysis choice.¶
See section 4.3.2 of [RFC6049] for details on calculating this statistic; see also section 4.3.3 of [RFC6049].¶
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 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 analysis 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:¶
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.¶
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 analysis choice.¶
See section 4.3.5 of [RFC6049] for details on calculating this statistic. However in this case FiniteDelay or MaxDelay MAY be used.¶
The <statistic> of one-way delay is expressed in seconds, where <statistic> is one of:¶
The one-way delay of the IP connection singleton is expressed in seconds.¶
Passive Measurements at an OP could be calibrated against an Active Measurement at host A where the Active Measurement represents the ground truth.¶
Current¶
This RFC¶
1.0¶
RFC Date¶
none¶
This section defines and describes the new IPFIX IEs.¶
The measured On-Path delay can be aggregated with Flow Aggregation as defined in [RFC7015] to the following device and control-plane dimensions to determine:¶
With node id and egressInterface(IE14), 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(IE15) or ipNextHopIPv6Address(IE62), the forwarding path to which next-hop IP contributed to how much delay.¶
With mplsTopLabelIPv4Address(IE47) or destinationIPv6Address and srhActiveSegmentIPv6 from [RFC9487], 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(IE8), the forwarding path delay on each node from each IPv4 source address to a specific application in the network.¶
Taking figure 1 from section 1 as topology example. Below example table shows the aggregated delay per each node, ingressInterface, egressInterface, destinationIPv6Address and srhActiveSegmentIPv6.¶
+-----------+-----------+------+-------------+-------------+------------+
| 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.
¶
This document requests IANA to create new performance metrics under the "Performance Metrics" registry [RFC8911] with the values defined in section 2.¶
This document requests IANA to create new IPFIX IEs (see table 3) under the "IPFIX Information Elements" registry [RFC7012] available at "IANA Performance Metric Registry [IANA-PERF-METRIC] and assign the following initial code points.¶
+-------+--------------------------------+
|Element| Name |
| ID | |
+-------+--------------------------------+
| TBD5 | PathDelayMeanDeltaMicroseconds |
| | |
+-------+--------------------------------+
| TBD6 | PathDelayMinDeltaMicroseconds |
| | |
+-------+--------------------------------+
| TBD7 | PathDelayMaxDeltaMicroseconds |
| | |
+-------+--------------------------------+
| TBD8 | PathDelaySumDeltaMicroseconds |
| | |
+-------+--------------------------------+
Table 3: Creates IPFIX IEs in the "IPFIX Information Elements" registry
¶
Note to the RFC-Editor:¶
Please replace TBD5 - TBD8 with the values allocated by IANA¶
Please replace the [RFC-to-be] with the RFC number assigned to this document¶
The same recommendation as defined in section 4.5 of [RFC5153] 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(TBD5) 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 microseconds can not observe more than 42949 packets without overflowing the unsigned32 counter. The procedure described in Section 6.2 of [RFC7011] could be applied to reduce network bandwidth between the IPFIX Exporter and Collector if unsigned32 would be large enough without wrapping around.¶
This document is applicable in IOAM to the Edge-to-Edge and Direct Exporting Option-Type.¶
In case of Edge-to-Edge Option-Type, as described in Section 4.6 of [RFC9197], by setting bits 2 and 3, timestamps can be encoded as defined in Section 4.4.2.3 and 4.4.2.4 of [RFC9197].¶
In case of Direct Exporting Option-Type, as described in Section 2 of [I-D.ahuang-ippm-dex-timestamp-ext], by setting Extension-Flags 2 and 3, timestamps can be encoded as defined in Section 4.4.2.3 and 4.4.2.4 of [RFC9197].¶
For the Enhanced Alternate Marking Method, Section 2 of [I-D.zhou-ippm-enhanced-alternate-marking] defines that within the metaInfo a nano second timestamp can be encoded in the encapsulation node and be read at the intermediate and decapsulation node to calculate the on-path delay. [RFC9343] defines how this can be appied to the IPv6 data-plane and [I-D.fz-spring-srv6-alt-mark] defines how this can be appied to the Segment Routing Header in SRv6.¶
There are no significant extra security considerations regarding the allocation of these new IPFIX IEs compared to [RFC7012].¶
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:¶
PathDelayMeanDeltaMicroseconds¶
PathDelayMaxDeltaMicroseconds¶
PathDelayMinDeltaMicroseconds¶
PathDelaySumDeltaMicroseconds¶
The open source code can be obtained here: [INSA-Lyon-VPP] and was validated at the IETF 116 hackathon.¶
Huawei implemented the following IEs as part of a a production implementation in the VRP platform:¶
PathDelayMeanDeltaMicroseconds¶
PathDelayMaxDeltaMicroseconds¶
PathDelayMinDeltaMicroseconds¶
PathDelaySumDeltaMicroseconds¶
The implementation was validated at the IETF 116 hackathon.¶
NTT Com implemented the following IEs in the Fluvia Exporter:¶
PathDelayMeanDeltaMicroseconds¶
PathDelayMaxDeltaMicroseconds¶
PathDelayMinDeltaMicroseconds¶
PathDelaySumDeltaMicroseconds¶
The open source code can be obtained here: [NTT-Fluvia] 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: [Paolo-Lucente-Pmacct] and was validated at the IETF 116 hackathon.¶
The authors would like to thank Al Morton, Greg Mirsky and Giuseppe Fioccola for their review and valuable comments.¶
This 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.¶
+------ +------+-----------+-----------+------+---------+---------+---------+---------+ |ingress|egress|destination|srhActive |packet|PathDelay|PathDelay|PathDelta|PathDelta| |Inter |Inter |IPv6Address|SegmentIPv6|Delta |MinDelta |MaxDelta |MeanDelta|MeanDelta| |face |face | | |Count |Micro.. |Micro.. |Micro.. |Micro.. | +-------+------+-----------+-----------+------+---------+---------+---------+---------+ | 271 | 276 |2001:db8::4|2001:db8::2| 5 | 22 us | 74 us | 36 us | 180 us | +-------+------+-----------+-----------+------+---------+---------+---------+---------+ Table 4: Aggregated delay with egressInterface and srhActiveSegmentIPv6¶
With encoding in Figure 1, the mean (average) path delay is calculated on the exporting node.¶
Ingress interface => ingressInterface¶
Egress interface => egressInterface¶
IPv6 destination address => destinationIPv6Address¶
Active SRv6 Segment => srhIPv6ActiveSegment¶
Packet Delta Count => packetDeltaCount¶
Minimum One-Way Delay => PathDelayMinDeltaMicroseconds (TBD6)¶
Maximum One-Way Delay => PathDelayMaxDeltaMicroseconds (TBD7)¶
Mean One-Way Delay => PathDelayMeanDeltaMicroseconds (TBD5)¶
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| srhIPv6ActiveSegment = 495 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount = 5 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PathDelayMinDelta.. = TBD6 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PathDelayMaxDelta.. = TBD7 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PathDelayMeanDelta.. = TBD5 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Template Record for 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| srhIPv6ActiveSegment = ... |
| ... |
| ... |
| 2001:db8::4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packetDeltaCount = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDelayMinDeltaMicroseconds = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDelayMaxDeltaMicroseconds = 74 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDelayMeanDeltaMicroseconds = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Data Set Encoding for PathDelayMeanDeltaMicroseconds
¶
With encoding in Figure 3, the mean (average) path delay is calculated on the IPFIX data collection.¶
Ingress interface => ingressInterface¶
Egress interface => egressInterface¶
IPv6 destination address => destinationIPv6Address¶
Active SRv6 Segment => srhIPv6ActiveSegment¶
Packet Delta Count => packetDeltaCount¶
Minimum One-Way Delay => PathDelayMinDeltaMicroseconds (TBD6)¶
Maximum One-Way Delay => PathDelayMaxDeltaMicroseconds (TBD7)¶
Sum of One-Way Delay => PathDelaySumDeltaMicroseconds (TBD8)¶
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| srhIPv6ActiveSegment = 495 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount = 5 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PathDelayMinDelta.. = TBD6 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PathDelayMaxDelta.. = TBD7 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PathDelaySumDelta.. = TBD8 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Template Record for 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 = 60 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface = 271 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv6Address = |
| ... |
| ... |
| 2001:db8::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| srhIPv6ActiveSegment = ... |
| ... |
| ... |
| 2001:db8::4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packetDeltaCount = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDelayMinDeltaMicroseconds = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDelayMaxDeltaMicroseconds = 74 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDelaySumDeltaMicroseconds = 180 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Data Set Encoding for PathDelaySumDeltaMicroseconds
¶