Pengcheng Laboratory

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

China Mobile

duzongpeng@chinamobile.com

Sun Yat-sen University

Gongchang Street Shenzhen Guangdong 518055 CN yangyx277@mail2.sysu.edu.cn

Harbin Institute of Technology

Taoyuan Street Shenzhen 518055 China shenbowen@stu.hit.edu.cn

Routing Computing-Aware Traffic Steering CATS C-SMA snapshot This document defines a nomination snapshot published by a CATS Service Metric Agent (C-SMA) to a CATS Path Selector (C-PS). The snapshot carries aggregated service metrics together with a nominated service candidate set. The document defines the snapshot contract and two interoperable binding for the C-SMA-to-C-PS interface: a YANG-modeled snapshot delivered over HTTPS using RESTCONF for centralized C-PS deployments, and a BGP-LS service-metadata mapping for distributed deployments in which a C-PS is located at an ingress CATS-Forwarder. The SCI-to-C-SMA interface, individual metric definitions, management models, generic OAM, and the C-SMA's internal aggregation, ranking, and caching methods are outside the scope of this document.

The Computing-Aware Traffic Steering (CATS) framework assigns the C-SMA the role of collecting service capabilities and status and advertising CS-IDs with metrics to C-PSes. It allows metrics to be reported per service contact instance, as aggregates, or both. The C-PS uses service information together with network information and local policy to select a destination and path. The CATS data model defines service identifiers and metric-type identities. Neither document defines a common C-SMA-to-C-PS snapshot format or its transport encoding. This matters when a C-SMA and C-PS are independently implemented: they need to agree on the identity, scope, metric content, and candidate information conveyed by a publication, and on how that information is represented by the selected transport. This document specifies the C-SMA-to-C-PS snapshot contract and two major bindings for delivering nomination snapshots from C-SMA to C-PS: Centralized C-PS: C-SMA exposes nomination snapshots to a centralized C-PS over HTTPS using RESTCONF, where path computation is performed. This scenario can use a subscription to receive each published snapshot. Distributed forwarding-plane selection: Nomination results are advertised directly to CATS ingress forwarding nodes. The ingress forwarding node runs local service-aware path selection, using the service metrics and candidate list carried in BGP updates. This architecture naturally reuses the BGP-LS distribution fabric. This document defines a single abstract nomination snapshot model, and specifies the two alternative transport bindings for carrying this snapshot from C-SMA to C-PS. The upstream SCI-to-C-SMA interface is not defined in this document; it is treated as an input source for C-SMA. If C-SMA and C-PS are co-located and built by a single vendor, their interaction is a private internal interface and this specification is not required. Standardization applies only to cross-node, cross-vendor C-SMA → C-PS interworking.

This document contains normative requirements for: Abstract semantic model of the C-SMA nomination snapshot, including snapshot identifier, observation window, timestamp, versioning, FULL publication, refresh, invalidation, and withdrawal semantics; Rules for identifying successive publications and obtaining a fresh FULL snapshot after synchronization is lost; Two proposed transport bindings for the C-SMA → C-PS interface: YANG-modeled nomination snapshot delivered over HTTPS using RESTCONF Mapping of nomination snapshot fields into BGP-LS service-metadata TLVs associated with an identified NLRI (Network Layer Reachability Information). This document explicitly excludes from normative scope: SCI-to-C-SMA metric snapshot format and interaction (referenced from a separate specification); Individual service metric definitions, metric registry entries; Existing CATS YANG configuration and state models beyond the nomination snapshot structure; Generic transport protocol characteristics and protocol applicability evaluation; Generic session keepalive, fault detection and link recovery from the CATS OAM framework; Internal C-SMA logic: aggregation algorithms, nomination ranking logic, cache eviction policies. These are implementation choices. NOTE: An implementation of C-SMA MAY support one or both transport bindings. A deployment selects one binding according to its control-plane architecture. Mixed bindings in the same control domain are permitted but not required.

C-SMA's nomination snapshot couples aggregated metrics with a consistent set of nominated service candidates aligned to the same observation window. A YANG data structure can define these fields independently of the protocol that delivers them. For centralized deployments, RESTCONF over HTTPS provides an existing way to deliver YANG-modeled information and subscribed notifications. Binding 1 specifies the subscription sequence and maps notification updates to the snapshot model. Instead of creating separate semantic structures for centralized and distributed deployments, this specification decouples the abstract nomination snapshot semantics from the underlying transport. For centralized C-PS: a YANG-modeled snapshot is delivered through RESTCONF over HTTPS. Each complete snapshot is carried as one notification, with the subscription procedure and update types specified in Binding 1. For distributed selection on CATS ingress forwarding nodes: the same abstract snapshot content is encoded into BGP-LS service attributes, reusing BGP's mature update, withdraw and flooding mechanisms across the routing domain. This approach keeps one consistent nomination data model for C-SMA output, while allowing operators to choose the control-plane distribution mechanism matching their network design.

