OPSAWG X. Song Internet-Draft ZTE Corp. Intended status: Standards Track S. Moeller Expires: 3 May 2027 Independent Y. Liu ZTE Corp. J. Newton Vodafone J. Livingood Independent 30 October 2026 Export of ECN Information in IPFIX draft-ietf-opsawg-ipfix-ecn-01 Abstract This document defines a set of IPFIX Information Elements for monitoring Explicit Congestion Notification (ECN). These Information Elements allow network operators to observe ECN codepoint usage across network traffic and evaluate the corresponding traffic performance. 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 3 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Song, et al. Expires 3 May 2027 [Page 1] Internet-Draft ECN Export in IPFIX October 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. Overview of ECN Format . . . . . . . . . . . . . . . . . . . 4 3.1. IP ECN . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. MPLS ECN . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. MPLS EXP Encoding . . . . . . . . . . . . . . . . . . 5 3.2.2. MPLS Network Actions (MNA) Encoding . . . . . . . . . 5 4. IPFIX Information Elements for ECN Monitoring . . . . . . . . 5 4.1. ipEcn . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. mplsEcn . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. mplsMnaEcn . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. notEctPacketDeltaCount . . . . . . . . . . . . . . . . . 8 4.5. notEctPacketTotalCount . . . . . . . . . . . . . . . . . 9 4.6. ect0PacketDeltaCount . . . . . . . . . . . . . . . . . . 9 4.7. ect0PacketTotalCount . . . . . . . . . . . . . . . . . . 9 4.8. ect1PacketDeltaCount . . . . . . . . . . . . . . . . . . 10 4.9. ect1PacketTotalCount . . . . . . . . . . . . . . . . . . 10 4.10. cePacketDeltaCount . . . . . . . . . . . . . . . . . . . 11 4.11. cePacketTotalCount . . . . . . . . . . . . . . . . . . . 11 5. Operational Considerations . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. IPFIX ECN Encoding Examples . . . . . . . . . . . . 17 A.1. ipEcn as Flow Key . . . . . . . . . . . . . . . . . . . . 17 A.2. ECN Counters IEs without Flow-Key Splitting . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Song, et al. Expires 3 May 2027 [Page 2] Internet-Draft ECN Export in IPFIX October 2026 1. Introduction Explicit Congestion Notification (ECN) [RFC3168] 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 [RFC5129], networks can improve congestion control efficiency and reduce latency. IP Flow Information Export (IPFIX) [RFC7011] 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. The Information Elements defined in this document are applicable to classical ECN deployments ([RFC3168]) as well as newer services (e.g., [RFC9331]). This document specifies eleven IPFIX Information Elements (IEs) [RFC7012] to export ECN information. 2. Terminology 2.1. Terms Used in This Document This document makes use of the terms defined in [RFC3168], [RFC9331], [RFC9330] and [RFC7011]. IPFIX: IP Flow Information Export IPFIX Information Elements Observation Point ECN: Explicit Congestion Notification ECT: ECN-capable Transport Not-ECT: Not ECN-capable transport CE: Congestion Experienced L4S: Low Latency, Low Loss, and Scalable throughput (L4S) service Song, et al. Expires 3 May 2027 [Page 3] Internet-Draft ECN Export in IPFIX October 2026 2.2. 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. 3. Overview of ECN Format This section describes the ECN field formats in IP headers (IPv4 and IPv6) and in MPLS label headers. 3.1. 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 [RFC791], which has been superseded by the six-bit DS Field [RFC2474], [RFC2780]. In IPv6, the DS field occupies the Traffic Class byte. Bits 6 and 7 are listed in [RFC2474] as Currently Unused, and are specified in [RFC2780] as approved for experimental use for ECN. The ECN field format is identical in both IPv4 and IPv6, as illustrated below: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DS Field, DSCP | ECN Field | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 1: ECN Field in IP Header ECN Codepoint values: - 00: Not ECT - 01: ECT(1) - 10: ECT(0) - 11: CE Song, et al. Expires 3 May 2027 [Page 4] Internet-Draft ECN Export in IPFIX October 2026 The ECT(0) and ECT(1) codepoints indicate ECN-capable transport, as defined in [RFC3168]. In addition, [RFC9331] specifies that ECT(1) is used to identify L4S-capable traffic, while ECT(0) is used to identify classical ECN-capable traffic. 3.2. MPLS ECN Two mechanisms exist for carrying ECN information in MPLS networks. 3.2.1. MPLS EXP Encoding [RFC5129] 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. 3.2.2. MPLS Network Actions (MNA) Encoding [I-D.halmir-mpls-ecn] 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. 4. IPFIX Information Elements for ECN Monitoring This Section defines the Information Elements for ECN. These Information Elements allow network operators to have network visibility to ECN marking and evaluate the traffic performance. 4.1. 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. The Information Element encodes only these 2 bits. Therefore, its value may range from 0 to 3. Song, et al. Expires 3 May 2027 [Page 5] Internet-Draft ECN Export in IPFIX October 2026 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 when ipClassOfService IE is used as Flow Key, 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 ECN monitoring deployments. Data Type: unsigned8 Data Type Semantics: identifier Range: 0-3 Additional Information: See [RFC3168] for ECN field definition. See [RFC9331] for the use of the ECT(1) codepoint to identify L4S- capable traffic. Reference: [RFC3168], [RFC9331], this document. 4.2. 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 [RFC5129]. Song, et al. Expires 3 May 2027 [Page 6] Internet-Draft ECN Export in IPFIX October 2026 [RFC5129] 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) (which may identify 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 Collector MUST apply domain-specific mapping knowledge to interpret the exported values as ECN codepoints. Specifically, this document applies the local two-bit TC mapping policy to the mplsEcn field. The PHB-specific congestion-marking scheme defined in [RFC5129] distinguishes only two states: Not-CM (Not Congestion Marked) and CM (Congestion Marked). Upon label push, Not-ECT, ECT(0), and ECT(1) packets are all mapped to Not-CM, whereas only CE packets are mapped to CM; consequently, this PHB-specific ECN mapping cannot identify ECT(1) traffic. In the absence of the local two-bit ECN mapping policy, the exporter can utilize mplsTopLabelExp (IE 203) in conjunction with domain mapping. Data Type: unsigned8 Data Type Semantics: identifier Range: 0-3 Additional Information: See [RFC5129] for the ECN propagation in MPLS. Note that [RFC5129] 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: [RFC5129], [RFC3032], this document. 4.3. 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 [I-D.halmir-mpls-ecn]. Song, et al. Expires 3 May 2027 [Page 7] Internet-Draft ECN Export in IPFIX October 2026 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 Data Type: unsigned8 Data Type Semantics: identifier Range: 0-3 Reference: [I-D.halmir-mpls-ecn], this document. 4.4. 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). Units: packet Data Type: unsigned64 Data Type Semantics: deltaCounter Additional Information: Refer to [RFC3168]. Reference: [RFC3168], this document. Song, et al. Expires 3 May 2027 [Page 8] Internet-Draft ECN Export in IPFIX October 2026 4.5. 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. Units: packet Data Type: unsigned64 Data Type Semantics: totalCounter Additional Information: Refer to [RFC3168]. Reference: [RFC3168], this document. 4.6. 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). Units: packet Data Type: unsigned64 Data Type Semantics: deltaCounter Additional Information: Refer to [RFC3168]. Reference: [RFC3168], this document. 4.7. 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. Song, et al. Expires 3 May 2027 [Page 9] Internet-Draft ECN Export in IPFIX October 2026 Units: packet Data Type: unsigned64 Data Type Semantics: totalCounter Additional Information: Refer to [RFC3168]. Reference: [RFC3168], this document. 4.8. 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). Units: packet Data Type: unsigned64 Data Type Semantics: deltaCounter Additional Information: Refer to [RFC3168]. Reference: [RFC3168], this document. 4.9. 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. Units: packet Data Type: unsigned64 Data Type Semantics: totalCounter Additional Information: Refer to [RFC3168]. Reference: [RFC3168], this document. Song, et al. Expires 3 May 2027 [Page 10] Internet-Draft ECN Export in IPFIX October 2026 4.10. 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). Units: packet Data Type: unsigned64 Data Type Semantics: deltaCounter Additional Information: Refer to [RFC3168]. Reference: [RFC3168], this document. 4.11. 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. Units: packet Data Type: unsigned64 Data Type Semantics: totalCounter Additional Information: Refer to [RFC3168]. Reference: [RFC3168], this document. 5. 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 Song, et al. Expires 3 May 2027 [Page 11] Internet-Draft ECN Export in IPFIX October 2026 capability. For cumulative statistics IEs, the statistical data may be processed with a higher priority at traffic aggregation or egress nodes. The CE marking may be either probabilistic or deterministic, as determined by the specific AQM implementation. The IEs for the statistical count of CE-mark packets enable operators to perform quantitative monitoring and management of congestion signaling and traffic performance, typically based on flow data that may be acquired via packet (see [RFC5476], [RFC5477]) or flow sampling (see [RFC7014]). Implementations SHOULD employ sampling methods (see [RFC5475]) 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 [RFC5129]. 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 [I-D.halmir-mpls-ecn]. 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., 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 rather than aggregated indiscriminately, ensuring that ECN congestion signals of different ECN origions are distinguished. The calculation strategy is out of the scope of this document. 6. Security Considerations The security considerations for IPFIX [RFC7011] 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 [RFC7011]. Song, et al. Expires 3 May 2027 [Page 12] Internet-Draft ECN Export in IPFIX October 2026 While individual ECN codepoints may not be sensitive in isolation, aggregated flow records can disclose: traffic patterns or user behavior. In deployments where specific semantics are assigned to ECN codepoints, such markings may reveal potential service types, for example, where ECT(1) indicates L4S-capable applications, it may reveal usage of services 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. 7. 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 [IANA-IPFIX]. Song, et al. Expires 3 May 2027 [Page 13] Internet-Draft ECN Export in IPFIX October 2026 +============+========================+=================+ | 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 | +------------+------------------------+-----------------+ Table 1: New IPFIX Information Elements 8. Acknowledgements The authors would like to acknowledge Greg Mirsky, Gorry Fairhurst, Joel Halpern, Sebastian Moeller, Ingemar Johansson, Benoit Claise, Zahed Sarker, Paul Aitken, Koen De Schepper, Djamel Sadok, for reviewing this document and providing their helpful comments. The authors would also like to acknowledge Saumya Dikshit, Libin Liu, Changwang Lin, Aditya Dogra for their review and comments during WG adoption call. Song, et al. Expires 3 May 2027 [Page 14] Internet-Draft ECN Export in IPFIX October 2026 9. References 9.1. Normative References [I-D.halmir-mpls-ecn] Halpern, J. M. and G. Mirsky, "Explicit Congestion Notification Using MPLS Network Actions", Work in Progress, Internet-Draft, draft-halmir-mpls-ecn-04, 6 July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [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, . [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [IANA-IPFIX] "IANA, "IP Flow Information Export (IPFIX) Entities"", . [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC791, September 1981, . Song, et al. Expires 3 May 2027 [Page 15] Internet-Draft ECN Export in IPFIX October 2026 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, . [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, . [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, DOI 10.17487/RFC5476, March 2009, . [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, DOI 10.17487/RFC5477, March 2009, . [RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, September 2013, . [RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, January 2023, . Song, et al. Expires 3 May 2027 [Page 16] Internet-Draft ECN Export in IPFIX October 2026 [RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9331, DOI 10.17487/RFC9331, January 2023, . Appendix A. IPFIX ECN Encoding Examples A.1. ipEcn as Flow Key With encoding in Figure 1, the example is represented with the following IEs, where "=>" is used to indicate which IE is mapped to given information. Source IP => sourceIPv4Address (8) Destination IP => destinationIPv4Address (12) Ingress interface => ingressInterface (10) ECN codepoint as Flow Key => ipEcn (TBD1) Per-codepoint packet/octet counts => packetDeltaCount (2), octetDeltaCount (1) Flow duration => flowStartMilliseconds (152), flowEndMilliseconds (153) Song, et al. Expires 3 May 2027 [Page 17] Internet-Draft ECN Export in IPFIX October 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 = 256 | Field Count = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address = 12 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ingressInterface = 10 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ipEcn = TBD1 | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| packetDeltaCount = 2 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| octetDeltaCount = 1 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| flowStartMilliseconds = 152 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| flowEndMilliseconds = 153 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Template Record with ipEcn as Flow Key In this example, the Template ID is 256, which will be used in the Data Record. Because ipEcn is a Flow Key, the observed flow is split into up to four Flow Records, one per observed ECN codepoint; the ECN-specific counter IEs (Section 4.4-4.11) are therefore not needed in this Template, as each record's codepoint is carried by the ipEcn key itself.In this example, the Template ID is 256, which will be used in the Data Record. Because ipEcn is a Flow Key, the observed flow is split into up to four Flow Records, one per observed ECN codepoint; the ECN-specific counter IEs (Section 4.4-4.11) are therefore not needed in this Template, as each record's codepoint is carried by the ipEcn key itself. A.2. ECN Counters IEs without Flow-Key Splitting With encoding in Figure 3, the same flow is monitored without splitting it by codepoint: Source IP => sourceIPv4Address (8) Destination IP => destinationIPv4Address (12) Song, et al. Expires 3 May 2027 [Page 18] Internet-Draft ECN Export in IPFIX October 2026 Ingress interface => ingressInterface (10) Per-codepoint packet counters => notEctPacketDeltaCount (TBD4), ect0PacketDeltaCount (TBD6), ect1PacketDeltaCount (TBD8), cePacketDeltaCount (TBD10) 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 = 36 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 257 | Field Count = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address = 12 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ingressInterface = 10 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| notEctPacketDeltaCount=TBD4 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ect0PacketDeltaCount=TBD6 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ect1PacketDeltaCount=TBD8 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| cePacketDeltaCount=TBD10 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Template Record with ECN Counter Information Elements Note the trade-off between the two encodings: Template 256 preserves byte-level visibility per codepoint via octetDeltaCount but multiplies the number of Flow Records by up to 4; Template 257 keeps one record per flow at the cost of losing per-codepoint octet counts. Authors' Addresses Xueyan Song ZTE Corp. Email: song.xueyan2@zte.com.cn Sebastian Moeller Independent Email: moeller0=40gmx.de@dmarc.ietf.org Song, et al. Expires 3 May 2027 [Page 19] Internet-Draft ECN Export in IPFIX October 2026 Yao Liu ZTE Corp. Email: liu.yao71@zte.com.cn Jonathan Newton Vodafone Email: jonathan.newton@vodafone.com Jason Livingood Independent Email: jason@thelivingoods.com Song, et al. Expires 3 May 2027 [Page 20]