Network Working Group J. Wang Internet-Draft China Mobile Intended status: Informational 6 July 2026 Expires: 7 January 2027 Token Service Flow Awareness: Use Cases and Requirements draft-wang-token-aware-usecases-requirements-00 Abstract This document outlines the use cases and requirements for token service flow awareness, providing the IETF working group with a standardized reference to better support the assurance of the user’s end-to-end experience. 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 7 January 2027. 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. Wang Expires 7 January 2027 [Page 1] Internet-Draft Token Service Flow Awareness: Use Cases July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Service Identification . . . . . . . . . . . . . . . . . 3 3.2. Operation Management . . . . . . . . . . . . . . . . . . 3 3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Service Identification . . . . . . . . . . . . . . . . . 4 4.2. Operation Management . . . . . . . . . . . . . . . . . . 4 4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. Informative References . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction In recent years, there has been a significant increase in the use of generative AI, LLM MaaS platforms, and autonomous AI Agents as mainstream internet services. Unlike traditional web, video, and file transfer traffic, AI services generate unique token-bearing flows. These include prompt/output token streaming, cross-Agent A2A collaborative token packets, and authorization tokens carried in JWT/ OAuth headers. AI token flows have distinct business attributes, such as ultra-low Time-To-First-Token (TTFT) latency for interactive Agent dialogue, longer transmission delay tolerance for offline batch inference, and stable cross-domain connectivity for cross-industry multi-Agent collaboration. However, current network traffic classification systems only identify generic application domains through SNI and DNS fingerprints, lacking fine-grained awareness of token volume, task priority, and Agent identity. This lack of dedicated token flow identification capabilities hinders operators from deploying differentiated QoS strategies, implementing token-based metering billing, and executing compute-aware routing optimization. As a result, there are consequences such as inconsistent dialogue latency, unfair bandwidth resource contention, inability to quantify AI service revenue, and unmonitored abnormal token consumption attacks. Against this background, this document outlines the use cases and requirements for token service flow awareness, providing the IETF working group with a standardized reference to better support the assurance of the user’s end-to-end experience.. Wang Expires 7 January 2027 [Page 2] Internet-Draft Token Service Flow Awareness: Use Cases July 2026 2. Conventions 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. 3. Use Cases This document categorizes use cases into service identification, operation & management and routing, 3.1. Service Identification The core goal of sevice identification is to map raw packet flows to standardized token service types to deliver differentiated user experience and tiered service packages. For example, personal multi- modal assistants, vehicle-mounted MUI Agents and customer service Agents generate low-latency interactive token streams. After identification, the network can implement various optimization measures to reduce TTFT jitter. 3.2. Operation Management The use case of operation management focus on full lifecycle monitoring, risk control and statistical analysis based on identified token flow tags. Network management platforms aggregate identified token flow data to analyze industry distribution of Agent services, and forecast token traffic growth for capacity planning of edge computing and backbone links. 3.3. Routing The use case of routing realize compute-network collaborative steering by leveraging token flow business attributes. For example, after marking interactive token flows, routing planes dynamically select nearby edge computing gateway links, avoiding long-distance backbone transmission to cut end-to-end latency. This enables latency-priority routing of real-time token streams. 4. Requirements Corresponding to the three use cases, this chapter defines mandatory and optional requirements for service identification, operation management and routing steering respectively. Wang Expires 7 January 2027 [Page 3] Internet-Draft Token Service Flow Awareness: Use Cases July 2026 4.1. Service Identification Identification equipment SHALL parse plaintext token count headers in SSE/gRPC/MCP streaming protocols, and extract Agent ID, task type and authorization token fields. For fully encrypted TLS traffic, the system MUST implement traffic fingerprint recognition based on packet interval, burst small-packet characteristics and TTFT statistical features to classify token flows without payload decryption. 4.2. Operation Management To ensure the smooth operation of the service, the operations management platform should support the ability to record service logs. All identified token flows SHALL generate structured logs containing five-tuple, token label, total token volume, start/end timestamp and Agent identity information, , stored for no less than user service period for audit. 4.3. Routing It should support different routing policies for different services to provide differentiated service guarantees and meet the needs of different users. In addition, routing nodes supporting KV context cache reuse shall match token flow labels to cache corresponding prompt data, reducing repeated token transmission volume and link load. 5. Conclusion This document outlines the use cases and requirements for token service flow awareness and provides an overview from three perspectives: service identification, operation management and routing, 6. Security Considerations TBD. 7. IANA Considerations TBD. 8. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Wang Expires 7 January 2027 [Page 4] Internet-Draft Token Service Flow Awareness: Use Cases July 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Author's Address Jing Wang China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: wangjingjc@chinamobile.com Wang Expires 7 January 2027 [Page 5]