Public Service Platform for Computing-Aware Traffic Steering (CATS)

Introduction Computing-aware traffic steering (CATS) is a traffic engineering approach that takes into account the dynamic nature of computing resources and network state to optimize service-specific traffic forwarding towards a given service instance. As described in , the Computing-Aware Traffic Steering (CATS) framework assumes that there might be multiple service instances that are providing one given service, which are running in one or more service sites. Each of these service instances can be accessed via a service contact instance, which is a client-facing service function instance. A single service site may host one or multiple service contact instances. A single service site may have limited computing resources available at a given time, whereas the various service sites may experience different resource availability issues over time. Therefore, steering traffic among different service sites can address the issues of lacking resources in a specific service site. Based on this, provides an architectural framework that aims at facilitating the making of compute- and network-aware traffic steering decisions in networking environments where computing service resources are deployed. In the CATS framework, the C-SMA collects computing-related capabilities and metrics, and associates them with a CS-ID that identifies the service. The C-SMA then advertises CS-IDs along with metrics to related C-PSes in the network. Computing metrics are numerous and highly variable, which makes them unsuitable for direct dissemination on the network. proposes to use normalized metrics in CATS. further defines service-oriented metrics and operational procedures for exposing actionable service capacity to CATS control-plane components. This document focuses on the public service platform that provides the catalogue and service context used by those metrics and procedures. Computing resources are inherently heterogeneous, spanning CPUs, GPUs, FPGAs, ASICs, and other accelerators, each with distinct performance characteristics. This diversity makes it difficult to define a single measurement or normalization scheme that is meaningful across all service providers and hardware types. Normalized scores can also hide service-specific information that is needed when a client requests a concrete service capability. This document describes a public service platform for CATS. A CS-ID identifies a service, but a CS-ID alone does not tell a client what function the service provides, what input data is required, or how a request should be constructed. Clients need a catalogue that explains the service associated with the identifier. Service sites and other service publishers also need a common place to publish service entries so that clients and other sites can discover, download, deploy, and use those services. The public service platform provides this catalogue and the reference service context used by service-oriented metrics. This document does not redefine the metric semantics or operational procedures specified in . This document describes the concrete purpose and functions of the public service platform, and identifies the CS-ID-related information fields that are needed to realize those functions. It does not constrain the implementation form of the platform. For example, a deployment can realize the platform by using capability search engines, service AI agents, DNS, or other approaches. The selection of such implementation approaches, as well as the definition of any search, retrieval, artificial-intelligence agent, database, authentication, or onboarding mechanism, is outside the scope of this document. Figure 1 extends the CATS functional components from the CATS framework with a public service platform. The platform is a catalogue and publication point: clients query it to generate service requests, and service sites query it to select and deploy services. Both clients and service sites can publish service entries and deployment-related information to the platform. Public Service Platform: query the platform to generate service requests; publish service entries and deployment-related information to the platform. Service Site <-> Public Service Platform: query the platform to select and deploy services; publish service entries and deployment-related information to the platform. Figure 1: CATS Functional Components with Public Service Platform ]]>

Terminology This document makes use of the terms defined in and the service-metric concepts defined in . It also makes use of the following terms:

Public service platform: A catalogue and publication component that maintains public service descriptions, identifiers, and deployment context for CATS.
Service entry: A catalogue item maintained by the public service platform. A service entry describes a service identifier, service name, input description, service description, deployment requirements, and service context such as Reference GAS and Reference Computing Time.

Public Service Platform Scope and Information Fields The public service platform hosts a public service catalogue for the CATS framework. Its purpose is to provide a common interpretation point for CS-ID-related information, including service descriptions, input descriptions, deployment requirements, and reference service context. The platform does not replace the CATS control-plane procedures. Instead, it provides the information needed before a client constructs a CATS service request, before a service site deploys a service instance, and before a service developer or provider publishes a service for CATS use. The public service platform supports three functions. First, it provides client-facing service function discovery by recommending a CS-ID and its related information, such as the service description, input description, Reference Computing Time, and other service context, based on a client service description or requirement. It acts like a public service store and holds all CS-ID-related information. Second, it provides service-site-facing deployment guidance by recommending CS-ID-related information needed to deploy service instances, such as code location, computing requirement, storage requirement, software dependency, Reference GAS, and Reference Computing Time. Third, it provides service-publisher-facing publication support by accepting service entries from service developers or providers. A published service entry includes the information needed to describe, deploy, and consume the service. The CS-ID associated with a published service is generated or assigned by the platform according to local rules. This document defines the information fields and the role of those fields in the above functions. It does not define the concrete realization of the public service platform. A deployment can realize the platform by using capability search engines, service AI agents, DNS, or other approaches. These approaches are implementation choices, and this document does not define their internal algorithms, data structures, authentication methods, or publication policies. Table 1 illustrates a typical public service table. It is an example of the CS-ID-related information that can be maintained by the public service platform for use by clients, service sites, and service publishers. Example Public Service Table

