Internet-Draft CATS Client Request Packet July 2026
Zhang & Dai Expires 22 January 2027 [Page]
Workgroup:
CATS
Internet-Draft:
draft-zhang-cats-clients-request-packet-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
B. Zhang, Ed.
Pengcheng Laboratory
Y. Dai, Ed.
Sun Yat-sen University

CATS Client Service Request Packet Format (IPv6 Extension Header and Payload-Based Carriage of CS-ID and Network/Computing Requirement Parameters)

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.

▲

Table of Contents

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:

This document specifies two complementary mechanisms for carrying CS-ID and requirement parameters in client service request packets:

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

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

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

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

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

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:

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

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

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

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

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

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

    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.

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.

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

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

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

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

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)

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

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)

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

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

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, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2827]
Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, , <https://www.rfc-editor.org/rfc/rfc2827>.
[RFC4193]
Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, , <https://www.rfc-editor.org/rfc/rfc4193>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, , <https://www.rfc-editor.org/rfc/rfc8200>.

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, , <https://datatracker.ietf.org/doc/html/draft-ietf-cats-framework-22>.
[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, , <https://datatracker.ietf.org/doc/html/draft-zhangb-cats-service-metrics-op-03>.

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
Yina Dai (editor)
Sun Yat-sen University
Sun Yat-sen Street
Guangzhou
510080
China