Fine-grained QoE Enhancement using Semantic Tables
draft-li-spring-fine-grained-qoe-enhancement-00

SPRING                                                             Z. Li
Internet-Draft                                                     Z. Du
Intended status: Standards Track                            China Mobile
Expires: 1 September 2026                                       W. Cheng
                                                                 J. Wang
                                                                G. Zhang
                                                         Centec Networks
                                                        28 February 2026

           Fine-grained QoE Enhancement using Semantic Tables
            draft-li-spring-fine-grained-qoe-enhancement-00

Abstract

   This document describes a fine-grained Quality of Experience (QoE)
   enhancement mechanism using semantic tables deployed at network
   forwarding nodes.  The mechanism enables application-level SLA
   (Service Level Agreement) guarantees by carrying address indices and
   high-frequency-changing information in packets while maintaining low-
   frequency-changing semantic information at network nodes.  This
   approach overcomes the limitations of traditional Application-aware
   Networking (APN) solutions, including excessive packet header
   overhead.  The mechanism supports collaborative optimization across
   network, computing, and energy dimensions, and can be deployed over
   MPLS, IPv4/v6, SRv6, and other protocol data planes.

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 1 September 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Li, et al.              Expires 1 September 2026                [Page 1]
Internet-Draft        Fine-grained QoE Enhancement         February 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Information Classification  . . . . . . . . . . . . . . .   5
     4.2.  Semantic Table Distribution Methods . . . . . . . . . . .   6
     4.3.  Semantic Table Content Acquisition  . . . . . . . . . . .   6
   5.  Protocol Specification  . . . . . . . . . . . . . . . . . . .   7
     5.1.  Semantic Table Structure  . . . . . . . . . . . . . . . .   7
     5.2.  Packet Format . . . . . . . . . . . . . . . . . . . . . .   7
     5.3.  TLV Type Definitions  . . . . . . . . . . . . . . . . . .   8
     5.4.  SRv6 Protocol Extension . . . . . . . . . . . . . . . . .   9
   6.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Centralized Control Flow  . . . . . . . . . . . . . . . .  10
     6.2.  Detailed Operation Steps  . . . . . . . . . . . . . . . .  11
     6.3.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   To provide better Quality of Experience (QoE) for users, networks
   need to offer fine-grained or even application-level Service Level
   Agreement (SLA) guarantees.

   Current approaches have the following limitations:

Li, et al.              Expires 1 September 2026                [Page 2]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

   SDN-based Centralized Approach:
      Uses orchestrators to perceive application requirements and
      arrange paths.  This approach has long decision paths, making it
      unsuitable for latency-sensitive applications, and faces
      difficulties in interfacing between multiple systems.

   Traditional Network Packets:
      Traditional network packets cannot carry sufficient information to
      indicate the diverse applications or services and their SLA
      requirements.

   To address these issues, the industry proposed the Application-aware
   Networking (APN) mechanism [I-D.ietf-apn-framework].  APN supports
   inserting APN information (such as ID information and SLA
   information) into IPv6 packet extension headers.  Network nodes, such
   as headend nodes, can parse this APN information and provide services
   on demand.

   While APN provides a valuable framework, certain deployment scenarios
   may benefit from alternative approaches that address the following
   considerations:

   1.  Large Packet Header Modifications: Requires defining entirely new
       packet header formats.

   2.  High Overhead: Application/service, user, and network
       requirements must be carried per-packet.

   3.  Lack of Computing-Network Collaboration: Does not consider
       computing-related information and cannot perform computing-
       network collaborative optimization.

   This document proposes a solution using semantic tables to enable
   fine-grained QoE enhancement while addressing these limitations.

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

2.  Terminology

   This document uses the following terminology:

Li, et al.              Expires 1 September 2026                [Page 3]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

   Semantic Table:
      A data structure deployed at network forwarding nodes containing
      user/service/application information and their SLA guarantee
      requirements.

   Address Index (ADDR):
      An identifier used to retrieve semantic tables at transit nodes,
      identifying specific application/user groups.

   High-Frequency-Changing Information:
      Dynamic information such as network, computing, and energy
      parameters that change frequently.

   Low-Frequency-Changing Information:
      Static configuration information that changes infrequently, such
      as user/application identifiers and bandwidth requirements.

   QoE (Quality of Experience):
      The degree of delight or annoyance of the user of an application
      or service, resulting from the fulfillment of expectations with
      respect to the utility and/or enjoyment of the application or
      service.

   SLA (Service Level Agreement):
      A commitment between a service provider and a client regarding
      aspects of the service such as quality, availability, and
      responsibilities.