Service Entry Field	AR1	LLM1	TR1	TP1	ST1
CS-ID	AR1	LLM1	TR1	TP1	ST1
Service Name	AR/VR	LLM inference	Model training	Intelligent transportation	Simultaneous interpretation
Input Description	Motion capture, voice tracking, eye tracking, and environmental sensing.	Prompt, context, and generation parameters.	Training data, model configuration, and parameters.	Transport standard data and traffic information.	Speech input and optional interaction input.
Service Description	Receives sensor input and generates AR/VR scenes.	Text generation or question-answering service.	Training or fine-tuning task that returns model artifacts.	Driving or transportation environment sensing.	Real-time captioning or conference translation.
Code Location	Code link	Code link	Code link	Code link	Code link
Computing Requirement	Multi-thread CPUs, minimum 2.0 GHz; GPU higher than RTX 4060.	GPU cluster or accelerator pool.	Dedicated GPU or accelerator resources.	CPU >= 4.0 GHz; GPU >= 200 TOPS.	CPU >= 3.5 GHz, 16 threads; RTX 4090-class GPU.
Storage Requirement	16 GB DRAM; 256 GB SSD.	Model storage and KV-cache memory.	Dataset storage and checkpoint storage.	64 GB DDR5 DRAM; 1 TB NVMe SSD.	32 GB DDR5 DRAM; 1 TB NVMe SSD; 16 GB GPU memory.
Reference Computing Time	<= 1 ms	50 ms - 2 s	Minutes to hours	<= 20 ms	<= 1 s
Reference GAS	1	500	1	200	1
Software Dependency	Unity, Unreal Engine	CUDA, inference runtime	PyTorch, CUDA/cuDNN	Apollo, CUDA	CUDA/cuDNN, Apache Kafka
Publisher	Service Site 1	Platform Operator 1	Client 1	Third Party 1	Service Site 2
Publication and Update Time	2026-05	2026-05	2026-05	2026-05	2026-05
Popularity	32	128	16	45	21

The CS-ID field is the public service identifier generated or assigned by the platform for a published service. The Service Name field identifies the service in human-readable form. The Input Description field describes the data or parameters that a client needs to provide when consuming the service. The Service Description field describes the function or capability of the service. The Code Location field identifies the running code, code package, or code location used by a service site to deploy the service. The Computing Requirement field describes the minimum or recommended computing resources for deploying the service. The Storage Requirement field describes the minimum or recommended storage resources for deploying the service. If a service site cannot satisfy these requirements, it is not recommended to deploy the service. A service site can deploy the service with resources greater than or equal to the listed requirements according to local policy and capacity. The Reference Computing Time field provides a catalogue-level computing time measured or estimated when the service processes a reference data sample under the reference execution context. Operational Computing Time can differ after local deployment and is measured and reported by service sites according to . The Reference GAS field provides a catalogue-level indication of the number of concurrent clients that the published service is expected to support under the listed reference resource configuration. This value is useful when another service site wants to deploy the same service without repeating the initial sizing exercise. If the resource allocated to a service instance just meets the listed requirements, the initial operational GAS can use the Reference GAS as a starting value. If more resources are allocated, the operational GAS needs to be evaluated and is generally larger than the Reference GAS. Operational GAS is evaluated and reported by each service site through the C-SMA after deployment, as defined in . The Software Dependency field describes software dependencies, such as libraries, runtimes, frameworks, or middleware needed to deploy or run the service. The Publisher field identifies the source of the service entry. The Publication and Update Time field indicates the freshness of the entry. The Popularity field is catalogue metadata that can reflect how often a service is downloaded, deployed, or selected. Popularity can help service sites decide whether a service is worth deploying, but it is not treated as a CATS routing metric in this document. A service entry can also include service tags, data samples, expected results, and other service context that help a platform recommend the entry to clients or service sites. The exact publication and maintenance policy for those fields is deployment specific.

Platform Functions and Workflows This section describes the three basic workflows supported by the public service platform: service publication, service site deployment, and client service discovery. These workflows explain how the information fields in Section 3 are used. They do not define a protocol between the participants and the platform.

