CATS Service Metric Agent (C-SMA) Functional Implementation
draft-zhangb-cats-csma-implementation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Bin Zhang | ||
| Last updated | 2026-07-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhangb-cats-csma-implementation-00
Computing-Aware Traffic Steering B. Zhang, Ed.
Internet-Draft Pengcheng Laboratory
Intended status: Standards Track 27 July 2026
Expires: 28 January 2027
CATS Service Metric Agent (C-SMA) Functional Implementation
draft-zhangb-cats-csma-implementation-00
Abstract
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 [I-D.ietf-cats-framework] and
[I-D.zhangb-cats-service-metrics-op] by providing the operational
execution layer for the C-SMA.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 28 January 2027.
Zhang Expires 28 January 2027 [Page 1]
Internet-Draft CATS C-SMA Functional Implementation July 2026
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. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. C-SMA Functional Architecture . . . . . . . . . . . . . . . . 5
3.1. C-SMA Position in CATS Framework . . . . . . . . . . . . 6
4. Metric Collection from SCIs . . . . . . . . . . . . . . . . . 7
4.1. Collection Interface . . . . . . . . . . . . . . . . . . 7
4.2. Metric Validation and Sanitization . . . . . . . . . . . 7
5. Metric Caching and State Management . . . . . . . . . . . . . 8
5.1. Local Metric Cache . . . . . . . . . . . . . . . . . . . 8
5.2. Soft-State and Aging . . . . . . . . . . . . . . . . . . 9
5.3. Per-SCI State Tracking . . . . . . . . . . . . . . . . . 9
6. Control-Plane Protocol Adaptation . . . . . . . . . . . . . . 9
6.1. Centralized Model: Northbound Interface . . . . . . . . . 10
6.2. Distributed Model: Routing Protocol Extensions . . . . . 10
6.3. Hybrid Model: Combined Approach . . . . . . . . . . . . . 11
7. Policy Enforcement . . . . . . . . . . . . . . . . . . . . . 11
7.1. Local Policy Engine . . . . . . . . . . . . . . . . . . . 11
7.2. Metric Transformation Policies . . . . . . . . . . . . . 11
7.3. Update Control Policies . . . . . . . . . . . . . . . . . 12
8. Security and Trust Management . . . . . . . . . . . . . . . . 12
8.1. SCI Authentication . . . . . . . . . . . . . . . . . . . 12
8.2. C-PS Authentication . . . . . . . . . . . . . . . . . . . 13
8.3. Metric Integrity and Freshness . . . . . . . . . . . . . 13
9. Dynamic Synchronization . . . . . . . . . . . . . . . . . . . 13
9.1. Trigger-Based Updates . . . . . . . . . . . . . . . . . . 13
9.2. Periodic Synchronization . . . . . . . . . . . . . . . . 14
9.3. Recovery and Reconciliation . . . . . . . . . . . . . . . 14
10. Failure Handling . . . . . . . . . . . . . . . . . . . . . . 15
10.1. SCI Failure Detection . . . . . . . . . . . . . . . . . 15
10.2. C-PS Unreachability . . . . . . . . . . . . . . . . . . 15
10.3. Partitioned Operation . . . . . . . . . . . . . . . . . 16
Zhang Expires 28 January 2027 [Page 2]
Internet-Draft CATS C-SMA Functional Implementation July 2026
11. Scalability Considerations . . . . . . . . . . . . . . . . . 16
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
The Computing-Aware Traffic Steering (CATS) framework
[I-D.ietf-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.
Zhang Expires 28 January 2027 [Page 3]
Internet-Draft CATS C-SMA Functional Implementation July 2026
* 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.
1.1. 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] and [I-D.zhangb-cats-service-metrics-op].
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:
Zhang Expires 28 January 2027 [Page 4]
Internet-Draft CATS C-SMA Functional Implementation July 2026
* 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.
3. C-SMA Functional Architecture
A C-SMA is logically composed of the following internal functional
components:
+----------------------------------------------------------------+
| CATS Service Metric Agent (C-SMA) |
| +----------------+ +------------------+ |
| | SCI Collection | | policy Engine | |
| | Interface (SI) |------------ | (PE) | |
| +--------+-------+ | +--------+---------+ |
| | | | |
| +--------v-------+ +--------v-------+ +------v-----------+ |
| | Metric Cache | | Validator & | | Update Controller| |
| | (MC) | | Sanitizer (VS) | | (UC) | |
| +--------+-------+ +--------+-------+ +------+-----------+ |
| | | | |
| +--------v-------------------v-------------------v----------+ |
| | Protocol Adapter (PA) | |
| +---------------------------+-------------------------------+ |
| | |
+------------------------------v----------------------------------+
|
+-------v--------+
| C-PS |
+----------------+
Figure 1: C-SMA Internal Functional Components
Zhang Expires 28 January 2027 [Page 5]
Internet-Draft CATS C-SMA Functional Implementation July 2026
The internal components of a C-SMA are defined as follows:
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 MA, PE, and UC.
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.
Policy Engine (PE): 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.
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. It supports multiple protocols (e.g., RESTful API, BGP-
LS, GRASP, NETCONF/YANG-Push) and can be extended for new
protocols.
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.
Zhang Expires 28 January 2027 [Page 6]
Internet-Draft CATS C-SMA Functional Implementation July 2026
* 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
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 VS performs the following
checks:
Range Validation: 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.
Zhang Expires 28 January 2027 [Page 7]
Internet-Draft CATS C-SMA Functional Implementation July 2026
Rate-of-Change Validation: 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.
Sequence Validation: The VS checks the sequence number or timestamp
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 | 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 |
+---------------+-------+-----+----------------+---------------+
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.
Zhang Expires 28 January 2027 [Page 8]
Internet-Draft CATS C-SMA Functional Implementation July 2026
5.2. Soft-State and Aging
The MC implements soft-state aging to handle SCI failures or network
partitions:
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.
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:
* 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.
6. Control-Plane Protocol Adaptation
The Protocol Adapter (PA) supports multiple control-plane protocols
for different deployment models.
Zhang Expires 28 January 2027 [Page 9]
Internet-Draft CATS C-SMA Functional Implementation July 2026
6.1. Centralized Model: Northbound Interface
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:
RESTful API (HTTP/HTTPS): 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).
gRPC: 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.
NETCONF/YANG-Push: 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.
6.2. Distributed Model: Routing Protocol Extensions
In the distributed model, the C-SMA distributes metrics via routing
protocol extensions. The PA supports:
BGP-LS with CATS Extensions: 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).
GRASP: 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.
OSPF/IS-IS TE Extensions: 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.
Zhang Expires 28 January 2027 [Page 10]
Internet-Draft CATS C-SMA Functional Implementation July 2026
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/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.
7. Policy Enforcement
The Policy Engine (PE) enforces local policies on metric reporting.
Policies are expressed as rules with conditions and actions.
7.1. Local Policy Engine
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.
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: Reported_GAS = Site_GAS *
0.8.
Ceiling/Floor: Enforce upper and lower bounds on metrics. Example:
Zhang Expires 28 January 2027 [Page 11]
Internet-Draft CATS C-SMA Functional Implementation July 2026
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
(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 label
change.
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.
Burst Control: Token bucket algorithm to limit update rate; Backoff
algorithm for repeated failures.
8. Security and Trust Management
The C-SMA MUST authenticate every SCI before accepting its reports.
Supported methods:
8.1. SCI Authentication
Mutual TLS (mTLS): 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.
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.
Zhang Expires 28 January 2027 [Page 12]
Internet-Draft CATS C-SMA Functional Implementation July 2026
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.,
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:
* Metric Change Trigger: When an aggregated metric crosses a
configured threshold, the UC sends a delta update.
Zhang Expires 28 January 2027 [Page 13]
Internet-Draft CATS C-SMA Functional Implementation July 2026
* 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.
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
Zhang Expires 28 January 2027 [Page 14]
Internet-Draft CATS C-SMA Functional Implementation July 2026
(e.g., due to message loss), the C-SMA's view takes precedence as
the authoritative source.
10. Failure Handling
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
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
Zhang Expires 28 January 2027 [Page 15]
Internet-Draft CATS C-SMA Functional Implementation July 2026
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.
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.
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
Zhang Expires 28 January 2027 [Page 16]
Internet-Draft CATS C-SMA Functional Implementation July 2026
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.
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 at this time.
14. References
14.1. Normative References
[I-D.ietf-cats-framework]
Li, C., Du, Z., and M. Boucadair, "A Framework for
Computing-Aware Traffic Steering (CATS)", Work in
Progress, Internet-Draft, draft-ietf-cats-framework-22,
March 2026, <https://www.ietf.org/archive/id/draft-ietf-
cats-framework-22.txt>.
[I-D.zhangb-cats-service-metrics-op]
Zhang, B., Dai, Y., and Z. Du, "Computing Service Metric
Definitions and Operation under CATS", Work in Progress,
Internet-Draft, draft-zhangb-cats-service-metrics-op-03,
July 2026, <https://www.ietf.org/archive/id/draft-zhangb-
cats-service-metrics-op-03.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119.txt>.
[RFC6241] Enns, R., Bjorklund, M., and J. Schoenwaelder, "Network
Configuration Protocol (NETCONF)", RFC 6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241.txt>.
Zhang Expires 28 January 2027 [Page 17]
Internet-Draft CATS C-SMA Functional Implementation July 2026
[RFC7471] Giacalone, S., Ward, D., and J. Drake, "OSPF Traffic
Engineering (TE) Metric Extensions", RFC 7471, March 2015,
<https://www.rfc-editor.org/rfc/rfc7471.txt>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174.txt>.
[RFC8570] Ginsberg, L., Previdi, S., and S. Giacalone, "IS-IS
Traffic Engineering (TE) Metric Extensions", RFC 8570,
March 2019, <https://www.rfc-editor.org/rfc/rfc8570.txt>.
[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,
<https://www.rfc-editor.org/rfc/rfc8571.txt>.
[RFC8639] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Subscription
to YANG Notifications", RFC 8639, September 2019,
<https://www.rfc-editor.org/rfc/rfc8639.txt>.
[RFC8990] Bormann, C., Carpenter, B., and B. Liu, "GeneRic Autonomic
Signaling Protocol (GRASP)", RFC 8990, March 2021,
<https://www.rfc-editor.org/rfc/rfc8990.txt>.
14.2. Informative References
[I-D.ietf-cats-metric-definition]
Kehan, Y. and C. Li, "CATS Metrics Definition", Work in
Progress, Internet-Draft, draft-ietf-cats-metric-
definition-10, June 2026,
<https://www.ietf.org/archive/id/draft-ietf-cats-metric-
definition-10.txt>.
[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-04, May
2026, <https://www.ietf.org/archive/id/draft-zhangb-cats-
cmas-04.txt>.
[RFC4760] Bates, T., Chandra, R., and D. Katz, "Multiprotocol
Extensions for BGP-4", RFC 4760, January 2007,
<https://www.rfc-editor.org/rfc/rfc4760.txt>.
Zhang Expires 28 January 2027 [Page 18]
Internet-Draft CATS C-SMA Functional Implementation July 2026
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, March 2014,
<https://www.rfc-editor.org/rfc/rfc7149.txt>.
[RFC7426] Haleplidis, E., Pentikousis, K., and S. Denazis,
"Software-Defined Networking (SDN): Layers and
Architecture Terminology", RFC 7426, January 2015,
<https://www.rfc-editor.org/rfc/rfc7426.txt>.
Appendix A. Acknowledgments
The authors thank the CATS working group for their valuable feedback
and contributions to this document.
Author's Address
Bin Zhang (editor)
Pengcheng Laboratory
Sibilong Street
Shenzhen
Guangdong, 518055
China
Email: zhangb@pcl.ac.cn
Zhang Expires 28 January 2027 [Page 19]