A nomination snapshot is published by one C-SMA for one CS-ID. It explicitly identifies the CSCI-IDs covered by its aggregated metrics and candidate list. An SCI-to-C-SMA computing-metric snapshot can provide input to this publication, but this C-SMA-to-C-PS snapshot has a different publisher, scope, and candidate information. The following fields describe that information. The YANG node names correspond to the notification module in Appendix B. It imports the reusable CATS identifier typedefs and metric-type identity from :

Field	Meaning	Proposed YANG node
Publisher identity	Identity of the C-SMA responsible for the publication.	publisher-id (required leaf)
Publisher epoch	Restart discriminator for the publisher. A new epoch begins a new version sequence.	publisher-epoch (required yang:uuid leaf)
CS-ID	Identifier of the one CATS service described by the snapshot.	cs-id (required leaf of type cats:cs-id)
Covered CSCI-IDs	The service contact instances represented by the aggregated metrics. In a FULL snapshot, this is the complete covered set for this publisher and CS-ID; a candidate must be a member of this set.	covered-instance (list keyed by csci-id of type cats:csci-id)
Snapshot ID	Unsigned 64-bit identifier unique within the publisher epoch for this notification event. It identifies the publication event and is distinct from the version used to order publications for one CS-ID.	snapshot-id (required leaf)
Snapshot version	Monotonically increasing update generation for this publisher, epoch, and CS-ID. It orders successive publications and is distinct from a format or schema version.	snapshot-version (required uint64 leaf)
Observation window	Start and end times of the observation interval represented by the aggregated metrics; the end must follow the start. A metric measured over a different window identifies that window in its metric record.	window-start and window-end (yang:date-and-time leaves for metric-bearing FULL snapshots)
Type flag	FULL snapshot, INVALIDATE signal, or WITHDRAW signal. The full and invalidate forms align conceptually with the SCI snapshot example, while WITHDRAW removes this C-SMA publication. Periodic and change-triggered metric reports use FULL; delta payloads are outside the current profile.	publication-content (required choice: full-snapshot, invalidated-version, or withdraw)
Aggregated metric set	Aggregated values derived from the covered CSCI-IDs and identified by metric-type identities defined in, or derived from the base identity in, the CATS data model . The specification defining each metric identity determines its value type, meaning, and units; this snapshot carries any metric-specific observation window and validity time.	metric-entry (list keyed by metric-type, with one typed value and optional observation and validity information)
Nomination candidate list	Nominated CSCI-IDs drawn from the covered set; each entry includes candidate rank and applicable constraint tags. In a FULL snapshot, this is the complete nominated set for this publisher and CS-ID.	candidate (list keyed by csci-id of type cats:csci-id, with rank and constraint tags)
Instance status markers	For each covered CSCI-ID, its reported availability state, such as available, drained, or failed.	status under each covered-instance entry

The YANG representation is a nomination-snapshot notification containing one publication from one publisher for one CS-ID. It is distinct from an SCI-originated computing-metric-snapshot notification: the C-SMA may aggregate input from multiple SCIs and add covered-instance status and nomination results before publishing to the C-PS. The publisher-id, publisher-epoch, cs-id, and snapshot-version identify one publication generation; snapshot-id identifies the event within that epoch. CS-ID and CSCI-ID use the CATS data-model typedefs; publisher-id remains a local identifier. A later version in the same epoch and CS-ID scope denotes a later publication. Each covered-instance entry identifies one CSCI-ID and carries its status. Each candidate refers to a covered CSCI-ID; ranks and any constraint tags require defined types and uniqueness rules. A metric-entry contains a CATS metric-type identity and one typed value. The specification defining that identity determines the value branch, units, and validity semantics. The module offers unsigned, decimal, text, and boolean value branches. The module uses a required choice with full-snapshot, invalidated-version, and withdraw cases; the selected case conveys the snapshot type. Window times and metric entries occur only in a FULL snapshot. An INVALIDATE signal identifies the version that is no longer valid; a WITHDRAW signal identifies the publisher and CS-ID whose publication is removed. Deleting a YANG data node is not, by itself, a snapshot withdrawal. All transport bindings defined in this document SHALL carry the complete information represented by this abstract model. Interoperability conformance is judged against this abstract model, not against a particular transport encoding. Appendix B contains the YANG module. Binding 1 specifies its JSON notification encoding and subscription sequence, illustrated in ; each metric identity needs an unambiguous value branch and interpretation.

