Computing-Aware Traffic Steering B. Zhang, Ed. Internet-Draft Pengcheng Laboratory Intended status: Standards Track Z. Du, Ed. Expires: 10 April 2027 China Mobile B. Shen, Ed. Harbin Institute of Technology Y. Yang, Ed. Sun Yat-sen University 7 October 2026 CATS Service Metric Agent (C-SMA) Functional Implementation draft-zhangb-cats-csma-implementation-01 Abstract The Computing-Aware Traffic Steering (CATS) framework defines the CATS Service Metric Agent (C-SMA) as the functional entity responsible for collecting service capabilities and status, and reporting them to CATS Path Selectors (C-PSes). While the framework and the CATS metric documents define the components and the metrics, the concrete observable behavior of the C-SMA - in particular, how it validates and sanitizes the metrics it collects, how it manages soft- state for stale or failing Service Contact Instances (SCIs), and how it synchronizes with the C-PS - remains underspecified. This document fills that gap. It specifies the functional behavior of the C-SMA in terms of observable behavior and reporting semantics: how the C-SMA collects metric reports from SCIs (as specified in [I-D.zhangb-cats-sci-implementation]); how it validates and sanitizes these reports to prevent erroneous or malicious data from influencing traffic steering; how it manages a local metric cache with soft-state aging; how it enforces local policies and update control policies; and how it synchronizes with the C-PS, including recovery and reconciliation. A decomposition of the C-SMA into internal functional components is provided as illustrative implementation guidance, not as a mandated software architecture. This document complements [RFC10053], [I-D.ietf-cats-metric-definition-13], [I-D.zhangb-cats-service-metrics-op], and [I-D.zhangb-cats-sci-implementation] by providing the operational execution layer for the C-SMA 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 10 April 2027 [Page 1] Internet-Draft CATS C-SMA Functional Implementation October 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 10 April 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 . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. C-SMA Functional Architecture . . . . . . . . . . . . . . . . 7 3.1. C-SMA Position in CATS Framework . . . . . . . . . . . . 9 4. Metric Collection from SCIs . . . . . . . . . . . . . . . . . 9 4.1. Collection Interface . . . . . . . . . . . . . . . . . . 9 4.2. Metric Validation and Sanitization . . . . . . . . . . . 10 5. Metric Caching and State Management . . . . . . . . . . . . . 11 5.1. Local Metric Cache . . . . . . . . . . . . . . . . . . . 11 5.2. Soft-State and Aging . . . . . . . . . . . . . . . . . . 11 5.3. Per-SCI State Tracking . . . . . . . . . . . . . . . . . 12 6. Control-Plane Protocol Adaptation . . . . . . . . . . . . . . 13 6.1. Centralized Model: Northbound Interface . . . . . . . . . 13 6.2. Distributed Model: Routing Protocol Extensions . . . . . 14 6.3. Hybrid Model: Combined Approach . . . . . . . . . . . . . 14 6.4. Open Items for Protocol Documents . . . . . . . . . . . . 15 7. Policy Enforcement . . . . . . . . . . . . . . . . . . . . . 15 7.1. Local Policy Engine . . . . . . . . . . . . . . . . . . . 15 Zhang, et al. Expires 10 April 2027 [Page 2] Internet-Draft CATS C-SMA Functional Implementation October 2026 7.2. Metric Transformation Policies . . . . . . . . . . . . . 16 7.3. Update Control Policies . . . . . . . . . . . . . . . . . 16 8. Security and Trust Management . . . . . . . . . . . . . . . . 16 8.1. SCI Authentication . . . . . . . . . . . . . . . . . . . 16 8.2. C-PS Authentication . . . . . . . . . . . . . . . . . . . 17 8.3. Metric Integrity and Freshness . . . . . . . . . . . . . 17 9. Dynamic Synchronization . . . . . . . . . . . . . . . . . . . 18 9.1. Trigger-Based Updates . . . . . . . . . . . . . . . . . . 18 9.2. Periodic Synchronization . . . . . . . . . . . . . . . . 18 9.3. Recovery and Reconciliation . . . . . . . . . . . . . . . 19 10. Failure Handling . . . . . . . . . . . . . . . . . . . . . . 19 10.1. SCI Failure Detection . . . . . . . . . . . . . . . . . 19 10.2. C-PS Unreachability . . . . . . . . . . . . . . . . . . 20 10.3. Partitioned Operation . . . . . . . . . . . . . . . . . 20 11. Scalability Considerations . . . . . . . . . . . . . . . . . 21 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 14.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction The Computing-Aware Traffic Steering (CATS) framework [RFC10053] defines the CATS Service Metric Agent (C-SMA) as a functional component that gathers information about service sites and server resources, as well as the status of the different service instances. The C-SMA advertises these metrics to CATS Path Selectors (C-PSes) to enable compute-aware traffic steering decisions. However, the framework does not specify: * How a C-SMA collects metrics from multiple Service Contact Instances (SCIs) within a service site. * How a C-SMA validates, and caches metrics before reporting. * How a C-SMA adapts to different control-plane deployment models (centralized, distributed, hybrid). * How a C-SMA enforces local policies, security policies, and update control policies. * How a C-SMA handles failures, partitions, and recovery scenarios. Zhang, et al. Expires 10 April 2027 [Page 3] Internet-Draft CATS C-SMA Functional Implementation October 2026 This document specifies the functional behavior of the C-SMA to address these gaps. The normative requirements of this document are stated in terms of observable C-SMA behavior and of the reporting semantics towards the C-PS; the decomposition of the C-SMA into internal functional components in Section 3 is provided as illustrative implementation guidance. The C-SMA acts as the bridge between the service site (and its SCIs) and the CATS control plane. It is responsible for: * Collecting metrics from one or more SCIs within the service site. * Validating and sanitizing metrics to prevent erroneous or malicious data from influencing traffic steering. * Caching metrics and maintaining soft-state to handle transient failures. * Adapting to the control-plane protocol used in the deployment (as analyzed in [I-D.yxl-cats-protocols-applicability]). * Enforcing local policies (e.g., metric transformation, update throttling, security level requirements). * Authenticating SCIs and C-PSes, and protecting metric integrity. * Handling failures of SCIs, C-PSes, and network partitions. 1.1. Scope and Relationship to Other CATS Documents This document specifies the functional behavior of the C-SMA as a CATS component. As with the SCI document [I-D.zhangb-cats-sci-implementation], the scope is deliberately limited in two ways. First, the normative requirements concern the _observable behavior_ of the C-SMA - the validation rules applied to incoming SCI reports, the soft-state management of the metric cache, and the synchronization semantics towards the C-PS. Second, how the C-SMA is internally structured 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: Zhang, et al. Expires 10 April 2027 [Page 4] Internet-Draft CATS C-SMA Functional Implementation October 2026 * [RFC10053] defines the CATS components and their interactions, including the C-SMA role of collecting service metrics and advertising them to C-PSes, and the centralized/distributed/hybrid deployment models (Appendix A of that document). This document provides the detailed C-SMA-side behavior that the framework leaves open. * [I-D.ietf-cats-metric-definition-13] defines the CATS metric taxonomy, the CATS metric field template, and the "CATS Metrics" registry. The validation rules in Section 4.2 of this document reference the metric semantics and field definitions of that document; this document does not define new metric categories. * [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. The metrics that the C-SMA collects, validates, and advertises are those defined in that document. * [I-D.zhangb-cats-sci-implementation] specifies the SCI-side behavior: how an SCI derives and reports service-oriented metrics to the C-SMA. This document is the control-plane counterpart: it specifies how the C-SMA receives, validates, caches, and forwards those reports. The two documents share the same metric semantics, the same health state model, and the same update-control philosophy; the report fields defined in that document are the input to the validation and caching functions defined here. * [I-D.ietf-cats-oam-fw] defines the OAM framework and requirements for CATS. The failure-detection, synchronization, and partitioned-operation behavior specified in Sections 9 and 10 of this document is a component-level behavior that complements, and is consistent with, the OAM requirements; the OAM mechanisms and management interfaces are out of scope here. * [I-D.ietf-cats-data-model] defines a YANG data model for the management of CATS. The thresholds, policies, and configuration objects mentioned in Section 7 of this document should be mapped to that data model where applicable; this document does not define new YANG objects. * [I-D.yxl-cats-protocols-applicability] discusses the applicability of existing protocols for CATS. This document does not define new protocol extensions or wire formats for metric distribution; it specifies the C-SMA-side behavior that is independent of the chosen transport, and leaves protocol selection to that document (see Section 6). Zhang, et al. Expires 10 April 2027 [Page 5] Internet-Draft CATS C-SMA Functional Implementation October 2026 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 C-SMA implementation; it standardizes the behavior of the C-SMA that is observable by other CATS components, in particular 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 [RFC10053], [I-D.ietf-cats-metric-definition-13], [I-D.zhangb-cats-service-metrics-op], and [I-D.zhangb-cats-sci-implementation]. In particular: * CS-ID (CATS Service ID): An identifier for a service. * CSCI-ID (CATS Service Contact Instance ID): An identifier for a service contact instance. * 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. * C-PS (CATS Path Selector): The functional entity that selects paths towards service sites and instances. Additionally, the following terms are used in this document: * Service Site: A location that hosts one or more SCIs and their underlying service instances. Zhang, et al. Expires 10 April 2027 [Page 6] Internet-Draft CATS C-SMA Functional Implementation October 2026 * SCI Report: A message sent by an SCI to the C-SMA containing aggregated metrics and status, as defined in [I-D.zhangb-cats-sci-implementation]. * Metric Cache: A local data structure maintained by the C-SMA to store the most recent metrics from each SCI. * Update Trigger: An event that causes the C-SMA to send a metric update to the C-PS. * Policy Engine: The component within the C-SMA that evaluates and enforces local policies on metric reporting. * Protocol Adapter: The component within the C-SMA that adapts internal metric representations to the wire format required by the control-plane protocol. 3. C-SMA Functional Architecture This section provides a decomposition of the C-SMA into internal functional components. This decomposition is _illustrative_: it identifies the functions that a C-SMA 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 C-SMA behavior (Sections 4 to 11), in particular the validation rules in Section 4.2 and the synchronization semantics in Section 9. Implementations may realize the functions below in any manner that satisfies those requirements. Figure 1 shows a logical decomposition of the C-SMA: Zhang, et al. Expires 10 April 2027 [Page 7] Internet-Draft CATS C-SMA Functional Implementation October 2026 +---------------------------------------------------------------+ | CATS Service Metric Agent (C-SMA) | | | | +----------------+ +------------------+ +---------------+ | | | SCI Collection | | Validator & | | Update | | | | Interface (SI) | | Sanitizer (VS) | | Controller(UC)| | | +-----+----------+ +--------+---------+ +------+--------+ | | | | | | | +-----v--------------------v--------------------v----------+ | | | Metric Cache (MC) | | | +---------------------------+------------------------------+ | | | | | +---------------------------v------------------------------+ | | | Protocol Adapter (PA) | | | +---------------------------+------------------------------+ | | | | +------------------------------v--------------------------------+ | +------v------+ | C-PS | +-------------+ Figure 1: C-SMA Internal Functional Components (Illustrative) The Policy Engine (PE) is a cross-cutting component consulted by the Validator & Sanitizer, the Metric Cache, and the Update Controller; it is omitted from the data path in Figure 1 for clarity. The internal components of a C-SMA are defined as follows. These definitions are descriptive; the behavioral requirements that each component helps satisfy are given in the corresponding sections. SCI Collection Interface (SI): Responsible for receiving metric reports from SCIs within the service site. It supports multiple transport protocols (e.g., gRPC, HTTP/2, MQTT, internal message bus) and manages the lifecycle of SCI connections. Metric Cache (MC): Responsible for storing the most recent metrics from each SCI. It provides fast lookup for the Validator & Sanitizer, the Policy Engine, and the Update Controller. The cache implements time-to-live (TTL) and soft-state aging to handle stale data. Validator & Sanitizer (VS): Responsible for validating incoming SCI reports for correctness and sanity. It checks for out-of-range values, sudden anomalous changes, duplicate or out-of-sequence reports, and format compliance. Invalid reports are logged and optionally dropped or quarantined. Zhang, et al. Expires 10 April 2027 [Page 8] Internet-Draft CATS C-SMA Functional Implementation October 2026 Policy Engine (PE): Responsible for enforcing local policies on metric reporting. Policies include metric transformation, security level assignment or verification, price and reputation policies, and update suppression during maintenance windows. Update Controller (UC): Responsible for determining when and how often to send updates to the C-PS. It implements threshold-based, event-based, and periodic update policies. It also implements rate limiting and burst control. Protocol Adapter (PA): Responsible for adapting internal metric representations to the wire format required by the control-plane protocol. The set of applicable protocols is analyzed in [I-D.yxl-cats-protocols-applicability]; this document does not define new wire formats. 3.1. C-SMA Position in CATS Framework The C-SMA sits between the service site (SCIs) and the CATS control plane (C-PS). Its relationships with other CATS components are: * The C-SMA receives metric reports from one or more SCIs within the service site. * The C-SMA validates, and caches these metrics. * The C-SMA advertises metrics to the C-PS via the control-plane protocol. * The C-SMA does not directly interact with clients, C-TCs, or CATS- Forwarders. * The C-SMA may be co-located with an SCI, an Egress CATS-Forwarder, or deployed as a standalone component within the service site. The C-SMA is the authoritative source of computing metrics for the service site. The C-PS relies on the C-SMA's reports to build the Computing Service Table. 4. Metric Collection from SCIs The SCI Collection Interface (SI) receives metric reports from SCIs. The interface supports the following modes: 4.1. Collection Interface Push Mode (Recommended): SCIs proactively push metric reports to the Zhang, et al. Expires 10 April 2027 [Page 9] Internet-Draft CATS C-SMA Functional Implementation October 2026 C-SMA at configurable intervals or upon significant changes. This reduces polling overhead and enables near-real-time updates. The SI MUST support at least one of the following push transports: gRPC streaming (bidirectional), HTTP/2 with Server-Sent Events (SSE), MQTT publish/subscribe, or Internal message bus (e.g., Kafka, RabbitMQ). Pull Mode: The C-SMA periodically queries SCIs for metrics. This is useful when SCIs cannot initiate connections (e.g., behind NAT or firewall). The SI MUST support HTTP GET or gRPC unary calls for pull mode. Hybrid Mode: A combination of push and pull. SCIs push routine updates, and the C-SMA pulls on-demand during recovery or anomaly detection. The SI MUST support multiple concurrent SCI connections. Each connection is identified by the CSCI-ID and authenticated. 4.2. Metric Validation and Sanitization The Validator & Sanitizer (VS) inspects every incoming SCI report before it enters the Metric Cache. The purpose is to prevent erroneous or malicious reports from influencing traffic steering decisions. The validation rules below are normative in the sense that a C-SMA MUST apply them; the exact thresholds are example values and MUST be configurable. The semantics and units of the validated metrics are those defined in [I-D.zhangb-cats-service-metrics-op] . The VS performs the following checks: Range Validation: Each metric value MUST fall within a valid range consistent with its field definition in [I-D.zhangb-cats-service-metrics-op]: GAS: 0 to MAX_UINT32; Computing Time: 0 to 3600000 ms (1 hour, as an example ceiling); Price: 0 to MAX_UINT32; Reputation: 0 to 10 (as an example scale); Security Level: 0 to 10 (as an example scale). Values outside these ranges are rejected. The valid ranges MUST be derived from the registered field definitions; the values above are examples. Rate-of-Change Validation: The VS detects anomalous changes: GAS change > 50% within 1 second without a corresponding health change; Computing Time change > 100% within 1 second; Health status flapping (> 3 transitions within 10 seconds). These thresholds are example configurations. Anomalous reports MAY be quarantined for manual review or accepted with a warning flag. Sequence Validation: The VS checks the sequence number or timestamp Zhang, et al. Expires 10 April 2027 [Page 10] Internet-Draft CATS C-SMA Functional Implementation October 2026 to detect duplicate, out-of-order, or replayed reports. Old reports are discarded. Cross-Metric Consistency: The VS checks consistency across metrics: if all SCIs are UNHEALTHY, Site_GAS MUST be 0; if Site_GAS > 0, at least one SCI MUST be HEALTHY; Computing Time SHOULD be > 0 if GAS > 0. Sanitization: The VS MAY apply smoothing filters (e.g., moving average) to reduce noise in frequently fluctuating metrics. 5. Metric Caching and State Management The Metric Cache (MC) stores the most recent validated metrics from each SCI. The cache is organized as follows: +===============+=======+=====+================+===============+ | CSCI-ID | CS-ID | GAS | Comp Time (ms) | Health Status | +===============+=======+=====+================+===============+ | 188.3.67.3:67 | ARS | 400 | 5 | HEALTHY | +---------------+-------+-----+----------------+---------------+ | 188.3.67.3:68 | VRS | 100 | 15 | HEALTHY | +---------------+-------+-----+----------------+---------------+ | 188.3.67.4:69 | ARS | 600 | 6 | HEALTHY | +---------------+-------+-----+----------------+---------------+ | 188.3.67.4:70 | LLMS | 300 | 12 | DEGRADED | +---------------+-------+-----+----------------+---------------+ Table 1: Metric Cache Structure 5.1. Local Metric Cache Each entry includes: CSCI-ID and CS-ID; all reported metrics (GAS, Computing Time, optional metrics); Health status; Timestamp of last update; Sequence number of last report; TTL (time-to-live) for soft- state aging. The MC provides O(1) lookup by CSCI-ID and supports range queries by CS-ID for aggregation. 5.2. Soft-State and Aging The MC implements soft-state aging to handle SCI failures or network partitions. The behavior in this section addresses the CATS charter item on the appropriate frequency and scope of metric distribution: aging and withdrawal semantics determine how a C-PS can safely rely on previously advertised metrics, and what the C-SMA advertises when a source of metrics disappears. Zhang, et al. Expires 10 April 2027 [Page 11] Internet-Draft CATS C-SMA Functional Implementation October 2026 TTL-Based Expiration: Each cache entry has a TTL (e.g., 2x the expected reporting interval). If no update is received within the TTL, the entry is marked as STALE. The TTL for each metric class MUST be configurable; the example multiplier is informative. STALE Handling: When an entry becomes STALE, the C-SMA MAY send a pull request to the SCI. If no response is received within a grace period, the SCI is marked as UNHEALTHY and its GAS contribution is set to 0. The C-SMA sends an update to the C-PS reflecting the reduced capacity. Hard-State vs. Soft-State: The C-SMA maintains hard-state for static information (e.g., CS-ID to CSCI-ID mappings) and soft-state for dynamic metrics (e.g., GAS, Computing Time). Cache Size Management: The MC MUST implement a maximum cache size. When the limit is reached, the least-recently-used (LRU) entries are evicted. Eviction of an entry triggers a withdrawal advertisement to the C-PS. 5.3. Per-SCI State Tracking The C-SMA maintains a state machine for each SCI. This state machine operates at the granularity of an SCI (a reporting endpoint at a service site) and tracks the reliability of the SCI as a source of metric reports. It is distinct from, and complementary to, the instance-level health state machine defined in [I-D.zhangb-cats-sci-implementation] (HEALTHY, DEGRADED, UNHEALTHY, UNKNOWN), which tracks the operational state of a service instance: an SCI in the ACTIVE state may report instances in any health state, and an SCI that is FAILED as a reporting source implies that the health of the instances behind it is unknown to the C-PS. * ACTIVE: The SCI has been discovered but not yet confirmed healthy. * HEALTHY: The SCI is reporting metrics normally. * STALE: No report received within TTL. The C-SMA attempts recovery. * FAILED: The SCI is considered unreachable. Its metrics are withdrawn. State transitions trigger updates to the C-PS as appropriate. Zhang, et al. Expires 10 April 2027 [Page 12] Internet-Draft CATS C-SMA Functional Implementation October 2026 6. Control-Plane Protocol Adaptation The Protocol Adapter (PA) maps the internal representation of the metric cache and the update-control decisions onto the control-plane protocol used in a deployment. The applicability of candidate protocols (e.g., BGP-LS, NETCONF/YANG-Push, RESTful APIs) to CATS is analyzed in [I-D.yxl-cats-protocols-applicability], and the configuration objects used by the C-SMA should be mapped to the YANG data model of [I-D.ietf-cats-data-model] where applicable. This document intentionally does not define new protocol extensions, TLVs, or API paths for metric distribution. The C-SMA-side requirements that are independent of the transport are specified here; the wire formats and their registrations are a matter for the protocol documents identified by [I-D.yxl-cats-protocols-applicability]. This keeps the protocol design in the documents where the corresponding review and registration processes live, and keeps the present document focused on C-SMA behavior. 6.1. Centralized Model: Northbound Interface In the centralized model (e.g., SDN controller, see [RFC7149] and [RFC7426]), the C-SMA acts as an application that reports metrics to a centralized C-PS via a northbound interface. The PA adapts the metric cache to a northbound API whose concrete design is out of scope for this document; the following are common transport choices discussed in [I-D.yxl-cats-protocols-applicability]: RESTful API (HTTP/HTTPS): The C-SMA publishes metric reports to the C-PS. The specific resource paths and payload schemas are defined by the applicable northbound specification, not by this document. The PA MUST preserve the semantics of the operations: publish a new or updated metric set, update metrics for a specific CSCI-ID, withdraw metrics for a failed SCI, and retrieve cached metrics for reconciliation. gRPC: The C-SMA may establish a gRPC stream to the C-PS for bidirectional communication, enabling streaming metric updates from C-SMA to C-PS and streaming policy updates or queries from C-PS to C-SMA. The service definition is out of scope here. NETCONF/YANG-Push: The C-SMA publishes metrics as YANG-modeled data via NETCONF notifications [RFC6241] or YANG-Push [RFC8639], using the data model of [I-D.ietf-cats-data-model] where applicable. This is suitable for deployments that already use NETCONF for network management. Zhang, et al. Expires 10 April 2027 [Page 13] Internet-Draft CATS C-SMA Functional Implementation October 2026 The PA MUST support transport security (e.g., TLS) for all northbound connections. 6.2. Distributed Model: Routing Protocol Extensions In the distributed model, the C-SMA distributes metrics via routing protocol extensions, as analyzed in [I-D.yxl-cats-protocols-applicability]. Whether and how CATS metrics are carried in BGP-LS, GRASP, or IGP TE extensions is a protocol design question that belongs to the corresponding protocol documents. This document does not specify such extensions. BGP-LS with CATS Extensions: If BGP-LS [RFC8571] (an application of the multiprotocol extensions of BGP-4 [RFC4760]) is selected as the distribution protocol, the encoding and registration of CATS metric TLVs are to be defined in the protocol document identified by [I-D.yxl-cats-protocols-applicability] (see Section 6.4). The PA is responsible for mapping internal metric values to the TLV fields once such an encoding exists. GRASP: If GRASP [RFC8990] is selected, the definition of CATS metric objectives is likewise a protocol design matter for the corresponding document. The PA maps internal metrics to the objective payload once defined. OSPF/IS-IS TE Extensions: Using IGP TE extensions [RFC7471][RFC8570] to carry CATS metrics requires a scoping analysis (e.g., whether the CATS metric set is suitable for link-state distribution and how often it changes). This document does not take a position on the suitability; the question is left to [I-D.yxl-cats-protocols-applicability]. The PA MUST implement protocol-specific rate limiting and dampening to prevent routing instability. 6.3. Hybrid Model: Combined Approach In the hybrid model, the C-SMA uses a combination of centralized and distributed mechanisms: * Static/Quasi-Static Metrics via Distributed Protocols: Infrequently changing metrics (e.g., maximum capacity, security levels) may be distributed via BGP-LS or GRASP where such encoding exists. Zhang, et al. Expires 10 April 2027 [Page 14] Internet-Draft CATS C-SMA Functional Implementation October 2026 * Dynamic/Status Metrics via Centralized Interface: Frequently changing metrics (e.g., GAS, Computing Time) are reported via the RESTful or gRPC northbound interface to avoid flooding the routing protocol. The PA MUST ensure consistency between the two channels. If a conflict is detected (e.g., a distributed advertisement reports GAS=500 while the northbound interface reports GAS=400), the more recent update takes precedence. 6.4. Open Items for Protocol Documents The following items are intentionally not resolved in this document and need to be addressed by the protocol documents identified in [I-D.yxl-cats-protocols-applicability]: * The wire encoding of CATS metrics in BGP-LS, including TLV codepoints and their IANA registration. * The GRASP objective name and payload schema for CATS metrics, if GRASP is selected. * The applicability analysis for OSPF/IS-IS TE extensions. * The YANG data model objects for the thresholds and policies referenced in Section 7 (see [I-D.ietf-cats-data-model]). 7. Policy Enforcement The Policy Engine (PE) enforces local policies on metric reporting. Policies are expressed as rules with conditions and actions. Policies are configured via the CATS management plane and stored in a local policy database; the configuration objects should be mapped to the YANG data model of [I-D.ietf-cats-data-model] where applicable. The policy examples in this section use example thresholds and values, which MUST be configurable. 7.1. Local Policy Engine Rule Format: IF THEN Examples (values are examples, not defaults): IF Site_GAS < 100 THEN SET Security_Level = 5; IF SCI_Health = DEGRADED THEN REDUCE SCI_GAS BY 50%; IF Time IN Maintenance_Window THEN SUPPRESS_UPDATES; IF Price > 100 THEN SET Price = 100. The PE evaluates policies in order of priority before metrics are sent to the C-PS. Zhang, et al. Expires 10 April 2027 [Page 15] Internet-Draft CATS C-SMA Functional Implementation October 2026 7.2. Metric Transformation Policies The PE applies the following transformation policies: Safety Margin: Reduce reported GAS by a configured percentage to prevent over-subscription. Example (informative): Reported_GAS = Site_GAS * 0.8. Ceiling/Floor: Enforce upper and lower bounds on metrics. Example (informative): Computing Time MUST be >= 1 ms and <= 10000 ms. Smoothing: Apply exponential moving average (EMA) to reduce noise: Smoothed_GAS(t) = alpha * Raw_GAS(t) + (1 - alpha) * Smoothed_GAS(t-1), where alpha is a configurable smoothing factor (example default 0.3). 7.3. Update Control Policies The PE controls when updates are sent to the C-PS: Threshold Policies: GAS delta > 10% or absolute delta > 50; Computing Time delta > 20%; Health status change; Security level change. Thresholds are example values and MUST be configurable. Time-Based Policies: Maximum update interval: force an update at least every 60 seconds (heartbeat); Minimum update interval: suppress updates more frequent than 5 seconds (rate limiting); Maintenance window: suppress all non-critical updates during scheduled maintenance. The intervals are example values and MUST be configurable. Burst Control: Token bucket algorithm to limit update rate; Backoff algorithm for repeated failures. 8. Security and Trust Management This section specifies the trust relationships that the C-SMA MUST maintain with its peers. The mechanisms listed below are examples of how the corresponding requirements can be met; the choice of mechanism is deployment-specific and MUST be consistent with the CATS security considerations discussed in [RFC10053]. The C-SMA MUST authenticate every SCI before accepting its reports. Supported methods include: 8.1. SCI Authentication Mutual TLS (mTLS): The SCI and C-SMA exchange X.509 certificates Zhang, et al. Expires 10 April 2027 [Page 16] Internet-Draft CATS C-SMA Functional Implementation October 2026 during connection establishment. The C-SMA validates the SCI's certificate against a trusted CA and checks that the certificate subject matches the expected CSCI-ID. Token-Based: The SCI includes a signed token (e.g., JWT) in each report. The C-SMA validates the token signature, expiration, and issuer. IPsec: For deployments where SCIs and C-SMA communicate over an untrusted network, IPsec MAY be used to protect the entire communication channel. The C-SMA MUST maintain a certificate revocation list (CRL) or support OCSP to check for revoked certificates. 8.2. C-PS Authentication The C-SMA MUST authenticate the C-PS before sending updates. Supported methods: Mutual TLS (mTLS): The C-SMA validates the C-PS certificate during northbound connection establishment. Pre-Shared Key (PSK): For lightweight deployments, the C-SMA and C-PS MAY use a pre-shared key for message authentication (e.g., HMAC-SHA256). The C-SMA MUST verify that the C-PS is authorized to receive the metrics for the advertised CS-IDs. This MAY be enforced via certificate attributes or policy configuration. 8.3. Metric Integrity and Freshness The C-SMA MUST protect the integrity of metric reports: Digital Signature: Each report sent to the C-PS is signed using the C-SMA's private key. The C-PS verifies the signature using the C-SMA's public key. Message Authentication Code (MAC): For deployments using PSK, a MAC (e.g., HMAC-SHA256) is appended to each report. Timestamp and Nonce: Each report includes a timestamp and a monotonically increasing nonce to prevent replay attacks. The C-PS MUST reject reports with timestamps outside a reasonable window (e.g., +/- 30 seconds) or duplicate nonces. Freshness Indicator: The C-SMA includes a freshness indicator (e.g., Zhang, et al. Expires 10 April 2027 [Page 17] Internet-Draft CATS C-SMA Functional Implementation October 2026 sequence number or epoch) in each report. The C-PS uses this to detect stale or out-of-order updates. 9. Dynamic Synchronization The Update Controller (UC) sends updates to the C-PS based on triggers and periodic synchronization. 9.1. Trigger-Based Updates The UC sends updates to the C-PS based on the following triggers. The behavior in this section, together with Section 9.2 and Section 9.3, defines the synchronization semantics that determine how fresh the C-PS's view of a service site is; the required update frequency and scope depend on the service class and are out of scope for this document (see the CATS charter and [I-D.zhangb-cats-service-metrics-op] for the corresponding discussion). * Metric Change Trigger: When an aggregated metric crosses a configured threshold, the UC sends a delta update. * Health Change Trigger: When an SCI changes health state (HEALTHY -> DEGRADED, DEGRADED -> UNHEALTHY, etc.), the UC sends an immediate update. * SCI Discovery Trigger: When a new SCI is discovered or an existing SCI is withdrawn, the UC sends a full update. * Policy Change Trigger: When a local policy is updated (e.g., new safety margin), the UC re-evaluates all metrics and sends updates as needed. The UC MUST prioritize triggers. Critical triggers (e.g., health change) take precedence over routine triggers (e.g., metric change). 9.2. Periodic Synchronization The UC sends periodic updates to maintain soft state: Heartbeat: A full metric snapshot is sent at a fixed interval (e.g., every 60 seconds) even if no triggers have fired. This ensures the C-PS does not age out the C-SMA's entries. Refresh: If the C-PS supports it, the C-SMA MAY use a lightweight refresh message (e.g., keepalive) to extend the C-PS's cache TTL without retransmitting all metrics. Zhang, et al. Expires 10 April 2027 [Page 18] Internet-Draft CATS C-SMA Functional Implementation October 2026 Synchronization Interval: The heartbeat interval SHOULD be configurable and MAY be adjusted dynamically based on network conditions or C-PS load. 9.3. Recovery and Reconciliation After a C-PS restart or network partition, the C-SMA and C-PS MUST reconcile their state: Full Sync: The C-SMA sends a complete snapshot of all metrics to the C-PS upon reconnection. Incremental Sync: If the C-PS has persisted some state, the C-SMA MAY send only the changes since the last acknowledged sequence number. Reconciliation Protocol: The C-PS MAY request a full sync by sending a synchronization request to the C-SMA. The C-SMA responds with all current metrics. Conflict Resolution: If the C-PS and C-SMA have divergent state (e.g., due to message loss), the C-SMA's view takes precedence as the authoritative source of service metrics. This document proposes this precedence rule because the framework does not define a conflict-resolution procedure between the C-SMA and the C-PS; the rule is subject to confirmation by the working group. 10. Failure Handling This section specifies the C-SMA-side behavior for detecting and responding to failures of its peers. The monitoring and management functions used to observe these failures (and the corresponding management interfaces) are in the scope of the OAM framework for CATS [I-D.ietf-cats-oam-fw]; this section defines only the C-SMA behavior that follows once a failure is detected. The C-SMA detects SCI failures through the following mechanisms: 10.1. SCI Failure Detection Missing Reports: If an SCI fails to send reports within the TTL, the C-SMA marks it as STALE and then FAILED. Health Monitor Integration: The C-SMA MAY integrate with an external health monitor (e.g., the SCI's own health checks or a site-wide monitoring system) to detect failures faster than TTL-based detection. Active Probing: The C-SMA MAY send active probes (e.g., ping, HTTP Zhang, et al. Expires 10 April 2027 [Page 19] Internet-Draft CATS C-SMA Functional Implementation October 2026 GET) to unresponsive SCIs to distinguish between SCI failure and network partition. Upon detecting an SCI failure, the C-SMA: 1. Sets the SCI's GAS contribution to 0. 2. Updates the aggregated site metrics. 3. Sends an immediate update to the C-PS. 4. Logs the failure for operational analysis. 10.2. C-PS Unreachability If the C-SMA cannot reach the C-PS: Retry with Backoff: The C-SMA retries with exponential backoff (e.g., 1s, 2s, 4s, 8s, ... up to a maximum of 60s). Buffering: The C-SMA buffers updates in a local queue. When the C-PS becomes reachable, the buffered updates are sent in batch. The buffer MUST have a maximum size; old updates are dropped when the buffer is full. Fallback: In distributed deployments, the C-SMA MAY fall back to an alternative C-PS or advertise metrics via a routing protocol if the primary C-PS is unreachable. Local Action: The C-SMA MAY notify local operators (e.g., via syslog, SNMP trap) of the C-PS unreachability. 10.3. Partitioned Operation During a network partition between the service site and the C-PS: Read-Only Mode: The C-SMA continues to collect and cache metrics from SCIs but stops sending updates to the C-PS. Local Steering: If the C-SMA is co-located with an Egress CATS- Forwarder, it MAY provide local steering decisions using cached metrics until the partition heals. Partition Healing: Upon reconnection, the C-SMA performs a full sync to reconcile state. Zhang, et al. Expires 10 April 2027 [Page 20] Internet-Draft CATS C-SMA Functional Implementation October 2026 11. Scalability Considerations The C-SMA MUST be designed to scale with the number of SCIs and the frequency of metric updates: Horizontal Scaling: In large service sites, multiple C-SMA instances MAY be deployed, each responsible for a subset of SCIs. A coordinator C-SMA aggregates metrics from the subordinate C-SMAs. Metric Compression: The PA SHOULD compress metric payloads (e.g., using gzip, CBOR, or Protocol Buffers) to reduce bandwidth. Update Aggregation: The UC SHOULD batch multiple SCI updates into a single C-PS advertisement to reduce control-plane overhead. Hierarchical Aggregation: In multi-site deployments, site-level C-SMAs report to a domain-level C-SMA, which aggregates across sites before reporting to the C-PS. This is a proposed extension of the framework: the framework currently considers a single- provider scope, so the hierarchy and the aggregation semantics of a domain-level C-SMA are not defined there. Whether the working group wants to standardize such a hierarchy is left open; this document describes the concept as a scalability option only. Selective Reporting: The PE MAY suppress non-critical metrics (e.g., optional extension metrics) during high-load conditions. 12. Security Considerations The C-SMA is a critical trust anchor in the CATS architecture. Its compromise could lead to traffic misdirection or denial of service. The following security measures are REQUIRED: Authentication: The C-SMA MUST authenticate all SCIs and C-PSes. Authorization: The C-SMA MUST verify that SCIs are authorized to report metrics for their claimed CS-IDs. The C-SMA MUST verify that C-PSes are authorized to receive metrics for the advertised CS-IDs. Integrity: All metric reports MUST be integrity-protected. Confidentiality: Metric reports SHOULD be encrypted to prevent disclosure of internal service topology and capacity. Availability: The C-SMA MUST be resilient to DoS attacks (e.g., excessive SCI reports, replay attacks). Rate limiting, burst control, and input validation are REQUIRED. Zhang, et al. Expires 10 April 2027 [Page 21] Internet-Draft CATS C-SMA Functional Implementation October 2026 Audit: The C-SMA MUST log all authentication failures, policy violations, and anomalous metric changes for security audit. 13. IANA Considerations This document has no IANA actions. This document specifies the behavior of the C-SMA and deliberately does not define wire formats, TLVs, or protocol extensions for metric distribution (see Section 6). If, in a future revision, protocol encodings for CATS metrics are defined, the corresponding codepoint registrations will be requested in the document that defines the encoding, following the process of the IANA registry established for CATS metrics (see [I-D.ietf-cats-metric-definition-13]). 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC4760] Bates, T., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007, . [RFC6241] Enns, R., Bjorklund, M., and J. Schoenwaelder, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, . [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014, . [RFC7426] Haleplidis, E., Pentikousis, K., and S. Denazis, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, January 2015, . [RFC7471] Giacalone, S., Ward, D., and J. Drake, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, March 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . Zhang, et al. Expires 10 April 2027 [Page 22] Internet-Draft CATS C-SMA Functional Implementation October 2026 [RFC8570] Ginsberg, L., Previdi, S., and S. Giacalone, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, March 2019, . [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, . [RFC8639] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Subscription to YANG Notifications", RFC 8639, September 2019, . [RFC8990] Bormann, C., Carpenter, B., and B. Liu, "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, March 2021, . [RFC10053] Li, C., Ed., Du, Z., Boucadair, M., Ed., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", RFC 10053, October 2026, . 14.2. Informative References [I-D.ietf-cats-data-model] Yao, H., Lin, C., Li, Z., Xiong, Q., and L. M. Contreras, "Data Model for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-ietf-cats-data- model-00, 23 September 2026, . [I-D.ietf-cats-metric-definition-13] 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-13, 29 September 2026, . [I-D.ietf-cats-oam-fw] Fu, H., Xiong, Q., Du, Z., Liu, B., and Z. Li, "Computing- Aware Traffic Steering (CATS) Operations, Administration, and Maintenance (OAM) Framework", Work in Progress, Internet-Draft, draft-ietf-cats-oam-fw-01, 21 July 2026, . Zhang, et al. Expires 10 April 2027 [Page 23] Internet-Draft CATS C-SMA Functional Implementation October 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., Shen, B., Zhang, W., and Y. Qiao, "Public Service Platform for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft- zhangb-cats-cmas-06, 18 August 2026, . [I-D.zhangb-cats-sci-implementation] Zhang, B., Shen, B., and Y. Yang, "CATS Service Contact Instance Functional Implementation", Work in Progress, Internet-Draft, draft-zhangb-cats-sci-implementation-01, 15 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, . 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 Zhang, et al. Expires 10 April 2027 [Page 24] Internet-Draft CATS C-SMA Functional Implementation October 2026 Zongpeng Du (editor) China Mobile Email: duzongpeng@chinamobile.com 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 10 April 2027 [Page 25]