3.  Problem Statement

   Current approaches for providing fine-grained QoE guarantees face the
   following core issues:

   1.  Packet Overhead: Each packet carries complete application/user
       information and SLA requirements, leading to excessive packet
       header overhead.

   2.  Security Issues: Sensitive user/application information is
       transmitted in plaintext across the network, posing privacy leak
       risks.

   3.  Lack of Flexibility: Cannot distinguish between high-frequency-
       changing and low-frequency-changing information; all information
       must be carried per-packet.

   4.  Computing-Network Separation: Existing solutions mainly focus on
       network resources and lack awareness and collaborative
       optimization capabilities for computing resources.

Li, et al.              Expires 1 September 2026                [Page 4]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

   The design goals of this mechanism include:

   *  Reduce packet header overhead by carrying only necessary indices
      and high-frequency-changing information in packets

   *  Improve security by keeping sensitive information within network
      nodes

   *  Support collaborative optimization across network, computing, and
      energy dimensions

   *  Maintain compatibility with existing protocol data planes (MPLS,
      IPv4/v6, SRv6, etc.)

4.  Solution Overview

   This mechanism proposes a fine-grained QoE enhancement method based
   on semantic tables:

   *  Packets carry address indices and high-frequency-changing
      information (or only address indices)

   *  Specific semantics of low-frequency-changing information are
      maintained at forwarding nodes

   *  Packets passing through transit nodes trigger semantic table
      lookups using the address index to execute corresponding policies

4.1.  Information Classification

   This mechanism classifies QoE-related information into two
   categories:

   Low-Frequency-Changing Information (deployed in semantic tables):

   *  User/service/application identification information

   *  Bandwidth requirements

   *  Delay tolerance

   *  Jitter tolerance

   *  Computing capacity requirements

   *  Other relatively stable SLA parameters

   High-Frequency-Changing Information (carried in packets):

Li, et al.              Expires 1 September 2026                [Page 5]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

   *  DSCP value adjustments

   *  Queue priority

   *  Queue buffer depth

   *  Process priority

   *  Other dynamically changing parameters

4.2.  Semantic Table Distribution Methods

   This mechanism supports the following semantic table distribution
   methods:

   Centralized:
      Semantic actions for fine-grained SLA guarantees at transit nodes
      are distributed via the southbound interface of a centralized
      controller (such as an SDN controller).

   Distributed:
      Semantic actions for fine-grained SLA guarantees at transit nodes
      are advertised via distributed routing protocols (such as OSPF,
      BGP, etc.).

   Hybrid:
      Centralized distribution within domains and distributed
      advertisement between domains.

   Manual Configuration:
      Administrators directly configure semantic tables on each node
      (not recommended for large-scale deployments).

4.3.  Semantic Table Content Acquisition

   This mechanism does not restrict how semantic table content is
   acquired.  Methods include:

   *  Active notification by users/applications/services through the
      northbound interface of controllers/orchestrators

   *  Active advertisement to network nodes via distributed routing
      protocols

   *  Passive detection by network edge nodes through DPI (Deep Packet
      Inspection) and subsequent advertisement to network nodes

Li, et al.              Expires 1 September 2026                [Page 6]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

5.  Protocol Specification

5.1.  Semantic Table Structure

   Each node's semantic table MUST contain the following mandatory
   fields:

    +===============+==========+======================================+
    | Field Name    | Length   | Description                          |
    +===============+==========+======================================+
    | ADDR          | 32 bits  | Address index carried in packets for |
    |               |          | identifying application/user groups  |
    +---------------+----------+--------------------------------------+
    | APP-Group-ID  | Variable | Application group identification     |
    +---------------+----------+--------------------------------------+
    | USER-Group-ID | Variable | User group identification            |
    +---------------+----------+--------------------------------------+

                Table 1: Mandatory Fields in Semantic Table

   The semantic table MAY contain the following optional fields:

     +====================+=========+================================+
     | Field Name         | Length  | Description                    |
     +====================+=========+================================+
     | Bandwidth          | 32 bits | Required bandwidth guarantee   |
     |                    |         | (in Kbps)                      |
     +--------------------+---------+--------------------------------+
     | Delay              | 32 bits | Maximum tolerable delay for    |
     |                    |         | user/service (in microseconds) |
     +--------------------+---------+--------------------------------+
     | Jitter             | 32 bits | Maximum tolerable jitter for   |
     |                    |         | user/service (in microseconds) |
     +--------------------+---------+--------------------------------+
     | Computing-Capacity | 32 bits | Minimum computing resources    |
     |                    |         | required by user/service       |
     +--------------------+---------+--------------------------------+
     | Priority           | 8 bits  | Service priority level (0-255, |
     |                    |         | higher is more important)      |
     +--------------------+---------+--------------------------------+

                 Table 2: Optional Fields in Semantic Table

