]> Pengcheng Laboratory

gengy@pcl.ac.cn

Pengcheng Laboratory

zhouzhp@pcl.ac.cn

Pengcheng Laboratory

xiegr@pcl.ac.cn

Pengcheng Laboratory

liq@pcl.ac.cn

Web and Internet Transport Individual Submission YANG P4 Configuration Consistency A YANG configuration can express management intent, but its acceptance does not establish that dependent entries in a programmable forwarding pipeline have become effective consistently. This document proposes an experimental mapping and update profile for P4. It describes a target-specific mapping contract, capability validation, generation-based activation, preservation of existing flow bindings, failure recovery, and operational reconciliation. The profile distinguishes configuration acceptance, verified activation, and eventual convergence. It defines neither a new packet encapsulation nor a new YANG module, and does not assume a network-wide atomic transaction.

Introduction The Computing-Aware Traffic Steering (CATS) framework defines the CATS Traffic Classifier (C-TC), CATS Path Selector (C-PS), metric agents, and CATS forwarders.The associated use cases and requirements are described in . An implementation can place classification and forwarding functions ina P4-programmable device while performing path selection on a controller. The CATS data model provides configuration and operational objects for managing such a system. P4 and P4Runtime operate on a different abstraction: a particular compiled pipeline and its tables, actions, parameters, and other entities. There is no general one-to-one translation from an arbitrary YANG tree to an arbitrary P4 pipeline. For example, changing the selected instance can require an instance entry, a next-hop entry, an encapsulation action, and a selection entry. Updating these entities independently can expose a selection entry before its dependencies exist. Retiring old entries too early can also break flows that must remain bound to an earlier instance. This document proposes a bounded experiment to address those problems. Its contribution is a mapping contract and an activation lifecycle with explicit safety conditions. It does not replace a CATS selection algorithm or prescribe where applications place their compute resources.

Scope and Status This is an individual experimental proposal for a single administrative domain. It is not a CATS working group document. Requirements stated here apply to implementations claiming this proposed profile, not to all CATS or P4 implementations. The mapping is based specifically on revision -00 of , which is work in progress. Later revisions require a reviewed mapping-contract update. This document defines no new YANG nodes, RPCs, notifications, P4Runtime messages, or on-wire version field. Operational concepts introduced here are adapter-local unless an implementation explicitly provides an implementation-specific management extension. The scope is an existing, compatible P4 pipeline. Replacing a pipeline program, migrating application state, inter-domain coordination, and transparent recovery of arbitrary stateful services are outside scope. The profile can preserve forwarding affinity, but cannot itself transfer application state between service instances.

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 when, and only when, they appear in all capitals, as shown here.

Terminology The CATS terms CS-ID, CSCI-ID, C-TC, and C-PS follow . The datastore terminology follows . This document also uses the following terms:

• Mapping contract: a versioned description that binds a supported YANG schema and policy interpretation to a particular P4 pipeline schema.
• Configuration revision: a controller-assigned identifier for one immutable snapshot of configuration intent.
• Generation: a locally scoped identifier for a coherent set of forwarding entries and all of its dependencies.
• Activation domain: one device and one explicitly enumerated set of ingress points sharing the activation mechanism. A switch with independent pipelines may contain several activation domains.
• Binding: a mapping from a service flow key to an instance and the forwarding generation needed to reach it.
• Admission: selection and, where required, binding of a new flow.
• Adapter: the component that validates intent, constructs target operations, tracks their application, and reports realized state.

A configuration revision and a forwarding generation are distinct. Metric-driven decisions can create multiple generations under the same configuration revision. Their lifecycle MUST be serialized with configuration-driven changes in the same activation domain.

Architecture and Management Semantics NETCONF or RESTCONF can carry management operations. The selected management protocol retains its defined transaction and error semantics. A successful datastore edit MUST NOT be reported by the adapter as verified data-plane activation unless the verification conditions in this document have also been satisfied. The adapter MUST distinguish the desired configuration revision, the last verified active generation for each activation domain, a pending generation, and any failed or unknown outcome. It MUST preserve the separation of intended and operational state described in . This proposal does not assign these reports to existing CATS model leaves that have different meanings. The C-PS supplies a selection result that the adapter can realize. Raw compute metrics are not automatically forwarding-table entries. The mapping contract determines which derived selection state is installed. The controller SHOULD coalesce metric-driven changes and limit update rates so that telemetry cannot exhaust the configuration work queue.

