Pengcheng Laboratory

Sibilong Street Shenzhen 518055 China zhangb@pcl.ac.cn

Sun Yat-sen University

Sun Yat-sen Street Guangzhou 510080 China daiyn5@mail2.sysu.edu.cn

Routing CATS Internet-Draft CATS Client Service Request IPv6 Extension Header CS-ID Computing-Aware Traffic Steering 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.

The Computing-Aware Traffic Steering (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 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. 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.

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 when, and only when, they appear in all capitals, as shown here.

This document uses the following terms defined in and : 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: 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. 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. A quantitative/qualitative constraint or preference related to network performance, such as maximum latency, minimum bandwidth, or maximum packet loss. A quantitative/qualitative constraint or preference related to computing services, such as GAS, computing time, or cost.

The VPA prefix MUST satisfy the following requirements: 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. 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. 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. Administratively Scoped: The VPA prefix SHOULD be allocated from administratively scoped address space (e.g., RFC1918 for IPv4, Unique Local Addresses for IPv6) to prevent conflicts with the global Internet. Example VPA Prefix Allocations:

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

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: Extract the CS-ID from the packet (via extension header or payload parsing). Extract network and computing requirement parameters. Query the C-PS for path selection based on CS-ID and parameters. Install forwarding state for the flow. Forward the packet along the CATS-computed path.

A client service request packet has the following general structure:

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

The client's real network address. 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.

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

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: Identifies the type of header immediately following the CSREH. Uses standard IP protocol numbers. Length of the CSREH in 8-octet units, not including the first 8 octets. Minimum value is 0 (8 octets total). MUST be set to zero on transmission and ignored on reception. Variable-length options carrying CS-ID, network requirements, and computing requirements. Each option uses the standard IPv6 Options format . 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.

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

Bits 00 (skip if not recognized); Bit 0 (does not change en-route) 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) The CATS Service Identifier. The length and semantics of the CS-ID are deployment-specific but MUST be consistent within a CATS domain.

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

Number of Network Requirement Entries following this field. MUST be set to zero on transmission and ignored on reception. Network 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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 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 Specifies the unit of the Value field:

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

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

Number of Computing Requirement Entries following this field. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Identifies the type of computing requirement:

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

Same format as Network Requirement Option (Section 5.3). 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 Same values as defined in Section 5.3.

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. If the CSREH contains multiple CS-ID Options, only the first one MUST be processed; subsequent CS-ID Options MUST be ignored. Network and Computing Requirement Options are OPTIONAL. If absent, the C-PS SHOULD use default policies or service-specific profiles configured by the operator. 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). 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.

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

Fixed value 0x43415453 (ASCII "CATS"). Used to detect the presence of the CATS TLV block in the payload. Version of the CATS TLV format. This document specifies version 0x01. 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 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Identifies the type of TLV (see Section 6.2). 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. Length of the TLV Value field in octets.

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

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

Length of the CS-ID in octets. RECOMMENDED values: 2, 4, 8, 16. The CATS Service Identifier. Same semantics as in Mode A.

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

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

Same values as defined in Section 5.3. Bit 0 (0x01): HARD - Hard constraint; Bit 1 (0x02): SOFT - Soft constraint; Bit 2 (0x04): PREF - Preference; Bits 3-7: Reserved Same values as defined in Section 5.3. The numerical value of the requirement.

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

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

Same values as defined in Section 5.4. Same format as Network Requirements TLV. Same values as defined in Section 5.4. The numerical value of the requirement.

A CATS-Forwarder processing a packet in payload mode MUST scan the transport payload for the Magic Number 0x43415453. If the Magic Number is found, the CATS-Forwarder MUST parse the TLV block to extract the CS-ID and requirement parameters. 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. 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. 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.

This section defines the behavior when both Mode A and Mode B are present in a single packet.

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

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: 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. 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). Step 3: Requirement Parameter Extraction Extract network and computing requirement parameters from the same source as the CS-ID (Mode A or Mode B). Step 4: Path Selection 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 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. 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.

This section describes security considerations for the CATS client service request packet format.

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 to prevent external injection of spoofed packets.

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

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

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.

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.

The CATS client service request packet format raises the following privacy considerations:

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.

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.

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.

This document requests IANA to make the following assignments:

A new IPv6 Next Header value for the CATS Service Request Extension Header (CSREH):

+--------+-----------------------------+-----------+ | Value | Protocol | Reference | +--------+-----------------------------+-----------+ | TBD1 | CATS Service Request EH | This doc | +--------+-----------------------------+-----------+

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

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

Two new registries for Network and Computing Requirement Types: Registry Name: CATS Network Requirement Types; Registration Procedure: Expert Review Registry Name: CATS Computing Requirement Types; Registration Procedure: Expert Review Initial assignments as specified in Sections 5.3 and 5.4.

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) Req Type: 0x01, Req Flags: 0x01, Value: 10, Unit: 0x0001 Entry 2: Min Bandwidth = 100Mbps (SOFT) Req Type: 0x02, Req Flags: 0x02, Value: 100, Unit: 0x0002 Option 3 - Computing Requirement Option (Type 0x12): Opt Data Len: 12 Num Req: 1 Entry 1: Max Cost = 5 (HARD) Req Type: 0x03, Req Flags: 0x01, Value: 5, Unit: 0x0004 TCP Header + Application Payload follows.

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) TLV 2 - Network Requirements TLV (Type 0x02): Flags: 0x01 (CRITICAL) Length: 12 Num Req: 1 Entry: Max Latency = 20ms (HARD) 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) Req Type: 0x02, Req Flags: 0x01, Unit: 0x0001, Value: 2 Application Payload follows.

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) CATS TLV Block (Mode B): Magic: 0x43415453 Flags: 0x01 (EXT_HEADER_PRESENT) Contains: CS-ID=0x00030001, Min Bandwidth=25Mbps RTSP Payload follows.

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."; } 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; } } 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; } }

The authors would like to thank the CATS Working Group for their valuable feedback and contributions to this document.

[Editor's Note: To be completed upon working group adoption.]