Skip to main content

Export of ECN Information in IPFIX
draft-song-opsawg-ipfix-ecn-03

Document Type Active Internet-Draft (candidate for opsawg WG)
Authors Xueyan Song , Yao Liu , Jonathan Newton , Jason Livingood
Last updated 2026-09-12 (Latest revision 2026-07-19)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state Call For Adoption By WG Issued
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-song-opsawg-ipfix-ecn-03
OPSAWG                                                           X. Song
Internet-Draft                                                    Y. Liu
Intended status: Standards Track                               ZTE Corp.
Expires: 20 January 2027                                       J. Newton
                                                                Vodafone
                                                            J. Livingood
                                                                 Comcast
                                                            19 July 2026

                   Export of ECN Information in IPFIX
                     draft-song-opsawg-ipfix-ecn-03

Abstract

   This document defines a set of IPFIX Information Elements for
   monitoring Explicit Congestion Notification (ECN), specifically in
   the context of the Low Latency, Low Loss, and Scalable Throughput
   (L4S) service.  These Information Elements allow network operators to
   observe ECN codepoint usage within L4S deployments 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 20 January 2027.

Copyright Notice

   Copyright (c) 2026 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

Song, et al.             Expires 20 January 2027                [Page 1]
Internet-Draft             ECN Export in IPFIX                 July 2026

   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terms Used in This Document . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Overview of ECN Format  . . . . . . . . . . . . . . . . . . .   4
     3.1.  IP ECN  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  MPLS ECN  . . . . . . . . . . . . . . . . . . . . . . . .   4
       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  . . . . . . . . . . . . . . . . .   8
     4.6.  ect0PacketDeltaCount  . . . . . . . . . . . . . . . . . .   8
     4.7.  ect0PacketTotalCount  . . . . . . . . . . . . . . . . . .   9
     4.8.  ect1PacketDeltaCount  . . . . . . . . . . . . . . . . . .   9
     4.9.  ect1PacketTotalCount  . . . . . . . . . . . . . . . . . .   9
     4.10. cePacketDeltaCount  . . . . . . . . . . . . . . . . . . .  10
     4.11. cePacketTotalCount  . . . . . . . . . . . . . . . . . . .  10
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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

Song, et al.             Expires 20 January 2027                [Page 2]
Internet-Draft             ECN Export in IPFIX                 July 2026

   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
   [RFC9331].  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)
   [RFC7012] to export ECN information.

2.  Terminology

2.1.  Terms Used in This Document

   This document makes use of the terms defined in [RFC9331], [RFC9330]
   and [RFC7011].

   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

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.

Song, et al.             Expires 20 January 2027                [Page 3]
Internet-Draft             ECN Export in IPFIX                 July 2026

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

   [RFC9331] specifies that ECT(1) is used to identify L4S-capable
   traffic.  ECT(0) is used to identify classical traffic.

3.2.  MPLS ECN

   Two mechanisms exist for carrying ECN information in MPLS networks.

Song, et al.             Expires 20 January 2027                [Page 4]
Internet-Draft             ECN Export in IPFIX                 July 2026

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.  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.

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.  L4S traffic is identified by the
      ECT(1) codepoint as specified in [RFC9331].

      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

Song, et al.             Expires 20 January 2027                [Page 5]
Internet-Draft             ECN Export in IPFIX                 July 2026

      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 [RFC2780] and [RFC3168] for ECN field
      definition.

   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].

      [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) 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.

Song, et al.             Expires 20 January 2027                [Page 6]
Internet-Draft             ECN Export in IPFIX                 July 2026

   Abstract Data Type:  unsigned8

   Data Type Semantics:  identifier

   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].

      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

Song, et al.             Expires 20 January 2027                [Page 7]
Internet-Draft             ECN Export in IPFIX                 July 2026

   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).

   Abstract Data Type:  unsigned64

   Data Type Semantics:  deltaCounter

   Additional Information:  Refer to [RFC9331].

   Reference:  [RFC3168], [RFC9331], this document.

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.

   Abstract Data Type:  unsigned64

   Data Type Semantics:  totalCounter

   Additional Information:  Refer to [RFC9331].

   Reference:  [RFC3168], [RFC9331], 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).

   Abstract Data Type:  unsigned64

