Export of ECN Information in IPFIX

Introduction Explicit Congestion Notification (ECN) allows network devices to signal congestion to endpoints without dropping packets. By marking the ECN field in IP headers (IPv4 and IPv6) or MPLS headers , networks can improve congestion control efficiency and reduce latency. IP Flow Information Export (IPFIX) provides a standard protocol for exporting flow information from network devices. This document defines a set of IPFIX Information Elements for monitoring ECN usage and performance across network traffic. These elements enable network operators to observe ECN codepoint distributions, detect congestion events, and analyze ECN deployment status. A key application of these Information Elements is the monitoring of the Low Latency, Low Loss, and Scalable throughput (L4S) service . L4S uses the ECT(1) codepoint to identify scalable congestion-controlled traffic and relies on accurate ECN signaling for its performance. The ECN statistics exported via these Information Elements are useful for L4S deployment, allowing operators to gather data to examine performance and identify nodes where remediation may be necessary. This document specifies eleven IPFIX Information Elements (IEs) to export ECN information.

Terminology

Terms Used in This Document This document makes use of the terms defined in , and . IPFIX: IP Flow Information Export IPFIX Information Elements Observation Point L4S: Low Latency, Low Loss, and Scalable throughput (L4S) service ECN: Explicit Congestion Notification ECT: ECN-capable Transport Not-ECT: Not ECN-capable transport CE: Congestion Experienced

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 when, and only when, they appear in all capitals, as shown here.

Overview of ECN Format This section describes the ECN field formats in IP headers (IPv4 and IPv6) and in MPLS label headers.

IP ECN For both IPv4 and IPv6 packets, the ECN field is located in bits 6 to 7 of the Differentiated Services (DS) field. In IPv4, the DS field occupies the Type of Service (TOS) byte , which has been superseded by the six-bit DS Field , . In IPv6, the DS field occupies the Traffic Class byte. Bits 6 and 7 are listed in as Currently Unused, and are specified in as approved for experimental use for ECN. The ECN field format is identical in both IPv4 and IPv6, as illustrated below:

ECN Field in IP Header ECN Codepoint values: - 00: Not ECT - 01: ECT(1) - 10: ECT(0) - 11: CE specifies that ECT(1) is used to identify L4S-capable traffic. ECT(0) is used to identify classical traffic.

MPLS ECN Two mechanisms exist for carrying ECN information in MPLS networks.

MPLS EXP Encoding defines a framework for propagating ECN information using the MPLS Experimental (EXP) field in the MPLS label entry. The mapping between EXP values and ECN codepoints is domain-specific and operator-configured. See Section 4.2 for the corresponding IPFIX IE.

MPLS Network Actions (MNA) Encoding defines an alternative mechanism using MPLS Network Actions (MNA) to carry ECN information in a dedicated Sub-stack, independent of the EXP field. This preserves EXP bits for QoS differentiation while enabling standardized ECN propagation. See Section 4.3 for the corresponding IPFIX IE.

IPFIX Information Elements for ECN Monitoring This Section defines the Information Elements for ECN. Specifically, in the context of L4S service, these Information Elements allow network operators to have network visibility to ECN marking and evaluate the traffic performance.

ipEcn

Name:: ipEcn
ElementID:: TBD1
Description:: This Information Element is used for capturing the complete ECN state of each packet, enabling detailed analysis of congestion notification. The ECN field format is introduced in Section 3.1 of this document. L4S traffic is identified by the ECT(1) codepoint as specified in . The Information Element encodes only these 2 bits. Therefore, its value may range from 0 to 3. This Information Element is protocol-agnostic and applies to both IPv4 and IPv6 packets, consistent with the design of ipClassOfService (IE ID 5) and ipDiffServCodePoint (IE ID 195). The IP protocol version can be determined from the ipVersion Information Element (IE ID 60) if needed. Reusing the existing information element ipClassOfService (IE ID: 5), which exports the 8 bits of the IPv4 ToS or IPv6 Traffic Class field, and then extracting bits 6 and 7 for ECN information, is technically feasible but complex: the observed flows may be split into up to 64 distinct flows due to DSCP differences, whereas Collectors might have a range limit (e.g., 5 to 10). Implementations MAY still derive ECN from ipClassOfService despite these limitations if the dedicated ipEcn IE is not available. In this case, it is only suitable for small-scale ECN information monitoring or experimental L4S deployments.
Abstract Data Type:: unsigned8
Data Type Semantics:: identifier
Additional Information:: See and for ECN field definition.
Reference:: , , this document.

mplsEcn

