Pengcheng Laboratory

Sibilong Street Shenzhen Guangdong 518055 CN zhangb@pcl.ac.cn

Routing Computing-Aware Traffic Steering CATS C-SMA service metric agent metric collection aggregation protocol adaptation policy enforcement The Computing-Aware Traffic Steering (CATS) framework introduces 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 existing drafts define the metrics and high-level framework, the concrete functional behavior, internal architecture, and operational procedures of the C-SMA remain underspecified. This document fills that gap by defining the functional implementation of the C-SMA. Specifically, it specifies how the C-SMA collects metrics from multiple Service Contact Instances (SCIs) within a service site; how it validates, and caches these metrics; how it adapts to various control-plane protocols for metric distribution; how it enforces local policies and security policies; and how it maintains synchronization with the C-PS under dynamic conditions. This document complements and by providing the operational execution layer for the C-SMA.

The Computing-Aware Traffic Steering (CATS) framework 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. This document defines the functional implementation of the C-SMA to address these gaps. It specifies the internal architecture, metric collection and validation mechanisms, protocol adaptation, policy enforcement, and failure handling required for a C-SMA to operate effectively within the CATS framework. 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 (RESTful API, BGP-LS, GRASP, etc.). Enforcing local policies (e.g., metric transformation, update throttling, security labels). Authenticating SCIs and C-PSes, and protecting metric integrity. Handling failures of SCIs, C-PSes, and network partitions.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This document makes use of the terms defined in and . 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. Computing Time: The time required for the site to perform one service request. 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. SCI Report: A message sent by an SCI to the C-SMA containing aggregated metrics and status. 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.

A C-SMA is logically composed of the following internal functional components:

The internal components of a C-SMA are defined as follows: 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. Responsible for storing the most recent metrics from each SCI. It provides fast lookup for the MA, PE, and UC. The cache implements time-to-live (TTL) and soft-state aging to handle stale data. 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. Responsible for enforcing local policies on metric reporting. Policies include metric transformation, security label assignment or verification, cost and reputation policies, and update suppression during maintenance windows. 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. Responsible for adapting internal metric representations to the wire format required by the control-plane protocol. It supports multiple protocols (e.g., RESTful API, BGP-LS, GRASP, NETCONF/YANG-Push) and can be extended for new protocols.

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.

The SCI Collection Interface (SI) receives metric reports from SCIs. The interface supports the following modes:

SCIs proactively push metric reports to the 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). 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. 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.

The Validator & Sanitizer (VS) inspects every incoming SCI report before it enters the Metric Cache. The VS performs the following checks: Each metric value MUST fall within a valid range: GAS: 0 to MAX_UINT32; Computing Time: 0 to 3600000 ms (1 hour); Cost: 0 to MAX_UINT32; Reputation: 0 to 10; Security Label: 0 to 10. Values outside these ranges are rejected. The VS detects anomalous changes: GAS change > 50% within 1 second without corresponding health change; Computing Time change > 100% within 1 second; Health status flapping (> 3 transitions within 10 seconds). Anomalous reports MAY be quarantined for manual review or accepted with a warning flag. The VS checks the sequence number or timestamp to detect duplicate, out-of-order, or replayed reports. Old reports are discarded. 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. The VS MAY apply smoothing filters (e.g., moving average) to reduce noise in frequently fluctuating metrics.

The Metric Cache (MC) stores the most recent validated metrics from each SCI. The cache is organized as follows: Metric Cache Structure

CSCI-ID	CS-ID	GAS	Comp Time (ms)	Health Status
188.3.67.3:67	AR1	400	5	HEALTHY
188.3.67.3:68	AR2	100	15	HEALTHY
188.3.67.4:69	AR1	600	6	HEALTHY
188.3.67.4:70	LLM1	300	12	DEGRADED

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.

The MC implements soft-state aging to handle SCI failures or network partitions: 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. 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. 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). 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.

The C-SMA maintains a state machine for each SCI: 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.

The Protocol Adapter (PA) supports multiple control-plane protocols for different deployment models.

In the centralized model (e.g., SDN controller), the C-SMA acts as an application that reports metrics to a centralized C-PS via a northbound interface. The PA supports: The C-SMA sends metric reports as JSON or XML payloads to the C-PS REST API endpoint. Supported operations include POST /cats/metrics (publish a new or updated metric set), PUT /cats/metrics/{csci-id} (update metrics for a specific CSCI-ID), DELETE /cats/metrics/{csci-id} (withdraw metrics for a failed SCI), and GET /cats/metrics/{csci-id} (retrieve cached metrics for reconciliation). The C-SMA establishes a gRPC stream to the C-PS for bidirectional communication. This enables streaming metric updates from C-SMA to C-PS, streaming policy updates or queries from C-PS to C-SMA, and efficient binary encoding using Protocol Buffers. The C-SMA publishes metrics as YANG-modeled data via NETCONF notifications or YANG-Push. This is suitable for deployments that already use NETCONF for network management. The PA MUST support TLS for all northbound connections.