Mapping Contract

Contract Identity and Inputs An adapter MUST bind each plan to the exact YANG module revisions and enabled features, the mapping-contract version, the P4Info or equivalent target schema, and an identity of the loaded forwarding pipeline. Where numeric table and action identifiers are used, they MUST be resolved against that exact schema. Names and identifiers are not assumed to be portable between compilations. The contract MUST specify supported service identifier types, bit widths, byte encoding, match kinds, action parameter ordering, default actions, priority resolution, and the interpretation of counters. It MUST also define the handling of absent or defaulted YANG values according to . Truncating an identifier to fit a target field or silently dropping a match condition is not permitted. The input to planning consists of an immutable configuration snapshot, a C-PS decision snapshot, current capabilities, and the observed activation and binding state. The adapter MUST revalidate the relevant identities immediately before activation. A pipeline identity change invalidates a previously prepared plan.

Mapping of CATS Objects The following paths are relative to the cats container under /rt:routing in . The P4 entity names below are examples of logical roles, not standardized table names or an extension to that model.

• base/enable controls admission of CATS traffic under the contract. The contract MUST state whether disabling CATS drains existing bindings or terminates them under an explicit operator policy. It MUST NOT implicitly disable unrelated forwarding functions.
• base/service-policy, keyed by cs-id, selects the supported policy interpretation. policy-type is translated into C-PS behavior and derived selection state. An unsupported policy MUST be rejected rather than mapped to an unrelated default algorithm.
• traffic-classifiers/traffic-classifier, keyed by cs-id, can contribute protocol and server-port conditions to a service_classify role. The contract MUST define direction, packet context, and ambiguous overlap handling. A port alone is not assumed to identify a service.
• service-metrics/service-metric, keyed by cs-id, csci-id, and source-type, contributes instance and metric information to the decision process. location can contribute reachability information. A next hop or tunnel endpoint MUST be resolved by the deployment contract rather than assumed to equal location in every deployment.
• metrics/metric-type and metric-value remain typed inputs to that process. Their units and ordering MUST NOT be inferred from the integer value alone. priority and affinity MUST retain their model semantics and MUST NOT be reinterpreted as P4 entry priorities or hardware timeout values merely because field names appear similar.
• base/flow-timeout and flow-limits affect binding management and admission. update-interval and notify-interval affect their specified control or reporting functions. The contract MUST document units, defaults, and timer precision rather than assume a device timer is an exact implementation of a model timer.
• matched-packets, matched-bytes, forwarded-packets, and forwarded-bytes are read-only observations. They MUST NOT be programmed as desired counter values. Counter scope and reset behavior MUST be documented.

Classification MUST handle packets lacking the fields used by a rule. For example, non-initial IP fragments do not expose transport ports. An implementation MUST define a bounded handling path, such as an existing association, controlled slow path, or drop. It MUST NOT parse encrypted application content as if it were clear-text service metadata.

Logical Forwarding Roles A generation-based realization can use the following roles: local service handle flow_binding(service, flow key) -> generation, instance handle active_generation(service) -> generation for new admission service_select(generation, service, selector) -> instance handle instance_resolve(generation, instance handle) -> forwarding action ]]> One physical table can implement several roles, or one role can require multiple tables. That arrangement MUST preserve the logical semantics. The local service handle is not a replacement for the external CS-ID. The contract MUST maintain an unambiguous mapping and prohibit reuse while any referencing entry or binding remains reachable. For the basic generation mechanism, classification semantics and binding key interpretation remain stable during an update. If an update changes those semantics, the adapter MUST include them in an independently verified versioned lookup design or use the admission-quiescence procedure below. Merely versioning the instance table is insufficient.

