Computing-Aware Traffic Steering B. Zhang, Ed. Internet-Draft Pengcheng Laboratory Intended status: Standards Track B. Shen, Ed. Expires: 19 March 2027 Harbin Institute of Technology Y. Yang, Ed. Sun Yat-sen University 15 September 2026 CATS Service Contact Instance Functional Implementation draft-zhangb-cats-sci-implementation-01 Abstract The Computing-Aware Traffic Steering (CATS) framework [I-D.ietf-cats-framework] introduces the concept of a Service Contact Instance (SCI) as the client-facing entity responsible for receiving and dispatching service requests. While the framework and the CATS metric documents define the components and the metrics, the concrete observable behavior of a Service Contact Instance - in particular, what it reports to the CATS Service Metric Agent (C-SMA), when it reports, and how service-instance health changes are reflected in the reported metrics - remains underspecified. This document fills that gap. It specifies the functional behavior of a CATS Service Contact Instance in terms of observable behavior and reporting semantics: how an SCI aggregates instance-level information into service-oriented metrics (e.g., Global Available Slots and Computing Time) as defined in [I-D.zhangb-cats-service-metrics-op]; how it monitors the health and status of underlying service instances and adjusts reported metrics accordingly; how it maintains affinity and handles failure scenarios; and how it reports metrics and status updates to the C-SMA, including update policies and threshold-based triggers. A decomposition of the SCI into internal functional components is provided as illustrative implementation guidance, not as a mandated software architecture. This document complements [I-D.ietf-cats-framework], [I-D.ietf-cats-metric-definition-11], and [I-D.zhangb-cats-service-metrics-op] by providing the operational execution layer for the SCI within the unified CATS architecture. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Zhang, et al. Expires 19 March 2027 [Page 1] Internet-Draft CATS SCI Functional Implementation September 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 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. Scope and Relationship to Other CATS Documents . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Service Contact Instance Functional Architecture . . . . . . 6 3.1. SCI Position in CATS Framework . . . . . . . . . . . . . 8 4. Service Instance Metric Collection . . . . . . . . . . . . . 8 4.1. Metric Collection Scope . . . . . . . . . . . . . . . . . 8 4.2. Collection Methods . . . . . . . . . . . . . . . . . . . 9 4.3. Aggregation and Derivation . . . . . . . . . . . . . . . 10 5. Service Instance Health Monitoring . . . . . . . . . . . . . 11 5.1. Health Check Types . . . . . . . . . . . . . . . . . . . 11 5.2. Failure Detection and Recovery . . . . . . . . . . . . . 11 5.3. Metric Adjustment on Health Changes . . . . . . . . . . . 13 6. Request Dispatch and Load Balancing . . . . . . . . . . . . . 13 6.1. Dispatch Decision Logic . . . . . . . . . . . . . . . . . 13 6.2. Affinity Handling . . . . . . . . . . . . . . . . . . . . 14 6.3. Session Lifecycle Management . . . . . . . . . . . . . . 14 7. Metric Reporting to C-SMA . . . . . . . . . . . . . . . . . . 15 7.1. Reporting Interface . . . . . . . . . . . . . . . . . . . 15 Zhang, et al. Expires 19 March 2027 [Page 2] Internet-Draft CATS SCI Functional Implementation September 2026 7.2. Update Policies and Thresholds . . . . . . . . . . . . . 15 7.3. Report Message Format . . . . . . . . . . . . . . . . . . 16 8. External Communication . . . . . . . . . . . . . . . . . . . 17 8.1. Client-Facing Interface . . . . . . . . . . . . . . . . . 17 8.2. Egress CATS-Forwarder Interface . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The Computing-Aware Traffic Steering (CATS) framework [I-D.ietf-cats-framework] defines a Service Contact Instance (SCI) as a client-facing function responsible for receiving requests in the context of a given service. The framework states that an SCI may dispatch service requests to one or more service instances and that steering beyond an SCI is hidden to both clients and CATS components. The framework also notes that "the metrics of the service contact instance may be aggregate metrics from multiple service instances". However, the framework does not specify: * How an SCI derives and aggregates service-oriented metrics (e.g., Global Available Slots, Computing Time) from its underlying service instances. * How an SCI monitors the health and availability of service instances, and how health changes are reflected in the reported metrics. * How an SCI dispatches incoming requests to the appropriate service instance while preserving affinity. * What an SCI reports to the CATS Service Metric Agent (C-SMA), when it reports, and how update frequency is controlled. This document specifies the functional behavior of a CATS Service Contact Instance to address these gaps. The normative requirements of this document are stated in terms of observable SCI behavior and of the reporting semantics towards the C-SMA; the decomposition of the SCI into internal functional components in Section 3 is provided as illustrative implementation guidance. Zhang, et al. Expires 19 March 2027 [Page 3] Internet-Draft CATS SCI Functional Implementation September 2026 The SCI acts as the boundary between the CATS-aware network and the service site. It is responsible for: * Collecting per-service-instance metrics (CPU, memory, GPU, throughput, queue depth, etc.). * Aggregating these metrics into service-oriented abstractions (e.g., Global Available Slots, Computing Time) as defined in [I-D.zhangb-cats-service-metrics-op]. * Monitoring service instance health and adjusting reported metrics accordingly. * Receiving client requests from the Egress CATS-Forwarder and dispatching them to the most suitable service instance. * Reporting aggregated metrics and status to the C-SMA. 1.1. Scope and Relationship to Other CATS Documents This document specifies the functional behavior of the SCI as a CATS component. The scope is deliberately limited in two ways. First, the normative requirements concern the _observable behavior_ of the SCI - the metrics it reports, the semantics of those metrics, the health state machine that drives metric adjustment, and the update policies that control reporting frequency. Second, how the SCI is internally structured (e.g., whether it is implemented as a load balancer, a gateway, or an application-level function) is a local matter; Section 3 provides an illustrative component decomposition that is informative in nature. The relationships to other CATS documents are as follows: * [I-D.ietf-cats-framework] defines the CATS components and their interactions, including general implementation considerations on using CATS metrics (Section 5.4 of that document). This document provides the detailed SCI-side behavior that the framework leaves open. * [I-D.ietf-cats-metric-definition-11] defines the CATS metric taxonomy (Level 0/1/2), the CATS metric field template, and the "CATS Metrics" registry. This document uses the service-oriented metrics defined in [I-D.zhangb-cats-service-metrics-op] (registered in that registry) and specifies how an SCI produces and reports them; it does not define new metric categories. Zhang, et al. Expires 19 March 2027 [Page 4] Internet-Draft CATS SCI Functional Implementation September 2026 * [I-D.zhangb-cats-service-metrics-op] defines the service-oriented metrics (Global Available Slots, Computing Time, Price, Reputation, Security Level) and the C-PS side joint selection workflow. This document specifies the SCI-side execution: how these metrics are derived and maintained at the service site, and how they are reported to the C-SMA. * [I-D.ietf-cats-oam-fw] defines the OAM framework and requirements for CATS. The health monitoring and failure-detection behavior specified in Section 5 of this document is a component-level behavior that complements, and is consistent with, the OAM requirements; the actual OAM mechanisms, measurement frameworks, and management interfaces are out of scope here. * [I-D.yl-cats-data-model] defines a YANG data model for the management of CATS. The report fields specified in Section 7.3 are semantic requirements; their mapping to configuration and management objects should be aligned with that data model where applicable. * [I-D.yxl-cats-protocols-applicability] discusses the applicability of existing protocols for CATS. The choice of transport for metric reporting (Section 7) should follow that document rather than being re-specified here. The framework states that how a service provider structures its services remains out of the scope of CATS. This document does not standardize the internal structure of a service site; it standardizes the behavior of the SCI that is observable by other CATS components, in particular the C-SMA and, indirectly, the C-PS. 1.2. 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 terms defined in [I-D.ietf-cats-framework], [I-D.ietf-cats-metric-definition-11], and [I-D.zhangb-cats-service-metrics-op]. In particular: * CS-ID (CATS Service ID): An identifier for a service. Zhang, et al. Expires 19 March 2027 [Page 5] Internet-Draft CATS SCI Functional Implementation September 2026 * CSCI-ID (CATS Service Contact Instance ID): An identifier for a service contact instance. In this document, it is used operationally as a locator (e.g., IP address and port) towards which the Egress CATS-Forwarder forwards traffic; the framework notes that a service contact instance is reachable via at least one Egress CATS-Forwarder. The exact encoding and resolution of the CSCI-ID are deployment-specific and to be confirmed with the working group. * Global Available Slots (GAS): The maximum number of concurrent requests 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]. * Computing Time: The time required for the site to perform one service request, as defined in [I-D.zhangb-cats-service-metrics-op]. * C-SMA (CATS Service Metric Agent): The functional entity that collects service metrics and advertises them to C-PSes. Additionally, the following terms are used in this document: * Service Instance (SI): A collection of running resources that are orchestrated following a service logic. An SCI may manage one or more SIs for the same CS-ID. * Service Instance ID (SI-ID): A local identifier for a service instance within the scope of an SCI. * Instance Metric: A raw or derived metric specific to a single service instance (e.g., instance CPU utilization, instance queue length). * Health Status: A qualitative assessment of a service instance's operational state (e.g., healthy, degraded, failed). 3. Service Contact Instance Functional Architecture This section provides a decomposition of the SCI into internal functional components. This decomposition is _illustrative_: it identifies the functions that an SCI implementation needs to provide, but it does not mandate a specific software architecture. The normative requirements of this document are expressed in terms of observable SCI behavior (Sections 4 to 8), in particular the reporting semantics towards the C-SMA in Section 7. Implementations may realize the functions below in any manner that satisfies those requirements. Zhang, et al. Expires 19 March 2027 [Page 6] Internet-Draft CATS SCI Functional Implementation September 2026 Figure 1 shows a logical decomposition of the SCI: +---------------------------------------------------------------+ | Service Contact Instance (SCI) | | | | +-----------+ +-----------+ +-----------+ +---------+ | | | Metric | | Health | | Dispatcher| | Session | | | | Collector | | Monitor | | (DP) | | Manager | | | | (MC) | | (HM) | | | | (SM) | | | +-----+-----+ +-----+-----+ +-----+-----+ +----+----+ | | | | | | | | +-------+ | +-------+ | | | | | | | | | +-------------v-------v-------v----------------------v-----+ | | | Metric Aggregator (MA) | | | +---------------------------+------------------------------+ | | | | | +---------------------------v------------------------------+ | | | Reporting Interface (RI) | | | +---------------------------+------------------------------+ | | | | +------------------------------v--------------------------------+ | +------v------+ | C-SMA | +-------------+ Figure 1: SCI Internal Functional Components (Illustrative) The internal components of an SCI are defined as follows. These definitions are descriptive; the behavioral requirements that each component helps satisfy are given in the corresponding sections. Metric Collector (MC): Responsible for collecting raw metrics from each service instance. This includes CPU utilization, memory usage, GPU utilization, request queue depth, response latency, throughput, and error rates. Metric Aggregator (MA): Responsible for aggregating instance-level metrics into service-oriented metrics (e.g., GAS, Computing Time) as defined in [I-D.zhangb-cats-service-metrics-op]. The MA applies local policy and reference information (e.g., from [I-D.zhangb-cats-cmas]) to derive actionable metrics. Health Monitor (HM): Responsible for actively and passively monitoring the health of each service instance. It performs health checks, detects anomalies, and classifies instance status. Zhang, et al. Expires 19 March 2027 [Page 7] Internet-Draft CATS SCI Functional Implementation September 2026 Failure Handler (FH): Responsible for reacting to health changes. It updates the metric aggregator when instances fail or recover, and may trigger re-dispatch of in-flight requests. Dispatcher (DP): Responsible for receiving client requests from the Egress CATS-Forwarder and dispatching them to the most suitable service instance based on local load, health status, and affinity requirements. Session Manager (SM): Responsible for maintaining session state, including affinity bindings between client flows and service instances. It tracks active sessions and notifies the Metric Aggregator of slot allocation and release. Reporting Interface (RI): Responsible for formatting and sending aggregated metrics and status updates to the C-SMA. 3.1. SCI Position in CATS Framework The SCI sits at the boundary between the CATS network and the service site. Its relationships with other CATS components are: * The SCI receives traffic from the Egress CATS-Forwarder. * The SCI reports metrics to the C-SMA, which may be co-located with or adjacent to the SCI. * The C-SMA advertises the SCI's metrics (along with the CSCI-ID) to the C-PS. * The C-PS uses these metrics to make traffic steering decisions. * The SCI does not directly interact with the C-PS or C-NMA; all control-plane communication goes through the C-SMA. The SCI is transparent to the client. The client sees only the CSCI- ID (e.g., an IP address and port) and is unaware of the internal service instances managed by the SCI. 4. Service Instance Metric Collection The Metric Collector (MC) gathers the following categories of information from each service instance: 4.1. Metric Collection Scope Resource Metrics: Raw computing resource utilization. Examples Zhang, et al. Expires 19 March 2027 [Page 8] Internet-Draft CATS SCI Functional Implementation September 2026 include: CPU utilization (%), Memory utilization (%), GPU utilization (%) and GPU memory usage, NPU/TPU utilization (if applicable), Disk I/O and network I/O rates. Performance Metrics: Service-level performance indicators. Examples include: Request queue depth, Average response time, Requests per second (throughput), Error rate (5xx errors, timeout rate). Status Metrics: Operational state indicators. Examples include: Instance health (up/down), Load average, Number of active connections/sessions, Custom application-level status. The MC collects these metrics at a configurable sampling interval (e.g., every 5-10 seconds). The specific collection mechanism (e.g., Prometheus scraping, SNMP, gRPC, HTTP health endpoints) is deployment-specific and outside the scope of this document. 4.2. Collection Methods The MC SHOULD support multiple collection methods to accommodate different service instance types: Pull-based: The MC periodically queries each service instance via a standardized metrics endpoint (e.g., Prometheus /metrics, HTTP REST API, SNMP). This is suitable for instances that expose metrics via well-known interfaces. Push-based: Service instances push metrics to the MC via a message queue or streaming protocol (e.g., gRPC streaming, MQTT, Kafka). This is suitable for high-frequency updates or event-driven metrics. Agent-based: A lightweight agent runs alongside each service instance and reports metrics to the MC. This is suitable for environments where instances cannot be modified to expose endpoints. The MC MUST support at least one of these methods. In mixed deployments, the MC MAY use different methods for different service instances. Zhang, et al. Expires 19 March 2027 [Page 9] Internet-Draft CATS SCI Functional Implementation September 2026 4.3. Aggregation and Derivation The Metric Aggregator (MA) combines instance-level metrics into the service-oriented metrics defined in [I-D.zhangb-cats-service-metrics-op], which are meaningful for CATS traffic steering. The definitions and semantics of these metrics are normative in [I-D.zhangb-cats-service-metrics-op]; this section specifies the SCI-side execution details for deriving and maintaining them. The key aggregated metrics are: Global Available Slots (GAS): The MA calculates the total GAS for the SCI by summing the available capacity of all healthy service instances. For each instance, the available capacity is derived from: the instance's maximum concurrent request capacity (the initial GAS value, which can be calculated based on resource allocation and the service reference information defined in [I-D.zhangb-cats-service-metrics-op]), the instance's current active session count (from the Session Manager), and the instance's health status (from the Health Monitor). Unhealthy instances contribute 0 to GAS. GAS = SUM_over_instances(max_capacity_i - active_sessions_i) for all healthy instances i The MA MAY apply a local policy factor (e.g., a safety margin of 80%, as an example configuration) to prevent over-subscription. Computing Time: The MA estimates the Computing Time for the SCI based on the observed response times of service instances. This can be computed as: the weighted average of instance response times, weighted by instance load; the median or percentile (e.g., p95) of instance response times to account for outliers; or a dynamically adjusted estimate based on current load and historical trends. The MA also reports the min/max computing time and the associated input token counts for reference. Optional Metrics: The MA MAY also derive optional service attributes such as Price, Reputation, and Security Level as defined in [I-D.zhangb-cats-service-metrics-op]. The derivation algorithm is a local matter and is not standardized by this document. However, the MA MUST ensure that the reported metrics are consistent and comparable across updates, and that they conform to the semantics and units defined in [I-D.zhangb-cats-service-metrics-op]. Zhang, et al. Expires 19 March 2027 [Page 10] Internet-Draft CATS SCI Functional Implementation September 2026 5. Service Instance Health Monitoring The Health Monitor (HM) monitors the health of each service instance and drives metric adjustment and dispatch behavior. The health monitoring behavior specified in this section is a component-level behavior of the SCI; it complements the CATS OAM framework [I-D.ietf-cats-oam-fw], which defines the OAM layering and requirements for CATS as a whole. The mechanisms used to realize health checks (e.g., in-band OAM, dedicated probes) are out of scope of this document. The HM performs the following types of health checks on each service instance: 5.1. Health Check Types Liveness Check: Verifies that the service instance process is running and responsive. This is typically done via a simple TCP connection or HTTP GET to a /health endpoint. Failure indicates the instance is down. Readiness Check: Verifies that the service instance is ready to accept new requests. This may check: whether the instance has finished initialization, whether critical dependencies are available, and whether the instance is not in a maintenance mode. Performance Check: Verifies that the service instance is performing within acceptable bounds. This may check: response time against a threshold, error rate against a threshold, and resource utilization (e.g., CPU > 90% for 30 seconds). The HM SHOULD perform these checks at regular intervals (e.g., every 5-10 seconds for liveness, every 30 seconds for readiness and performance). The intervals and thresholds SHOULD be configurable. 5.2. Failure Detection and Recovery The HM classifies each service instance into one of the following health states: * HEALTHY: The instance is fully operational and accepting requests. * DEGRADED: The instance is operational but experiencing performance issues (e.g., high latency, high error rate). New requests MAY be steered away, but existing sessions are maintained. Zhang, et al. Expires 19 March 2027 [Page 11] Internet-Draft CATS SCI Functional Implementation September 2026 * UNHEALTHY: The instance is not operational or not ready. No new requests are dispatched to this instance. Existing sessions MAY be migrated or terminated based on policy. * UNKNOWN: The HM cannot determine the instance's status (e.g., network partition). The instance is treated as UNHEALTHY until status is confirmed. Figure 2 shows the health state machine and the transitions between states: +------------+ | UNKNOWN | +-----+------+ | status confirmed (treated as UNHEALTHY meanwhile) v +--------+ fail xN +----------+ fail xN +-----------+ | HEALTHY| ---------> | DEGRADED | ---------> | UNHEALTHY | | | <--------- | | <--------- | | +--------+ pass xM +----------+ pass xM +-----------+ ^ | ^ | ^ | | | | | +----------+------------+----------+------------+ recovery (pass xM) at any degraded/unhealthy state Figure 2: Service Instance Health State Machine State transitions trigger the following actions: * HEALTHY -> DEGRADED: The HM notifies the MA to reduce the instance's contribution to GAS. The DP reduces or stops sending new requests to the instance. * DEGRADED -> UNHEALTHY: The HM notifies the MA to set the instance's contribution to GAS to 0. The DP stops sending new requests. The SM initiates session migration or graceful termination for affected sessions. * UNHEALTHY -> HEALTHY: The HM notifies the MA to restore the instance's contribution to GAS. The DP resumes sending requests. The HM MUST implement a hysteresis mechanism (e.g., require N consecutive failed checks before marking UNHEALTHY, and M consecutive passed checks before marking HEALTHY; N and M are example configuration parameters) to avoid flapping. Zhang, et al. Expires 19 March 2027 [Page 12] Internet-Draft CATS SCI Functional Implementation September 2026 5.3. Metric Adjustment on Health Changes When the HM detects a health state change, the MA MUST adjust the aggregated metrics accordingly: * When an instance becomes DEGRADED, the MA MAY reduce its max_capacity by a configured degradation factor (e.g., 50%) or set it to 0 based on local policy. * When an instance becomes UNHEALTHY, the MA MUST set its contribution to GAS to 0. * When an instance recovers to HEALTHY, the MA MUST restore its contribution to GAS based on current load. * The Computing Time estimate MUST be recalculated to exclude UNHEALTHY instances and weight DEGRADED instances lower. These adjustments are reflected in the next metric report to the C-SMA. The MA SHOULD batch rapid health changes to avoid excessive updates. 6. Request Dispatch and Load Balancing The Dispatcher (DP) receives client requests from the Egress CATS- Forwarder and selects a service instance to handle each request. The dispatch decision is based on: 6.1. Dispatch Decision Logic 1. Affinity Requirements: If the request belongs to an existing session with affinity, the DP MUST dispatch to the same service instance (if healthy). 2. Health Status: The DP MUST NOT dispatch to UNHEALTHY instances. It SHOULD avoid DEGRADED instances unless no HEALTHY instances are available. 3. Load Balancing Policy: The DP selects among HEALTHY instances using a local load balancing algorithm. Supported algorithms include round-robin, least-connections, weighted response time, resource-aware (lowest CPU/memory/GPU utilization), and slot- based (most available slots, i.e., max_capacity - active_sessions). The choice of algorithm is a local matter. 4. Local Policy: The DP MAY apply additional policies such as price optimization, security level requirements, or instance preference. Zhang, et al. Expires 19 March 2027 [Page 13] Internet-Draft CATS SCI Functional Implementation September 2026 The DP MUST handle the case where no HEALTHY instances are available. In this case, it MAY: * Return an error to the client (e.g., HTTP 503 Service Unavailable). * Queue the request and retry after a timeout. * Dispatch to a DEGRADED instance as a last resort. 6.2. Affinity Handling The Session Manager (SM) maintains affinity bindings between client flows and service instances. Affinity is identified by a flow key (e.g., 5-tuple: source IP, destination IP, source port, destination port, protocol). When a new request arrives: * The SM checks if the flow key has an existing binding. * If yes, and the bound instance is HEALTHY, the DP dispatches to that instance. * If yes, but the bound instance is UNHEALTHY, the SM removes the binding and the DP selects a new instance. * If no binding exists, the DP selects an instance and the SM creates a new binding. Affinity bindings have a configurable timeout. After the timeout expires with no activity, the SM removes the binding. The SM MUST support affinity at the flow level. It MAY also support affinity at the session level (e.g., for HTTP sessions identified by cookies or session IDs). 6.3. Session Lifecycle Management The SM tracks the lifecycle of each session: Allocation: When a request is dispatched, the SM increments the active session count for the selected instance and records the flow binding. Renewal: For long-lived sessions, the SM may refresh the binding timeout on each packet or keepalive. Zhang, et al. Expires 19 March 2027 [Page 14] Internet-Draft CATS SCI Functional Implementation September 2026 Release: When the session ends (e.g., TCP FIN/RST, timeout, explicit logout), the SM decrements the active session count and removes the binding. The SM notifies the MA of session allocation and release events so that GAS can be updated. However, per-session changes do not necessarily trigger immediate reports to the C-SMA; the MA applies local aggregation and threshold policies. 7. Metric Reporting to C-SMA The Reporting Interface (RI) communicates with the C-SMA to report aggregated metrics and status updates. This section is normative: it specifies the semantics of what an SCI reports, when it reports, and how update frequency is controlled. The transport mechanisms used to carry the reports are deployment-specific and should follow the protocol applicability analysis in [I-D.yxl-cats-protocols-applicability]. 7.1. Reporting Interface The RI SHOULD use a reliable transport (e.g., TCP, QUIC, or HTTP/2) to ensure metric delivery. The specific protocol is deployment- specific. In centralized deployments (e.g., SDN controller), the RI MAY use a RESTful API (e.g., RESTCONF [RFC8040]) or gRPC to push metrics to the C-SMA. In distributed deployments, the RI MAY use a routing protocol extension (e.g., BGP-LS [RFC8571], GRASP [RFC8990]) or a dedicated CATS metric distribution protocol. The applicability of these mechanisms is discussed in [I-D.yxl-cats-protocols-applicability]; this document does not select among them. 7.2. Update Policies and Thresholds The RI applies the following policies to control update frequency. These policies directly address the question of the appropriate frequency and scope of metric distribution, which the CATS framework leaves open: Periodic Heartbeat: A full report is sent at a fixed interval (e.g., every 60 seconds, as an example configuration) to maintain soft state and prevent stale metrics. Threshold-based Trigger: A delta report is sent when any metric Zhang, et al. Expires 19 March 2027 [Page 15] Internet-Draft CATS SCI Functional Implementation September 2026 crosses a configured threshold. Examples include: GAS changes by more than 10% or an absolute value of 50, Computing Time deviates by more than 20%, or Health status changes for any instance. The numerical values above are examples; the thresholds MUST be configurable. Event-based Trigger: A delta report is sent immediately upon critical events: all instances become UNHEALTHY (GAS = 0), an instance recovers from UNHEALTHY to HEALTHY, or security-related events (e.g., detected attack). Rate Limiting: The RI MUST implement rate limiting to prevent excessive updates during rapid fluctuations (e.g., during a thundering herd or DDoS attack). The specific thresholds and intervals SHOULD be configurable via the CATS Management Plane, and their alignment with the CATS data model [I-D.yl-cats-data-model] SHOULD be provided. 7.3. Report Message Format The report message contains the following fields. The semantics of these fields are normative; their encoding and wire format depend on the chosen transport and are out of scope of this document: Zhang, et al. Expires 19 March 2027 [Page 16] Internet-Draft CATS SCI Functional Implementation September 2026 +===========+====================================================+ | Field | Description | +===========+====================================================+ | CSCI-ID | Identifier of the reporting SCI | +-----------+----------------------------------------------------+ | CS-ID | Identifier of the service | +-----------+----------------------------------------------------+ | Timestamp | Time of metric generation (Unix epoch) | +-----------+----------------------------------------------------+ | Sequence | Monotonically increasing sequence number | | Number | | +-----------+----------------------------------------------------+ | GAS | Global Available Slots, as defined in | | | [I-D.zhangb-cats-service-metrics-op] | +-----------+----------------------------------------------------+ | Computing | Estimated processing time in milliseconds, as | | Time | defined in [I-D.zhangb-cats-service-metrics-op] | +-----------+----------------------------------------------------+ | Health | Number of HEALTHY/DEGRADED/UNHEALTHY instances | | Summary | | +-----------+----------------------------------------------------+ | Optional | Price, Reputation, Security Level (if applicable), | | Metrics | as defined in [I-D.zhangb-cats-service-metrics-op] | +-----------+----------------------------------------------------+ | Instance | Per-instance status (optional, for debugging) | | Details | | +-----------+----------------------------------------------------+ Table 1: Report Message Fields The encoding details, including field lengths and wire format, are TBD and depend on the chosen transport protocol, following the applicability analysis in [I-D.yxl-cats-protocols-applicability]. 8. External Communication The SCI exposes a client-facing interface that is the CSCI-ID (e.g., an IP address and port). Clients send service requests to this interface, and the Egress CATS-Forwarder forwards traffic to it. 8.1. Client-Facing Interface The SCI MUST support the following on the client-facing interface: * Accept incoming connections/requests from the Egress CATS- Forwarder. Zhang, et al. Expires 19 March 2027 [Page 17] Internet-Draft CATS SCI Functional Implementation September 2026 * Maintain transport-layer state (e.g., TCP connections) for the duration of the session. * Support the service protocol (e.g., HTTP, gRPC, RTP) required by the CS-ID. The SCI MUST NOT expose internal service instance details (e.g., SI- IDs, internal IP addresses) to the client. 8.2. Egress CATS-Forwarder Interface The SCI communicates with the Egress CATS-Forwarder via the underlay network. The Egress CATS-Forwarder is responsible for: * Decapsulating CATS overlay traffic and forwarding it to the SCI's CSCI-ID. * Receiving responses from the SCI and encapsulating them for return to the Ingress CATS-Forwarder. The SCI does not need to be CATS-aware; it operates as a standard service endpoint from the network perspective. However, the SCI MAY support CATS-specific signaling (e.g., for affinity or session state synchronization) if defined by future documents. 9. Security Considerations The SCI handles client requests and manages internal service instances, making it a critical security boundary. The following security measures are REQUIRED: Authentication: The SCI MUST authenticate the Egress CATS-Forwarder to prevent unauthorized traffic injection. This may use mutual TLS, IPsec, or network-layer authentication. Authorization: The SCI MUST verify that incoming requests are authorized for the requested CS-ID. This may involve validating tokens, certificates, or network-level policies. Isolation: Service instances managed by the same SCI MUST be isolated from each other to prevent cross-tenant attacks. This includes network isolation (e.g., separate VLANs or namespaces) and resource isolation (e.g., CPU/memory limits). Metric Integrity: The RI MUST protect the integrity of metric reports sent to the C-SMA. This may use TLS, message authentication codes (MACs), or digital signatures. Zhang, et al. Expires 19 March 2027 [Page 18] Internet-Draft CATS SCI Functional Implementation September 2026 Confidentiality: Metric reports SHOULD be encrypted to prevent disclosure of internal service topology and capacity. DDoS Protection: The SCI SHOULD implement rate limiting and connection throttling to protect against denial-of-service attacks that could exhaust GAS. Health Check Security: Health check endpoints exposed by service instances SHOULD be protected to prevent spoofing or manipulation. 10. IANA Considerations This document defines the semantics of the metrics reported by an SCI, but does not define a new protocol or a new wire format for metric reporting; the encoding depends on the chosen transport (see Section 7.1). Therefore, this document has no IANA actions at this time. If a dedicated CATS metric reporting protocol or a registry for report fields is defined in the future, the corresponding IANA registrations would be specified in that document, in coordination with the CATS working group. 11. References 11.1. 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, 2 April 2026, . [I-D.ietf-cats-metric-definition-11] Kehan, Y., Li, C., Contreras, L. M., Ros-Giralt, J., and G. Zeng, "CATS Metrics Definition", Work in Progress, Internet-Draft, draft-ietf-cats-metric-definition-11, 4 September 2026, . Zhang, et al. Expires 19 March 2027 [Page 19] Internet-Draft CATS SCI Functional Implementation September 2026 [I-D.zhangb-cats-service-metrics-op] Zhang, B., Dai, Y., Du, Z., Zeng, G., and C. Miao, "Computing Service Metrics Operation and Joint Service Selection under CATS", Work in Progress, Internet-Draft, draft-zhangb-cats-service-metrics-op-05, 14 September 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 11.2. Informative References [I-D.ietf-cats-oam-fw] Fu, H., Xiong, Q., Du, Z., and B. Liu, "OAM Framework and Requirements for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-ietf-cats-oam-fw- 01, 21 July 2026, . [I-D.yl-cats-data-model] Lin, C., Li, Z., Xiong, Q., and L. M. Contreras, "Data Model for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-yl-cats-data-model-07, 6 July 2026, . [I-D.yxl-cats-protocols-applicability] Yao, H., Dunbar, L., Xiong, Q., and C. Lin, "Protocols Applicability for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-yxl-cats- protocols-applicability-01, 2 July 2026, . [I-D.zhangb-cats-cmas] Zhang, B., Dai, Y., and Z. Du, "Public Service Platform for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-zhangb-cats-cmas-06, 18 August 2026, . Zhang, et al. Expires 19 March 2027 [Page 20] Internet-Draft CATS SCI Functional Implementation September 2026 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, January 2017, . [RFC8571] Ginsberg, L., Previdi, S., and Q. Wu, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, March 2019, . [RFC8990] Bormann, C., Carpenter, B., and B. Liu, "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, March 2021, . Appendix A. Acknowledgments The authors thank the CATS working group for their valuable feedback and contributions to this document. Authors' Addresses Bin Zhang (editor) Pengcheng Laboratory Sibilong Street Shenzhen Guangdong, 518055 China Email: zhangb@pcl.ac.cn Bowen Shen (editor) Harbin Institute of Technology Taoyuan Street Shenzhen 518055 China Email: shenbowen@stu.hit.edu.cn Yixuan Yang (editor) Sun Yat-sen University Gongchang Street Shenzhen Guangdong, 518055 China Email: yangyx277@mail2.sysu.edu.cn Zhang, et al. Expires 19 March 2027 [Page 21]