CATS B. Zhang, Ed. Internet-Draft Pengcheng Laboratory Intended status: Standards Track Y. Dai, Ed. Expires: 22 January 2027 Sun Yat-sen University 21 July 2026 CATS Client Service Request Packet Format (IPv6 Extension Header and Payload-Based Carriage of CS-ID and Network/Computing Requirement Parameters) draft-zhang-cats-clients-request-packet-00 Abstract This document specifies two complementary mechanisms for carrying the CATS Service Identifier (CS-ID) and network/computing requirement parameters in client service request packets within the Computing- Aware Traffic Steering (CATS) framework. Mode A uses IPv6 Extension Headers to carry CS-ID and requirement parameters as hop-by-hop or destination options, enabling in-band signaling that is visible to all CATS-aware network nodes along the path. Mode B uses a payload-based TLV structure that is transport- protocol agnostic and can be used with both IPv4 and IPv6, as well as with encrypted transports. The document defines the Virtual Placeholder Address (VPA) prefix requirements, the CATS Service Request Extension Header (CSREH) format, the CATS Service Request TLV format, and the CATS_PACKET_IN process for handling these packets at ingress CATS-Forwarders. 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 22 January 2027. Zhang & Dai Expires 22 January 2027 [Page 1] Internet-Draft CATS Client Request Packet July 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Virtual Placeholder Address (VPA) . . . . . . . . . . . . . . 5 3.1. VPA Prefix Requirements . . . . . . . . . . . . . . . . . 5 3.2. VPA Catch-All Route Configuration . . . . . . . . . . . . 6 4. Client Service Request Packet Overview . . . . . . . . . . . 6 5. Mode A: IPv6 Extension Header-Based Carriage . . . . . . . . 7 5.1. CATS Service Request Extension Header . . . . . . . . . . 7 5.2. CS-ID Option Format . . . . . . . . . . . . . . . . . . . 8 5.3. Network Requirement Option Format . . . . . . . . . . . . 9 5.4. Computing Requirement Option Format . . . . . . . . . . . 11 5.5. Extension Header Processing Rules . . . . . . . . . . . . 12 6. Mode B: Payload-Based Carriage . . . . . . . . . . . . . . . 13 6.1. CATS Service Request TLV Format . . . . . . . . . . . . . 13 6.2. TLV Type Definitions . . . . . . . . . . . . . . . . . . 14 6.3. CS-ID TLV . . . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Network Requirements TLV . . . . . . . . . . . . . . . . 15 6.5. Computing Requirements TLV . . . . . . . . . . . . . . . 16 6.6. Payload Processing Rules . . . . . . . . . . . . . . . . 17 7. Dual-Mode Operation and Interoperability . . . . . . . . . . 17 8. CATS_PACKET_IN Process . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9.1. CS-ID Spoofing . . . . . . . . . . . . . . . . . . . . . 19 9.2. Requirement Parameter Manipulation . . . . . . . . . . . 20 9.3. Extension Header Amplification . . . . . . . . . . . . . 20 9.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 20 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 10.1. Service Fingerprinting . . . . . . . . . . . . . . . . . 21 10.2. Requirement Disclosure . . . . . . . . . . . . . . . . . 21 10.3. Location Privacy . . . . . . . . . . . . . . . . . . . . 21 Zhang & Dai Expires 22 January 2027 [Page 2] Internet-Draft CATS Client Request Packet July 2026 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11.1. IPv6 Next Header Value . . . . . . . . . . . . . . . . . 21 11.2. IPv6 Hop-by-Hop Option Types . . . . . . . . . . . . . . 22 11.3. CATS TLV Registry . . . . . . . . . . . . . . . . . . . 22 11.4. Requirement Type Registries . . . . . . . . . . . . . . 22 12. Packet Format Examples . . . . . . . . . . . . . . . . . . . 23 12.1. Example 1: Mode A - AI Inference Service Request . . . . 23 12.2. Example 2: Mode B - Gaming Service Request . . . . . . . 24 12.3. Example 3: Dual Mode - Video Streaming Service . . . . . 25 13. YANG Data Model for CATS Request Parameters . . . . . . . . . 26 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 15.1. Normative References . . . . . . . . . . . . . . . . . . 28 15.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Authors' Addresses . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction The Computing-Aware Traffic Steering (CATS) framework [I-D.ietf-cats-framework] defines an architecture for steering service requests to the most suitable service contact instance based on both network and computing metrics. Clients need a mechanism to express not only which service they want to access, but also the specific network and computing requirements that enable optimal instance selection. This document addresses this gap by providing a standardized message format for clients to explicitly declare: * the CS-ID (Computing-aware Service ID) they wish to access; * network requirements such as bandwidth; * computing requirements such as computing time; This document specifies two complementary mechanisms for carrying CS- ID and requirement parameters in client service request packets: * Mode A - Extension Header-Based Carriage: Leverages IPv6 Extension Headers [RFC8200] to carry CS-ID and requirement parameters as hop-by-hop or destination options. This mode provides in-band signaling that is visible to all CATS-aware network nodes along the path, enabling early classification and steering decisions at ingress CATS-Forwarders. Zhang & Dai Expires 22 January 2027 [Page 3] Internet-Draft CATS Client Request Packet July 2026 * Mode B - Payload-Based Carriage: Encapsulates CS-ID and requirement parameters within a dedicated CATS Service Request TLV structure carried in the packet payload. This mode is transport- protocol agnostic and can be used with both IPv4 and IPv6, as well as with encrypted transports where extension headers may not be accessible. Both modes MAY be used independently or in combination. When both modes are present in a single packet, the extension header information takes precedence for CATS-Forwarder processing, while the payload-based information is used as a fallback or for end-to-end service negotiation. The Virtual Placeholder Address (VPA) serves as the destination address for all service requests, ensuring that packets addressed to it reach an ingress CATS-Forwarder for CATS_PACKET_IN processing. 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 terms defined in [I-D.ietf-cats-framework] and [I-D.zhangb-cats-service-metrics-op]: * CATS Service ID (CS-ID) * CATS Service Contact Instance ID (CSCI-ID) * CATS-Forwarder (Ingress/Egress) * CATS Path Selector (C-PS) * CATS Traffic Classifier (C-TC) * Global Available Slots (GAS) Additionally, this document defines the following terms: Virtual Placeholder Address (VPA): A non-routable address within a configured prefix that serves as the destination address for CATS service requests. Packets addressed to a VPA are intercepted by ingress CATS-Forwarders and trigger the CATS_PACKET_IN process. Zhang & Dai Expires 22 January 2027 [Page 4] Internet-Draft CATS Client Request Packet July 2026 CATS Service Request Packet: A packet sent by a client to initiate a service request within the CATS domain. Such packets carry a CS- ID and optionally, network and computing requirement parameters. Network Requirement Parameter: A quantitative/qualitative constraint or preference related to network performance, such as maximum latency, minimum bandwidth, or maximum packet loss. Computing Requirement Parameter: A quantitative/qualitative constraint or preference related to computing services, such as GAS, computing time, or cost. 3. Virtual Placeholder Address (VPA) 3.1. VPA Prefix Requirements The VPA prefix MUST satisfy the following requirements: 1. Globally Unique: The VPA prefix MUST be globally unique within the CATS domain to avoid ambiguity in service request routing. Multiple CATS domains MAY use distinct VPA prefixes. 2. Non-Routable in Underlay: The VPA prefix MUST NOT be routable in the underlay IP infrastructure. This ensures that packets addressed to a VPA are not forwarded by standard IP routing but are instead intercepted by ingress CATS-Forwarders. 3. Sufficiently Large: The VPA prefix MUST be sufficiently large to allow sub-prefix allocation per service category if desired. The following prefix lengths are RECOMMENDED: * IPv4: /16 prefix (65,536 addresses), allowing /24 sub-prefixes per service category. * IPv6: /48 prefix (2^80 addresses), allowing /64 sub-prefixes per service category. 4. Administratively Scoped: The VPA prefix SHOULD be allocated from administratively scoped address space (e.g., RFC1918 for IPv4, Unique Local Addresses [RFC4193] for IPv6) to prevent conflicts with the global Internet. Example VPA Prefix Allocations: Zhang & Dai Expires 22 January 2027 [Page 5] Internet-Draft CATS Client Request Packet July 2026 +----------------+------------------+----------------------------+ | Address Family | Recommended Prefix | Example Allocation | +----------------+------------------+----------------------------+ | IPv4 | 10.128.0.0/16 | 10.128.0.0/24 = AI Service | | | | 10.128.1.0/24 = Gaming | | | | 10.128.2.0/24 = Video | +----------------+------------------+----------------------------+ | IPv6 | fd00:cats::/48 | fd00:cats:1::/64 = AI | | | | fd00:cats:2::/64 = Gaming | | | | fd00:cats:3::/64 = Video | +----------------+------------------+----------------------------+ 3.2. VPA Catch-All Route Configuration The VPA prefix SHOULD be configured on all ingress CATS-Forwarders as a "catch-all" route pointing to a local CPU/handling pipeline. This configuration triggers the CATS_PACKET_IN process when a packet with a VPA destination address arrives. The catch-all route configuration MUST include the following: * Route destination: The configured VPA prefix. * Next hop: Local CPU/handling pipeline (not a remote next hop). * Action: Trigger CATS_PACKET_IN and invoke C-TC classification. The CATS_PACKET_IN process performs the following operations: 1. Extract the CS-ID from the packet (via extension header or payload parsing). 2. Extract network and computing requirement parameters. 3. Query the C-PS for path selection based on CS-ID and parameters. 4. Install forwarding state for the flow. 5. Forward the packet along the CATS-computed path. 4. Client Service Request Packet Overview A client service request packet has the following general structure: Zhang & Dai Expires 22 January 2027 [Page 6] Internet-Draft CATS Client Request Packet July 2026 +---------------------------------------------------------------+ | IP Header (IPv4 or IPv6) | | Source: Client's real IP address | | Destination: VPA within configured prefix | +---------------------------------------------------------------+ | [Optional] IPv6 Extension Headers (Mode A) | | - CATS Service Request Extension Header | +---------------------------------------------------------------+ | Transport Header (TCP/UDP/QUIC/etc.) | +---------------------------------------------------------------+ | [Optional] CATS Service Request TLV (Mode B) | | - Carried in transport payload | +---------------------------------------------------------------+ | Application Payload | +---------------------------------------------------------------+ Source IP/MAC: The client's real network address. Destination IP: A VPA within the configured prefix. The specific VPA MAY encode service category information in sub-prefix bits. The packet MUST contain a CS-ID, carried via either Mode A (extension header) or Mode B (payload), or both. 5. Mode A: IPv6 Extension Header-Based Carriage 5.1. CATS Service Request Extension Header This document defines a new IPv6 Extension Header called the "CATS Service Request Extension Header" (CSREH). The CSREH is a Hop-by-Hop Options Header [RFC8200] that carries CATS-specific information visible to all CATS-aware nodes along the forwarding path. The CSREH uses the Next Header value TBD1 (to be assigned by IANA). CSREH Format: Zhang & Dai Expires 22 January 2027 [Page 7] Internet-Draft CATS Client Request Packet July 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | CS-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CS-ID (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | Network Req Parameters... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | Computing Req Parameters... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header (8 bits): Identifies the type of header immediately following the CSREH. Uses standard IP protocol numbers. Hdr Ext Len (8 bits): Length of the CSREH in 8-octet units, not including the first 8 octets. Minimum value is 0 (8 octets total). Reserved (16 bits): MUST be set to zero on transmission and ignored on reception. Options: Variable-length options carrying CS-ID, network requirements, and computing requirements. Each option uses the standard IPv6 Options format [RFC8200]. The CSREH MUST contain exactly one CS-ID Option. It MAY contain zero or one Network Requirement Option and zero or one Computing Requirement Option. 5.2. CS-ID Option Format The CS-ID Option carries the CATS Service Identifier. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|1|0|0|0|0| Opt Data Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + CS-ID (variable) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhang & Dai Expires 22 January 2027 [Page 8] Internet-Draft CATS Client Request Packet July 2026 Option Type: 0x10 (TBD2 - to be assigned by IANA): Bits 00 (skip if not recognized); Bit 0 (does not change en-route) Opt Data Len (8 bits): Length of the CS-ID field in octets. RECOMMENDED values: * 2: 16-bit CS-ID (small-scale deployments) * 4: 32-bit CS-ID (standard deployments) * 8: 64-bit CS-ID (large-scale deployments) * 16: 128-bit CS-ID (UUID-based identifiers) CS-ID (variable length): The CATS Service Identifier. The length and semantics of the CS-ID are deployment-specific but MUST be consistent within a CATS domain. 5.3. Network Requirement Option Format The Network Requirement Option carries network performance constraints requested by the client. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|1|0|0|0|1| Opt Data Len | Num Req | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Network Requirement Entries ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type: 0x11 (TBD3 - to be assigned by IANA) Num Req (8 bits): Number of Network Requirement Entries following this field. Reserved (8 bits): MUST be set to zero on transmission and ignored on reception. Network Requirement Entry Format: Zhang & Dai Expires 22 January 2027 [Page 9] Internet-Draft CATS Client Request Packet July 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Req Type | Req Flags | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | Unit Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Req Type (8 bits): Identifies the type of network requirement: +--------+--------------------------------+-----------+ | Value | Requirement Type | Unit Code| +--------+--------------------------------+-----------+ | 0x01 | Maximum Latency | 0x01=ms | | 0x02 | Minimum Bandwidth | 0x02=Mbps | | 0x03 | Maximum Packet Loss Rate | 0x03=% | | 0x04 | Maximum Jitter | 0x04=ms | | 0x05 | Minimum Throughput | 0x05=Mbps | | 0x06 | Maximum Path Hops | 0x06=count| | 0x07 | Path Diversity Required | 0x07=bool | | 0x08 | Encryption Required | 0x08=bool | | 0x09-0xFF | Reserved for future use | | +--------+--------------------------------+-----------+ Req Flags (8 bits): Bit 0 (0x01): HARD constraint - MUST be satisfied; Bit 1 (0x02): SOFT constraint - SHOULD be satisfied; Bit 2 (0x04): PREFERENCE - preferred but not required; Bits 3-7: Reserved, MUST be zero Value (32 bits): The numerical value of the requirement. Interpretation depends on the Req Type and Unit Code. The value zero is reserved as a qualitative indicator for all requirement types. It Indicates that the client requires the optimal services for the corresponding requirement type. For example: * Maximum Latency=0: selecting the minimum latency among all candidates * Minimum Bandwidth=0: selecting the maximum bandwidth among all candidates * Maximum Packet Loss Rate=0: selecting the minimum Packet Loss Rate among all candidates * Maximum Jitter=0: selecting the minimum Jitter among all candidates Unit Code (16 bits): Specifies the unit of the Value field: Zhang & Dai Expires 22 January 2027 [Page 10] Internet-Draft CATS Client Request Packet July 2026 +--------+---------------------+--------+-------------------+ | Value | Unit | Value | Unit | +--------+---------------------+--------+-------------------+ | 0x0001 | Milliseconds (ms) | 0x0007 | Gbps | | 0x0002 | Megabits/sec (Mbps) | 0x0008 | Bytes/sec (Bps) | | 0x0003 | Percentage (%) | 0x0009 | Kbps | | 0x0004 | Count (integer) | 0x000A | Hops (count) | | 0x0005 | Boolean (0/1) | 0x000B | Reserved | | 0x0006 | Microseconds (us) | 0x000C | Reserved | +--------+---------------------+--------+-------------------+ 5.4. Computing Requirement Option Format The Computing Requirement Option carries computing service constraints requested by the client. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|1|0|0|1|0| Opt Data Len | Num Req | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Computing Requirement Entries ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type: 0x12 (TBD4 - to be assigned by IANA) Num Req (8 bits): Number of Computing Requirement Entries following this field. Reserved (8 bits): MUST be set to zero on transmission and ignored on reception. Computing Requirement Entry Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Req Type | Req Flags | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont.) | Unit Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Req Type (8 bits): Identifies the type of computing requirement: Zhang & Dai Expires 22 January 2027 [Page 11] Internet-Draft CATS Client Request Packet July 2026 +--------+--------------------------------+------------+ | Value | Requirement Type | Unit Code | +--------+--------------------------------+-----------+ | 0x01 | Minimum GAS | 0x01=count| | 0x02 | Maximum Computing Time | 0x02=ms | | 0x03 | Maximum Cost | 0x03=count| | 0x04 | Minimum Reputation | 0x04=count| | 0x05 | Minimum Security Label | 0x05=count| | 0x06 | Minimum Capability | 0x06=count| | 0x07-0xFF | Reserved for future use | | +--------+--------------------------------+------------+ Req Flags (8 bits): Same format as Network Requirement Option (Section 5.3). Value (32 bits): The numerical value of the requirement. Interpretation depends on the Req Type and Unit Code. The value zero is reserved as a qualitative indicator for all requirement types. It Indicates that the client requires the optimal services for the corresponding requirement type. For example: * Minimum GAS=0: selecting the maximum GAS among all candidates * Maximum Computing Time=0: selecting the minimum Computing Time among all candidates * Maximum Cost=0: selecting the minimum Cost among all candidates * Minimum Reputation=0: selecting the maximum Reputation among all candidates * Minimum Security Label=0: selecting the maximum Security Label among all candidates Unit Code (16 bits): Same values as defined in Section 5.3. 5.5. Extension Header Processing Rules 1. A CATS-Forwarder receiving a packet with a CSREH MUST process the CS-ID Option. If the CS-ID Option is absent, the packet MUST be dropped and an ICMP Parameter Problem message MAY be sent to the source. 2. If the CSREH contains multiple CS-ID Options, only the first one MUST be processed; subsequent CS-ID Options MUST be ignored. Zhang & Dai Expires 22 January 2027 [Page 12] Internet-Draft CATS Client Request Packet July 2026 3. Network and Computing Requirement Options are OPTIONAL. If absent, the C-PS SHOULD use default policies or service-specific profiles configured by the operator. 4. A CATS-Forwarder that does not recognize the CSREH Next Header value MUST pass the packet to the next header processor without modification (standard IPv6 extension header behavior). 5. The CSREH MUST be removed by the Egress CATS-Forwarder before delivering the packet to the service contact instance, unless the service contact instance is explicitly configured to receive CATS signaling. 6. Mode B: Payload-Based Carriage 6.1. CATS Service Request TLV Format Mode B uses a Type-Length-Value (TLV) structure carried in the transport payload. This mode is independent of the IP version and can be used with any transport protocol. The CATS Service Request TLV structure is placed at the beginning of the transport payload, before any application-specific data. A magic number identifies the presence of the CATS TLV block. Overall Structure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Number | | (0x43415453 = "CATS") | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Flags | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV Block(s) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Application Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Magic Number (32 bits): Fixed value 0x43415453 (ASCII "CATS"). Used to detect the presence of the CATS TLV block in the payload. Version (8 bits): Version of the CATS TLV format. This document Zhang & Dai Expires 22 January 2027 [Page 13] Internet-Draft CATS Client Request Packet July 2026 specifies version 0x01. Flags (8 bits): Bit 0 (0x01): EXT_HEADER_PRESENT - Set if Mode A extension header is also present in this packet; Bit 1 (0x02): ENCRYPTED - Set if the TLV block is encrypted (future use); Bit 2 (0x04): SIGNED - Set if the TLV block is signed (future use); Bits 3-7: Reserved, MUST be zero. Total Length (16 bits): Total length of the TLV block(s) in octets, including this header but excluding the Magic Number. TLV Block Format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Flags | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type (8 bits): Identifies the type of TLV (see Section 6.2). TLV Flags (8 bits): Bit 0 (0x01): CRITICAL - If set and this TLV is not understood, the entire packet MUST be dropped; Bit 1 (0x02): MUST_HONOR - The requirement MUST be satisfied; if not possible, the request MUST be rejected; Bits 2-7: Reserved, MUST be zero. TLV Length (16 bits): Length of the TLV Value field in octets. 6.2. TLV Type Definitions Zhang & Dai Expires 22 January 2027 [Page 14] Internet-Draft CATS Client Request Packet July 2026 +--------+---------------------------+--------------------------------+ | Type | Name | Description | +--------+---------------------------+--------------------------------+ | 0x01 | CS-ID TLV | CATS Service ID | | 0x02 | Network Requirements TLV | Network params | | 0x03 | Computing Requirements TLV| Computing params | | 0x04 | Service Contact Instance ID| CSCI-ID (optional) | | 0x05 | Client Capability TLV | Client capabilities | | 0x06 | Request Timestamp TLV | Request time | | 0x07 | Request Nonce TLV | Anti-replay nonce | | 0x08 | Service Affinity TLV | Affinity hint | | 0x09 | QoS Class TLV | Traffic class | | 0x0A-0x7F | Reserved for CATS use | | | 0x80-0xFF | Private/Experimental | | +--------+---------------------------+--------------------------------+ 6.3. CS-ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | TLV Flags | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Length | | +-+-+-+-+-+-+-+-+ + | | ~ CS-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID Length (8 bits): Length of the CS-ID in octets. RECOMMENDED values: 2, 4, 8, 16. CS-ID (variable): The CATS Service Identifier. Same semantics as in Mode A. 6.4. Network Requirements TLV Zhang & Dai Expires 22 January 2027 [Page 15] Internet-Draft CATS Client Request Packet July 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x02 | TLV Flags | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Req | | +-+-+-+-+-+-+-+-+ + | | ~ Network Requirement Entries ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Num Req (8 bits): Number of Network Requirement Entries. Network Requirement Entry (TLV Mode): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Req Type | Req Flags | Unit Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Req Type (8 bits): Same values as defined in Section 5.3. Req Flags (8 bits): Bit 0 (0x01): HARD - Hard constraint; Bit 1 (0x02): SOFT - Soft constraint; Bit 2 (0x04): PREF - Preference; Bits 3-7: Reserved Unit Code (16 bits): Same values as defined in Section 5.3. Value (32 bits): The numerical value of the requirement. 6.5. Computing Requirements 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 | TLV Flags | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Req | | +-+-+-+-+-+-+-+-+ + | | ~ Computing Requirement Entries ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhang & Dai Expires 22 January 2027 [Page 16] Internet-Draft CATS Client Request Packet July 2026 Num Req (8 bits): Number of Computing Requirement Entries. Computing Requirement Entry (TLV Mode): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Req Type | Req Flags | Unit Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Req Type (8 bits): Same values as defined in Section 5.4. Req Flags (8 bits): Same format as Network Requirements TLV. Unit Code (16 bits): Same values as defined in Section 5.4. Value (32 bits): The numerical value of the requirement. 6.6. Payload Processing Rules 1. A CATS-Forwarder processing a packet in payload mode MUST scan the transport payload for the Magic Number 0x43415453. 2. If the Magic Number is found, the CATS-Forwarder MUST parse the TLV block to extract the CS-ID and requirement parameters. 3. If the Magic Number is not found and the packet is addressed to a VPA, the CATS-Forwarder MAY attempt deep packet inspection or MAY drop the packet depending on local policy. 4. The CATS TLV block SHOULD be removed by the Egress CATS-Forwarder before delivering the packet to the service contact instance, unless the service contact instance is configured to receive it. 5. If both Mode A and Mode B are present, the CATS-Forwarder MUST use the Mode A (extension header) information for CATS processing and MAY validate consistency with Mode B information. 7. Dual-Mode Operation and Interoperability This section defines the behavior when both Mode A and Mode B are present in a single packet. Zhang & Dai Expires 22 January 2027 [Page 17] Internet-Draft CATS Client Request Packet July 2026 +-----------------+-----------------+-------------------------------------------+ | Mode A Present | Mode B Present | CATS-Forwarder Behavior | +-----------------+-----------------+------------------------------------------+ | Yes | Yes | Use Mode A; validate consistency | | Yes | No | Use Mode A | | No | Yes | Use Mode B | | No | No | Drop or DFI | +-----------------+-----------------+-------------------------------------------+ DFI = Deep Flow Inspection (operator-configured fallback) Consistency Validation: When both modes are present, the CATS-Forwarder SHOULD verify that the CS-ID values match. If they do not match, the packet MUST be dropped and a CATS error notification MAY be logged. 8. CATS_PACKET_IN Process The CATS_PACKET_IN process is triggered when an ingress CATS- Forwarder receives a packet destined to a VPA. The process consists of the following steps: 1. Step 1: Packet Interception The ingress CATS-Forwarder matches the destination address against the configured VPA catch-all route and redirects the packet to the local CPU/handling pipeline. 2. Step 2: CS-ID Extraction The C-TC examines the packet for CS-ID: * First, check for Mode A (CSREH with CS-ID Option). * If not found, check for Mode B (CATS TLV block with CS-ID TLV). * If neither is found, apply operator-configured fallback (e.g., drop, default service, or deep packet inspection). 3. Step 3: Requirement Parameter Extraction Extract network and computing requirement parameters from the same source as the CS-ID (Mode A or Mode B). 4. Step 4: Path Selection Zhang & Dai Expires 22 January 2027 [Page 18] Internet-Draft CATS Client Request Packet July 2026 The C-PS performs path selection using: * CS-ID (required) * Network requirements (optional, defaults if absent) * Computing requirements (optional, defaults if absent) * Current network metrics from C-NMA * Current computing metrics from C-SMA 5. Step 5: Flow State Installation Install forwarding state in the CATS-Forwarder to ensure all subsequent packets of this flow are steered to the selected service contact instance. 6. Step 6: Packet Forwarding Encapsulate the packet (if needed) and forward it along the CATS- computed path to the selected Egress CATS-Forwarder. Flow Identification: For flow state installation, the flow is typically identified by the 5-tuple (source IP, destination IP, source port, destination port, protocol). The CATS-Forwarder MAY use additional fields (e.g., flow label) for finer-grained identification. 9. Security Considerations This section describes security considerations for the CATS client service request packet format. 9.1. CS-ID Spoofing An attacker could forge a packet with a legitimate CS-ID to redirect traffic to an unauthorized service contact instance. To mitigate this: * Ingress CATS-Forwarders SHOULD authenticate the source of service requests using existing mechanisms (e.g., IPsec, TLS, or network- layer authentication). * The VPA prefix SHOULD be protected by ingress filtering [RFC2827] to prevent external injection of spoofed packets. Zhang & Dai Expires 22 January 2027 [Page 19] Internet-Draft CATS Client Request Packet July 2026 9.2. Requirement Parameter Manipulation An attacker could modify requirement parameters to cause denial of service (e.g., requesting impossible resource combinations) or to steer traffic to overloaded instances. Mitigations: * C-PS implementations SHOULD validate requirement parameters against operator-defined bounds. * Requirement parameters carried in Mode B SHOULD be integrity- protected using transport-layer security (e.g., TLS, DTLS). 9.3. Extension Header Amplification Maliciously crafted extension headers with excessive options could cause processing overhead. Mitigations: * CATS-Forwarders SHOULD enforce a maximum CSREH length (RECOMMENDED: 256 octets). * Unknown or malformed options SHOULD be handled according to the option type bits (skip, discard, discard with ICMP). 9.4. Privacy The CS-ID may reveal information about the service being accessed. When privacy is a concern: * Use encrypted transports (TLS, QUIC) to protect Mode B TLVs. * Consider that Mode A extension headers are visible to all on-path nodes. 9.5. Replay Attacks An attacker could replay captured service request packets to exhaust computing resources. Mitigations: * The Request Nonce TLV (Type 0x07) MAY be used to detect replays. * CATS-Forwarders SHOULD implement rate limiting per source. Zhang & Dai Expires 22 January 2027 [Page 20] Internet-Draft CATS Client Request Packet July 2026 10. Privacy Considerations The CATS client service request packet format raises the following privacy considerations: 10.1. Service Fingerprinting The CS-ID may allow on-path observers to infer which service a client is accessing. This is particularly relevant for Mode A, where the CS-ID is carried in a visible extension header. Mitigation: Clients concerned about service fingerprinting SHOULD use Mode B with encrypted transports, or request that the operator deploy per-client VPAs. 10.2. Requirement Disclosure Computing requirement parameters may reveal sensitive information about the client's workload type or data sensitivity. Mitigation: Requirement parameters SHOULD be encrypted when transmitted over untrusted networks. Mode B with TLS provides this protection. 10.3. Location Privacy The source IP address in the service request packet reveals the client's network location. This is inherent to IP networking and not specific to CATS. Mitigation: Standard IP privacy techniques (e.g., VPNs, proxies) may be used in conjunction with CATS. 11. IANA Considerations This document requests IANA to make the following assignments: 11.1. IPv6 Next Header Value A new IPv6 Next Header value for the CATS Service Request Extension Header (CSREH): +--------+-----------------------------+-----------+ | Value | Protocol | Reference | +--------+-----------------------------+-----------+ | TBD1 | CATS Service Request EH | This doc | +--------+-----------------------------+-----------+ Zhang & Dai Expires 22 January 2027 [Page 21] Internet-Draft CATS Client Request Packet July 2026 11.2. IPv6 Hop-by-Hop Option Types Three new IPv6 Hop-by-Hop Option Types: +--------+-----------------------------------+-----------+ | Value | Name | Reference | +--------+-----------------------------------+-----------+ | TBD2 | CS-ID Option | This doc | | TBD3 | Network Requirement Option | This doc | | TBD4 | Computing Requirement Option | This doc | +--------+-----------------------------------+-----------+ 11.3. CATS TLV Registry A new registry for CATS Service Request TLV Types: Registry Name: CATS Service Request TLV Types Registration Procedure: Standards Action for 0x00-0x7F, Expert Review for 0x80-0xFF Initial assignments: +--------+---------------------------+-----------+ | Type | Name | Reference | +--------+---------------------------+-----------+ | 0x00 | Reserved | This doc | | 0x01 | CS-ID TLV | This doc | | 0x02 | Network Requirements TLV | This doc | | 0x03 | Computing Requirements TLV| This doc | | 0x04 | CSCI-ID TLV | This doc | | 0x05 | Client Capability TLV | This doc | | 0x06 | Request Timestamp TLV | This doc | | 0x07 | Request Nonce TLV | This doc | | 0x08 | Service Affinity TLV | This doc | | 0x09 | QoS Class TLV | This doc | | 0x0A-0x7F | Unassigned | | | 0x80-0xFF | Private/Experimental | This doc | +--------+---------------------------+-----------+ 11.4. Requirement Type Registries Two new registries for Network and Computing Requirement Types: * Registry Name: CATS Network Requirement Types; Registration Procedure: Expert Review Zhang & Dai Expires 22 January 2027 [Page 22] Internet-Draft CATS Client Request Packet July 2026 * Registry Name: CATS Computing Requirement Types; Registration Procedure: Expert Review Initial assignments as specified in Sections 5.3 and 5.4. 12. Packet Format Examples 12.1. Example 1: Mode A - AI Inference Service Request Client requests an AI inference service with specific cost requirements using IPv6 extension headers. IPv6 Header: * Source: 2001:db8:client::1 * Destination: fd00:cats:1::1 (VPA for AI services) * Next Header: TBD1 (CSREH) CATS Service Request Extension Header: * Next Header: 6 (TCP) * Hdr Ext Len: 3 (32 octets) * Option 1 - CS-ID Option (Type 0x10): - Opt Data Len: 4 - CS-ID: 0x00010001 (AI Inference Service) * Option 2 - Network Requirement Option (Type 0x11): - Opt Data Len: 16 - Num Req: 2 - Entry 1: Max Latency = 10ms (HARD) o Req Type: 0x01, Req Flags: 0x01, Value: 10, Unit: 0x0001 - Entry 2: Min Bandwidth = 100Mbps (SOFT) o Req Type: 0x02, Req Flags: 0x02, Value: 100, Unit: 0x0002 * Option 3 - Computing Requirement Option (Type 0x12): Zhang & Dai Expires 22 January 2027 [Page 23] Internet-Draft CATS Client Request Packet July 2026 - Opt Data Len: 12 - Num Req: 1 - Entry 1: Max Cost = 5 (HARD) o Req Type: 0x03, Req Flags: 0x01, Value: 5, Unit: 0x0004 TCP Header + Application Payload follows. 12.2. Example 2: Mode B - Gaming Service Request Client requests a cloud gaming service using payload-based TLVs over UDP. IPv4 Header: * Source: 192.168.1.100 * Destination: 10.128.2.50 (VPA for Gaming services) * Protocol: 17 (UDP) UDP Header: * Source Port: 54321 * Destination Port: 3478 CATS TLV Block: * Magic: 0x43415453 ("CATS") * Version: 0x01 * Flags: 0x00 * Total Length: 28 * TLV 1 - CS-ID TLV (Type 0x01): - Flags: 0x03 (CRITICAL | MUST_HONOR) - Length: 5 - ID Length: 4 - CS-ID: 0x00020001 (Cloud Gaming Service) Zhang & Dai Expires 22 January 2027 [Page 24] Internet-Draft CATS Client Request Packet July 2026 * TLV 2 - Network Requirements TLV (Type 0x02): - Flags: 0x01 (CRITICAL) - Length: 12 - Num Req: 1 - Entry: Max Latency = 20ms (HARD) o Req Type: 0x01, Req Flags: 0x01, Unit: 0x0001, Value: 20 * TLV 3 - Computing Requirements TLV (Type 0x03): - Flags: 0x01 (CRITICAL) - Length: 12 - Num Req: 1 - Entry: Max Computing Time = 2ms (HARD) o Req Type: 0x02, Req Flags: 0x01, Unit: 0x0001, Value: 2 Application Payload follows. 12.3. Example 3: Dual Mode - Video Streaming Service Client sends a request with both Mode A and Mode B for redundancy and compatibility. IPv6 Header: * Source: 2001:db8:client::2 * Destination: fd00:cats:3::1 (VPA for Video services) * Next Header: TBD1 (CSREH) CSREH (Mode A): * Next Header: 17 (UDP) * Contains: CS-ID=0x00030001, Max Latency=50ms UDP Header: * Destination Port: 554 (RTSP) Zhang & Dai Expires 22 January 2027 [Page 25] Internet-Draft CATS Client Request Packet July 2026 CATS TLV Block (Mode B): * Magic: 0x43415453 * Flags: 0x01 (EXT_HEADER_PRESENT) * Contains: CS-ID=0x00030001, Min Bandwidth=25Mbps RTSP Payload follows. 13. YANG Data Model for CATS Request Parameters This appendix provides a simplified YANG data model for configuring and managing CATS client request parameters. module ietf-cats-request { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-cats-request"; prefix cats-req; import ietf-inet-types { prefix inet; } organization "IETF CATS Working Group"; description "YANG data model for CATS client service request parameters."; revision 2026-07-07 { description "Initial revision."; } typedef cs-id { type binary { length "2..16"; } description "CATS Service Identifier."; } typedef req-type { type uint8 { range "1..255"; } description "Requirement type identifier."; Zhang & Dai Expires 22 January 2027 [Page 26] Internet-Draft CATS Client Request Packet July 2026 } typedef unit-code { type uint16; description "Unit code for requirement values."; } grouping requirement-entry { leaf req-type { type req-type; mandatory true; } leaf req-flags { type bits { bit hard { position 0; } bit soft { position 1; } bit preference { position 2; } } default "hard"; } leaf value { type uint32; mandatory true; } leaf unit-code { type unit-code; mandatory true; } } grouping network-requirements { list network-req { key "req-type"; uses requirement-entry; } } grouping computing-requirements { list computing-req { key "req-type"; uses requirement-entry; Zhang & Dai Expires 22 January 2027 [Page 27] Internet-Draft CATS Client Request Packet July 2026 } } container cats-service-request { leaf cs-id { type cs-id; mandatory true; } leaf mode { type enumeration { enum extension-header; enum payload-based; enum dual-mode; } default "dual-mode"; } uses network-requirements; uses computing-requirements; } } 14. Acknowledgements The authors would like to thank the CATS Working Group for their valuable feedback and contributions to this document. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . Zhang & Dai Expires 22 January 2027 [Page 28] Internet-Draft CATS Client Request Packet July 2026 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017, . 15.2. Informative References [I-D.ietf-cats-framework] Li, C., Ed., Du, Z., Boucadair, M., Ed., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft- ietf-cats-framework-22, March 2026, . [I-D.zhangb-cats-service-metrics-op] Zhang, B., "Computing Service Metric Definitions and Operation under CATS", Work in Progress, Internet-Draft, draft-zhangb-cats-service-metrics-op-03, June 2026, . Appendix A. Authors' Addresses [Editor's Note: To be completed upon working group adoption.] Authors' Addresses Bin Zhang (editor) Pengcheng Laboratory Sibilong Street Shenzhen 518055 China Email: zhangb@pcl.ac.cn Yina Dai (editor) Sun Yat-sen University Sun Yat-sen Street Guangzhou 510080 China Email: daiyn5@mail2.sysu.edu.cn Zhang & Dai Expires 22 January 2027 [Page 29]