Network Working Group                                        Z. Han, Ed.
Internet-Draft                                                   R. Pang
Intended status: Standards Track                                 Z. Ruan
Expires: 23 April 2026                                             X. Yi
                                                            China Unicom
                                                         20 October 2025

Fine-Grained Flow Control Backpressure Mechanism for Wide Area Networks
               draft-han-rtgwg-fine-grained-backpressure-00

Abstract

   This document specifies a fine-grained flow control backpressure
   mechanism for Wide Area Networks (WANs). The mechanism enables
   precise congestion notification and flow control at tenant or task
   granularity through extended network protocols and controller-
   assisted path discovery. It addresses the limitations of traditional 
   flow control mechanisms in WAN environments by providing intelligent
   backpressure with detailed congestion information, with specific
   applicability in SRv6-based networks.

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 23 April 2026.

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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  System Architecture  . . . . . . . . . . . . . . . . . . . . .  4
   4.  Fine-Grained Flow Control Backpressure Mechanism  . . . . . .  5
     4.1.  Flow Control Capability Discovery . . . . . . . . . . . .  5
     4.2.  Congestion Detection and Controller Assistance  . . . . .  7
     4.3.  Backpressure Message Generation and Forwarding . . . . . .  8
     4.4.  Multi-hop Backpressure Propagation  . . . . . . . . . . .  9
     4.5.  SRv6 Integration and Path Handling  . . . . . . . . . . . 10
   5.  Backpressure Message Formats . . . . . . . . . . . . . . . . . 11
     5.1.  ICMP-based Backpressure Message  . . . . . . . . . . . . . 11
     5.2.  SRv6-enhanced Backpressure Message . . . . . . . . . . . . 12
     5.3.  Backpressure Path TLV . . . . . . . . . . . . . . . . . . 13
     5.4.  Slice Information TLV  . . . . . . . . . . . . . . . . . . 14
     5.5.  Backpressure Policy TLV . . . . . . . . . . . . . . . . . 15
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative References  . . . . . . . . . . . . . . . . . 18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 19

1.  Introduction

   With the rapid development of High-Performance Computing (HPC),
   remote healthcare, multimedia content production, and AI-Generated
   Content (AIGC) applications, the volume, velocity, and variety of
   data are growing exponentially. This poses higher requirements for
   the efficiency and reliability of massive data transmission across
   Wide Area Networks (WANs). WANs are characterized by large scale,
   complex topology, long round-trip times, diverse service types,
   continuously increasing load, and frequent high-intensity burst
   traffic, making them prone to congestion.

   Traditional congestion control mechanisms like Priority Flow Control
   (PFC) and Explicit Congestion Notification (ECN) face limitations in
   WAN environments. PFC provides coarse-grained port-based flow control
   that can lead to congestion spreading, head-of-line blocking, and
   deadlocks. ECN requires end-host participation with slow and
   inaccurate responses, making it unsuitable for long-distance
   transmission in WANs.

   This document proposes a fine-grained flow control backpressure
   mechanism that extends network protocols (including but not limited
   to ICMP and UDP) to carry detailed congestion information and 
   utilizes controller assistance for optimal path discovery. The 
   mechanism enables precise flow control at tenant or task granularity, 
   provides intelligent backpressure strategies, and supports multi-hop 
   congestion notification along the traffic path. The solution is 
   particularly relevant for SRv6-based networks where precise path 
   control and slicing capabilities are essential.

2.  Terminology

   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.

   Fine-Grained Flow Control: Flow control mechanism that operates at
   tenant or task granularity rather than port or queue level.

   Backpressure Message: Network protocol message carrying congestion
   information and flow control policies, which can be implemented using
   ICMP, UDP, or other suitable protocols.

   First Path Forwarding Node: The node experiencing congestion that
   initiates the backpressure process.

   Second Path Forwarding Node: The upstream node capable of handling
   congestion through fine-grained flow control.

   Controller: Central entity that maintains network topology and node
   capabilities, assisting in optimal backpressure path discovery.

   SRv6: IPv6 Segment Routing as defined in [RFC8754].

   SID: Segment Identifier in SRv6 networks.

   SRH: Segment Routing Header as defined in [RFC8754].

3.  System Architecture

   The fine-grained flow control backpressure system consists of three
   main components, with specific considerations for SRv6 networks:

   +----------+      +-------------+      +----------+
   | First    |      | Controller  |      | Second   |
   | Path     |<---->|             |<---->| Path     |
   |Forwarding|      |             |      | Forwarding|
   | Node     |      |             |      | Node     |
   +----------+      +-------------+      +----------+
         |                                      |
         | Backpressure Message                |
         | (ICMP/UDP/SRv6-enhanced)            |
         |------------------------------------>|

   Figure 1: System Architecture

   In SRv6 environments, the backpressure mechanism leverages the
   existing SRv6 infrastructure:

   - First Path Forwarding Node: Detects congestion and initiates
    backpressure process by contacting the controller and generating
    backpressure messages. In SRv6 networks, this node maintains SID
    information and SRH processing capabilities.

   - Controller: Maintains network topology, node capability 
    information, and SRv6 SID allocations. Determines optimal 
    backpressure paths and policies, considering SRv6 path segments.

   - Second Path Forwarding Node: Receives backpressure messages and
    performs fine-grained flow control on specified traffic. Supports
    SRv6 processing and slice-aware congestion handling.

