Pengcheng Laboratory

zhangb@pcl.ac.cn

Sun Yat-sen University

daiyn5@mail2.sysu.edu.cn

China Mobile

duzongpeng@chinamobile.com

Pengcheng Laboratory

yangrw@pcl.ac.cn

Routing CATS CATS CS-ID IPv6 options request constraints 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.

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

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

Terminology This document makes use of the following terms defined in and :

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

Additionally, this document defines the following terms:

CATS domain

A limited domain, as described by , 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.

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 and the carriage modes are specified in and . A client service request packet has the general structure shown in the following figure: 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 ().

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

Application Payload

The application data of the request.

Every service request packet MUST identify a service as specified in . 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.

Common CATS Request Metadata Encoding Section 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 () and Mode B () 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.

TLV Type

An 8-bit type from the CATS Request TLV Types registry ().

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

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. Permitted Service Identification Combinations

Destination Address Mapping	CS-ID TLV	Constraint TLVs	Use
Maps to one CS-ID	Absent	Optional	Preferred address-based form
Does not identify one service	Present	Optional	Explicit form
Maps to one CS-ID	Present and matching	Optional	Combined form
Maps to one CS-ID	Present but different	Any	Invalid; reject

CS-ID TLV The CS-ID TLV carries the CATS Service Identifier when explicit service identification is used.

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.

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.

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.

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.

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

Network Constraints TLV Format TLV Length MUST equal 4 + (8 * Num Entries). Each entry uses the format in and a Req Type from the Network Requirement Types table in . The C bit SHOULD be zero unless the applicable application profile requires all network entries to be understood. Network Requirement Types

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 Variation	maximum	1 (microseconds)

Computing Constraints TLV Format TLV Length MUST equal 4 + (8 * Num Entries). Each entry uses the format in and a Req Type from the Computing Requirement Types table in . The C bit SHOULD be zero unless the applicable application profile requires all computing entries to be understood. Computing Requirement Types

Type	Name	Direction	Unit
1	Global Available Slots (GAS)	minimum	4 (slots)
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)

GAS, Computing Time, Price, Reputation, and Security Level are the service-oriented metrics defined in . 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.

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 as updated by .

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

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. and apply. 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.

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

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.

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.

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.

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 . 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 . Examples in this document use and documentation space, which MUST NOT be used in production.

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

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

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.

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

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.

IANA Considerations

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

No new IPv6 Extension Header or Next Header value is requested.

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 . Specifications must define syntax, multiplicity, processing, and security.

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

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

Normative References Informative References

Examples The examples use documentation addresses and illustrative CS-ID values. They do not assign production addresses or CS-IDs.

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.

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

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.

Byte-Level Mode A Request This example shows the Mode A request of 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 . TBD1 is shown as 0x1E for illustration only.

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.

Acknowledgements The authors thank CATS Working Group participants for their review and comments.