Name:: mplsEcn
ElementID:: TBD2
Description:: This Information Element captures the ECN-specific semantics from the MPLS Experimental (EXP) field. The EXP field is a 3-bit field in the MPLS label entry that MAY be used to carry ECN information within the MPLS domain, as defined in . does not specify a standardized mapping between EXP values and ECN codepoints. The interpretation is domain-specific. In deployments where the operator has configured ECN propagation using the least significant 2 bits of the EXP field, this Information Element exports those 2 bits (values 0-3). However, the semantic meaning of each value, including which value corresponds to ECT(1) and thus identifies L4S-capable traffic, depends on the MPLS domain's configured policy. It is noted that the information extraction of this Information Element is only used when the MPLS domain has ECN support. The EXP field information is only extracted from the outermost layer of MPLS labels. The Collector MUST apply domain-specific mapping knowledge to interpret the exported values as ECN codepoints. This Information Element is semantically related to mplsTopLabelExp (IE ID 203), which encodes the full 3-bit EXP field. While mplsTopLabelExp captures the generic EXP value, mplsEcn specifically exports the bits designated for ECN semantics within that domain's policy. Implementations MAY derive mplsEcn from mplsTopLabelExp by extracting the appropriate bits when the MPLS domain's ECN mapping policy is known.
Abstract Data Type:: unsigned8
Data Type Semantics:: identifier
Additional Information:: See for the ECN propagation in MPLS. Note that defines multiple propagation models (Uniform, Pipe, Short Pipe) and does not mandate a specific EXP-to-ECN bit mapping. Operators MUST configure and document their domain-specific mapping for Collector-side interpretation.
Reference:: , , this document.

mplsMnaEcn

Name:: mplsMnaEcn
ElementID:: TBD3
Description:: This Information Element captures the ECN field from an MPLS Network Action (MNA) Sub-stack carrying ECN information, as defined in . The MNA ECN mechanism uses a dedicated Opcode (including ISD and PSD option) to carry a 2-bit ECN value independently of the MPLS TC (i.e., EXP) field. This allows ECN propagation without consuming EXP bits that may be used for QoS marking. This Information Element is applicable when the MPLS domain has been configured to use MNA for ECN propagation. Implementations MUST identify the MNA ECN Opcode in the label stack and extract the corresponding 2-bit ECN value. Once IANA assigns the ECN MNA Opcodes, this document will be updated to include the specific values. The ECN field values are semantically equivalent to IP ECN: - 00: Not ECT - 01: ECT(1) - 10: ECT(0) - 11: CE
Abstract Data Type:: unsigned8
Data Type Semantics:: identifier
Reference:: , this document.

notEctPacketDeltaCount

Name:: notEctPacketDeltaCount
ElementID:: TBD4
Description:: The number of packets since the previous report (if any) in this Flow with ECN codepoint set to Not-ECT (binary 00).
Abstract Data Type:: unsigned64
Data Type Semantics:: deltaCounter
Additional Information:: Refer to .
Reference:: , , this document.

notEctPacketTotalCount

Name:: notEctPacketTotalCount
ElementID:: TBD5
Description:: The total number of packets of this Flow with ECN codepoint set to Not-ECT at the Observation Point since the Metering Process (re-)initialization for this Observation Point.
Abstract Data Type:: unsigned64
Data Type Semantics:: totalCounter
Additional Information:: Refer to .
Reference:: , , this document.

ect0PacketDeltaCount

Name:: ect0PacketDeltaCount
ElementID:: TBD6
Description:: The number of packets since the previous report (if any) in this Flow with ECN codepoint set to ECT(0) (binary 10).
Abstract Data Type:: unsigned64
Data Type Semantics:: deltaCounter
Additional Information:: Refer to .
Reference:: , , this document.

ect0PacketTotalCount

Name:: ect0PacketTotalCount
ElementID:: TBD7
Description:: The total number of packets of this Flow with ECN codepoint set to ECT(0) at the Observation Point since the Metering Process (re-)initialization for this Observation Point.
Abstract Data Type:: unsigned64
Data Type Semantics:: totalCounter
Additional Information:: Refer to .
Reference:: , , this document.

ect1PacketDeltaCount

Name:: ect1PacketDeltaCount
ElementID:: TBD8
Description:: The number of packets since the previous report (if any) in this Flow with ECN codepoint set to ECT(1) (binary 01).
Abstract Data Type:: unsigned64
Data Type Semantics:: deltaCounter
Additional Information:: Refer to .
Reference:: , , this document.

ect1PacketTotalCount

Name:: ect1PacketTotalCount
ElementID:: TBD9
Description:: The total number of packets of this Flow with ECN codepoint set to ECT(1) at the Observation Point since the Metering Process (re-)initialization for this Observation Point.
Abstract Data Type:: unsigned64
Data Type Semantics:: totalCounter
Additional Information:: Refer to .
Reference:: , , this document.

cePacketDeltaCount

