CATS B. Zhang, Ed.
Internet-Draft Pengcheng Laboratory
Intended status: Standards Track Y. Dai, Ed.
Expires: 25 March 2027 Sun Yat-sen University
Z. Du, Ed.
China Mobile
R. Yang, Ed.
Pengcheng Laboratory
21 September 2026
Carriage of CATS Service Identification and Request Constraints
draft-zhang-cats-clients-request-packet-01
Abstract
This document defines a common encoding for a CATS Service Identifier
(CS-ID) and optional client-supplied request constraints, and
specifies two ways to carry that encoding from a client to an ingress
CATS-Forwarder. Mode A carries the encoding in an IPv6 Destination
Options or Hop-by-Hop Options header. Mode B carries the same
encoding in an application-layer envelope whose position is
explicitly identified by an application, API, or transport mapping,
and which can operate over IPv4 or IPv6.
The document specifies how a service request is identified, either by
the destination address (e.g., a Virtual Placeholder Address (VPA),
an anycast address, or a dedicated service address), by an explicit
CS-ID, or by both together. It defines the CS-ID, Network
Constraints, and Computing Constraints TLVs and their processing at
an ingress CATS-Forwarder, and describes how the extracted
information is provided to the CATS Path Selector (C-PS) for service
selection. The mechanisms are intended for limited domains in which
clients and CATS nodes are provisioned to use the selected mode.
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/.
Zhang, et al. Expires 25 March 2027 [Page 1]
Internet-Draft CATS Client Request Metadata September 2026
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 25 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Client Service Request Packet Overview . . . . . . . . . . . 5
4. Common CATS Request Metadata Encoding . . . . . . . . . . . . 7
4.1. Service Identification Alternatives . . . . . . . . . . . 8
4.2. CS-ID TLV . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Constraint TLVs . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Constraint Entry Format . . . . . . . . . . . . . . . 10
4.3.2. Network Constraints TLV Format . . . . . . . . . . . 11
4.3.3. Computing Constraints TLV Format . . . . . . . . . . 11
5. Mode A: IPv6 CATS Request Option . . . . . . . . . . . . . . 13
5.1. Mode A Applicability . . . . . . . . . . . . . . . . . . 13
5.2. Mode A Processing . . . . . . . . . . . . . . . . . . . . 14
6. Mode B: CATS Request Envelope . . . . . . . . . . . . . . . . 14
6.1. Mode B Applicability . . . . . . . . . . . . . . . . . . 15
7. Addressing and VPA Use . . . . . . . . . . . . . . . . . . . 16
8. Ingress Processing and Failure Handling . . . . . . . . . . . 17
9. Use of Both Modes . . . . . . . . . . . . . . . . . . . . . . 17
10. Operational Considerations . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13.1. IPv6 Option Type . . . . . . . . . . . . . . . . . . . . 19
13.2. CATS Request TLV Types Registry . . . . . . . . . . . . 19
Zhang, et al. Expires 25 March 2027 [Page 2]
Internet-Draft CATS Client Request Metadata September 2026
13.3. Requirement and Unit Registries . . . . . . . . . . . . 20
14. Normative References . . . . . . . . . . . . . . . . . . . . 20
15. Informative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 22
A.1. Address-Based Identification without Client-Specified
Constraints . . . . . . . . . . . . . . . . . . . . . . . 22
A.2. Mode A with a Bandwidth Bound and Fastest Computing . . . 22
A.3. Mode B with Multiple Computing Requirements . . . . . . . 23
A.4. Byte-Level Mode A Request . . . . . . . . . . . . . . . . 23
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
The Computing-Aware Traffic Steering (CATS) framework
[I-D.ietf-cats-framework] describes how traffic for a service can be
steered using both network and computing information, as reported and
evaluated by the CATS control plane. To make such decisions, a CATS
Traffic Classifier (C-TC) needs an unambiguous input with which to
associate a service request with a CS-ID. Some deployments also wish
to convey a small set of client-supplied constraints to the CATS Path
Selector (C-PS).
This document addresses this gap by providing a standardized message
format that a client can use to explicitly declare:
* the CS-ID that the client wishes to access;
* network requirements, such as minimum bandwidth or maximum
latency;
* computing requirements, such as minimum GAS (Global Available
Slots) or maximum computing time.
The computing-requirement vocabulary used by this format (GAS,
Computing Time, Price, Reputation, and Security Level) is defined in
[I-D.zhangb-cats-service-metrics-op]. This document defines how a
client carries a CS-ID and a small set of such requirements to an
ingress CATS-Forwarder, and how that forwarder makes the information
available to the C-PS. It does not redefine the metrics or the
service-selection procedures themselves.
This document specifies one common metadata encoding and two carriage
modes. The encoding is independent of any particular CATS control-
plane realization and can be used with centralized, distributed, SDN-
based, segment-routing-based, or hybrid CATS deployments.
Mode A: IPv6 Option The metadata is carried as one CATS Request
Zhang, et al. Expires 25 March 2027 [Page 3]
Internet-Draft CATS Client Request Metadata September 2026
Option in an existing IPv6 Destination Options or Hop-by-Hop
Options header. No new IPv6 Extension Header or Next Header value
is defined.
Mode B: Application-Layer Envelope The metadata is carried at a
location explicitly identified by a CATS-aware application, API,
or transport mapping. A receiver never searches arbitrary payload
bytes for the encoding.
Both modes are intended for limited domains as described by
[RFC8799], in which clients and CATS nodes are provisioned to use the
selected mode. Mode A depends on IPv6 option support along the
applicable path; Mode B depends on an explicit framing mapping that
tells the CATS-Forwarder where the envelope is. Where the envelope
is protected by end-to-end encryption, an on-path classifier can only
read it if the CATS processing function is an authorized security
endpoint.
This document does not define application-layer or transport mappings
for Mode B, VPA or anycast address allocation, CS-ID discovery or
assignment, the C-PS-to-forwarder interface, or service-selection
procedures; those are specified elsewhere or by deployment.
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 makes use of the following terms defined in
[I-D.ietf-cats-framework] and [I-D.zhangb-cats-service-metrics-op]:
CS-ID (CATS Service Identifier) An identifier for a service. Within
a CATS domain it acts as a stable lookup key for the C-PS, and it
is the value carried by the encoding defined in this document.
CSCI-ID (CATS Service Contact Instance Identifier) An identifier for
the contact information of a service instance that provides a
specific CS-ID at a service site. It is the locator ultimately
selected by the C-PS and used to establish the data path.
CATS-Forwarder An IPv6/IPv4 forwarding node, situated in the data
Zhang, et al. Expires 25 March 2027 [Page 4]
Internet-Draft CATS Client Request Metadata September 2026
plane and taking part in moving information between clients and
service sites. A CATS-Forwarder that first handles a client
service request is an ingress CATS-Forwarder.
C-TC (CATS Traffic Classifier) A component that identifies whether a
packet or flow matches the criteria of a CATS service, typically
co-located with an ingress CATS-Forwarder.
C-PS (CATS Path Selector) A component that selects the service
contact instance, and the path toward it, that best meets the CS-
ID and the client-supplied and operator constraints.
GAS (Global Available Slots) The maximum number of concurrent
requests or sessions a service site is willing and able to serve
for a specific CS-ID at a given time, as defined in
[I-D.zhangb-cats-service-metrics-op].
Additionally, this document defines the following terms:
CATS domain A limited domain, as described by [RFC8799], whose
operator controls the CATS clients or their attachment
authorization, the participating CATS-Forwarders, and the
interpretation of CS-IDs.
VPA (Virtual Placeholder Address) An operator-assigned destination
address that can route a request to an ingress CATS-Forwarder for
interception and reinterpretation. A VPA is one possible
deployment choice and is not part of the CS-ID wire encoding.
3. Client Service Request Packet Overview
This section provides an overview of the structure of a client
service request packet. The detailed encoding is specified in
Section 4 and the carriage modes are specified in Section 5 and
Section 6.
A client service request packet has the general structure shown in
the following figure:
Zhang, et al. Expires 25 March 2027 [Page 5]
Internet-Draft CATS Client Request Metadata September 2026
+---------------------------------------------------------------+
| IP Header (IPv4 or IPv6) |
| Source: client's address |
| Destination: VPA, anycast, or dedicated service address |
+---------------------------------------------------------------+
| [Optional] IPv6 Options Header with the CATS Request Option |
| (Mode A) |
+---------------------------------------------------------------+
| Transport Header (TCP/UDP/QUIC/etc.) |
+---------------------------------------------------------------+
| [Optional] CATS Request Envelope with the TLVs (Mode B) |
| -- position identified by a mapping |
+---------------------------------------------------------------+
| Application Payload |
+---------------------------------------------------------------+
The general parts are as follows:
IP Header The source is the client address. The destination is a
VPA, an anycast service address, or a dedicated service address
within the client-facing domain. The destination may itself
identify the service, or it may only identify an ingress CATS-
Forwarder.
IPv6 Options Header (Mode A) Optional. Carries a CATS Request
Option with the metadata, using an existing Destination Options or
Hop-by-Hop Options header (Section 5).
Transport Header The client transport protocol. It is unaffected by
the CATS metadata unless Mode B is used at a transport-mapped
location.
CATS Request Envelope (Mode B) Optional. Carries the same metadata
TLVs in an application-layer envelope whose position is identified
by a mapping (Section 6).
Application Payload The application data of the request.
Every service request packet MUST identify a service as specified in
Section 4.1. Constraint information is OPTIONAL. A packet MAY carry
the metadata in Mode A, in Mode B, or not at all when the destination
address itself identifies the service unambiguously.
Zhang, et al. Expires 25 March 2027 [Page 6]
Internet-Draft CATS Client Request Metadata September 2026
4. Common CATS Request Metadata Encoding
Section Section 3 presented the overall packet structure. This
section specifies the byte-level encoding shared by the two carriage
modes: an ordered sequence of CATS Request TLVs. The encoding is
independent of the carriage mechanism. Mode A (Section 5) and Mode B
(Section 6) each define only how to place this sequence into their
own container and do not define any metadata format of their own, so
a C-TC or C-PS parses the same encoding regardless of the mode in
which a request arrives.
All multi-octet integers use network byte order. Each TLV has the
following header.
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 An 8-bit type from the CATS Request TLV Types registry
(Section 13.2).
TLV Flags Bit 0 is Critical (C). An implementation that does not
understand a TLV with C=1 MUST reject the metadata block; it MUST
ignore an unknown TLV with C=0. Bits 1 through 7 MUST be zero on
transmission and ignored on receipt.
TLV Length The unsigned length of the TLV Value in octets, excluding
the four-octet TLV header.
The CS-ID TLV MAY appear at most once. The Network Constraints and
Computing Constraints TLVs are OPTIONAL and MUST NOT appear more than
once each. Duplicate singleton TLVs, invalid lengths, and TLVs
extending beyond the containing block are malformed, and the request
MUST be rejected.
If neither constraint TLV is present, the client expresses no
explicit network or computing requirement. The C-PS SHOULD then
select the best eligible service contact instance according to the
operator's default policy. For example, a deployment can use network
reachability or proximity in an anycast-like manner and then apply
its default computing policy. Absence of client constraints does not
mean that every possible metric must be optimized simultaneously.
Zhang, et al. Expires 25 March 2027 [Page 7]
Internet-Draft CATS Client Request Metadata September 2026
A client includes a constraint entry when it needs either a
quantitative bound, such as at least 1 Gbit/s of available bandwidth,
or an explicit optimization objective, such as the shortest available
computing time.
4.1. Service Identification Alternatives
Every request MUST identify a service using at least one of the
following sources:
1. *Address-based identification:* The destination VPA, anycast
address, dedicated service address, or destination prefix is
mapped by the C-TC to one CS-ID.
2. *Explicit identification:* A CS-ID TLV carries the CS-ID
independently of the destination address.
Address-based identification is generally simpler when one stable
address unambiguously identifies one service. A client SHOULD use
address-based identification without a CS-ID TLV when the configured
destination already identifies one service unambiguously. A client
MUST include the CS-ID TLV when the destination identifies only a
CATS ingress, when multiple services share the destination, or when
local policy requires explicit identification.
Address-based identification and an explicit CS-ID are not mutually
exclusive. A request MAY use both sources. In that case, the CATS-
Forwarder MUST resolve the address-based identifier and compare it
with the complete CS-ID TLV. If they differ, the request MUST be
rejected, treating the mismatch as an authorization failure. Network
and computing constraints MAY accompany any of these identification
choices.
Zhang, et al. Expires 25 March 2027 [Page 8]
Internet-Draft CATS Client Request Metadata September 2026
+===================+=============+============+====================+
| Destination | CS-ID TLV | Constraint | Use |
| Address Mapping | | TLVs | |
+===================+=============+============+====================+
| Maps to one CS-ID | Absent | Optional | Preferred address- |
| | | | based form |
+-------------------+-------------+------------+--------------------+
| Does not identify | Present | Optional | Explicit form |
| one service | | | |
+-------------------+-------------+------------+--------------------+
| Maps to one CS-ID | Present | Optional | Combined form |
| | and | | |
| | matching | | |
+-------------------+-------------+------------+--------------------+
| Maps to one CS-ID | Present | Any | Invalid; reject |
| | but | | |
| | different | | |
+-------------------+-------------+------------+--------------------+
Table 1: Permitted Service Identification Combinations
4.2. CS-ID TLV
The CS-ID TLV carries the CATS Service Identifier when explicit
service identification is used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 |C| Reserved | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ CS-ID (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1, identifying the CS-ID TLV.
C The Critical bit MUST be set to 1 because a receiver cannot use an
unrecognized explicit service identifier.
Reserved Bits 1 through 7 of TLV Flags. They MUST be zero on
transmission and ignored on receipt.
TLV Length The length of the CS-ID in octets. Values 2, 4, 8, and
16 are RECOMMENDED for 16-bit, 32-bit, 64-bit, and 128-bit
identifiers, respectively. Other lengths from 1 through 32 octets
MAY be used by agreement within a CATS domain.
Zhang, et al. Expires 25 March 2027 [Page 9]
Internet-Draft CATS Client Request Metadata September 2026
CS-ID An opaque identifier of TLV Length octets. Receivers MUST
compare the complete octet string and MUST NOT infer structure
from its length or contents.
A CS-ID must be unambiguous within its CATS domain; it need not be
globally unique. Permitted values and client authorization are
supplied by discovery or provisioning. At a domain boundary, a
gateway either maps the CS-ID under an explicit inter-domain
agreement or rejects the request.
4.3. Constraint TLVs
Type 2 is Network Constraints and Type 3 is Computing Constraints.
This section defines the entry format shared by both TLVs and then
the format of each TLV. These constraints are policy inputs, not
measurements; a C-PS MUST NOT treat a client assertion as current
network or computing state.
4.3.1. Constraint Entry Format
A constraint TLV begins with Num Entries and three reserved octets,
followed by fixed-size entries. Reserved fields MUST be zero on
transmission and ignored on receipt.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Entries | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Req Type | Req Flags | Unit Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unsigned Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Req Type An 8-bit value from the applicable requirement registry.
Req Flags Bit 0 is Hard (H). If H=1, failure to satisfy a non-zero
quantitative bound causes rejection; if H=0, the value is a
preference. Other bits MUST be zero on transmission and ignored
on receipt. H MUST be zero when Unsigned Value is zero.
Unit Code A 16-bit value from the CATS Request Units registry. The
unit MUST be permitted for the Req Type.
Unsigned Value A 32-bit unsigned integer. A non-zero value
specifies the quantitative bound defined by Req Type. Zero means
that the client does not specify a numeric bound but requests the
best available value for that metric. For a maximum-type
Zhang, et al. Expires 25 March 2027 [Page 10]
Internet-Draft CATS Client Request Metadata September 2026
requirement, zero requests minimization; for a minimum-type
requirement, zero requests maximization. Such a zero-valued entry
is an optimization preference, not a zero threshold or resource
guarantee.
4.3.2. Network Constraints TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 |C| Reserved | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Entries | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Requirement Entry 1 (first 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Requirement Entry 1 (last 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Length MUST equal 4 + (8 * Num Entries). Each entry uses the
format in Section 4.3.1 and a Req Type from the Network Requirement
Types table in Table 2. The C bit SHOULD be zero unless the
applicable application profile requires all network entries to be
understood.
+======+========================+===========+=======================+
| Type | Name | Direction | Unit |
+======+========================+===========+=======================+
| 1 | Path Latency | maximum | 1 (microseconds) |
+------+------------------------+-----------+-----------------------+
| 2 | Available Bandwidth | minimum | 2 (kilobits/second) |
+------+------------------------+-----------+-----------------------+
| 3 | Packet Loss Ratio | maximum | 3 (parts per million) |
+------+------------------------+-----------+-----------------------+
| 4 | Packet Delay | maximum | 1 (microseconds) |
| | Variation | | |
+------+------------------------+-----------+-----------------------+
Table 2: Network Requirement Types
4.3.3. Computing Constraints TLV Format
Zhang, et al. Expires 25 March 2027 [Page 11]
Internet-Draft CATS Client Request Metadata September 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 |C| Reserved | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Entries | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Computing Requirement Entry 1 (first 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Computing Requirement Entry 1 (last 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Length MUST equal 4 + (8 * Num Entries). Each entry uses the
format in Section 4.3.1 and a Req Type from the Computing Requirement
Types table in Table 3. The C bit SHOULD be zero unless the
applicable application profile requires all computing entries to be
understood.
+======+==================+===========+====================+
| Type | Name | Direction | Unit |
+======+==================+===========+====================+
| 1 | Global Available | minimum | 4 (slots) |
| | Slots (GAS) | | |
+------+------------------+-----------+--------------------+
| 2 | Computing Time | maximum | 1 (microseconds) |
+------+------------------+-----------+--------------------+
| 3 | Price | maximum | 5 (service-profile |
| | | | price units) |
+------+------------------+-----------+--------------------+
| 4 | Reputation | minimum | 6 (service-profile |
| | | | score) |
+------+------------------+-----------+--------------------+
| 5 | Security Level | minimum | 7 (service-profile |
| | | | level) |
+------+------------------+-----------+--------------------+
Table 3: Computing Requirement Types
GAS, Computing Time, Price, Reputation, and Security Level are the
service-oriented metrics defined in
[I-D.zhangb-cats-service-metrics-op]. Price, Reputation, and
Security Level are meaningful only when the client and CATS domain
share the corresponding service profile, including scale and
comparison rules. Unknown profiles MUST be rejected. Future work
should align additional entries with the CATS metrics definition
instead of duplicating metric semantics.
Zhang, et al. Expires 25 March 2027 [Page 12]
Internet-Draft CATS Client Request Metadata September 2026
5. Mode A: IPv6 CATS Request Option
Mode A places one CATS Request Option in an IPv6 Destination Options
header or, subject to the applicability below, a Hop-by-Hop Options
header. The containing header follows [RFC8200] as updated by
[RFC9673].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Version | R | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CATS Request TLVs ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type TBD1. The act bits are 00 (skip if unrecognized) and
chg is 0 (immutable en route).
Opt Data Len Length after this field, in octets.
Version Four bits; this document defines version 1.
R Four reserved bits, zero on transmission and ignored on receipt.
Reserved Eight bits, zero on transmission and ignored on receipt.
A node that does not recognize the option processes it according to
its action bits, that is, it skips it. A CATS node that recognizes
the option applies the TLV Critical-bit rules of Section 4: it MUST
reject the request if it contains an unknown TLV with the Critical
bit set and MUST ignore an unknown TLV with the Critical bit clear.
A node changing a field must be an authorized endpoint for the
client-facing leg and originate a new packet; it MUST NOT silently
modify a transit packet. In a Hop-by-Hop Options header, the CATS
option SHOULD NOT exceed 64 octets or four constraint entries.
5.1. Mode A Applicability
Mode A is suitable for a controlled IPv6 domain in which the client,
the selected CATS-Forwarder, and relevant network devices are known
to pass and, where required, process the selected IPv6 Options
header. It is NOT RECOMMENDED as the only means of service
identification over an unverified Internet path. IPv6 Extension
Headers can be filtered, and routers are not required to process
every Hop-by-Hop option. [RFC9098] and [RFC9673] apply.
Zhang, et al. Expires 25 March 2027 [Page 13]
Internet-Draft CATS Client Request Metadata September 2026
A Destination Options header is RECOMMENDED when the VPA or other
destination identifies the ingress CATS-Forwarder as the endpoint of
the client-facing leg. A Hop-by-Hop Options header MAY be used when
explicitly configured routers must examine the option. A transit
router MUST NOT inspect a Destination Option as though it were a Hop-
by-Hop Option.
Support MUST be established by configuration, capability discovery,
or an application-specific procedure before Mode A is used. A client
MUST NOT infer support merely from a lack of an ICMP error. If Mode
A is unavailable, the client uses a separately established Mode B
mapping or an operator-defined address-based classifier. Sending
both modes in one packet is not reliable fallback if that packet is
discarded because it contains an Extension Header.
5.2. Mode A Processing
1. Process the option only when configured as the applicable CATS-
Forwarder or an authorized endpoint.
2. Validate the IPv6 header chain, option length, version, TLV
bounds, and singleton rules. The first fragment MUST contain the
complete IPv6 header chain through the upper-layer header as
required by [RFC7112].
3. Reject unsupported versions and malformed critical metadata, with
error signaling subject to rate limits.
4. Validate and authorize the CS-ID before consulting the C-PS.
Reject unknown or unauthorized CS-IDs.
5. An ingress that terminates the client-facing leg MUST remove the
option or construct a new packet without it unless an explicit
downstream contract authorizes propagation.
6. Mode B: CATS Request Envelope
Mode B carries the same metadata TLVs in an application-layer
envelope. Its use and exact position MUST be identified by an
application protocol, API, or transport mapping. Defining such
mappings is outside the scope of this document.
Zhang, et al. Expires 25 March 2027 [Page 14]
Internet-Draft CATS Client Request Metadata September 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic (0x43415453) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |Flags| Reserved | Metadata Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CATS Request TLVs ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Magic 0x43415453. It is a framing check, not discovery or
authentication.
Version Four bits; this document defines version 1.
Flags and Reserved Twelve bits, zero on transmission and ignored on
receipt.
Metadata Length Length in octets of the TLVs after the fixed eight-
octet header.
A receiver MUST parse an envelope only where a mapping says one is
present. It MUST NOT scan arbitrary payload for the magic value.
The complete envelope MUST be available before use; a stream mapping
must provide framing and reassembly.
Insertion or removal can change transport lengths, checksums,
sequence spaces, and application semantics. A device MUST do so only
as an endpoint or explicitly authorized proxy. A generic CATS-
Forwarder MUST NOT rewrite opaque application payload.
6.1. Mode B Applicability
Mode B is suitable when an application protocol, API, or transport
mapping explicitly identifies the CATS envelope and its position. It
can operate over IPv4 or IPv6, but it is not a transparent prefix for
an arbitrary TCP, UDP, or QUIC application stream.
An on-path CATS-Forwarder can parse Mode B only when the envelope is
outside end-to-end encryption or when that forwarder is an authorized
security endpoint, such as a trusted proxy. Deployments MUST NOT
weaken end-to-end security solely to expose CATS metadata.
Zhang, et al. Expires 25 March 2027 [Page 15]
Internet-Draft CATS Client Request Metadata September 2026
7. Addressing and VPA Use
This section describes how the destination address can route a
request to an ingress CATS-Forwarder and participate in service
identification. It does not define the format, allocation, or
routing procedure for a VPA or anycast address; those matters are
supplied by the applicable addressing and deployment specification.
A VPA is a destination address that routes a packet to an ingress
CATS-Forwarder so that the forwarder can intercept and reinterpret
it. It is a deployment choice. A deployment MAY instead use a
service anycast address, an ingress CATS-Forwarder address, or
another local classifier. When the destination address, anycast
address, or dedicated service address already maps to one CS-ID, that
address-based identification SHOULD be used in preference to carrying
a duplicate CS-ID TLV.
An anycast address expresses reachability to the nearest node that
advertises the address. When a CATS deployment advertises a service
address from multiple service sites or accesses the ingress at the
nearest CATS-Forwarder, the destination address itself becomes a
service-selection signal, and the C-PS still applies its default
policy or the carried constraints. Using an address that identifies
a service is generally simpler than carrying an explicit CS-ID, while
carrying an explicit CS-ID is useful when the identifier must be
independent of the destination locator or when several services share
one address.
A VPA prefix MUST come from address space the operator is entitled to
use, MUST be routed within the client-facing domain to intended
ingress nodes, and MUST be filtered at boundaries absent an inter-
domain agreement. Operators must account for private IPv4 overlap
and generate IPv6 Unique Local Addresses per [RFC4193]. Whether a
particular destination is treated as a VPA is an operator decision;
an address does not become non-routable merely by being called a VPA.
This document requests no address prefix. If an address identifies a
service and an explicit CS-ID is also present, they MUST agree; a
mismatch is an authorization failure as described in Section 4.1.
Examples in this document use [RFC5737] and [RFC3849] documentation
space, which MUST NOT be used in production.
Zhang, et al. Expires 25 March 2027 [Page 16]
Internet-Draft CATS Client Request Metadata September 2026
8. Ingress Processing and Failure Handling
When an ingress CATS-Forwarder receives a client service request, the
CATS Traffic Classifier (C-TC) classifies the packet and the CATS
Path Selector (C-PS) is consulted to select the CSCI-ID and the path
toward it. With the CS-ID and constraints extracted as described in
this document, the C-PS makes its selection as specified in
[I-D.zhangb-cats-service-metrics-op]. The ingress processing steps
are as follows:
1. Classify only packets on an authorized attachment matching a
configured address-based, Mode A, or Mode B profile.
2. Perform inexpensive length, version, rate-limit, and source
checks before C-PS lookup or control-plane punt.
3. Resolve the CS-ID from the destination address, the CS-ID TLV, or
both as specified in Section 4.1. Reject a request with no
service identification or with inconsistent sources.
4. Reject malformed, unknown-critical, duplicate, unknown-CS-ID, and
unauthorized-CS-ID requests.
5. Apply operator bounds to constraints. Client values do not
override access, admission, or local policy.
6. If a hard constraint cannot be met, reject the request. A
preference MAY be ignored under policy.
7. Install state only after selection succeeds. Implementations
SHOULD bound pending requests, cache reusable results, define
state lifetime, and specify C-PS timeout behavior.
Failure actions include rejection, an authorized default instance, or
asking a cooperating client to retry another supported mode. A
device MUST NOT bypass CATS to an arbitrary destination if doing so
violates policy.
Flow binding is deployment-specific. A five-tuple is not always
stable across NAT, QUIC migration, multipath, or fragmentation. The
applicable mapping or policy MUST define the key and lifetime.
9. Use of Both Modes
Using both modes is NOT RECOMMENDED in normal operation because it
duplicates information and does not solve Extension Header filtering.
It MAY be used in a controlled experiment or transition.
Zhang, et al. Expires 25 March 2027 [Page 17]
Internet-Draft CATS Client Request Metadata September 2026
If both are visible, the CS-ID and duplicated constraints MUST be
identical. A mismatch MUST be rejected and SHOULD be rate-limited in
logs. The deployment profile MUST state which encoding is
authoritative for fields present in only one mode; there is no
universal precedence rule.
10. Operational Considerations
Operators SHOULD validate the selected mode over intended paths,
including firewalls, tunnels, load balancers, hardware offload,
fragmentation, and path MTU. Mode A testing must check both
forwarding of the Options header and processing of TBD1.
Implementations SHOULD expose counters for malformed metadata,
unknown versions, unauthorized CS-IDs, unsatisfied hard constraints,
rate-limit drops, C-PS timeouts, and dual-mode mismatch, while
minimizing identifying data.
This mechanism supplies C-PS input but does not require a particular
C-PS-to-forwarder protocol. Failure or non-adoption of one control
protocol does not change this wire encoding.
11. Security Considerations
CATS metadata can influence traffic placement and scarce computing
resources and is therefore untrusted input.
* An ingress MUST validate that a CS-ID exists and that the
authenticated client or attachment is authorized. Source-address
filtering alone is insufficient.
* The ingress MUST validate lengths, counts, reserved fields, type/
unit combinations, and value ranges before invoking the C-PS.
Parsing MUST be bounded by the containing option or envelope.
* The ingress MUST rate-limit before expensive parsing or control
work, and SHOULD use per-client quotas, bounded pending state, and
negative caching. Bad traffic MUST NOT create unbounded logs or
errors.
* Where packets can be modified, metadata MUST receive integrity
protection binding it to client identity and the relevant flow,
for example IPsec, a mutually authenticated channel, or
authenticated attachment security.
Zhang, et al. Expires 25 March 2027 [Page 18]
Internet-Draft CATS Client Request Metadata September 2026
* A magic value, VPA, CS-ID, nonce, or timestamp is not
authentication. Replay protection requires integrity-protected
freshness and bounded receiver state; this version relies on the
selected security association.
* Metadata MUST be removed at its authorized scope boundary absent
an explicit propagation agreement. Packet changes must account
for IPsec and other integrity protection.
The guidance in [RFC3552] applies.
12. Privacy Considerations
A CS-ID and constraints can reveal the application, workload, latency
sensitivity, budget, or security expectations. Mode A exposes them
to nodes inspecting the IPv6 header. Mode B is confidential only
inside a secure channel, in which case a transparent on-path CATS-
Forwarder cannot read it.
Deployments SHOULD minimize fields and precision, use coarse profiles
where practical, limit visibility to the ingress trust domain, and
avoid stable per-user identifiers. Logs MUST be access controlled
and SHOULD use the shortest practical retention.
13. IANA Considerations
13.1. IPv6 Option Type
IANA is requested to assign one value from the "Destination Options
and Hop-by-Hop Options" registry:
+======+=====+=====+======+=====================+===============+
| Hex | act | chg | rest | Description | Reference |
+======+=====+=====+======+=====================+===============+
| TBD1 | 00 | 0 | TBD | CATS Request Option | This document |
+------+-----+-----+------+---------------------+---------------+
Table 4
No new IPv6 Extension Header or Next Header value is requested.
13.2. CATS Request TLV Types Registry
IANA is requested to create this registry. Values 1-127 are
Specification Required, 128-254 are Private Use, and 0 and 255 are
Reserved, following [RFC8126]. Specifications must define syntax,
multiplicity, processing, and security.
Zhang, et al. Expires 25 March 2027 [Page 19]
Internet-Draft CATS Client Request Metadata September 2026
+=========+=======================+===============+
| Value | Name | Reference |
+=========+=======================+===============+
| 0 | Reserved | This document |
+---------+-----------------------+---------------+
| 1 | CS-ID | This document |
+---------+-----------------------+---------------+
| 2 | Network Constraints | This document |
+---------+-----------------------+---------------+
| 3 | Computing Constraints | This document |
+---------+-----------------------+---------------+
| 4-127 | Unassigned | |
+---------+-----------------------+---------------+
| 128-254 | Private Use | This document |
+---------+-----------------------+---------------+
| 255 | Reserved | This document |
+---------+-----------------------+---------------+
Table 5
13.3. Requirement and Unit Registries
IANA is requested to create Network Requirement Types, Computing
Requirement Types, and Request Units under a CATS Request Parameters
group. For the two 8-bit Requirement Type registries, 0 is Reserved,
1-127 are Specification Required, 128-254 are Private Use, and 255 is
Reserved. For the 16-bit Request Units registry, 0 is Reserved,
1-32767 are Specification Required, 32768-65534 are Private Use, and
65535 is Reserved. Initial requirement assignments are in Table 2
and Table 3. Unit assignments are 1 microseconds, 2 kilobits/second,
3 parts per million, 4 slots, 5 service-profile price units, 6
service-profile reputation score, and 7 service-profile security
level. A sender SHOULD choose a unit that keeps the value within the
range of the 32-bit Unsigned Value field; for example, a bandwidth
above roughly 4 Tbit/s should use a coarser unit.
14. Normative References
[I-D.ietf-cats-framework]
Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
Drake, "A Framework for Computing-Aware Traffic Steering
(CATS)", Work in Progress, Internet-Draft, draft-ietf-
cats-framework-24, April 2026,
.
Zhang, et al. Expires 25 March 2027 [Page 20]
Internet-Draft CATS Client Request Metadata September 2026
[I-D.zhangb-cats-service-metrics-op]
Zhang, B., Dai, Y., Du, Z., and C. Miao, "Computing
Service Metric Definitions and Operation under CATS", Work
in Progress, Internet-Draft, draft-zhangb-cats-service-
metrics-op-05, September 2026,
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005,
.
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112, January 2014,
.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, July 2017,
.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, July 2020,
.
[RFC9098] Gont, G., Hilliard, N., Doering, G., and W. Kumari,
"Operational Implications of IPv6 Packets with Extension
Headers", RFC 9098, September 2021,
.
[RFC9673] Hinden, R. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", RFC 9673, October 2024,
.
15. Informative References
Zhang, et al. Expires 25 March 2027 [Page 21]
Internet-Draft CATS Client Request Metadata September 2026
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003, .
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004,
.
[RFC5737] Arkko, J., Cotton, M., and L. Veggoda, "IPv4 Address
Blocks Reserved for Documentation", RFC 5737, January
2010, .
Appendix A. Examples
The examples use documentation addresses and illustrative CS-ID
values. They do not assign production addresses or CS-IDs.
A.1. Address-Based Identification without Client-Specified Constraints
A client sends a request to the service anycast address
2001:db8:100::1. The deployment maps that address to CS-ID
0x00010001. The request carries no CS-ID TLV and no Network
Constraints or Computing Constraints TLV. The address identifies the
service, while the absence of constraint TLVs means that the client
expresses no preference for bandwidth, latency, computing time,
price, or another metric.
The ingress CATS-Forwarder derives and validates CS-ID 0x00010001,
then asks the C-PS to select the best eligible instance according to
the domain's default policy. For example, the policy can first
select a network-near site in an anycast-like manner and then choose
an available instance at that site.
A.2. Mode A with a Bandwidth Bound and Fastest Computing
An IPv6 client at 2001:db8:10::1 sends a service request to the VPA
2001:db8:200::1. In this deployment the VPA identifies the CATS
ingress but not a particular service, so a Destination Options header
carries a CATS Request Option with the following TLVs:
* CS-ID TLV: Type 1, C=1, CS-ID 0x00020001.
* Network Constraints TLV: Available Bandwidth, H=1, Unit Code 2,
Unsigned Value 1000000. This requests at least 1,000,000
kilobits/second (1 Gbit/s).
Zhang, et al. Expires 25 March 2027 [Page 22]
Internet-Draft CATS Client Request Metadata September 2026
* Computing Constraints TLV: Computing Time, H=0, Unit Code 1,
Unsigned Value 0. This supplies no numeric time bound and
requests the candidate with the shortest available computing time.
The C-PS first removes candidates that cannot provide the hard
bandwidth bound. Among the remaining eligible candidates, it uses
computing time as an optimization objective together with operator
policy. If no candidate meets the bandwidth bound, the request is
rejected.
A.3. Mode B with Multiple Computing Requirements
A CATS-aware application sends to the dedicated service address
192.0.2.30, which the deployment maps to CS-ID 0x00030001. Its Mode
B envelope also carries CS-ID TLV 0x00030001, illustrating that
address-based and explicit identification can coexist. The envelope
contains these entries:
* Path Latency: H=1, Unit Code 1, Unsigned Value 20000 (at most 20
milliseconds).
* GAS: H=1, Unit Code 4, Unsigned Value 10 (at least 10 slots).
* Price: H=1, Unit Code 5, Unsigned Value 100 (at most 100 price
units under the applicable service profile).
* Reputation: H=0, Unit Code 6, Unsigned Value 0 (prefer the highest
reputation).
* Security Level: H=1, Unit Code 7, Unsigned Value 3 (at least level
3 under the applicable service profile).
The mapping explicitly identifies the envelope location. An on-path
CATS-Forwarder does not search arbitrary application bytes for it.
If the envelope is inside end-to-end encryption, this example applies
only when the CATS processing function is an authorized security
endpoint.
A.4. Byte-Level Mode A Request
This example shows the Mode A request of Appendix A.2 as an octet-
level packet. The IPv6 Next Header value 0x3B indicates that no
upper-layer header is shown for brevity; the Destination Options
header is 48 octets and is 8-octet aligned per [RFC8200]. TBD1 is
shown as 0x1E for illustration only.
Zhang, et al. Expires 25 March 2027 [Page 23]
Internet-Draft CATS Client Request Metadata September 2026
60 00 00 00 00 30 3C 20 20 01 0d b8 00 10 00 00 IPv6: ver 6, Payload
00 00 00 00 00 00 00 01 20 01 0d b8 02 00 00 00 Len 0x30, NH 0x3C,
00 00 00 00 00 00 00 01 3B 05 1E 2A 10 00 01 80 src/dst, DOH, option
00 04 00 02 00 01 02 00 00 0C 01 00 00 00 02 80 CS-ID TLV, Net TLV
00 02 00 0F 42 40 03 00 00 0C 01 00 00 00 02 00 Net TLV, Comp TLV
00 01 00 00 00 00 01 00 Comp TLV, PadN
IPv6 header Source 2001:db8:10::1, destination 2001:db8:200::1 (the
VPA), Payload Length 0x30 (48), Next Header 0x3C (Destination
Options).
Destination Options header Next Header 0x3B (no upper-layer header),
Hdr Ext Len 0x05 (48 octets total).
CATS Request Option Option Type 0x1E (illustrative value for TBD1),
Opt Data Len 0x2A (42 octets after this field), Version 1, R 0,
Reserved 0.
CS-ID TLV Type 1, C=1, Length 4, value 0x00020001.
Network Constraints TLV Type 2, C=0, Length 0x0C (12); Num Entries
1; entry: Available Bandwidth, H=1, Unit Code 2 (kbit/s), value
0x000F4240 (1,000,000).
Computing Constraints TLV Type 3, C=0, Length 0x0C (12); Num Entries
1; entry: Computing Time, H=0, Unit Code 1 (microseconds), value 0
(best available).
PadN Two octets (0x01 0x00) aligning the Destination Options header
to 48 octets.
Appendix B. Acknowledgements
The authors thank CATS Working Group participants for their review
and comments.
Authors' Addresses
Bin Zhang (editor)
Pengcheng Laboratory
Email: zhangb@pcl.ac.cn
Yina Dai (editor)
Sun Yat-sen University
Email: daiyn5@mail2.sysu.edu.cn
Zhang, et al. Expires 25 March 2027 [Page 24]
Internet-Draft CATS Client Request Metadata September 2026
Zongpeng Du (editor)
China Mobile
Email: duzongpeng@chinamobile.com
Rongwei Yang (editor)
Pengcheng Laboratory
Email: yangrw@pcl.ac.cn
Zhang, et al. Expires 25 March 2027 [Page 25]