Internet-Draft CATS Metric Snapshot Exchange October 2026
Zhang, et al. Expires 29 April 2027 [Page]
Workgroup:
Computing-Aware Traffic Steering
Published:
Intended Status:
Standards Track
Expires:
Authors:
B. Zhang, Ed.
Pengcheng Laboratory
B. Shen, Ed.
Harbin Institute of Technology
Y. Yang, Ed.
Sun Yat-sen University

Metric Snapshot Exchange between SCI and C-SMA in CATS

Abstract

This document specifies metric snapshot exchange between a Service Contact Instance (SCI) and a CATS Service Metric Agent (C-SMA). It defines atomic replacement, ordering, and validity for periodic full snapshots and change-triggered updates over HTTPS/JSON. An informative appendix explains how one shared snapshot YANG model can support generation of the publication and response messages.

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 29 April 2027.

▲

Table of Contents

1. Introduction

The SCI supplies service observations to the C-SMA, which reports service information to the CATS Path Selector (C-PS) [RFC10053]. A snapshot groups metrics so that the consumer can apply a coherent publication and distinguish it from older or incomplete updates.

The contract applies to independently implemented components and can also be used within a co-located platform. Individual metrics follow their defining specifications. A shared, versioned metric profile fixes metric keys, units, value encodings, required members, observation windows, maximum ages, and cross-metric acceptance constraints.

Section 4 defines the HTTPS/JSON exchange. All structured messages described here can be populated and serialized by tooling based on one shared snapshot YANG model, using the mapping in Appendix B. That appendix is informative; conformance is determined by the snapshot contract and HTTPS/JSON binding in the main body.

1.1. Motivation for the HTTPS/JSON Binding

SCI and C-SMA may run on different hosts. The reporting policy recommends a 10-second refresh and sends an update whenever a published metric changes. With many SCI sources, these changes produce frequent updates that require an external reporting interface.

gNMI supports periodic and on-change telemetry [GNMI]. On a service host without a gNMI target, using it requires a target or adapter with gRPC/Protobuf and subscription handling. The C-SMA must establish subscriptions to those targets. This adds deployment work to service applications that already use HTTP clients.

With RESTCONF polling, the C-SMA makes repeated reads and detects changes only at the next poll. Notification streams and dynamic subscriptions avoid polling but require a publisher endpoint and subscription handling [RFC8040] [RFC8650]. A RESTCONF push RPC is also possible, with a YANG RPC definition and RESTCONF operation mapping.

This binding uses SCI-initiated HTTPS POST to a C-SMA collector, reusing existing HTTP clients and authenticated connections. The SCI publishes changes under the exchange rules without deploying a telemetry server on every SCI or requiring C-SMA subscriptions. The JSON contract defines snapshot acceptance, ordering, and retry behavior for this exchange.

1.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" are interpreted as described in BCP 14 [RFC2119] [RFC8174] when they appear in all capitals.

2. Snapshot Messages

A reporting scope is (provider, cs-id, csci-id, group). Each scope has one authorized logical producer and one active profile. FULL, DELTA, and WITHDRAW reuse the following envelope.

Table 1: Publication envelope
Field Meaning
contract Integer 1 for this contract.
scope Object containing provider, cs-id, csci-id, and group.
profile Identifier of the shared metric profile version.
context Current receiver token, issued by the C-SMA.
generation, revision Producer lifetime and publication numbers; revision is positive.
kind FULL, DELTA, or WITHDRAW.
generated-at UTC time when this publication was assembled.
entries Metric-keyed object for FULL and DELTA; absent for WITHDRAW.
base-revision, remove DELTA only: accepted base revision and array of keys to remove.

Each entry contains status, observed-at, and valid-until. An available entry includes value; an unavailable entry omits it. An available interval statistic also contains window-start and window-end, with observed-at equal to window-end. Instantaneous and unavailable entries omit the window fields.

The consumer MUST validate and apply each publication as one operation. FULL replaces the group, DELTA replaces or removes listed entries, and WITHDRAW removes the group. A required profile member must remain present in FULL and after DELTA, with either available or unavailable status. A DELTA key MUST NOT occur in both entries and remove.

An omitted entry is removed by FULL and unchanged by DELTA. An unavailable required metric makes the group unusable but does not prevent acceptance; numeric constraints apply to available values. The same scope and entry definitions are reused for every publication kind, including in the shared-model mapping in Appendix B.

3. Exchange Rules

FULL and WITHDRAW are required; DELTA is optional. The SCI serializes requests per scope, waiting for a response or timeout before sending another. A new publication has a greater revision than all earlier publications assigned in the generation; a retry preserves the same version and body bytes.

Generations increase across producer resets and MUST NOT be reused or wrap. The consumer compares (generation, revision) lexicographically. A new context or higher generation requires FULL; DELTA requires the currently accepted base-revision in the same generation and a PRESENT group.

An identical retry of the last accepted publication returns DUPLICATE. Older versions return STALE, and different content at the same version returns CONFLICT. A missing delta base or outdated context returns RESYNC; the producer obtains the descriptor and sends a newer FULL. Rejected messages leave accepted state unchanged.