In the distributed model, the C-SMA distributes metrics via routing protocol extensions. The PA supports: The C-SMA injects CATS metrics into BGP-LS as new node or link attributes. The PA maps internal metrics to BGP-LS TLVs: GAS -> CATS-GAS-TLV (TBD), Computing Time -> CATS-COMP-TIME-TLV (TBD), CS-ID -> CATS-CS-ID-TLV (TBD), CSCI-ID -> CATS-CSCI-ID-TLV (TBD). The C-SMA uses GRASP to negotiate and distribute CATS metrics among autonomic nodes. The PA maps metrics to GRASP objectives: Objective: "CATS:ServiceMetrics", Payload: CBOR-encoded metric set. The C-SMA MAY use IGP TE extensions to carry metrics within the routing domain. This is suitable for deployments where the C-PS is co-located with an Ingress CATS-Forwarder. The PA MUST implement protocol-specific rate limiting and dampening to prevent routing instability.

In the hybrid model, the C-SMA uses a combination of centralized and distributed mechanisms: Static/Capability Metrics via Distributed Protocols: Infrequently changing metrics (e.g., maximum capacity, security labels) are distributed via BGP-LS or GRASP. 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., BGP-LS advertises GAS=500 while the REST API reports GAS=400), the more recent update takes precedence.

The Policy Engine (PE) enforces local policies on metric reporting. Policies are expressed as rules with conditions and actions.

Rule Format: IF <condition> THEN <action> Examples: IF Site_GAS < 100 THEN SET Security_Label = 5; IF SCI_Health = DEGRADED THEN REDUCE SCI_GAS BY 50%; IF Time IN Maintenance_Window THEN SUPPRESS_UPDATES; IF Cost > 100 THEN SET Cost = 100. Policies are configured via the CATS Management Plane (e.g., NETCONF, RESTCONF) and stored in a local policy database. The PE evaluates policies in order of priority before metrics are sent to the C-PS.

The PE applies the following transformation policies: Reduce reported GAS by a configured percentage to prevent over-subscription. Example: Reported_GAS = Site_GAS * 0.8. Enforce upper and lower bounds on metrics. Example: Computing Time MUST be >= 1 ms and <= 10000 ms. 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 (default 0.3).

The PE controls when updates are sent to the C-PS: GAS delta > 10% or absolute delta > 50; Computing Time delta > 20%; Health status change; Security label change. 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. Token bucket algorithm to limit update rate; Backoff algorithm for repeated failures.

The C-SMA MUST authenticate every SCI before accepting its reports. Supported methods:

The SCI and C-SMA exchange X.509 certificates 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. The SCI includes a signed token (e.g., JWT) in each report. The C-SMA validates the token signature, expiration, and issuer. 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.

The C-SMA MUST authenticate the C-PS before sending updates. Supported methods: The C-SMA validates the C-PS certificate during northbound connection establishment. 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.

The C-SMA MUST protect the integrity of metric reports: 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. For deployments using PSK, a MAC (e.g., HMAC-SHA256) is appended to each report. 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. The C-SMA includes a freshness indicator (e.g., sequence number or epoch) in each report. The C-PS uses this to detect stale or out-of-order updates.

The Update Controller (UC) sends updates to the C-PS based on triggers and periodic synchronization.

The UC sends updates to the C-PS based on the following triggers: 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).

The UC sends periodic updates to maintain soft state: 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. 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. The heartbeat interval SHOULD be configurable and MAY be adjusted dynamically based on network conditions or C-PS load.

After a C-PS restart or network partition, the C-SMA and C-PS MUST reconcile their state: The C-SMA sends a complete snapshot of all metrics to the C-PS upon reconnection. If the C-PS has persisted some state, the C-SMA MAY send only the changes since the last acknowledged sequence number. 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. 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.

The C-SMA detects SCI failures through the following mechanisms:

If an SCI fails to send reports within the TTL, the C-SMA marks it as STALE and then FAILED. 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. The C-SMA MAY send active probes (e.g., ping, HTTP GET) to unresponsive SCIs to distinguish between SCI failure and network partition. Upon detecting an SCI failure, the C-SMA: Sets the SCI's GAS contribution to 0. Updates the aggregated site metrics. Sends an immediate update to the C-PS. Logs the failure for operational analysis.

If the C-SMA cannot reach the C-PS: The C-SMA retries with exponential backoff (e.g., 1s, 2s, 4s, 8s, ... up to a maximum of 60s). 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. 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. The C-SMA MAY notify local operators (e.g., via syslog, SNMP trap) of the C-PS unreachability.

During a network partition between the service site and the C-PS: The C-SMA continues to collect and cache metrics from SCIs but stops sending updates to the C-PS. 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. Upon reconnection, the C-SMA performs a full sync to reconcile state.

The C-SMA MUST be designed to scale with the number of SCIs and the frequency of metric updates: 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. The PA SHOULD compress metric payloads (e.g., using gzip, CBOR, or Protocol Buffers) to reduce bandwidth. The UC SHOULD batch multiple SCI updates into a single C-PS advertisement to reduce control-plane overhead. 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. The PE MAY suppress non-critical metrics (e.g., optional extension metrics) during high-load conditions.

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: The C-SMA MUST authenticate all SCIs and C-PSes. 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. All metric reports MUST be integrity-protected. Metric reports SHOULD be encrypted to prevent disclosure of internal service topology and capacity. 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. The C-SMA MUST log all authentication failures, policy violations, and anomalous metric changes for security audit.

This document has no IANA actions at this time.

The authors thank the CATS working group for their valuable feedback and contributions to this document.