Service Publication Workflow A service developer or provider can publish a service entry to the public service platform. The submitted information can include service name, input description, service description, running code or code location, computing requirement, storage requirement, Reference Computing Time, software dependency, data sample, and expected result. After the platform accepts the entry according to local policy, it generates or assigns a CS-ID for the service and builds or updates the service table and service sample result table. Figure 2 illustrates this service publish workflow. The figure is informative and does not specify the authentication method, publish protocol, validation procedure, CS-ID generation rule, or internal platform implementation. | | | | 2: AUTHENTICATION(who are you?) | |<---------------------------------------| | | | 3: AUTH_RESPONSE(IP, domain, host, | | port, params) | |--------------------------------------->| | | | 4: PUBLISH_RESPONSE(CS-ID, | | success/failure) | |<---------------------------------------| | | Build service | | table and | | service sample | | result table Figure 2: Service Publish Workflow ]]>

Service Site Deployment Workflow A service site can query the public service platform to identify services that it intends to host. The platform provides CS-ID-related deployment information, including the service identifier, input description, service description, code location, computing requirement, storage requirement, software dependency, Reference GAS, and Reference Computing Time. The service site uses this information to determine whether it can deploy the service and how much local resource should be allocated initially. The reference values in the platform help the service site estimate its initial deployment scale. For example, if a service entry has Reference GAS 200 under the reference resource configuration, three equivalent deployments can provide an initial aggregate capacity of about 600 concurrent clients, while four equivalent deployments can provide about 800. If a site allocates more resources than the reference configuration and verifies the result through local testing, it may report a higher operational GAS, such as 260 instead of the reference value 200. The same principle applies to operational Computing Time, which may differ from the catalogue reference value after local deployment. After deployment, the service site determines the service contact instances and reports the corresponding service identifiers and service-oriented metrics through its C-SMA. These reports form the Computing Service Table defined in . This document uses that mechanism by reference and does not define metric encoding, update policy, or selection procedures. In this way, the public service platform supplies the service context, while the service-metric draft defines the metric behaviour and operation. Figure 3 illustrates the service site deployment workflow. The figure is informative and does not define a deployment protocol, a metric encoding, or a C-SMA update policy. | | | | | | 2: SERVICE_INFO(CS-ID, | | | code, input, | | | requirements, | | | Reference GAS, | | | Reference Computing | | | Time) | | |<------------------------| | | | | | 3: Local action: | | | deploy service | | | instance and service | | | contact instance | | | | | | 4: REPORT(CS-ID, | | | CSCI-ID, GAS, | | | Computing Time) | | |------------------------------------------------>| | | | Update | | | computing | | | service table Figure 3: Service Site Deployment Workflow ]]>

Client Service Discovery in a CATS Service Flow To clarify the role of the public service platform in an end-to-end CATS service flow, this section describes a complete service consumption example. The platform is used at the beginning of the flow to recommend CS-ID-related information to the client. The later selection of a service contact instance, data-plane forwarding, and associated metric operation follow the CATS framework and .

The client provides a service description or service requirement to the public service platform.
The platform maps the client input to one or more candidate service entries and returns the corresponding CS-ID-related information, such as service description, input description, Reference Computing Time, Reference GAS, and other service context.
The client selects a suitable CS-ID and constructs a CATS service request. The request contains the selected CS-ID and can include additional service constraints, such as expected service time.
The client sends the CATS service request to the data plane, such as an ingress CATS-Forwarder. Candidate selection and forwarding are performed according to the CATS framework and the service-metric operation defined in .
After a service contact instance is selected and a data path is established, the client uses the Input Description from the platform to construct the service data sent to the selected service site.
The service instance processes the service data and returns the result to the client.

The platform implementation can use keyword matching, tag-based capability search, semantic retrieval, service AI agents, DNS, or other mechanisms to map a client service description to candidate CS-IDs. This document does not standardize those mechanisms. It only describes the CS-ID-related information that makes such recommendation possible. Figure 4 illustrates the position of the public service platform in the client service discovery workflow. The public service platform helps the client obtain CS-ID-related information before the client sends traffic into the data plane. It is not on the data-plane forwarding path. | | | | | | | | 2: CANDIDATE | | | | CS-ID + context | | | |<-------------------| | | | | | | | 3: CATS request | | | | (CS-ID, | | | | requirements) | | | |----------------------------------------->| | | | | 4: Select or | | | | request | | | | service | | | | contact | | | | instance | | | |--------------->| | | | 5: Decision | | | |<---------------| | | | | | 6: Service data via selected service | | | contact instance | | |----------------------------------------->| | | 7: Service result | | |<-----------------------------------------| | Figure 4: Client Service Discovery Workflow ]]>

Security Considerations The public service platform provides catalogue information that clients and service sites rely on for service discovery and deployment context. Implementations should protect the integrity and authenticity of service entries, apply appropriate access control to publication and update operations, and consider the availability of the platform because it may affect service discovery and deployment decisions. Detailed service descriptions and deployment requirements may expose operational or business information. Operators should control what information is published in the catalogue according to local policy. These considerations are complementary to those discussed in and . This document does not define specific security mechanisms.

IANA Considerations This document has no IANA actions at this time.