Capability Validation and Planning Before writing a plan, the adapter MUST validate the required parser fields, match kinds, action parameters, table capacity, dependency ordering, and activation behavior for every affected activation domain. It MUST account for old entries retained by bindings as well as the complete pending generation. Estimates based only on the new generation are insufficient. Validation MUST include limits on bindings, simultaneous generations, encapsulation size, and counter or timer behavior used by the plan. Packets that exceed the resulting path MTU require an existing, explicitly configured handling mechanism. This document defines no fragmentation or new tunnel mechanism. P4Runtime exposes schema information through P4Info, but P4Info alone does not establish available capacity or every target behavior. The adapter MUST combine schema checks with target documentation and verified operational capabilities. An implementation MUST reject a plan when a required guarantee cannot be established. Validation returns either an applicable plan or an actionable error identifying the unsupported input or capability. Configuration errors, capacity exhaustion, stale controller ownership, and an unknown device outcome MUST remain distinguishable. An error MUST NOT reveal another tenant's identifiers or configuration.

Update Consistency

Guarantees and Limits The basic safety property is that a packet admitted under a generation uses a complete, internally compatible set of forwarding dependencies. For an established binding, the property additionally preserves the selected instance for the lifetime allowed by the service policy. These properties do not imply that all packets in the network observe the same generation at the same wall-clock instant. The adapter MUST identify one of the following activation mechanisms for each plan:

• A verified data-plane-atomic write covering the complete affected dependency set in one supported target operation.
• A verified generation selector that is sampled once for each new admission, with the sampled generation retained through all relevant lookups, recirculation, and binding creation.
• An admission gate that prevents new admissions while changes are applied and verified. Existing bindings either remain fully supported or are drained under an explicit service policy before modification.

If none is available, the adapter MUST reject a request for this profile. It MUST NOT silently weaken consistency to best-effort writes. In P4Runtime, CONTINUE_ON_ERROR does not give all-or-nothing behavior. ROLLBACK_ON_ERROR can restore state after an error but does not make intermediate states invisible to packets. DATAPLANE_ATOMIC provides a stronger per-batch data-plane guarantee when supported . The adapter MUST verify support for the actual operations and dependency set. Separate atomic batches do not form one transaction. Read-back by itself cannot prove that intermediate states were invisible.

Lifecycle PREPARING -> READY -> ACTIVATING -> ACTIVE | | | | | +------------+---------+ | DRAINING | | | FAILED UNKNOWN RETIRED | RECONCILING ]]> The lifecycle is maintained per activation domain. PREPARING and READY describe a pending generation. ACTIVE, DRAINING, and RETIRED describe the generation after activation and replacement. These are conceptual adapter states, not new YANG enumerations.

1. VALIDATING: validate the input snapshots and capabilities. Allocate a non-conflicting generation and record a durable transaction identity, desired revision, pipeline identity, and dependency plan.
2. PREPARING: install dependencies before the entries that reference them. Pending entries MUST remain unreachable by production admission. A dependency crossing separate writes MUST be acknowledged before its dependent write is issued, unless the target explicitly supports that dependency in a single atomic operation.
3. READY: read back the relevant owned entries or use an equivalent authoritative device confirmation. Compare normalized entity state with the plan. Verification MUST cover keys, masks, priorities, action identifiers, and parameters, not only entry counts.
4. ACTIVATING: recheck ownership and pipeline identity, then switch the admission selector using the verified mechanism. Journal the intended switch before issuing it. A transport timeout is an unknown outcome, not evidence of success or failure.
5. ACTIVE: confirm the selector and required generation state. Report verified activation only for domains that have reached this step.
6. DRAINING: retain the old generation while live bindings or in-flight packets can reference it. Prevent creation of new bindings under that generation, except those already racing with the selector switch and explicitly included in the drain accounting.
7. RETIRED: remove old selection entries before removing their dependencies. Do not reuse generation identifiers until no old references, outstanding writes, or delayed recovery operations can resolve to the reused value.

The selector MUST be scoped to the same coherence unit as the generation. If an update spans several services without a common atomic selector, the adapter MUST report separate activation outcomes. It cannot claim that the service group changed atomically.

