Deterministic Networking (DetNet) YANG Data Model
Extracted elements (27)
Flow aggregation is supported to improve scalability of data, management, and control planes. Eight distinct aggregation scenarios are defined covering App-flow-to-service, service-to-forwarding, service-to-service, and forwarding-to-forwarding aggregation at both ingress and relay nodes.
The 'copy-from-app-flow' sequence number option exists specifically for the case where App-flows have already been replicated across multiple ingress nodes: a relay node can then eliminate duplicate App-flow packets by matching sequence numbers without generating new ones.
The model separates three layers — App-flow, service sub-layer, and forwarding sub-layer — corresponding to edge, relay, and transit node types. A shared traffic-profile referenced by any layer avoids repeating traffic parameters at each level; membership back-references are automatically populated as read-only state.
The YANG model is explicitly controller-based: a controller or operator configures all devices along the path to form a service, enabling end-to-end DetNet provisioning without depending on any signaling protocol. This allows static data-plane configuration for both MPLS and IP paths.
The forwarding sub-layer supports both IP and MPLS data planes. For MPLS static tunnels, configuration is required at every transit node along the path; for IP, static next-hop and address configuration is used. The module provides data-plane programming only, not control-plane signaling or resource reservation signaling.
The ietf-detnet YANG module conforms to the Network Management Datastore Architecture (NMDA), allowing both configuration and operational state to be accessed uniformly via NETCONF and RESTCONF.
The mandatory-to-implement secure transport for NETCONF access to this YANG module is Secure Shell (SSH) per RFC 6242; NETCONF is the lowest management layer accessing DetNet configuration.
The mandatory-to-implement secure transport for RESTCONF access to this YANG module is TLS per RFC 8446; the lowest RESTCONF layer is HTTPS.
When aggregating DetNet flows, if bandwidth reservation is used the reservation should represent the total aggregate bandwidth; if maximum delay bounds are used, the system should ensure the total DetNet flow delay does not exceed the maximum delay bound of any individual flow.
Each service sub-layer entry carries 'service-rank' (uint8, default 255 = lowest priority), a 'service-protection' container specifying protection type and 'sequence-number-length', and an 'operation' leaf selecting initiation, termination, relay, or non-detnet behavior.
The 'app-flow' list entry includes a 'bidir-congruent' boolean (default false) indicating whether both flow directions must share the same physical path. The read-only 'app-flow-status' leaf (identityref based on app-status) reports ingress operational readiness.
The 'app-status' identity hierarchy defines five operational states: 'none' (configuration incomplete), 'ready' (ingress/egress ready), 'failed' (ingress/egress failed), 'out-of-service' (administratively blocked), and 'partial-failed' (one or more egress instances ready, one or more failed; usable if ingress is ready).
The 'data-flow-spec' grouping provides a three-way choice of App-flow type: 'tsn-app-flow' (L2 header via l2-header: src/dst MAC, ethertype, VLAN ID, PCP), 'ip-app-flow' (IP 6-tuple via ip-flow-id), or 'mpls-app-flow' (MPLS label stack with context or platform label-space choice).
The forwarding sub-layer 'operation' uses 'mpls-fwd-operation' typedef with values: impose-and-forward, pop-and-forward, pop-impose-and-forward, swap-and-forward, forward, and pop-and-lookup. All but 'forward' mirror RFC 8960 MPLS base operations.
The 'ip-flow-id' grouping identifies IP DetNet flows using: src/dest IP prefix (inet:ip-prefix), protocol/next-header (uint8), DSCP (inet:dscp), IPv6 flow-label, source and destination port ranges (range or operator), and optionally an IPsec SPI (uint32, range 1..max, per RFC 4303 ESP).
The 'operation' typedef for service sub-layers has four values: 'initiation' (encapsulation of d-CW and S-Label), 'termination' (decapsulation), 'relay' (label swap), and 'non-detnet' (no service sub-layer operation). A single service sub-layer may combine operation types.
The 'sequence-number-field' typedef configures DetNet sequence number field length: 'zero-sn' (field not used, default), 'short-sn' (enum value 16, a 16-bit field), or 'long-sn' (enum value 28, a 28-bit field). Used within the service-protection container.
The 'sequence-number-generation' typedef defines how sequence numbers are produced for DetNet encapsulation: 'copy-from-app-flow' reuses the sequence number already present in the App-flow, and 'generate-by-detnet-flow' creates a new sequence number at the ingress node.
The 'service-protection' typedef enumerates PREOF function combinations: none, replication (PRF), elimination (PEF), ordering (POF), elimination-ordering (PEF+POF), elimination-replication (PEF+PRF), and elimination-ordering-replication (full PREOF). Corresponds to DetNet service protection defined in RFC 8938 Section 4.3.
The top-level 'detnet' container in module ietf-detnet (namespace urn:ietf:params:xml:ns:yang:ietf-detnet, prefix dnet) has four major children: list 'traffic-profile' (keyed by name), container 'app-flows', container 'service' (service sub-layers), and container 'forwarding' (forwarding sub-layers).
The 'traffic-requirements' container within a traffic-profile captures DetNet service requirements: 'min-bandwidth' (uint64, octets/sec), 'max-latency' (uint32, nanoseconds, max ~4.29 sec), 'max-latency-variation' (uint32, nanoseconds), 'max-loss' (decimal64, percent), 'max-consecutive-loss-tolerance' (uint32, packets), and 'max-misordering' (uint32, packets; 0 = strict in-order required).
The 'traffic-spec' container describes the source's transmission promise to the network: 'interval' (uint32, nanoseconds), 'max-pkts-per-interval' (uint32), 'max-payload-size' (uint32), 'min-payload-size' (uint32), and 'min-pkts-per-interval' (uint32). Used by the network for resource reservation, shaping, filtering, and policing.
IANA registered the URI 'urn:ietf:params:xml:ns:yang:ietf-detnet' in the 'ns' subregistry of the IETF XML Registry (RFC 3688). This namespace identifies the ietf-detnet YANG module.
IANA registered the YANG module 'ietf-detnet' in the 'YANG Module Names' subregistry under 'YANG Parameters', with prefix 'dnet', namespace 'urn:ietf:params:xml:ns:yang:ietf-detnet', and reference RFC 9633.
Read access to /detnet/app-flows and related app-flow membership nodes can reveal identifiable characteristics of application flows. Read access to /detnet/service/sub-layer and /detnet/forwarding/sub-layer can expose aspects of the network topology.
The Network Configuration Access Control Model (NACM) per RFC 8341 provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of available operations and content for this YANG module.
Unauthorized write operations (e.g., edit-config) to writable data nodes can break or incorrectly connect DetNet flows. Since DetNet is a configured data plane, uncoordinated changes result in denial of service; arbitrary writes could also reroute traffic to avoid security controls or expose it to an adversary node.