Name:: cePacketDeltaCount
ElementID:: TBD10
Description:: The number of packets since the previous report (if any) in this Flow with ECN codepoint set to CE (Congestion Experienced, binary 11).
Abstract Data Type:: unsigned64
Data Type Semantics:: deltaCounter
Additional Information:: Refer to .
Reference:: , , this document.

cePacketTotalCount

Name:: cePacketTotalCount
ElementID:: TBD11
Description:: The total number of packets of this Flow with ECN codepoint set to CE at the Observation Point since the Metering Process (re-)initialization for this Observation Point.
Abstract Data Type:: unsigned64
Data Type Semantics:: totalCounter
Additional Information:: Refer to .
Reference:: , , this document.

Operational Considerations The IPFIX IEs defined in this document may have their information extraction positions adjusted based on different ECN monitoring purposes in the network. Among them, the basic ECN field elements are used to reflect the ECN codepoints carried in the IPv4 header, the IPv6 header, or the MPLS header. These fields can be flexibly extracted at any node along the path that has IPFIX export capability. For cumulative statistics IEs, the statistical data may be processed with a higher priority at traffic aggregation or egress nodes. In L4S deployments, CE marking may be either probabilistic or deterministic, as determined by the specific AQM implementation. The IEs on the statistical count of CE-mark packets are defined to enable operators to perform quantitative monitoring and management of L4S service performance, typically based on flow data that may be acquired via packet or flow sampling. Implementations SHOULD employ sampling methods (see ) that preserve the statistical representativeness of these IEs and reduce bias risk of sampling results. MPLS networks support two mechanisms for ECN propagation as introduced in Section 3.2.1 and Section 3.2.2. The IPFIX Information Element exported MUST correspond to the mechanism deployed in the MPLS domain. mplsEcn is used when the MPLS domain propagates ECN information via the EXP field, per . In this mode, the mapping between EXP values and ECN codepoints is domain-specific. As an alternative, mplsTopLabelExp (IE ID 203) MAY be used to export the raw 3-bit EXP value, with ECN interpretation performed at the Collector. mplsMnaEcn is used when the MPLS domain propagates ECN information via MPLS Network Actions (MNA), per . In this mode, ECN information is carried in a dedicated MNA Sub-stack identified by an Opcode. No domain-specific mapping is required at the Collector. The calculation of derived metrics (e.g., L4S CE marking ratios) from the base counters defined in Section 4 of this document is an implementation issue for the IPFIX Collector. Operators can utilize the per-flow counts such as ect1PacketTotalCount and cePacketTotalCount for such purposes, provided that CE-marked packets are attributed to their original ECT codepoint (e.g., ECT(1) for L4S) rather than aggregated indiscriminately, ensuring L4S and Classic ECN congestion signals are distinguished. The calculation strategy is out of the scope of this document.

Security Considerations The security considerations for IPFIX apply to this document. The elements for ECN reveal information about endpoint ECN capabilities. Although the information may generally be not sensitive, operators SHOULD consider applicable privacy regulations. IPFIX records containing L4S monitoring information SHOULD be transported using secure protocols such as TLS or DTLS and satisfy the mutual authentication between IPFIX Exporting Processes and IPFIX Collecting Processes as specified in . While individual ECN codepoints may not be sensitive in isolation, aggregated flow records can disclose: traffic patterns or user behavior. ECT(1) marking may indicate L4S-capable applications, potentially service types, such as interactive video conferencing, cloud gaming or real-time service. Long-term collection of per-flow ECN statistics may enable correlation with user activity patterns, raising considerations under privacy regulations. Network operators are expected to implement some policies such as access control, anonymizing or aggregating ECN statistics to prevent endpoint identification.

IANA Considerations IANA is requested to allocate the following new IEs to the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group . New IPFIX Information Elements

Element ID	Name	Reference
TBD1	ipEcn	Section 4.1 of this document
TBD2	mplsEcn	Section 4.2 of this document
TBD3	mplsMnaEcn	Section 4.3 of this document
TBD4	notEctPacketDeltaCount	Section 4.4 of this document
TBD5	notEctPacketTotalCount	Section 4.5 of this document
TBD6	ect0PacketDeltaCount	Section 4.6 of this document
TBD7	ect0PacketTotalCount	Section 4.7 of this document
TBD8	ect1PacketDeltaCount	Section 4.8 of this document
TBD9	ect1PacketTotalCount	Section 4.9 of this document
TBD10	cePacketDeltaCount	Section 4.10 of this document
TBD11	cePacketTotalCount	Section 4.11 of this document

Acknowledgements The authors would like to acknowledge Greg Mirsky, Gorry Fairhurst, Joel Halpern, Sebastian Moeller, Ingemar Johansson, Benoit Claise, Zahed Sarker, Paul Aitken for reviewing this document and providing their helpful comments.