Fine-grained QoE Enhancement using Semantic Tables

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

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

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

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

2. Terminology

This document uses the following terminology:¶

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

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¶

5. Protocol Specification

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

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

6. Protocol Operations

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

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

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

Authors' Addresses