Explicit Congestion Notification Using MPLS Network Actions

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 28 December 2025.¶

Copyright Notice

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

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

Low Latency, Low Loss, and Scalable Throughput (L4S) technology, introduced in [RFC9330], uses Explicit Congestion Notification (ECN) ([RFC3168]) bits in IP or TCP by marking packets suffering potential congestion in the network ([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.¶

[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 [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 ([I-D.ietf-mpls-mna-fwk]) while preserving the existing MPLS traffic class capability.¶

3. Realization of Explicit Congestion Notification as an MPLS Network Action

MNA, according to [I-D.ietf-mpls-mna-fwk], can support ECN by an MNA Sub-stack using either In-Stack Data (ISD) or Post-Stack Data (PSD) for ancillary data.¶

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

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

4. Theory of Operation

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 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 (Figure 1) or of the ECN MNA using PSD MNA (Figure 2). If a transit Label Switching Router (LSR) that supports this specification receives an MPLS packet with MNA ECN 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 [RFC3168]), the LSR MUST set the ECN field to the Congestion Experienced (0b11) value. If an egress LER that supports this specification, receives an MPLS packet with ECN MNA, it MUST combine the value of the ECN field with the value in the ECN field of the IP header of the encapsulated packet.¶

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

5. IANA Considerations

6. Security Considerations

Security considerations discussed in [RFC9197], [RFC9326], and [I-D.ietf-mpls-mna-fwk] apply to this document.¶

Authors' Addresses