4.  Fine-Grained Flow Control Backpressure Mechanism

4.1.  Flow Control Capability Discovery

   Before participating in the fine-grained flow control mechanism, each
   forwarding node MUST register its capabilities with the controller.
   The controller maintains a comprehensive view of flow control
   capabilities throughout the network to facilitate optimal 
   backpressure path selection.

   The capability discovery process include the following
   information:
   - Node identifier and addressing information
   - Flow control granularity support (tenant-level, task-level, or 
     both)
   - Supported flow control mechanisms and algorithms
   - Buffer management capabilities and thresholds
   - Supported transport protocols for backpressure messages (ICMP, UDP,
     etc.)
   - SRv6-specific capabilities (if applicable), including:
     * Supported SID types and functions
     * SRH processing capabilities
     * Slice awareness and isolation capabilities
     * Path segment manipulation support

   The capability discovery follow this procedure:
   1. Node initiates capability advertisement to controller
   2. Controller validates and stores flow control capabilities
   3. Periodic capability updates SHALL be sent to reflect any changes
   4. Controller MAY proactively query node capabilities as needed

   Example capability advertisement format:

    +-------------------------------------+
    |         Node Identifier             |
    +-------------------------------------+
    |       Flow Control Granularity      |
    | (tenant-level | task-level | both)  |
    +-------------------------------------+
    |    Supported Transport Protocols    |
    |    (ICMP | UDP | SRv6-enhanced)     |
    +-------------------------------------+
    |         SRv6 Capabilities           |
    | (SID types | SRH support | slicing) |
    +-------------------------------------+
    |      Buffer Management Info         |
    | (thresholds | queue management)     |
    +-------------------------------------+

   This capability discovery enables the controller to maintain a 
   real-time understanding of nodes capable of fine-grained flow control 
   throughout the network, with specific awareness of SRv6 capabilities 
   and protocol support variations.

4.2.  Congestion Detection and Controller Assistance

   When a forwarding node detects congestion, it initiate the
   backpressure process by sending a request to the controller.

   The congestion detection be based on monitoring of:
   - Queue length
   - Link utilization
   - Packet loss rate
   - Delay
   - Resource utilization rate
   - In SRv6 networks: per-slice queue utilization and SID-specific
     congestion metrics

   The request to controller include:
   - Identity of the congested node
   - Request for second path forwarding node that meets congestion
     handling conditions
   - In SRv6 networks: current SID list, slice information, and path
     segment details

   The congestion handling conditions include:
   - Ability to perform data traffic control at tenant or task 
     granularity
   - Existence of shortest forwarding path between nodes
   - In SRv6 networks: compatibility with SRv6 path segments and slicing

   Upon receiving the request, the controller:
   1. Identify suitable second path forwarding nodes based on network
      topology and node capabilities
   2. Determine the optimal backpressure path, considering SRv6 SID
      lists when applicable
   3. Generate appropriate backpressure policies
   4. Return the second path forwarding node address information and
      backpressure policies to the first path forwarding node

4.3.  Backpressure Message Generation and Forwarding

   After receiving the controller's response, the first path forwarding
   node generate backpressure messages and forward them to the
   second path forwarding node.

   The backpressure message generation follow these steps:
   1. Receive backpressure policy information from controller
   2. Select appropriate transport protocol (ICMP, UDP, or 
      SRv6-enhanced) based on node capabilities and network 
      configuration
   3. Generate backpressure message containing:
      - Backpressure notification path
      - Slice information
      - Backpressure policy information
      - In SRv6 networks: relevant SID information and SRH details
   4. Send the message to second path forwarding node using IP-based
      transmission

   The backpressure message includes the following information:
   - Message type and protocol identification
   - Checksum or integrity verification
   - Backpressure notification path
   - Number of slices
   - Slice identifier
   - Control mode (0 for congestion backpressure, 1 for cache release)
   - Traffic rate
   - Cache capability
   - Backpressure policy information
   - Protocol-specific extensions (e.g., SRH for SRv6-enhanced messages)