5.2.  Packet Format

   The packet format defined in this mechanism uses a TLV (Type-Length-
   Value) structure for flexible extension:

Li, et al.              Expires 1 September 2026                [Page 7]
Internet-Draft        Fine-grained QoE Enhancement         February 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ADDR                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |            Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Value                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1: TLV Packet Format

   Field Definitions:

   ADDR (4 bytes):
      Used to retrieve the semantic table at transit nodes, finding the
      application/user information that the TLV should act upon.  A
      value of 0x00000000 is reserved and MUST NOT be used.

   Type (2 bytes):
      Indicates the type of high-frequency-changing service/resource
      that needs to be guaranteed for the application/user corresponding
      to ADDR, such as DSCP, queue priority, queue buffer depth, process
      priority, etc.

   Length (2 bytes):
      Indicates the length of the Value field in bytes.

   Value (Length bytes):
      Contains the specific value of the service/resource indicated by
      the Type field.  The length is determined by the Length field.

5.3.  TLV Type Definitions

   This section defines the TLV Type field values.  The Value field is
   dynamically specified based on the specific requirements of the user,
   service, or application.

Li, et al.              Expires 1 September 2026                [Page 8]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

    +===============+==========+=====================================+
    | Type (16bit)  | Length   | Description                         |
    |               | (16bit)  |                                     |
    +===============+==========+=====================================+
    | 0x0000        | -        | Reserved                            |
    +---------------+----------+-------------------------------------+
    | 0x0001        | 0x0001   | DSCP adjustment: Value specifies    |
    |               |          | the target DSCP value (0-63) for    |
    |               |          | the transmission path               |
    +---------------+----------+-------------------------------------+
    | 0x0002        | 0x0001   | Queue priority adjustment: Value    |
    |               |          | specifies the target queue priority |
    |               |          | level at network node ports         |
    +---------------+----------+-------------------------------------+
    | 0x0003        | 0x0004   | Queue buffer depth: Value specifies |
    |               |          | the buffer depth in bytes           |
    +---------------+----------+-------------------------------------+
    | 0x0004        | 0x0001   | Process priority: Value specifies   |
    |               |          | the computing process priority      |
    |               |          | level                               |
    +---------------+----------+-------------------------------------+
    | 0x0005-0xFFFE | Variable | Reserved for future use             |
    +---------------+----------+-------------------------------------+
    | 0xFFFF        | 0x0000   | TLV terminator, payload follows     |
    +---------------+----------+-------------------------------------+

                      Table 3: TLV Type Definitions

   The above Type values (0x0001-0x0004) are examples.  Additional Type
   values can be defined based on deployment requirements and registered
   through IANA.

5.4.  SRv6 Protocol Extension

   The packet format can be carried over MPLS, IPv4/v6, SRv6, and other
   protocol data planes.  This section describes the SRv6 protocol
   extension as an example.

   SRv6 [RFC8754] is a source routing technology.  The SRH extension
   header supports multiple SIDs, with each SID being 128 bits and
   containing Locator, Function, and Argument parts.  The bit width of
   each part can be flexibly defined, providing good programmability.

   In this mechanism:

   *  The ADDR in the packet occupies the Function and Argument parts of
      one SID, totaling 32 bits

Li, et al.              Expires 1 September 2026                [Page 9]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

   *  The remaining 96 bits are used for the Locator

   *  The TLV in the packet is carried via the Optional TLV variable
      field in the SRH extension header

    0                                                             127
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Locator (96 bits)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Function (16 bits)        |      Argument (16 bits)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |<------------------------ ADDR (32 bits) -------------------->|

                    Figure 2: SRv6 SID Format with ADDR

6.  Protocol Operations

6.1.  Centralized Control Flow

   Using a client-server pair with two intermediate network nodes and a
   centralized controller as an example:

     client        node1         node2        server     controller
        |            |             |            |              |
        | (1) Request fine-grained SLA semantic actions        |
        |----------------------------------------------------->|
        |            |             |            |              |
        |            | (2) Semantic table distribution         |
        |            |<----------------------------------------|
        |            |             |            |              |
        |            |             | (2) Semantic table distribution
        |            |             |<--------------------------|
        |            |             |            |              |
        | (3) Service packet with ADDR + TLV    |              |
        |----------->|             |            |              |
        |            | (4) Lookup  |            |              |
        |            | semantic    |            |              |
        |            | table       |            |              |
        |            | Execute TLV |            |              |
        |            | actions     |            |              |
        |            |------------>|            |              |
        |            |             | (4) Lookup |              |
        |            |             | semantic   |              |
        |            |             | table      |              |
        |            |             | Execute TLV|              |
        |            |             | actions    |              |
        |            |             |----------->|              |
        |            |             |            |              |

