<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-halmir-mpls-ecn-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.6.0 -->
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<front>
    <title abbrev="ECN Over MNA">Explicit Congestion Notification Using MPLS Network Actions</title>
    <seriesInfo name="Internet-Draft" value="draft-halmir-mpls-ecn-01"/>
    
      <author fullname="Joel Halpern" initials="J." surname="Halpern">
      <organization>Ericsson</organization>
      <address>
        <email>jmh@joelhalpern.com</email>
      </address>
    </author>
    
      <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
      <organization>Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    
    <date year="2025"/>
    
    <area>Routing</area>
    <workgroup>MPLS Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>IOAM</keyword>
    <keyword>MPLS Network Action</keyword>
    <abstract>
      <t>
It has been broadly demonstrated that user experience improvements
   for time-critical applications have not increased at the same pace as
   network throughput (i.e., the increased bandwidth does not result in
   a corresponding increase in the user experience). Optimizing network
   latency rather than throughput can lead to a significantly improved
   user experience for time-critical applications. Low Latency, Low
   Loss, and Scalable Throughput (L4S) technology, introduced in RFC 9330,
   uses Explicit Congestion Notification (ECN) bits by marking
   packets suffering potential congestion in the network. L4S operates
   as a congestion-control mechanism, using markers within the data
   packets to detect and promptly respond to congestion conditions.
   This feedback loop enables devices (e.g., endpoints such as client
   devices and server devices) to adjust data flow in real-time,
   preventing bottlenecks and ensuring smoother transmission.
   </t>
   <t>
RFC 5129 describes a mechanism for supporting ECN in the Multiprotocol Label Switching (MPLS) data plane.
 That mechanism is based on the codepoints that take part in the Traffic Class (TC) field and, thus, prevent the use of TC
 field for traffic differentiation.
 This document defines how ECN can be supported in the MPLS data plane using the MPLS Network Actions technology.
</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
Network throughput (also referred to as bandwidth) has increased exponentially over the last several decades,
enabling a variety of new features for end users, including video streaming, online gaming,
and mixed reality implementations, as well as more advanced applications such as
remote teleoperation and autonomous services. The focus on network throughput,
however, underestimates the fact that users are primarily interested in application
responsiveness rather than the number of bits they can transfer per second.
As a result, user experience improvements for time-critical applications have not
necessarily increased at the same pace as network throughput (i.e., the increased
bandwidth does not result in a corresponding increase in the user experience).
Optimizing network latency rather than throughput can lead to a significantly improved
user experience for time-critical applications.
</t>
<t>
Low Latency, Low Loss, and Scalable Throughput (L4S) technology, introduced in <xref target="RFC9330"/>,
uses Explicit Congestion Notification (ECN) (<xref target="RFC3168"/>) bits in IP or TCP by marking
   packets suffering potential congestion in the network (<xref target="RFC9331"/>). L4S operates
   as a congestion-control mechanism, using ECN markers within the data
   packets to detect and promptly respond to congestion conditions.
   This feedback loop enables devices (e.g., endpoints such as client
   devices and server devices) to adjust data flow in real-time,
   preventing bottlenecks and ensuring smoother transmission.
</t>
   <t>
<xref target="RFC5129"/> describes a mechanism for supporting ECN in the Multiprotocol Label Switching (MPLS) data plane.
 That mechanism is based on the codepoints that take part in the Traffic Class (TC) field <xref target="RFC3032"/>
 and, thus, prevent the use of the TC field for traffic differentiation.
 This document defines how ECN can be supported in the MPLS data plane using
 the MPLS Network Actions technology (<xref target="RFC9789"/>)
 while preserving the existing MPLS traffic class capability.
