IP Flow Information Export (IPFIX) Alternate-Marking Information Elements
draft-ietf-opsawg-ipfix-alt-mark-07
| Document | Type | Active Internet-Draft (opsawg WG) | |
|---|---|---|---|
| Authors | Thomas Graf , Giuseppe Fioccola , Tianran Zhou , Yongqing Zhu | ||
| Last updated | 2026-07-28 | ||
| Replaces | draft-gfz-opsawg-ipfix-alt-mark | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestone |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-opsawg-ipfix-alt-mark-07
OPSAWG T. Graf
Internet-Draft Swisscom
Intended status: Standards Track G. Fioccola
Expires: 30 January 2027 T. Zhou
Huawei
Y. Zhu
China Telecom
29 July 2026
IP Flow Information Export (IPFIX) Alternate-Marking Information
Elements
draft-ietf-opsawg-ipfix-alt-mark-07
Abstract
This document specifies the IP Flow Information Export (IPFIX)
Information Elements (IEs) to export Alternate Marking measurement
data.
Status of This Memo
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 30 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Graf, et al. Expires 30 January 2027 [Page 1]
Internet-Draft ipfix-alternate-marking July 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. AltMark IPFIX Information Elements . . . . . . . . . . . . . 3
2.1. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 3
2.2. Flow Correlation . . . . . . . . . . . . . . . . . . . . 4
2.3. Flow Measurements . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
3.1. altmarkFlowMonID . . . . . . . . . . . . . . . . . . . . 7
3.2. Loss flag . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Delay flag . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Period Number . . . . . . . . . . . . . . . . . . . . . . 8
4. Operational Considerations . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. AltMark Examples . . . . . . . . . . . . . . . . . . 12
A.1. Loss Measurement Flow Record . . . . . . . . . . . . . . 12
A.2. Delay Measurement Flow Record . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Alternate-Marking Method (AltMark) [RFC9341] [RFC9342] is a technique
used to measure packet loss, delay, and jitter on in-flight packets.
[I-D.ietf-ippm-alt-mark-deployment] provides a framework for
Alternate Marking deployments and includes considerations and
guidance for application and methodology. The IP Flow Information
Export (IPFIX) protocol [RFC7011] [RFC7012] is considered for data
export in Section 6.1 of [I-D.ietf-ippm-alt-mark-deployment].
Graf, et al. Expires 30 January 2027 [Page 2]
Internet-Draft ipfix-alternate-marking July 2026
[RFC7012] defines the data types and management policy for the
information model of the IPFIX protocol [RFC7011]. This document
defines the new IPFIX Information Elements (IEs) for the Alternate
Marking Method.
1.1. Requirements Language
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.
2. AltMark IPFIX Information Elements
This section describes existing Information Elements (IEs)
[IANA-IPFIX] that are relevant for the Alternate Marking application
and also introduces new IEs.
With AltMark [RFC9341] [RFC9342], each node needs to export the
packet counters and timestamps at each period for the monitored flow,
according to AltMark operation. To identify and export telemetry
data for an AltMark monitored flow, it is needed a combination of
already existing IEs and new IEs, which are introduced in this
document. A flow can be identified using IEs such as source address,
destination address, protocol and ports. But, according to [RFC9343]
and its AltMark protocol extensions, it is also necessary to define
new IEs (the flow identifier FlowMonID, the Period Number, the Loss
flag and the Delay flag) to complete the AltMark information to be
exported.
2.1. Flow Aggregation
To use IPFIX for exporting AltMark data, it is necessary to aggregate
AltMark flows, according to Section 5 of [RFC7015]. As mentioned
above, the export of the AltMark data should be realized based on the
fields defined in the specific protocol extension.
Graf, et al. Expires 30 January 2027 [Page 3]
Internet-Draft ipfix-alternate-marking July 2026
For IPv6, the AltMark Extension Header Option, described in
Section 3.1 of [RFC9343], or the Segment Routing Header TLV,
described in Section 3.1 of [RFC9947], contains the FlowMonID, Loss
and Delay flag, that need to be used for data aggregation. The
existing Information Element (IE) that could be employed is
ipPayloadPacketSection(IE314), defined in Section 4.2 of [RFC7133],
because any extension header present is considered part of the
payload. However, ipPayloadPacketSection should be decomposed to
export the relevant data, that need to be extracted, parsed, and
exposed from the ipPayloadPacketSection. For this reason, the use of
the existing IEs is not the best option and, therefore, this document
introduces a better approach by defining new IEs.
New IPFIX Information Elements are needed so that the data can now be
aggregated easily. The new IEs defined in this document are:
altmarkFlowMonID (TBD1), altmarkLossFlag (TBD2) and altmarkDelayFlag
(TBD3). Therefore altmarkFlowMonID, altmarkLossFlag and
altmarkDelayFlag are Flow Key fields for the AltMark flow
aggregation.
2.2. Flow Correlation
The following IPFIX IEs can be used to describe the flow on the
different nodes:
* ingressInterface(IE10)
* egressInterface(IE14)
* sourceIPv4Address(IE8) or sourceIPv6Address(IE27)
* sourceTransportPort(IE7)
* destinationIPv4Address(IE12) or destinationIPv6Address(IE28)
* destinationTransportPort(IE11)
* protocolIdentifier(IE4)
In addition to the existing IEs above, the new IEs defined in this
document are also added for the AltMark monitored flows.
* altmarkFlowMonID (TBD1)
* altmarkLossFlag (TBD2)
* altmarkDelayFlag (TBD3)
Graf, et al. Expires 30 January 2027 [Page 4]
Internet-Draft ipfix-alternate-marking July 2026
Note that, in case of Link Aggregation Group (LAG) interface, the
ingressInterface IE and egressInterface IE can be used to refer the
logical LAG port, while ingressPhysicalInterface IE and
egressPhysicalInterface IE can be used to indicate the physical
interfaces which are members of the LAG port.
2.3. Flow Measurements
[I-D.ietf-ippm-alt-mark-deployment] describes how to manage and
deploy the AltMark method and IPFIX can be used to export the
telemetry data to the Network Management System (NMS).
An Alternate-Marking Domain consists of marking nodes, unmarking
nodes, and transit nodes. These nodes are all IPFIX Observation
Points, while the IPFIX Observation Domain is the AltMark measurement
domain.
As specified in the previous sections, the Flow Keys used to define a
flow are, at minimum, altmarkFlowMonID (TBD1), altmarkLossFlag (TBD2)
and altmarkDelayFlag (TBD3). The traditional '5-tuple' Flow Key of
source and destination IP address, source and destination transport
port, and transport protocol can be selected as additional Flow Keys,
next to the altmarkFlowMonID, altmarkLossFlag and altmarkDelayFlag.
The AltMark Flows are defined separately for loss measurements and
delay measurements. In particular, the flow for loss measurements
can be identified by the altmarkFlowMonID, the altmarkLossFlag (and
potentially the extra Key Fields, if configured); while the flow for
delay measurements can be identified by the altmarkFlowMonID, the
altmarkDelayFlag (and potentially the extra Key Fields, if
configured).
[I-D.ietf-ippm-alt-mark-deployment] also introduces the
altmarkPeriodNumber (TBD4), which is needed for Alternate-Marking
measurement correlation.
The Flow Record, which is observed at each Observation Point,
contains the characteristic properties of the Flow together with the
measured properties (i.e., packet count and timestamps).
Furthermore, as specified in [I-D.ietf-ippm-alt-mark-deployment], the
altmarkPeriodNumber (TBD4) is calculated on each Observation Point as
the modulo of the local time and the interval of the marking time
period. The altmarkPeriodNumber is associated to each Flow Record.
Graf, et al. Expires 30 January 2027 [Page 5]
Internet-Draft ipfix-alternate-marking July 2026
Together with the Key Fields, the Flow Records typically export the
altmarkPeriodNumber and the packetDeltaCount(IE2) for the loss
measurement, while they typically export the altmarkPeriodNumber and
the flowStartMicroseconds(IE154), flowEndMicroseconds(IE155) for the
delay measurements.
The AltMark marking, transit and unmarking nodes can be Exporters and
export the data record. The periodicity or export policy is
configurable and it must be in line with the AltMark period, as
specified in [I-D.ietf-ippm-alt-mark-deployment].
There are two options for the computation:
The NMS acts as Collector. The loss and delay metrics are
computed on the NMS by comparing the packet counts and timestamps
at each AltMark period, according to the AltMark technique
[RFC9341] [RFC9342].
The computation of loss or delay metrics can be done directly on
the node. Indeed, according to [RFC9951], it is possible to
export the delay performance metrics in IPFIX. Therefore,
assuming we have the counter and timestamp information directly on
the node, as enabled by [RFC9947], the delay can be computed on
the router.
To calculate loss, the packet count can be based upon
octetDeltaCount(IE1) or packetDeltaCount(IE2).
To calculate delay, either flowStartSeconds(IE150),
flowStartMilliseconds(IE152), flowStartMicroseconds(IE154) or
flowStartNanoseconds(IE156), can be used depending on timestamp
granularity requirements. It is also possible to use
flowEndSeconds(IE151), flowEndMilliseconds(IE153),
flowEndMicroseconds(IE155) or flowEndNanoseconds(IE157). While, if
the computation is done on the node, pathDelayMeanDeltaMicroseconds
(IE530), pathDelayMinDeltaMicroseconds (IE531),
pathDelayMaxDeltaMicroseconds (IE532), pathDelaySumDeltaMicroseconds
(IE533) can be used to export directly the delay information.
3. IANA Considerations
This document requests IANA to create new elements under the "IPFIX
Information Elements" registry [RFC7012] available at [IANA-IPFIX].
The allocation policy of these new Information Elements is Expert
Review (Section 4.5 of [RFC8126]).
The code points are defined in Table 1.
Graf, et al. Expires 30 January 2027 [Page 6]
Internet-Draft ipfix-alternate-marking July 2026
+------------+---------------------+-------------------------------------+
| Element ID | Name | Reference |
+------------+---------------------+-------------------------------------+
| TBD1 | altmarkFlowMonID | [RFC-to-be], |
| | | RFC9343 |
+------------+---------------------+-------------------------------------+
| TBD2 | altmarkLossFlag | [RFC-to-be], |
| | | RFC9343 |
+------------+---------------------+-------------------------------------+
| TBD3 | altmarkDelayFlag | [RFC-to-be], |
| | | RFC9343 |
+------------+---------------------+-------------------------------------+
| TBD4 | altmarkPeriodNumber | [RFC-to-be], |
| | | [I-D.ietf-ippm-alt-mark-deployment] |
+------------+---------------------+-------------------------------------+
Table 1: "IPFIX Alternate-Marking" Registry
3.1. altmarkFlowMonID
Name: altmarkFlowMonID
Element ID: TBD1
Description: The Flow Monitoring Identification (FlowMonID) is
described in [RFC9343] and identifies the monitored flows with
AltMark. It is 20-bit unsigned integer encoded in the 20 least
significant bits of the 32 bits, while the other bits are set to 0.
As specified in [RFC9343], it can be set pseudo-randomly by the
source node or by a centralized controller. Note that it corresponds
to the flow-mon-id parameter defined in [I-D.ietf-ippm-alt-mark-yang]
and [I-D.ietf-ippm-on-path-telemetry-yang].
Abstract Data Type: unsigned32
Data Type Semantics: identifier
3.2. Loss flag
Name: altmarkLossFlag
Element ID: TBD2
Description: Loss flag (L flag) for Packet Loss Measurement as
described in [RFC9343]. Note that it corresponds to the loss-flag
parameter defined in [I-D.ietf-ippm-on-path-telemetry-yang].
Abstract Data Type: boolean
Graf, et al. Expires 30 January 2027 [Page 7]
Internet-Draft ipfix-alternate-marking July 2026
Data Type Semantics: default
3.3. Delay flag
Name: altmarkDelayFlag
Element ID: TBD3
Description: Delay flag (D flag) for Single Packet Delay Measurement
as described in [RFC9343]. Note that it corresponds to the delay-
flag parameter defined in [I-D.ietf-ippm-on-path-telemetry-yang].
Abstract Data Type: boolean
Data Type Semantics: default
3.4. Period Number
Name: altmarkPeriodNumber
Element ID: TBD4
Description: The Period Number (PN), described in
[I-D.ietf-ippm-alt-mark-deployment], is used to help to determine the
packet counts related to the same block of markers, or the timestamps
related to the same marked packet. The PN is associated with each
packet count and timestamp reported. It is calculated as the modulo
of the local time and the interval of the marking time period. Note
that it corresponds to the measurement-period-number parameter
defined in [I-D.ietf-ippm-on-path-telemetry-yang].
Abstract Data Type: unsigned32
Data Type Semantics: identifier
4. Operational Considerations
The operational and management considerations for the Alternate
Marking Method are covered in [I-D.ietf-ippm-alt-mark-deployment],
Alternate Marking [RFC9341] and Multipoint Alternate Marking
[RFC9342].
Graf, et al. Expires 30 January 2027 [Page 8]
Internet-Draft ipfix-alternate-marking July 2026
There are specific considerations to do with regard to the IPFIX
exporting. The export interval and the marking period must be
aligned and the exporting should be done in the middle of the period,
as described in Alternate Marking [RFC9341]. Also, in case of missed
exports the corresponding interval is not considered for the
measurement. While, if the AltMark period changes, the export
interval must be modified accordingly.
Further details about the method operation are specified for the
different extensions: IPv6 [RFC9343], SRH [RFC9947], and MPLS
[RFC9714].
5. Security Considerations
Alternate Marking [RFC9341] and Multipoint Alternate Marking
[RFC9342] analyze different security concerns and related solutions.
These aspects are valid and applicable also to this document. In
particular the fundamental security requirement is that Alternate
Marking MUST only be applied in a specific limited domain, as also
mentioned in [RFC8799].
There are no additional security considerations regarding allocation
of these new IPFIX IEs compared to [RFC7012]. The IEs described in
this document export AltMark telemetry data. Applications and
operators using the IEs described in this document must evaluate the
sensitivity of this information in their implementation context and
apply the storage guidance in Section 11.8 of [RFC7011] as
appropriate.
6. Acknowledgements
The authors of this document would like to thank Greg Mirsky, Alex
Huang Feng, Mohamed Boucadair, Benoit Claise for their comments and
reviews.
7. Contributors
Mauro Cociglio
Email: mauro.cociglio@outlook.com
Fabio Bulgarella
Telecom Italia
Email: fabio.bulgarella@guest.telecomitalia.it
Massimo Nilo
FiberCop
Graf, et al. Expires 30 January 2027 [Page 9]
Internet-Draft ipfix-alternate-marking July 2026
Email: massimo.nilo@fibercop.com
Fabrizio Milan
FiberCop
Email: fabrizio.milan@fibercop.com
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013,
<https://www.rfc-editor.org/info/rfc7012>.
[RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
for the IP Flow Information Export (IPFIX) Protocol",
RFC 7015, DOI 10.17487/RFC7015, September 2013,
<https://www.rfc-editor.org/info/rfc7015>.
[RFC7133] Kashima, S., Kobayashi, A., Ed., and P. Aitken,
"Information Elements for Data Link Layer Traffic
Measurement", RFC 7133, DOI 10.17487/RFC7133, May 2014,
<https://www.rfc-editor.org/info/rfc7133>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
Graf, et al. Expires 30 January 2027 [Page 10]
Internet-Draft ipfix-alternate-marking July 2026
[RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
DOI 10.17487/RFC9342, December 2022,
<https://www.rfc-editor.org/info/rfc9342>.
[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/info/rfc9343>.
[RFC9714] Cheng, W., Ed., Min, X., Ed., Zhou, T., Dai, J., and Y.
Peleg, "Encapsulation for MPLS Performance Measurement
with the Alternate-Marking Method", RFC 9714,
DOI 10.17487/RFC9714, February 2025,
<https://www.rfc-editor.org/info/rfc9714>.
8.2. Informative References
[I-D.ietf-ippm-alt-mark-deployment]
Fioccola, G., Zhu, K., Graf, T., Zhang, L., and M. Nilo,
"Alternate Marking Deployment Framework", Work in
Progress, Internet-Draft, draft-ietf-ippm-alt-mark-
deployment-07, 3 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
alt-mark-deployment-07>.
[I-D.ietf-ippm-alt-mark-yang]
Graf, T., Wang, M., Fioccola, G., Zhou, T., and X. Min, "A
YANG Data Model for the Alternate Marking Method", Work in
Progress, Internet-Draft, draft-ietf-ippm-alt-mark-yang-
05, 11 June 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-ippm-alt-mark-yang-05>.
[I-D.ietf-ippm-on-path-telemetry-yang]
Fioccola, G., Zhou, T., Zhu, Y., Zhang, W., and K. Zhu,
"On-Path Telemetry YANG Data Model", Work in Progress,
Internet-Draft, draft-ietf-ippm-on-path-telemetry-yang-04,
3 July 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-ippm-on-path-telemetry-yang-04>.
[IANA-IPFIX]
"IANA, IPFIX",
<https://www.iana.org/assignments/ipfix/ipfix.xhtml>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Graf, et al. Expires 30 January 2027 [Page 11]
Internet-Draft ipfix-alternate-marking July 2026
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC9947] Fioccola, G., Zhou, T., Mishra, G., Wang, X., Zhang, G.,
and M. Cociglio, "Application of the Alternate-Marking
Method to the Segment Routing Header", RFC 9947,
DOI 10.17487/RFC9947, March 2026,
<https://www.rfc-editor.org/info/rfc9947>.
[RFC9951] Graf, T., Claise, B., and A. Huang-Feng, "Export of Delay
Performance Metrics in IP Flow Information Export
(IPFIX)", RFC 9951, DOI 10.17487/RFC9951, April 2026,
<https://www.rfc-editor.org/info/rfc9951>.
Appendix A. AltMark Examples
This appendix represents two different examples for the loss and
delay measurements.
A.1. Loss Measurement Flow Record
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| sourceIPv6Address = 27 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv6Address = 28 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| altmarkFlowMonID = TBD1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| altmarkLossFlag = TBD2 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| altmarkPeriodNumber = TBD4 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount = 2 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Template Record for Loss Measurements
A.2. Delay Measurement Flow Record
Graf, et al. Expires 30 January 2027 [Page 12]
Internet-Draft ipfix-alternate-marking July 2026
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| sourceIPv6Address = 27 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv6Address = 28 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| altmarkFlowMonID = TBD1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| altmarkDelayFlag = TBD3 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartMicroseconds = 154 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Template Record for Delay Measurements
Authors' Addresses
Thomas Graf
Swisscom
Binzring 17
CH-8045 Zurich
Switzerland
Email: thomas.graf@swisscom.com
Giuseppe Fioccola
Huawei
Viale Martesana, 12
20055 Vimodrone (Milan)
Italy
Email: giuseppe.fioccola@huawei.com
Tianran Zhou
Huawei
156 Beiqing Rd.
Beijing
100095
China
Email: zhoutianran@huawei.com
Graf, et al. Expires 30 January 2027 [Page 13]
Internet-Draft ipfix-alternate-marking July 2026
Yongqing Zhu
China Telecom
China
Email: zhuyq8@chinatelecom.cn
Graf, et al. Expires 30 January 2027 [Page 14]