Data Model for Computing-Aware Traffic Steering (CATS)

Introduction introduces a framework for Computing-Aware Traffic Steering (CATS). This document defines a YANG data model for managing the CATS system. The model extends the "ietf-routing" YANG model defined in , is agnostic to specific protocol extensions, and conforms to the framework definition to serve as a critical diagnostic or control mechanism.

Terminology The following terms as defined in are used:

CS-ID: CATS Service ID.
CSCI-ID: CATS Service Contact Instance ID.
C-SMA: CATS Service Metric Agent.
C-NMA: CATS Network Metric Agent.
C-PS: CATS Path Selector.
C-TC: CATS Traffic Classifier.

The new defined terms:

C-CIB: CATS Computing Information Base, as shown in , responsible for maintaining CATS network computing information. Provides basic data for the C-SMA.
C-NIB: CATS Network Information Base, as shown in , responsible for maintaining CATS network information. Provides basic data for the C-NMA.

Conventions Used in This Document 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.

Tree Diagrams Tree diagrams used in this document follow the notation defined in .

Prefixes in Data Node Names In this document, names of data nodes, actions, and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in . Prefixes and Corresponding YANG Modules

Prefix	YANG module	Reference
ip	ietf-ip
rt	ietf-routing
cats	ietf-cats
yang	ietf-yang-types
inet	ietf-inet-types

CATS System Overview As defined in , the CATS framework structure consists of the C-SMA (responsible for maintaining service metrics), the C-NMA (responsible for maintaining network metrics), the C-PS (responsible for maintaining forwarding table entries), and the C-TC (responsible for traffic classification), as shown in . The C-CIB and C-NIB are defined in the management plane.

CATS System Architecture | C-SMA | | | | | | | | | | +--v---+ +--v---+ | +--+----+ | | |C-CIB | |C-NIB | | | | | +---^--+ +--^---+ | | | | | | | | +---------|-------|---------|------+ | | Control | +---v--+ +--v---+ | | | Plane | |C-SMA | |C-NMA | | | | | +------+ +------+ | | | | | | | | +-------+ | | | +-->| C-PS | | | | +-------+ | | +----------------------------------+ | /\ /\ | || || | \/ \/ | +----------------+ +-----------------------+ | |CATS Forwarder1 | |CATS Forwarder2 | | | +------+ | | +------+------+ | +--------+ | | C-TC | | | | C-TC | C-PS | |<=========>| +--------+ | +------+ | | +------+--+---+ | | |Service | | | | | | | |Contact | +----------------+ | | | +-|Instance| | +---+---+ | +--------+ | | | | | | +---+--+ +--+--+ | +--------+ | |C-SMA | |C-NMA| | | +--------+ | +------+ +-----+ | | |Service | +-----------------------+ +-|Instance| +--------+ ]]>

Design of CATS Data Model

Scope of Model The model covers CATS systems as described in . This model can be used to manage CATS systems. The operational state data and statistics can be retrieved by this model. The subscription and push mechanism defined in and can be implemented by the user to subscribe to notifications on the data nodes in this model. The model contains all the basic configuration parameters to operate the CATS system. Depending on the implementation choices, some systems might not allow some of the advanced parameters to be configurable. Occasionally-implemented parameters are modeled as optional features in this model. This model can be extended, and it has been structured in a way that such extensions can be conveniently made.

Specification This model imports from and augments the "ietf-routing" YANG model defined in . Both configuration branch and state branch of are augmented. The configuration branch covers node base and policy configuration. The container 'cats' is the top level container in this data model. The operational state data is combined with the associated configuration data in the same hierarchy .

Model Structure This document defines a YANG data model for the management of CATS corresponding data. The data model is applicable to the CATS system architecture in . The CATS YANG model includes basic CATS objects, traffic-classifier objects, and service-metric objects. The model also includes YANG notifications.