The reporting policy determines when the C-SMA publishes information. The periodic refresh and significant-change triggers described in may be used for this purpose. A threshold-triggered report is a report caused by a change; it does not imply an INCREMENTAL payload. This document defines the publication content and its meaning on the C-SMA-to-C-PS interface, not the threshold values, reporting interval, or local metric cache. A publisher sends a FULL snapshot for each publisher and CS-ID when a C-PS first establishes its view, on a periodic refresh, and after a significant metric, candidate, or instance-status change. Each FULL snapshot contains the complete current covered set, aggregated metric set, instance statuses, and nominated candidate set for that publisher and CS-ID. Its version is greater than the preceding version for the same publisher, epoch, and CS-ID. After restart or loss of version state, the publisher changes its epoch and sends a new FULL snapshot. A new FULL snapshot replaces the preceding publication in that scope. If one covered instance becomes unavailable, the publisher issues a new FULL snapshot promptly according to the reporting policy. The snapshot can retain that instance in the covered set with an unavailable status while removing it from the candidate list. That change does not withdraw the publication for the CS-ID. INVALIDATE identifies a specified snapshot version in the publisher, epoch, and CS-ID scope whose information must no longer be treated as current. WITHDRAW removes the current publication for the identified publisher and CS-ID. Both are explicit signals; silence, expiry, and deletion of a YANG node are not equivalent to a publisher-issued WITHDRAW. The C-PS determines its local response to unavailable or expired information under its own policy. A publisher that resumes after a lost subscription or other loss of synchronization provides a fresh FULL snapshot before relying on subsequent publications. This profile uses complete FULL snapshots for both periodic and change-triggered reporting. It does not define INCREMENTAL payloads. A future extension may add them only with explicit base-version, ordering, and resynchronization rules for each binding.

In a centralized deployment, the C-SMA publishes nomination snapshots from its RESTCONF server, and the remote C-PS subscribes to receive them. This binding uses the nomination-snapshot notification in Appendix B, encoded as YANG JSON and delivered through RESTCONF over HTTPS . A C-PS establishes a dynamic subscription to the notification stream using the subscribed-notifications procedure and its RESTCONF binding . The C-PS obtains the subscription URI and performs the RESTCONF GET that starts the server-sent event stream. Only an authorized C-PS receives these notifications. After the subscription becomes active, the C-SMA sends one FULL notification for each CS-ID included in the subscription scope before sending later changes for that CS-ID. It sends later FULL notifications on the periodic and significant-change triggers described in Section 6.1 and Section 8 of . Those documents guide reporting frequency; this document does not select threshold values or a heartbeat interval. An INVALIDATE notification names the invalidated version. A WITHDRAW notification removes the publisher's publication for the CS-ID. A candidate's removal from a later FULL notification is not a WITHDRAW. The C-PS uses publisher-id, publisher-epoch, cs-id, and snapshot-version to distinguish publications. Within one epoch and CS-ID scope, a FULL notification with a greater version replaces the earlier FULL notification. If the subscription terminates or the C-PS cannot determine whether it missed an event, it establishes a new subscription and uses the initial FULL notifications to rebuild its view. The publisher starts a new epoch after a restart that loses version continuity. The C-PS's selection and local storage policies are outside the scope of this binding.

This section proposes a BGP-LS mapping for deployments in which a C-PS at an ingress CATS-Forwarder receives nomination information through BGP-LS distribution. The exact NLRI, TLV definitions, field mapping, and code-point allocations remain to be specified. Appendix A illustrates the intended deployment without defining a wire encoding. This profile is limited to a service whose CS-ID maps unambiguously to one service prefix and for which one authorized publisher owns the advertisement for that prefix in the distribution domain. A future BGP-LS encoding would use the corresponding Prefix NLRI and associate a service-metadata TLV in the BGP-LS Attribute with it. The TLV would contain CATS-specific sub-TLVs for Snapshot Context (publisher identity, epoch, CS-ID, snapshot ID, version, and window), Covered Instance and Status, repeated CATS Metric entries, and Candidate entries. The exact TLV and sub-TLV types, lengths, duplicate rules, and code points require IDR coordination and are not assigned here. Each BGP UPDATE for the NLRI carries the complete current FULL snapshot in one advertisement. The publisher sends replacement UPDATEs after significant changes and for periodic refresh under the policy described in ; a threshold-triggered report is still encoded as a FULL snapshot. A changed or unavailable instance is represented in a replacement FULL snapshot and does not withdraw the NLRI. To signal INVALIDATE while retaining the NLRI, the future Snapshot Context sub-TLV needs an explicit invalid indication and the targeted version. WITHDRAW removes the whole publication by withdrawing the NLRI. The encoding must make the publisher and CS-ID scope of that withdrawal unambiguous. A BGP-LS receiver can obtain the current complete advertisement after joining or restarting without reconstructing earlier deltas. This profile does not map INCREMENTAL snapshot payloads into ordinary BGP UPDATEs. It does not define a new BGP session behavior or address family. Appendix A illustrates the prefix-addressable case; a general CS-ID or multiple publishers for one prefix require additional identification mechanisms.