Song, et al.             Expires 20 January 2027                [Page 8]
Internet-Draft             ECN Export in IPFIX                 July 2026

   Data Type Semantics:  deltaCounter

   Additional Information:  Refer to [RFC3168].

   Reference:  [RFC3168], [RFC9331], 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.

   Abstract Data Type:  unsigned64

   Data Type Semantics:  totalCounter

   Additional Information:  Refer to [RFC3168].

   Reference:  [RFC3168], [RFC9331], 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).

   Abstract Data Type:  unsigned64

   Data Type Semantics:  deltaCounter

   Additional Information:  Refer to [RFC3168].

   Reference:  [RFC3168], [RFC9331], this document.

4.9.  ect1PacketTotalCount

   Name:  ect1PacketTotalCount

   ElementID:  TBD9

   Description:  The total number of packets of this Flow with ECN

Song, et al.             Expires 20 January 2027                [Page 9]
Internet-Draft             ECN Export in IPFIX                 July 2026

      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 [RFC9331].

   Reference:  [RFC3168], [RFC9331], this document.

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).

   Abstract Data Type:  unsigned64

   Data Type Semantics:  deltaCounter

   Additional Information:  Refer to [RFC9331].

   Reference:  [RFC3168], [RFC9331], 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.

   Abstract Data Type:  unsigned64

   Data Type Semantics:  totalCounter

   Additional Information:  Refer to [RFC9331].

   Reference:  [RFC3168], [RFC9331], this document.

Song, et al.             Expires 20 January 2027               [Page 10]
Internet-Draft             ECN Export in IPFIX                 July 2026

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
   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 [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., 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.

Song, et al.             Expires 20 January 2027               [Page 11]
Internet-Draft             ECN Export in IPFIX                 July 2026

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].

   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.

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 20 January 2027               [Page 12]
Internet-Draft             ECN Export in IPFIX                 July 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 for reviewing this document and providing
   their helpful comments.

9.  References

Song, et al.             Expires 20 January 2027               [Page 13]
Internet-Draft             ECN Export in IPFIX                 July 2026

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-03, 6 July
              2026, <https://datatracker.ietf.org/doc/html/draft-halmir-
              mpls-ecn-03>.

   [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>.

   [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,
              <https://www.rfc-editor.org/info/rfc3168>.

   [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>.

   [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>.

9.2.  Informative References

   [IANA-IPFIX]
              "IANA, "IP Flow Information Export (IPFIX) Entities"",
              <https://www.iana.org/assignments/ipfix/ipfix.xhtml>.

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

Song, et al.             Expires 20 January 2027               [Page 14]
Internet-Draft             ECN Export in IPFIX                 July 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,
              <https://www.rfc-editor.org/info/rfc2474>.

   [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,
              <https://www.rfc-editor.org/info/rfc2780>.

   [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,
              <https://www.rfc-editor.org/info/rfc3032>.

   [RFC5129]  Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
              Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
              2008, <https://www.rfc-editor.org/info/rfc5129>.

   [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,
              <https://www.rfc-editor.org/info/rfc5475>.

   [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,
              <https://www.rfc-editor.org/info/rfc9330>.

   [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,
              <https://www.rfc-editor.org/info/rfc9331>.

Authors' Addresses

   Xueyan Song
   ZTE Corp.
   Email: song.xueyan2@zte.com.cn

   Yao Liu
   ZTE Corp.
   Email: liu.yao71@zte.com.cn

Song, et al.             Expires 20 January 2027               [Page 15]
Internet-Draft             ECN Export in IPFIX                 July 2026

   Jonathan Newton
   Vodafone
   Email: jonathan.newton@vodafone.com

   Jason Livingood
   Comcast
   Email: Jason_Livingood@comcast.com

Song, et al.             Expires 20 January 2027               [Page 16]