The C-SMA retains ordering state after expiry and withdrawal. Loss of that state, or a change to producer authorization, profile, capabilities, or limits, invalidates the group and creates a fresh context. Old-context publications cannot restore that group.

The deployment maintains a maximum clock difference S. The consumer rejects observations later than generated-at or more than S ahead of its own time; it also checks window-start <= window-end and observed-at < valid-until within the profile's maximum age. Each metric retains its own measurement window.

An entry is usable only while the receiver's time plus S is earlier than valid-until. A group needs all required entries to be available and usable; expiry stops their use even if no message arrives. A newer valid publication advances ordering even when its observations have already expired. Retransmission and forwarding MUST NOT extend source validity.

3.1. Periodic and Change-Triggered Reporting

While advertising a service offer, the SCI MUST schedule a FULL report at each configured period boundary, even when values are unchanged. The recommended default period is 10 seconds. Triggered updates MUST NOT reset this timer.

Every detected change in a published metric value, availability, or entry membership MUST trigger an update, sent promptly under the serialized exchange rules. Use DELTA when supported and a valid base exists; otherwise use FULL. The SCI applies no change-magnitude threshold.

The SCI derives service metrics locally and reports their changes. The C-SMA controls downstream aggregation, thresholds, and publication timing toward the C-PS. Periodic reports use current observations; retained samples keep their original observation times and validity.

4. HTTPS/JSON Binding

The provider provisions one HTTPS endpoint per scope, the authorized producer, and the metric profile. HTTP [RFC9110] uses mutually authenticated TLS 1.3 [RFC8446]. GET retrieves the receiver descriptor; POST submits a publication. Bodies are UTF-8 application/json [RFC8259], and responses use Cache-Control: no-store.

The descriptor contains contract, scope, profile, context, delta-supported, max-message-bytes, max-entries, max-clock-skew-ms, current-generation, current-revision, and state. State is EMPTY, PRESENT, or WITHDRAWN; current version fields are null in EMPTY. PRESENT indicates accepted state whose usability follows Section 3.

Context is a non-reused 32-character lowercase hexadecimal token generated from 128 unpredictable bits. The three max fields are positive integers: they bound request-body bytes, each entries/remove collection and resulting group size, and clock difference S in milliseconds. Delta-supported is boolean.

Identifiers and profile keys are nonempty case-sensitive strings. Version numbers are unsigned 64-bit decimal strings without leading zeros; revision is nonzero. Times use UTC RFC 3339 strings ending in Z [RFC3339] with up to nine fractional digits. Value types and ranges follow the profile.

The receiver checks authorization, envelope, context, capability, ordering, and the resulting group. It rejects unsupported contract versions or profiles, duplicate JSON names, unknown members or metric keys, invalid types or ranges, and exceeded limits. All envelope fields are required except those restricted to another kind; entries use only the fields in Section 2.

The JSON result contains result, context, submitted-generation, submitted-revision, current-generation, current-revision, and state. HTTP 200 carries ACCEPTED or DUPLICATE; 409 carries RESYNC, STALE, or CONFLICT; 422 carries INVALID. Malformed JSON returns 400, unauthorized requests 401 or 403, oversized bodies 413, and unsupported media types or Content-Encoding 415.

A timeout leaves the outcome unknown: retry the same body or obtain the descriptor before sending a newer FULL. A response must match the submitted context and version to acknowledge that publication. Unsupported DELTA returns INVALID. Senders omit Content-Encoding and do not follow endpoint redirects automatically.

5. JSON Example

The example uses profile example-service-v2 for GAS, Computing Time, Price, Reputation, and Security Level as described in [I-D.zhangb-cats-service-metrics-op]. GAS and Computing Time are required; the other three attributes are optional. The profile uses a maximum age of 20 seconds and the value types below.

Table 2: Example metric profile
Key Value interpretation
gas uint32; available concurrent-request count; instantaneous estimate.
comp_time Nonnegative finite number; mean processing time in milliseconds over the given window.
price uint16; provider-defined pricing unit.
reputation Integer score from 0 to 10.
security_level Integer score from 0 to 10.

All five values apply to the same service offer. The SCI has confirmed the attributes at the observation time; the context token is an illustrative value standing for a token obtained by GET. The following body is also supplied as sci-csma-snapshot-main-02.example.json.