A deployment may use gNMI to expose or subscribe to YANG-modeled snapshot data when its agents and controllers support gNMI, including deployments with a C-SMA on a mobile device. Device mobility alone does not require gNMI. Such a mapping is informative here; it would need to specify the snapshot path, encoding, subscription mode, and correspondence of update and withdrawal events to the abstract snapshot model.

The abstract nomination snapshot carries service selection state that affects forwarding behavior. All transport bindings MUST provide authentication, integrity and replay protection. HTTPS/RESTCONF transport: authenticate and authorize the C-SMA and C-PS, protect the exchange with TLS, and restrict subscription access to the intended snapshot data; BGP-LS transport: distribution must be restricted to authorized CATS nodes and the intended administrative domain. The final BGP-LS encoding must identify mechanisms for publisher authentication, integrity, confidentiality, and freshness; TCP-AO or BGPsec alone does not provide all of these properties.

The YANG namespace and module name in Appendix B require registration if this document advances. The proposed BGP-LS mapping requires TLV and sub-TLV assignments only after its encoding is specified and reviewed with IDR. No BGP-LS code points are requested by this version.

This appendix is informative. It illustrates a possible mapping for a service whose CS-ID is unambiguously associated with an IP prefix. The names and values below are examples; no NLRI, TLV, sub-TLV, or code point is allocated by this appendix. Suppose CS-ID 42 is associated with service prefix 2001:db8:42::/48. C-SMA csma-1 publishes a FULL snapshot covering CSCI-IDs 101 and 102. The snapshot identifies its publisher, CS-ID, snapshot ID and version, observation window, aggregated metric records, and instance status markers. Its candidate list nominates 101 at rank 1 and 102 at rank 2. For this prefix-addressable case, a future BGP-LS binding could associate a Prefix NLRI for 2001:db8:42::/48 with a service-metadata TLV in the BGP-LS Attribute. Proposed CATS-specific sub-TLVs within that container would carry Snapshot Context (including csma-1, 42, and snapshot identification), Covered Instance entries for 101 and 102, the CATS Metric entries, Candidate entries with their ranks, and Instance Status entries. The service prefix alone identifies 42 only where that binding is configured or otherwise specified unambiguously; a general CS-ID requires an explicit encoding or another suitable NLRI. If 102 becomes unavailable, csma-1 publishes a later FULL snapshot for the same service. Its covered set still includes 102, its status marks 102 unavailable, and its candidate list contains only 101. In the illustrated BGP-LS approach, a new UPDATE replaces the attributes for the same NLRI with this complete current snapshot. Removal of the entire publication would instead withdraw that NLRI. Removing one candidate does not by itself withdraw the service NLRI. The authorized BGP-LS distribution domain delivers the advertisement to an ingress CATS-Forwarder hosting a C-PS. The C-PS receives the snapshot information and combines it with network information under its own selection policy. An eventual binding specification needs to define the exact container and sub-TLV encodings, duplicate and unknown-type handling, size limits, authorization, and the relationship between the NLRI and CS-ID.

This YANG module defines the C-SMA-to-C-PS notification used by Binding 1. It imports cats:cs-id, cats:csci-id, and cats:metric-type-base from the CATS data model . It also imports ietf-yang-types for yang:uuid and yang:date-and-time. The metric-value choice and snapshot-specific fields remain defined here. This module is separate from any SCI-to-C-SMA notification model.

This appendix illustrates the JSON encoding of the nomination-snapshot YANG notification from Appendix B when Binding 1 delivers it over RESTCONF. Each example shows the JSON notification body inside one server-sent event; the RESTCONF event stream adds the data: prefix and event framing described in . The JSON member names and values follow . These examples illustrate the existing binding and introduce no additional fields or update semantics. The following FULL notification publishes version 7 for CS-ID 42. The CATS data-model typedefs allow numeric CS-ID and CSCI-ID values. The metric-type identity is qualified by the module in which it is defined. The uint64 snapshot identifiers and metric value are JSON strings, while the uint32 CS-ID and CSCI-IDs and the uint16 rank are JSON numbers.

After CSCI-ID 102 becomes unavailable, the C-SMA publishes another FULL snapshot for the same CS-ID. Version 8 still lists 102 as covered, marks it failed, and nominates only 101. This complete notification replaces version 7; removing one candidate does not withdraw the publication.

The next notification invalidates version 8 in the same publisher, epoch, and CS-ID scope. It does not carry a FULL snapshot or a candidate list.

The following notification withdraws the publication for CS-ID 42. The withdraw leaf has YANG type empty and is therefore encoded as [null] in JSON.

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