Flow Binding and Retirement An established binding is looked up before choosing a new generation. The binding key MUST include the service and applicable tenant context, not merely a hash whose collisions can redirect traffic. A hash-based implementation MUST detect or otherwise safely resolve collisions. Concurrent first packets of the same flow MUST select the same binding. This requires a verified atomic binding operation or a serialized, bounded admission path. A read-then-write sequence without exclusion does not satisfy this requirement. Buffering, drops, and admission timeouts on that path MUST have explicit limits and observable counters. Flow aging MUST follow the configured service semantics. If the target cannot implement the required aging accurately, a documented controller timer can provide a coarser behavior only when that behavior satisfies the accepted policy. Otherwise the configuration MUST be rejected. Retirement requires authoritative evidence that no live binding remains and a sufficient bound on in-flight packet residence, including queues and recirculation. If such evidence or a bound is unavailable, the adapter MUST retain the generation or explicitly quiesce and drain the affected service. A fixed delay chosen without these conditions is not proof of safe retirement.

Failure, Rollback, and Controller Recovery Before activation, failure leaves the previous generation active. Unreachable partial entries can be removed after their ownership and absence of references are verified. Capacity reservations MUST remain accounted for until cleanup is confirmed. After activation, changing the selector back is a new admission decision. Flows already bound to the newer generation MUST continue to have their dependencies available. Rollback MUST NOT delete those dependencies or move such flows to a different instance without explicit service policy. If the newer instance has failed, ordinary affinity is no longer enough. The adapter MUST apply a declared service recovery policy, such as drop, reject, or use of a service-supported alternative. This document cannot guarantee continuity of application state. On a timeout or controller restart, the adapter enters reconciliation with the outcome marked UNKNOWN. It MUST recover the durable journal, read the pipeline identity and activation selector, and compare the owned dependency set before taking further action. Repeating INSERT or DELETE blindly is not idempotent recovery. A retry MUST compare desired and observed normalized entities and issue only the required changes. Only one authorized writer may control an activation domain at a time. When using P4Runtime, the applicable arbitration and role mechanism MUST be used. The adapter MUST stop writes when its authority is lost. Other target APIs require equivalent fencing. A management datastore lock alone does not fence a stale writer on the southbound interface. If the device loses bindings during restart, the adapter MUST NOT claim that prior affinity remains intact. The recovery policy must explicitly re-establish supported state, drain affected sessions, or expose service disruption before admitting affected traffic.

More Than One Device READY can be required on every intended device before activation starts, but activation can still succeed on only a subset. The controller MUST report that partial state and the recovery policy. It MUST NOT report a distributed atomic commit based only on separate device acknowledgments. For ingress and egress dependencies, a deployment MUST either keep both generations compatible at egress during the overlap, use an already defined and verified way to identify the required forwarding context, or quiesce admission across the affected service path. A device-local metadata generation is not automatically carried across the network. Defining a new packet field to carry it is outside this document.

Operational State and Reconciliation The adapter MUST expose, through a documented implementation interface, the desired revision, mapping-contract identity, pipeline identity, pending and active generations per domain, lifecycle state, last verified time, and a bounded error description. It SHOULD expose retained generations, resource usage, and drift counters. This is a reporting requirement for the experiment, not a claim that already defines all of these objects. Reconciliation MUST be bounded in rate and scope. It compares only entities owned by the adapter and MUST NOT delete unrelated routing, ACL, or other application entries. Shared dependencies require explicit ownership or reference tracking. Unexpected pipeline identity changes halt activation until the mapping contract has been revalidated. Counters can reset on restart or generation replacement. Their aggregation MUST avoid double counting during overlap and MUST identify discontinuities to consumers. A counter read and a table read are not assumed to be one simultaneous snapshot. Metric validity, reachability, and configuration consistency are separate properties. A fully installed generation can still embody an obsolete C-PS decision. The deployment SHOULD define maximum decision age, metric-loss handling, and admission behavior when no eligible instance exists. An adapter MUST NOT infer that a successful write makes stale metrics valid again.