{
  "contract": 1,
  "scope": {
    "provider": "p1",
    "cs-id": "S1",
    "csci-id": "SCI-A",
    "group": "service-offer"
  },
  "profile": "example-service-v2",
  "context": "fedcba9876543210fedcba9876543210",
  "generation": "7",
  "revision": "12",
  "kind": "FULL",
  "generated-at": "2026-10-24T08:00:10Z",
  "entries": {
    "gas": {
      "status": "available",
      "value": 7,
      "observed-at": "2026-10-24T08:00:10Z",
      "valid-until": "2026-10-24T08:00:30Z"
    },
    "comp_time": {
      "status": "available",
      "value": 10.0,
      "observed-at": "2026-10-24T08:00:10Z",
      "valid-until": "2026-10-24T08:00:30Z",
      "window-start": "2026-10-24T08:00:00Z",
      "window-end": "2026-10-24T08:00:10Z"
    },
    "price": {
      "status": "available",
      "value": 100,
      "observed-at": "2026-10-24T08:00:10Z",
      "valid-until": "2026-10-24T08:00:30Z"
    },
    "reputation": {
      "status": "available",
      "value": 8,
      "observed-at": "2026-10-24T08:00:10Z",
      "valid-until": "2026-10-24T08:00:30Z"
    },
    "security_level": {
      "status": "available",
      "value": 7,
      "observed-at": "2026-10-24T08:00:10Z",
      "valid-until": "2026-10-24T08:00:30Z"
    }
  }
}
Figure 1: Full service snapshot

Acceptance returns HTTP 200 with result ACCEPTED and current version (7, 12). An identical retry returns DUPLICATE. A DELTA with revision 13 and base-revision 12 can replace an entry; an unknown base returns RESYNC. WITHDRAW removes the offer while retaining its accepted version.

For a 10-second period, a FULL at t=0 can be followed by change-triggered updates at t=3 and t=7, then another FULL at t=10. Those updates do not postpone the periodic report. The example's 20-second maximum age leaves margin for delivery and clock error between periodic observations; it does not refresh retained samples.

6. Security Considerations

A forged or replayed snapshot can affect service selection. The C-SMA authorizes the authenticated publisher for its scope, protects ordering state, and rotates context after losing that state. A deployment unable to maintain its clock bound suspends use of time-sensitive groups. Message limits, access controls, and bounded log retention protect processing capacity and service information [RFC10053].

7. IANA Considerations

This document requests no IANA allocations.

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, , <https://www.rfc-editor.org/info/rfc3339>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/info/rfc8259>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/info/rfc9110>.
[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, DOI 10.17487/RFC10053, , <https://www.rfc-editor.org/info/rfc10053>.

9. Informative References

[GNMI]
OpenConfig, "gRPC Network Management Interface (gNMI) Specification", Version 0.11.0, , <https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md>.
[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, , <https://datatracker.ietf.org/doc/html/draft-zhangb-cats-service-metrics-op-05>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
[RFC7951]
Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, , <https://www.rfc-editor.org/info/rfc7951>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
[RFC8641]
Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, , <https://www.rfc-editor.org/info/rfc8641>.
[RFC8650]
Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and A. Bierman, "Dynamic Subscription to YANG Events and Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, , <https://www.rfc-editor.org/info/rfc8650>.

Appendix A. Local Metric Production (Informative)

For two independent service instances with budgets of ten requests and active counts of six and seven, the aggregate GAS is four plus three, or seven. Shared resources limit that sum; a pool with four unused allocations can support at most four additional requests. A processing-time estimate uses compatible requests and the stated measurement window.

Appendix B. Shared Snapshot YANG Model (Informative)

One shared snapshot YANG model can describe the payloads for FULL, DELTA, WITHDRAW, receiver descriptors, and publication results [RFC7950]. Both components can reuse its scope, version, timestamp, and metric-entry definitions. Model-driven tooling can generate data bindings and serializers; the application supplies observations, context tokens, and accepted versions.

Table 3: Reuse of the shared model
Message Shared definitions and message-specific data
FULL Common envelope and complete collection of metric entries.
DELTA Same envelope and entries, plus base-revision and remove.
WITHDRAW Same envelope; entries, base-revision, and remove are absent.
Receiver descriptor Common scope, profile, context, and version types; capabilities, limits, and state.
Publication result Common context and version types; result and state.

A serializer uses the exact JSON field names and kind-specific presence rules in the main body. If metric entries are represented as a YANG list keyed by metric-key, the adapter produces the entries object keyed by those values. The profile determines each value's JSON type. Shared RPC input/output groupings can cover descriptor retrieval and publication results as well as publications.

RFC 7951 encoding of YANG data introduces namespace and list rules [RFC7951]. The HTTPS binding here uses its own application/json envelope, so a model-based adapter maps those representations explicitly, including decimal strings for uint64 values and null current versions in EMPTY state. This appendix supplies implementation guidance, not a normative YANG module or a NETCONF/gNMI binding.

YANG-Push and gNMI provide existing subscription mechanisms [RFC8641] [GNMI]. A future binding can reuse the common payload definitions while specifying subscription reset, atomic scope, and application acknowledgments.

Appendix C. Acknowledgments

The authors thank the CATS working group for its feedback.

Authors' Addresses

Bin Zhang (editor)
Pengcheng Laboratory
Sibilong Street
Shenzhen
Guangdong, 518055
China
Bowen Shen (editor)
Harbin Institute of Technology
Taoyuan Street
Shenzhen
518055
China
Yixuan Yang (editor)
Sun Yat-sen University
Gongchang Street
Shenzhen
Guangdong, 518055
China