4.4.  Multi-hop Backpressure Propagation

   If the second path forwarding node cannot fully handle the 
   congestion, the backpressure process propagates further upstream.

   The multi-hop propagation follows this process:
   1. Second path forwarding node reports its cache occupancy rate to
      first path forwarding node
   2. If cache occupancy rate exceeds threshold (e.g., 80%), first path
      forwarding node requests updated backpressure policy from 
      controller
   3. Controller generates new backpressure policy based on current
      network traffic information
   4. First path forwarding node generates new backpressure message and
      sends it to third path forwarding node (upstream from second node)
   5. Process continues until congestion is resolved or reaches the
      traffic source

   In SRv6 networks, the backpressure path SHOULD follow the reverse
   direction of the SRv6 SID list to ensure optimal congestion handling
   along the established path segments.

4.5.  SRv6 Integration and Path Handling

   For SRv6-enabled networks, the backpressure mechanism leverages
   SRv6 capabilities for enhanced congestion control:

   - SID-based Path Identification: Backpressure messages SHOULD include
     SID information to precisely identify the congested path segment.

   - SRH for Backpressure Routing: When available, SRH MAY be used to
     ensure backpressure messages follow specific paths, bypassing
     nodes that do not support fine-grained flow control.

   - Slice-aware Congestion Management: SRv6 slicing capabilities SHOULD
     be utilized to isolate congestion to specific slices and prevent
     cross-slice interference.

   - Path Segment Optimization: The controller SHOULD consider SRv6 path
     segments when determining backpressure paths to minimize the number
     of hops and reduce latency.

5.  Backpressure Message Formats

5.1.  ICMP-based Backpressure Message

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |    BP Flags   |        Backpressure ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Original Packet                       |
   |                          (Variable Length)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Backpressure TLVs                          |
   |                          (Variable Length)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: ICMP-based Backpressure Message Format

   Fields:
   - Type: ICMP message type (to be assigned by IANA)
   - Code: Subtype (0 for tenant granularity, 1 for task granularity)
   - Checksum: Standard ICMP checksum
   - BP Flags: Backpressure flags
   - Backpressure ID: Identifier for the backpressure session
   - Original Packet: Header of the packet that triggered congestion
   - Backpressure TLVs: Type-Length-Value structures carrying detailed
     backpressure information

5.2.  SRv6-enhanced Backpressure Message

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|    Flags    |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SRv6 Source Address (128 bits IPv6 address)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Segment Routing Header                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Slice ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Backpressure TLVs                          |
   |                          (Variable Length)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: SRv6-enhanced Backpressure Message Format

   Fields:
   - Type: Message type (ICMP or other as appropriate)
   - Code: Message code
   - Checksum: Protocol checksum
   - Flags: SRv6-specific flags (S bit indicates presence of Slice ID)
   - SRv6 Source Address: Source address of the SRv6 message
   - Segment Routing Header: SRH as defined in [RFC8754]
   - Slice ID: Identifier for the network slice
   - Backpressure TLVs: Type-Length-Value structures carrying detailed
     backpressure information

5.3.  Backpressure Path TLV

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Node 1 Address (IPv4/IPv6)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Node 2 Address (IPv4/IPv6)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4: Backpressure Path TLV

   Fields:
   - Type: TLV type for backpressure path (to be assigned by IANA)
   - Length: Total length of the TLV in bytes
   - Node Addresses: Sequence of node addresses forming the 
     backpressure path

5.4.  Slice Information TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   Slice Type  |   Info Type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Slice Identifier                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Tenant ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Task ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 5: Slice Information TLV

   Fields:
   - Type: TLV type for slice information (to be assigned by IANA)
   - Length: Total length of the TLV in bytes
   - Slice Type: Type of network slice
   - Info Type: Type of information (tenant or task)
   - Slice Identifier: Unique identifier for the slice
   - Tenant ID: Identifier for the tenant
   - Task ID: Identifier for the task

5.5.  Backpressure Policy TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   Policy Type |   Action Type |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Rate Limit (bps)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Duration (ms)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Alternate Path                         |
   |                          (Variable)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 6: Backpressure Policy TLV

   Fields:
   - Type: TLV type for backpressure policy (to be assigned by IANA)
   - Length: Total length of the TLV in bytes
   - Policy Type: Type of backpressure policy
   - Action Type: Specific action to be taken
   - Rate Limit: Maximum allowed traffic rate in bits per second
   - Duration: Time duration for which the policy should be applied
   - Alternate Path: Suggested alternative path for traffic
     (variable length)

6.  Security Considerations

    TBD;

7.  IANA Considerations

    TBD;


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020.


Authors' Addresses

   Zhengxin Han (editor)
   China Unicom
   Beijing
   China
   Email: hanzx21@chinaunicom.cn

   Ran Pang
   China Unicom
   Beijing
   China
   Email: pangran@chinaunicom.cn

   Zheng Ruan
   China Unicom
   Beijing
   China
   Email: ruanz6@chinaunicom.cn

   Xinxin Yi
   China Unicom
   Beijing
   China
   Email: yixx3@chinaunicom.cn