</t>

      </section>
      
      <section numbered="true" toc="default">
        <name>Conventions Used in this Document</name>
    
         <section title="Acronyms">

          <t>ECN:                Explicit Congestion Notification </t>
          <t>ISD:                 In-Stack Data</t>
          <t>L4S:                Low Latency, Low Loss, and Scalable Throughput</t>
          <t>LER:               Label Edge Router</t>
          <t>LSR:               Label Switching Router</t>
           <t>MPLS:          Multiprotocol Label Switching</t>
            <t>MNA:          MPLS Network Action</t>
            <t>NAS:           Network Action Sub-stack</t>
            <t>PSD:           Post-Stack Data</t>
            <t>TC:               Traffic Class</t>
         </section>    
         
        <section numbered="true" toc="default">
          <name>Requirements Language</name>
          <t>
   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 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> 
   when, and only when, they appear in all capitals, as shown here.
          </t>
      </section>
    </section>

<section anchor="ecn-mpls-sec" numbered="true" toc="default">
<name>Realization of Explicit Congestion Notification as an MPLS Network Action</name>
<t>
MNA, according to <xref target="RFC9789"/>, can support ECN by an MNA Sub-stack
using either In-Stack Data (ISD) or Post-Stack Data (PSD) for ancillary data.
</t>