The CATS base table provides interfaces for the functionality of the C-PS component, which can be used for communication between the Control Plane and the C-SMA, as well as for the interface between the Control Plane and the CATS Forwarder.
The CATS traffic-classifier table provides interfaces for the functionality of the C-TC component, which can be used for communication between the Control Plane and the CATS Forwarder. The Control Plane can distribute directly CATS traffic-classifier table to the CATS Forwarder, allowing the CATS Forwarder to proactively select paths according to forwarding policies.
The CATS service-metric table provides interfaces for the C-SMA component, which can be used for communication between the Control Plane and the CATS Forwarder, as well as for transmitting service metric information from the C-SMA to the Control Plane. It is also used for forwarding service metric information from the Control Plane to the CATS Forwarder.
The CATS notification definitions are used by the management layer component and can be utilized for the CATS Forwarder to report events to the Control Plane.

The full tree diagram of the "ietf-cats" YANG module is provided in . And the is overall tree structure of the CATS YANG module:

Yang Organization and Hierarchy

CATS Base

Base Configuration Tree View In the base shown in , you can set the 'enable' attribute to enable/disable CATS function on a per-device basis. When set to false, the CATS function component is shut down. You can set the 'update-interval' parameter to determine the interval at which the C-SMA notifies the C-PS of metric changes. The default value for this interval is 30 seconds. You can set the maximum number of metric table entries by configuring 'metric-limits'. You can set the maximum number of flow tables by configuring 'flow-limits'. When flow tables have been inactive for a long period of time, it is necessary to age out the stale state entries. This can be achieved by configuring 'flow-timeout' to control the aging time of flow tables. To prevent notification flooding when limits are reached and unreached in quick succession (flapping), you can configure 'notify-interval' to set the minimum time between consecutive notifications. The default value is 10 seconds. You can set the 'service-policy' table for traffic steering, which includes affinity-based, service-metric-based, network-metric-based, and combined service-metric and network-metric-based steering.

CATS Traffic-classifier

Traffic-classifier Tree View The CATS traffic-classifier table is used to define the features of the service and to classify the traffic, as shown in . The 'cs-id' is used to uniquely identify a CATS service, and the 'description' serves to document its content. The 'server-port' defines the application port for a CATS service. This port number matches the destination port in the IP packets of data flows destined for the service. The 'protocol' defines the application transport protocol for a CATS service. This protocol number matches the protocol in the IP packets of data flows destined for the service. The 'matched-packets' and 'matched-bytes' indicate the statistics of traffic matching the specified service.

CATS Service-metric

Service-metric Tree View The CATS service-metric table is used to control the delivery service metrics on the control plane, as shown in , thereby generating the forwarding table on the forwarding plane in conjunction with network metrics. The 'cs-id' is used to uniquely identify a CATS service, and the 'csci-id' is used to represent an instance of that service. The 'source-type' indicates the source protocol of this service metric information, such as a static protocol. The 'priority' indicates the priority of different service instances of the same service, and the 'affinity' indicates the affinity between this service and its service site. The 'location' indicates the IP address of the service site where this service instance resides. And the 'metrics' indicates different types of service metric values. The 'forwarded-packets' and 'forwarded-bytes' indicate the statistics of traffic forwarded by the specified service metric entry.

CATS Notify

Notify Tree View Four notifications are defined to alert operators when metric or flow entry limits are exceeded or recovered:

metric-limit-exceeded: Sent when the number of metric entries exceeds the configured maximum.
metric-limit-recovered: Sent when the number of metric entries returns to or falls below the configured maximum.
flow-limit-exceeded: Sent when the number of flow entries exceeds the configured maximum.
flow-limit-recovered: Sent when the number of flow entries returns to or falls below the configured maximum.

Each notification carries a timestamp indicating when the event occurred and a human-readable message that includes the configured maximum limit, as shown in . Having separate notifications for each event type allows operators to better parse and route specific events. To prevent notification flooding caused by rapid state changes (flapping), the 'notify-interval' parameter in the base configuration can be used to set the minimum time between consecutive notifications.