Li, et al.              Expires 1 September 2026               [Page 10]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

                     Figure 3: Centralized Control Flow

6.2.  Detailed Operation Steps

   1.  Client Request Phase:

       The client sends a request to the controller, with the request
       type being "semantic action request for fine-grained or
       application-level SLA guarantee at transit nodes."

   2.  Semantic Table Distribution Phase:

       The controller sends semantic tables to each node.

   3.  Service Packet Transmission Phase:

       The client sends service packets carrying the mechanism header.

   4.  Node Processing Phase:

       Each node receives the packet, looks up the semantic table, and
       executes the actions indicated by the packet TLV.

6.3.  Error Handling

   Implementations MUST handle the following error conditions:

   *  Unknown ADDR: If a packet contains an ADDR that is not present in
      the local semantic table, the node SHOULD forward the packet using
      default QoS settings and MAY log the event.

   *  Invalid TLV: If a TLV with an unknown Type is encountered, the
      node SHOULD skip to the next TLV using the Length field and
      continue processing.

   *  Malformed Packet: If the packet structure is invalid (e.g.,
      truncated TLV), the node SHOULD drop the packet and MAY increment
      an error counter.

7.  Security Considerations

   The semantic table mechanism introduces the following security
   considerations:

   Semantic tables contain user and application identification
   information that may be sensitive.  Unauthorized access to semantic
   table contents could reveal service topology and user behavior
   patterns.  Implementations MUST enforce access control for semantic

Li, et al.              Expires 1 September 2026               [Page 11]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

   table read and write operations.  Semantic table distribution
   channels SHOULD be protected using authentication and encryption
   mechanisms.

   The ADDR field carried in packets serves as an index into semantic
   tables.  An attacker who can observe ADDR values may infer
   application or user group membership.  When operating across trust
   domain boundaries, implementations SHOULD consider encrypting or
   obfuscating ADDR values.

   Malicious injection of packets with crafted ADDR and TLV values could
   cause nodes to apply incorrect QoS policies.  Implementations SHOULD
   validate that incoming packets originate from authorized sources
   before applying semantic table actions.  BCP 38 ingress filtering
   SHOULD be applied at network boundaries.

8.  IANA Considerations

   This document requests IANA to create a new registry titled "Fine-
   grained QoE TLV Types" under an appropriate registry group.

   The initial contents of the registry are defined in Section 5.3.  The
   registration policy for new entries is Specification Required
   [RFC8126].

   If the SRv6 extension defined in Section 5.4 is used, the SRv6 SID
   Function value used for semantic table lookup is allocated from the
   SRv6 Endpoint Behaviors registry defined in RFC 8986.  This document
   does not request a specific allocation at this time; allocation will
   be requested when the mechanism is further specified.

9.  References

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

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

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

Li, et al.              Expires 1 September 2026               [Page 12]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

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

9.2.  Informative References

   [I-D.ietf-apn-framework]
              Liu, P., Peng, S., Li, Z., and C. Li, "Application-aware
              Networking (APN) Framework", Work in Progress, Internet-
              Draft, draft-ietf-apn-framework-10, October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-apn-
              framework>.

Acknowledgements

   The authors would like to thank the members of the SPRING working
   group for their valuable feedback and discussions.

Contributors

   The following individuals contributed to this document:

   [Contributor Name]
   [Organization]
   Email: [email@example.com]

Authors' Addresses

   Zhiqiang Li
   China Mobile
   32 Xuanwumen West Street
   Beijing
   100053
   China
   Email: lizhiqiangyjy@chinamobile.com

   Zongpeng Du
   China Mobile
   32 Xuanwumen West Street
   Beijing
   100053
   China
   Email: duzongpeng@chinamobile.com

Li, et al.              Expires 1 September 2026               [Page 13]
Internet-Draft        Fine-grained QoE Enhancement         February 2026

   Wei Cheng
   Centec Networks
   Suzhou
   215000
   China
   Email: chengw@centec.com

   Junjie Wang
   Centec Networks
   Suzhou
   215000
   China
   Email: wangjj@centec.com

   Guoying Zhang
   Centec Networks
   Suzhou
   215000
   China
   Email: zhanggy@centec.com

Li, et al.              Expires 1 September 2026               [Page 14]