<section anchor="isd-ecn-sec" numbered="true" toc="default">
<name>ECN Encapsulation Using In-Stack MPLS Network Actions</name>
<t>
<xref target="isd-ecn-fig"/> displays the encoding of ECN using ISD MNA.
</t>
 <figure anchor="isd-ecn-fig">
   <name>Format of the ECN MNA Using ISD MNA</name>
  <artwork name="" type="" align="left" alt=""><![CDATA[    
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode ECN |           Data1           |ECN|S|U| Data2 | NAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
Where fields are defined as follows:
</t>
<ul spacing="normal">
<li>Opcode ECN is seven-bit field. IANA is requested to assign (TBA1) value <xref target="iana-ecn-option-sec"/>.</li>
<li>Data1 is 14-bit field. It MUST be zeroed on transmission and ignored on reception and processing of the Opcode ECN.</li>
<li>ECN is two-bit field.</li>
<li>S is the Bottom of Stack one-bit flag, as defined in <xref target="RFC3032"/></li>
<li>U is a one-bit Unknown Network Action Handling field as defined in <xref target="I-D.ietf-mpls-mna-hdr"/>.</li>
<li>Data2 is four-bit field. It MUST be zeroed on transmission and ignored on reception and processing of the Opcode ECN.</li>
<li>NAL is three-bit Network Action Length as defined in <xref target="I-D.ietf-mpls-mna-hdr"/>.</li>
</ul>

</section>

<section anchor="psd-ecn-sec" numbered="true" toc="default">
<name>ECN Encoding Using Post-Stack MPLS Network Actions</name>
<t>
<xref target="psd-ecn-fig"/> displays the encoding of ECN using PSD MNA.
</t>

 <figure anchor="psd-ecn-fig">
   <name>Format of the ECN MNA Using PSD MNA</name>
  <artwork name="" type="" align="left" alt=""><![CDATA[    
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN PS-MNA-OP|R|R|   PS-NAL    |ECN|       Post-Stack Data     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>

<t>Where the enclosed elements are defined as follows:</t>
<ul spacing="normal">
<li>ECN PS-MNA-OP is seven-bit field. IANA is requested to assign (TBA2) value (<xref target="iana-ecn-psd-option-sec"/>).</li>
<li>R - two Reserved bits as defined in <xref target="I-D.ietf-mpls-mna-ps-hdr"/>.</li>
<li>PS-NAL is seven-bit field as defined in <xref target="I-D.ietf-mpls-mna-ps-hdr"/>.</li>
<li>ECN is two-bit field.</li>
<li>Post-Stack Data is 14-bit field. It MUST be zeroed on transmission and ignored on reception and processing of the ECN PS-MNA-OP.</li>
      </ul>
</section>
</section>

    <section anchor="operation-sec" numbered="true" toc="default">
    <name>Theory of Operation</name>
    <t>
    If an ingress Label Edge Router (LER) that supports this specification is enabled to use ECN MNA receives a packet
    with the indication that the endpoints of the transport protocol are ECN-capable or the packet has experienced congestion,
    it MUST copy the value of the ECN field in the received IP packet into the ECN field of the ECN MNA
    using ISD MNA (<xref target="isd-ecn-fig"/>) or of the ECN MNA using PSD MNA (<xref target="psd-ecn-fig"/>).
    If the incoming packet is marked as non-ECN capable, the encapsulator SHOULD NOT use the ECN MNA.
    If, for some reason, the local policy requires the ECN MNA to be used, it MUST set the ECN value to Not-ECT.
    This corresponds to the normal mode behavior defined in <xref target="RFC6040"/>.
    </t>
    <t>
    If a transit Label Switching Router (LSR) that supports this specification receives an MPLS packet with ECN MNA
    and determines that the egress interface for the received packet experiences congestion although its buffer is not full
    so that the packet can be transmitted (see  for the detailed explanation of the incipient congestion <xref target="RFC3168"/>),
    the LSR MUST set the ECN field to the Congestion Experienced (0b11) value.
    </t>
    <t>
    If an egress LER that supports this specification, receives an MPLS packet with ECN MNA,
    it MUST follow the decapsulator's behavior defined in Section 4.2 of <xref target="RFC6040"/>.
    </t>
    <t>
   In some scenarios, the Readable Label Depth of the constructed path through the MPLS domain
   may require the placement of more than one ECN MNA Network Action Sub-stacks (NASes).
   If that is the case, then the Label Switching Router that exposes the NAS with ECN MNA MUST copy the value of the ECN field
   in that NAS into the ECN field in the next NAS that includes ECN MNA.
    </t>
    </section>
    
    <section anchor="iana-consider" numbered="true" toc="default">
    <name>IANA Considerations</name>
    
      <section anchor="iana-ecn-option-sec" numbered="true" toc="default">
      <name>ECN as an MPLS Network Action Opcode</name>
      <t>IANA is requested to assign an ECN codepoint (TBA1) from its Network Action Opcodes registry
    (creation requested in <xref target="I-D.ietf-mpls-mna-hdr"/>)
      as specified in <xref target="iana-ecn-mna-option-tbl"/>.</t>
      
          <table anchor="iana-ecn-mna-option-tbl" align="center">
          <name>ECN as MPLS Network Action Opcode</name>
          <thead>
            <tr>
              <th align="left">Opcode</th>
              <th align="center">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBA1</td>
              <td align="center">ECN as MPLS Network Action Indicator</td>
              <td align="left">This&nbsp;document</td>
            </tr>
          </tbody>
        </table>
      </section>
      
    <section anchor="iana-ecn-psd-option-sec" numbered="true" toc="default">
      <name>ECN as an Post-Stack Network Action Opcode</name>
      <t>IANA is requested to assign an ECN codepoint (TBA1) from its Post-Stack Network Action Opcodes registry
    (creation requested in <xref target="I-D.ietf-mpls-mna-ps-hdr"/>)
      as specified in <xref target="iana-ecn-psd-option-tbl"/>.</t>
      
          <table anchor="iana-ecn-psd-option-tbl" align="center">
          <name>ECN as MPLS Network Action Opcode</name>
          <thead>
            <tr>
              <th align="left">Opcode</th>
              <th align="center">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBA2</td>
              <td align="center">ECN as Post-Stack Network Action Opcode</td>
              <td align="left">This&nbsp;document</td>
            </tr>
          </tbody>
        </table>
      </section>
      
    </section>
    
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
 Security considerations discussed in <xref target="RFC9197"/>, <xref target="RFC9326"/>, and
 <xref target="RFC9789"/> apply to this document. 
      </t>
    </section>
    
        <section numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>
<!--The authors exxpress their sincere appreciation to Loa Andersson for his thorough review
and thoughtful suggestion that helped in improving this document.-->
TBA
      </t>
    </section>
    
  </middle>
  <back>
  <references>
  <name>References</name>
  <references>
        <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/>
      
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9789.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mpls-mna-hdr.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mpls-mna-ps-hdr.xml"/>

    </references>
    
    <references>
    <name>Informational References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9330.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9331.xml"/>

<!--
<reference anchor="IANA-IOAM-Trace-Type" target="https://www.iana.org/assignments/ioam/ioam.xhtml#trace-type">
        <front>
            <title>IOAM Trace-Type</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
-->
        
          </references>
    
    </references>

  </back>
</rfc>