CATS YANG Module Editor: Huijuan Yao Editor: Changwang Lin Editor: Zhenqiang Li Editor: Quan Xiong Editor: Luis M. Contreras "; description "This module describes a YANG model for managing the CATS system. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). All revisions of IETF and IANA published modules can be found at the YANG Parameters registry group (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-06-25 { description "Initial Version"; reference "RFC XXXX: YANG Data Model for CATS"; } typedef cs-id { type union { type uint32; type inet:ipv4-address; type inet:ipv6-address; } description "This type defines the CATS Service ID (CS-ID), which uniquely identifies a service."; reference "draft-ietf-cats-framework: A Framework for Computing-Aware Traffic Steering (CATS)"; } typedef csci-id { type union { type uint32; type inet:ipv4-address; type inet:ipv6-address; } description "This type defines the CATS Service Contact Instance ID (CSCI-ID), which uniquely identifies a service contact instance."; reference "draft-ietf-cats-framework: A Framework for Computing-Aware Traffic Steering (CATS)"; } /* * Identities for source-type */ identity source-type-base { description "Base identity for source types of service computing metrics."; } identity source-type-static { base source-type-base; description "Static configuration. This identity is used when the service metric information is configured statically (not learned from a dynamic protocol)."; } /* * Identities for metric-type */ identity metric-type-base { description "Base identity for service metric types."; } identity metric-delay { base metric-type-base; description "Transmission delay metric. The metric value is the delay time in milliseconds."; } identity metric-service-ratio { base metric-type-base; description "Service capacity ratio metric. The metric value is the current capacity percentage."; } identity metric-memory-ratio { base metric-type-base; description "Memory utilization metric. The metric value is the current memory utilization percentage."; } grouping service-policy-type { description "Service policy type"; leaf policy-type { type enumeration { enum base-on-affinity { value 0; description "Base on affinity"; } enum base-on-sm-only { value 1; description "Base on service metric only"; } enum base-on-nm-only { value 2; description "Base on network metric only"; } enum base-on-sm-nm { value 3; description "Base on the combination of service metric and network metric"; } } description "Service policy type"; } } augment "/rt:routing" { description "This augments the CATS configuration."; container cats { description "Support for the CATS configuration."; container base { description "CATS base configuration."; leaf enable { type boolean; description "Enable CATS"; } leaf update-interval { type uint32; units "seconds"; default "30"; description "Update interval of CATS metric. A value of 0 indicates that metrics are sent only when a significant change occurs and not on a periodic basis."; } leaf metric-limits { type uint32; description "The maximum number of metric table entries that can be maintained by the device. This limit prevents resource exhaustion. The actual maximum value is implementation-dependent and should be documented by the vendor. A value of 0 indicates no configured limit (subject to device capacity)."; } leaf flow-limits { type uint32; description "The maximum number of flow table entries that can be maintained by the device. This limit prevents resource exhaustion. The actual maximum value is implementation-dependent and should be documented by the vendor. A value of 0 indicates no configured limit (subject to device capacity)."; } leaf flow-timeout { type uint32; units "seconds"; default "120"; description "CATS flow timeout when no flow. A value of 0 means that the flow does not time out due to inactivity (i.e., infinite timeout), and must be terminated explicitly (e.g., via signaling or administrative action)."; } leaf notify-interval { type uint32; units "seconds"; default "10"; description "The minimum interval between consecutive notifications. This is used to prevent notification flooding when limits are reached and unreached in quick succession (flapping). A value of 0 means notifications are sent immediately without rate limiting."; } list service-policy { key "cs-id"; description "CATS service policy configuration for traffic steering. Each entry defines the policy type for a specific service identified by cs-id."; leaf cs-id { type cs-id; description "The CATS Service ID (CS-ID) that uniquely identifies a service. This identifier is used by clients to access the service."; reference "draft-ietf-cats-framework: A Framework for Computing-Aware Traffic Steering (CATS)"; } uses service-policy-type; } } container traffic-classifiers { description "CATS traffic-classifier entries for classifying traffic by service. Each entry defines the matching criteria for a specific service identified by cs-id."; list traffic-classifier { key "cs-id"; description "A traffic classifier entry for a specific service. The cs-id uniquely identifies the service to be classified."; leaf cs-id { type cs-id; description "The CATS Service ID (CS-ID) that uniquely identifies a service."; reference "draft-ietf-cats-framework: A Framework for Computing-Aware Traffic Steering (CATS)"; } leaf description { type string; description "A human-readable description of this service (e.g., 'http', 'video-streaming')."; } leaf server-port { type uint16; description "Server-port of the service, matches the destination port in the IP packets of data flows destined for the service."; } leaf protocol { type uint8; description "The IP protocol number of the service. This value matches the protocol field in the IP header of data flows destined for the service. Common values include: 6 (Transmission Control Protocol), 17 (User Datagram Protocol), and 132 (Stream Control Transmission Protocol)."; reference "IANA: Protocol Numbers Registry "; } leaf matched-packets { type yang:zero-based-counter64; config false; description "The number of packets matching the specified service."; } leaf matched-bytes { type yang:zero-based-counter64; config false; description "The number of bytes in packets matching the specified service."; } } } container service-metrics { description "CATS service metric entries for controlling delivery of service metrics from the control plane to the forwarding plane."; list service-metric { key "cs-id csci-id source-type"; description "A service metric entry for a specific service instance. The combination of cs-id, csci-id, and source-type uniquely identifies a service metric entry."; leaf cs-id { type cs-id; description "The CATS Service ID (CS-ID) that uniquely identifies a service."; reference "draft-ietf-cats-framework: A Framework for Computing-Aware Traffic Steering (CATS)"; } leaf csci-id { type csci-id; description "The CATS Service Contact Instance ID (CSCI-ID) that uniquely identifies a specific service contact instance."; reference "draft-ietf-cats-framework: A Framework for Computing-Aware Traffic Steering (CATS)"; } leaf source-type { type identityref { base source-type-base; } description "The source type of the service computing metric. Indicates how the metric information was learned. The base identity 'source-type-base' can be extended by other modules to define additional source types."; } leaf priority { type uint8; description "The server priority. The smaller the value, the higher the priority (i.e., 0 is the highest priority). This convention follows common practice in networking protocols (e.g., IP precedence, administrative distance)."; } leaf affinity { type uint8; description "The server affinity. The higher the value, the higher the affinity (i.e., 0 is the lowest affinity). This convention follows common practice for affinity or weight metrics in load balancing."; } leaf location { type inet:ip-address; description "The IPv4 or IPv6 address of the service site where this service contact instance resides. This address represents the logical location of the service in the network topology. CATS-enabled routers use this location information to compute network distances and make steering decisions based on proximity to the service instance."; } container metrics { description "Service metrics for the service contact instance. Each metric entry carries a metric type and its associated value."; list metric { key "metric-type"; description "A service metric of a specific type."; leaf metric-type { type identityref { base metric-type-base; } description "The type of the service metric. The base identity 'metric-type-base' can be extended by other modules to define additional metric types."; reference "draft-ietf-cats-metric-definition: CATS Metrics Definition"; } leaf metric-value { type uint32; description "The value of the service metric."; } } } leaf forwarded-packets { type yang:zero-based-counter64; config false; description "The number of packets forwarded by the specified service"; } leaf forwarded-bytes { type yang:zero-based-counter64; config false; description "The number of bytes in packets forwarded by the specified service"; } } } notification metric-limit-exceeded { description "Event notification sent when the number of metric entries exceeds the configured maximum limit."; leaf timestamp { type yang:date-and-time; mandatory true; description "The time when the metric limit was exceeded."; } leaf message { type string; mandatory true; description "A human-readable message describing the event, including the configured maximum limit."; } } notification metric-limit-recovered { description "Event notification sent when the number of metric entries returns to or falls below the configured maximum limit after having exceeded it."; leaf timestamp { type yang:date-and-time; mandatory true; description "The time when the metric limit was recovered."; } leaf message { type string; mandatory true; description "A human-readable message describing the event, including the configured maximum limit."; } } notification flow-limit-exceeded { description "Event notification sent when the number of flow entries exceeds the configured maximum limit."; leaf timestamp { type yang:date-and-time; mandatory true; description "The time when the flow limit was exceeded."; } leaf message { type string; mandatory true; description "A human-readable message describing the event, including the configured maximum limit."; } } notification flow-limit-recovered { description "Event notification sent when the number of flow entries returns to or falls below the configured maximum limit after having exceeded it."; leaf timestamp { type yang:date-and-time; mandatory true; description "The time when the flow limit was recovered."; } leaf message { type string; mandatory true; description "A human-readable message describing the event, including the configured maximum limit."; } } } } } ]]>