Example Update The following values and names are illustrative local identifiers. They are not allocated protocol values, a prescribed P4 program, or a new YANG schema. (7, instance-1) new C-PS decision: instance-2 prepare generation 8: instance_resolve(8, instance-2) = verified forwarding action service_select(8, 100, default) = instance-2 verify generation 8 and current pipeline identity activate: active_generation(100) = 8 flow-A still resolves through (7, instance-1) newly admitted flow-B binds to (8, instance-2) retire 7 only after its bindings and packets have drained ]]> If the activation response is lost, read-back can show either 7 or 8. In either case, the controller verifies the corresponding dependencies before reporting the outcome. If neither result is trustworthy, the state remains UNKNOWN and further admission follows the configured failure policy. If a rollback admits new flows under 7, generation 8 still remains available to flow-B until it drains.

Experimental Evaluation An experiment SHOULD compare direct sequential writes, any verified target-atomic mechanism, and the generation mechanism under the same traffic and resource conditions. Unsupported mechanisms must be marked unsupported rather than emulated and reported as hardware guarantees. No performance ordering between switch ASIC and FPGA targets is assumed. The experiment SHOULD cover concurrent first packets, flow-hash collisions, near-capacity tables, delayed responses, lost activation acknowledgments, controller failover, device restart, partial multi-device activation, and a change in classifier or pipeline identity. A service instance failure during drain is a separate required recovery scenario. Measurements SHOULD include accepted-to-active time, reconciliation time, retained entry count, admission loss, incorrect-instance delivery, binding changes, and application completion latency. Zero observed violations in a finite test is not a proof of correctness. Reports SHOULD state device and compiler versions, supported atomicity modes, traffic seeds, offered load, sample counts, and uncertainty. Progress toward wider interoperability depends on showing that at least two target realizations preserve the same classification and affinity semantics, that unknown outcomes recover without blind replay, and that resource exhaustion produces a bounded, observable failure. Whether a common YANG augmentation for activation status is useful is a subject for subsequent work, not an unimplemented requirement of this revision.

Security Considerations A compromised mapping contract or C-PS input can redirect service traffic even when table updates are internally consistent. Management and southbound access MUST authenticate peers, authorize operations by tenant and role, and protect integrity and confidentiality. NETCONF and RESTCONF access control can use . P4Runtime transport security must follow its specification , with appropriate TLS configuration . Physical placement within one domain alone is not an adequate authorization mechanism. Pipeline artifacts and mapping contracts MUST come from authorized sources. Their identity must be bound to a plan so that a valid plan cannot be replayed onto an incompatible program. Journals and ownership records MUST be protected against unauthorized modification and stale writer replay. Generations alone are not security tokens. Operators MUST limit outstanding plans, retained generations, flow bindings, and slow-path admission work. An attacker can otherwise exhaust table memory by inducing updates or keeping bindings alive. Cleanup under pressure MUST preserve isolation and MUST NOT silently reassign a live flow to another tenant or instance. Operational reports and counters can reveal workload placement and activity. Access SHOULD be restricted to the necessary scope, and error messages SHOULD avoid packet payloads and unrelated identifiers. Recovery and rollback MUST retain policy enforcement, including ACLs, even when steering is unavailable. A fallback path MUST NOT bypass authorization merely to keep packets moving.

IANA Considerations This document has no IANA actions. It defines no new YANG module, namespace, registry, port, IP protocol number, or packet header. Local table names and generation identifiers in the examples have no on-wire allocation or interoperability significance.

References Normative References The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. The framework covers only the case of a single service provider. The P4.org API Working Group In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. Distributed computing enhances service response time and energy efficiency by utilizing diverse computing facilities for compute-intensive and delay-sensitive services. To optimize throughput and response time, Computing-Aware Traffic Steering (CATS) selects servers and directs traffic based on compute capabilities and resources, rather than static dispatch or connectivity metrics alone. This document outlines the problem statement and scenarios for CATS within a single domain and drives requirements for the CATS framework. The P4 Language Consortium

Implementation Status No implementation is reported in this revision. The mapping roles, state machine, and example are proposals for evaluation. Publication of test results should identify both supported and unsupported consistency mechanisms and the exact target configurations used.