Operational Considerations This section provides operational considerations for implementing and deploying the CATS YANG data model.

Installation and Configuration When deploying the CATS YANG model, operators should configure the 'update-interval' parameter to balance responsiveness against control plane load. The 'metric-limits' and 'flow-limits' parameters should be set based on expected service scale and available device resources.

Monitoring The CATS YANG model provides read-only state data nodes for monitoring: 'matched-packets' and 'matched-bytes' for traffic classification statistics, and 'forwarded-packets' and 'forwarded-bytes' for service forwarding statistics. The 'notify-interval' parameter helps prevent notification flooding during unstable conditions.

Migration Considerations CATS can be incrementally deployed alongside traditional forwarding. The CATS model augments the ietf-routing model without replacing it, allowing for gradual migration.

Security Considerations This section is modeled after the template described in Section 3.7.1 of . The "ietf-cats" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:

/cats:base/cats:enable
/cats:base/cats:update-interval
/cats:base/cats:metric-limits
/cats:base/cats:flow-limits
/cats:base/cats:flow-timeout
/cats:base/cats:service-policy/cats:cs-id
/cats:base/cats:service-policy/cats:policy-type
/cats:traffic-classifiers/cats:traffic-classifier/cats:cs-id
/cats:traffic-classifiers/cats:traffic-classifier/cats:description
/cats:traffic-classifiers/cats:traffic-classifier/cats:server-port
/cats:traffic-classifiers/cats:traffic-classifier/cats:protocol
/cats:service-metrics/cats:service-metric/cats:cs-id
/cats:service-metrics/cats:service-metric/cats:csci-id
/cats:service-metrics/cats:service-metric/cats:source-type
/cats:service-metrics/cats:service-metric/cats:priority
/cats:service-metrics/cats:service-metric/cats:affinity
/cats:service-metrics/cats:service-metric/cats:location
/cats:service-metrics/cats:service-metric/cats:metrics/cats:metric/cats:metric-type
/cats:service-metrics/cats:service-metric/cats:metrics/cats:metric/cats:metric-value

For these augmentations to ietf-routing.yang, the ability to delete, add, and modify CATS base configuration, traffic classifier configuration and service metric configuration would allow traffic to be misrouted. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities:

/cats:traffic-classifiers/cats:traffic-classifier/cats:matched-packets
/cats:traffic-classifiers/cats:traffic-classifier/cats:matched-bytes
/cats:service-metrics/cats:service-metric/cats:forwarded-packets
/cats:service-metrics/cats:service-metric/cats:forwarded-bytes
/cats:metric-limit-exceeded
/cats:metric-limit-recovered
/cats:flow-limit-exceeded
/cats:flow-limit-recovered

Exposing the notification will expose the CATS table information of the network device. This may be undesirable due to the fact that such exposure may facilitate other attacks. Additionally, network operators MAY consider their CATS table information to be sensitive confidential data. All the security considerations for writable and readable data nodes defined in apply to the augmentations described herein. There are no particularly sensitive RPC or action operations.

IANA Considerations The IANA is requested to assign the following URI in the "IETF XML Registry" : This document registers the following YANG module in the "YANG Module Names" registry :