IM Engineer Study Notes
← Back to list
Networking
#DetNet#확정형네트워킹#PREOF#상한지연#TSN연계
Last updated · 2026-11-01

Deterministic Networking (DetNet)

1. Overview

Definition: Deterministic Networking (DetNet) is an IETF standard suite of technologies that provides a specific flow with bounded latency, low jitter, extremely low packet loss, and order preservation over an IP/MPLS routed network (Layer 3). By combining resource reservation, explicit routes, and packet replication/elimination, it realizes deterministic delivery rather than "best-effort" delivery — a network service model.

The word "deterministic" is often misread as "very fast," but the key is not speed but predictability. For control applications, a flow that deterministically respects a 10 ms bound is safer than one that averages 1 ms but occasionally spikes to 50 ms. This is because a control loop can only design for stability once it knows the upper bound of communication latency. DetNet's goal is therefore not "the fastest delivery" but "delivery whose never-exceeded upper bound is known in advance," and the need for a separate technology arises precisely because best-effort networks cannot structurally provide this predictability.

Traditional IP networks were designed on the premise of statistical multiplexing. While multiple flows sharing the same link and buffers are efficient on average, when traffic momentarily converges, queues build up and latency oscillates (jitter), and when buffers overflow, congestion loss occurs. This is no problem for applications such as web or file transfer that can absorb hundreds of ms of latency variation with retransmission and buffering, but it is fatal for applications that must "arrive by a fixed deadline," such as industrial control, power protection relaying, professional audio/video, vehicle control, and robot collaboration. For these applications, it is not average latency but the upper bound of worst-case latency that must be defined, and even a single loss is directly tied to safety or quality problems.

This requirement was long solved with dedicated industrial buses (Fieldbus) or vendor-proprietary protocols (EtherCAT, PROFINET IRT, etc.), but as the convergence of IT and OT (operational technology) accelerated, the demand to provide determinism over standard Ethernet/IP infrastructure grew. If IEEE 802.1 TSN (Time-Sensitive Networking) solved this problem in the Layer 2 (Ethernet bridge) domain, the IETF DetNet WG (formed in 2015) published its architecture standard (RFC 8655) in 2019 with the goal of extending that determinism all the way to Layer 3 routing domains (IP/MPLS). In other words, DetNet is not a competitor to TSN but is best understood as an upper-layer complement that completes end-to-end determinism by stitching TSN subnetworks together over an IP/MPLS backbone.

One common misconception should be addressed here: the objection that "if you lay down ample bandwidth (overprovisioning), won't latency naturally decrease?" Average latency clearly drops, but over-provisioning cannot guarantee an upper bound. At the worst moment when bursts overlap simultaneously, momentary queues build up no matter how much spare bandwidth exists; the frequency is merely lower, yet the bound still exists only statistically. For applications such as protection relaying or motion control where "not even one exceedance in a million is permitted," a deterministic mechanism is required rather than probabilistic headroom. It must be made clear that the essence of the problem DetNet solves is not average performance but the deterministic worst-case bound.

2. Overall Structure and Service Model

DetNet divides the data plane into a service sub-layer and a forwarding sub-layer. The service sub-layer handles flow identification and packet replication/elimination/reordering (PREOF) to provide reliability (service protection), while the forwarding sub-layer provides a latency bound (congestion protection) through explicit routes and resource allocation. This separation of responsibility between the two sub-layers is the starting point for understanding DetNet.

graph LR
  subgraph APP["Application/Endpoint"]
    SRC["Sending endpoint(Talker)"]
    DST["Receiving endpoint(Listener)"]
  end
  subgraph CTRL["Control plane"]
    CC["Central controller(PCE/SDN)"]
    YANG["YANG model/flow registration"]
  end
  subgraph DP["DetNet data plane"]
    SVC["Service sub-layer<br/>(flow ID·PREOF)"]
    FWD["Forwarding sub-layer<br/>(explicit route·resource alloc)"]
  end
  SRC --> SVC
  SVC --> FWD
  FWD --> DST
  CC -->|"route·bandwidth calc"| FWD
  YANG -->|"flow parameters"| SVC
  CC --- YANG

The three core techniques DetNet uses to achieve determinism are as follows, each targeting a different quality objective.

A. Resource Allocation — guaranteeing the latency bound. For a DetNet flow, buffers and bandwidth are reserved in advance at each node along the path. The core idea is "DetNet traffic must never experience queuing due to congestion." By limiting the maximum resources the set of DetNet flows can consume at each hop during the admission control stage, and by using formalized schedulers such as cyclic queuing (CQF) or time-aware scheduling, per-hop latency becomes mathematically bounded. Summing per-hop bounds lets you compute the end-to-end worst-case latency, so that, for example, "this control flow arrives within 2 ms under any load" can be guaranteed in advance. This is the fundamental difference from a best-effort network — best-effort may be good on average but has no bound.

A representative mechanism that embodies resource allocation is CQF (Cyclic Queuing and Forwarding). Time is sliced into fixed-length cycles, and two (or more) queues are used alternately so that packets arriving during one cycle are necessarily transmitted in the next cycle. This makes the latency of one hop converge to "an integer multiple of the cycle length," so that per-hop latency is fixed like a constant regardless of the flow pattern. For example, if the cycle is 100 μs and the path is 6 hops, the end-to-end latency is determined at roughly 600 μs, and jitter is suppressed to within a cycle boundary. The cost is that all nodes must share cycle boundaries, so precise time synchronization is a prerequisite, and the asynchronous techniques that seek to remove this synchronization burden become the core of the scaling challenge discussed later.

B. Explicit Routes — path stability. In ordinary IP, routing protocols (OSPF, BGP) change the path depending on conditions, so micro-loops, reordering, and abrupt latency changes can occur at the moment of a path change. A DetNet flow is pinned onto a fixed explicit route (an MPLS-TE label stack or segment routing), so it is delivered along the same path regardless of changes in network state. Only when the path is fixed do per-hop resource reservation and latency computation become meaningful. In other words, the explicit route is a precondition for resource allocation.

In particular, to use replication-elimination (PREOF), the two paths must be physically disjoint, and this too is guaranteed only when explicit routes exist. If left to ordinary routing, the two replicas may share the same link or node at some segment (fate-sharing), and if that shared point fails, the redundancy collapses simultaneously. Therefore, when computing paths, the control plane must produce two paths that are as independent as possible, considering even the Shared Risk Link Group (SRLG), and this is what distinguishes DetNet path design from simple traffic engineering.

C. Service Protection — losslessness. Even if resource allocation prevents congestion loss, it cannot prevent loss due to link failures or bit errors. DetNet solves this with PREOF (Packet Replication, Elimination and Ordering Functions). The sender replicates a packet and transmits it simultaneously over two or more disjoint paths, and the receiver (or a merge node) adopts only the one that arrives first, eliminates duplicates, and reorders them. Because the probability of two paths being severed simultaneously is extremely low, seamless redundancy, in which not even the loss during failure-recovery time (tens of ms to several seconds) occurs, is realized. The important point is that this hides loss without retransmission, so it does not harm real-time behavior.

For replication and elimination to work correctly, each packet must be assigned a sequence number to identify which replicas are the same original. The elimination node remembers sequence numbers it has already seen within a certain history window and discards duplicates; if the window is too narrow, replicas with a large inter-path latency difference are not recognized as duplicates and duplicate delivery occurs, while if it is too wide, memory and latency grow. Therefore the practical point is to know the upper bound of the latency skew between the two paths and design the window accordingly. Whereas traditional retransmission (ARP/TCP) is after-the-fact recovery that "detects a loss and then retrieves it," PREOF is suitable for real-time applications in that it is proactive protection that "covers in advance, with duplicates, situations where loss would occur."

Quality objective Responsible technique Sub-layer Core mechanism
Latency bound·low jitter Resource allocation Forwarding Admission control·formal scheduler (CQF, etc.)
Path stability Explicit routes Forwarding MPLS-TE·segment routing
Lossless·uninterrupted Service protection (PREOF) Service Replication·elimination·reordering, disjoint paths

The table summarizes the three techniques, but what matters in actual design is that end-to-end determinism holds only when they are combined. Reserving resources without explicit routes makes the reservation meaningless when the path changes, and replicating without resource allocation nullifies redundancy because both paths suffer congestion loss. In other words, the three techniques are not independent options but are in a mutual-prerequisite relationship.

The four quality objectives these three techniques collectively aim to achieve are specified in RFC 8655 — ① a bound on minimum and maximum latency (bounded latency), ② bounded jitter, ③ an extremely low (effectively near-zero) packet loss rate, and ④ order preservation (in-order delivery). Notably, these objectives are qualitatively different from best-effort QoS (DiffServ prioritization). DiffServ merely sends "relatively faster" and does not promise an absolute bound. DetNet isolates and reserves resources on a per-flow basis to provide an absolute guarantee of "within such-and-such even in the worst case," and because of this, as the number of flows grows, the guaranteeable capacity is limited by admission control. In other words, DetNet is a model of "a few with certainty" rather than "everyone a little faster."

3. Detailed Operation of the Data Plane and Control Plane

DetNet is not a single protocol but an encapsulation/identification convention that rides on top of existing IP/MPLS data planes. In terms of the RFC family, with RFC 8655 (architecture) at the apex, RFC 8938 (data plane framework) defines the service/forwarding sub-layer structure, and RFC 8964 (MPLS data plane), RFC 8939 (IP data plane), and RFC 9056 (IP over MPLS) specify the concrete encapsulation for each delivery technology. The process by which a flow passes through a node, in detail, is as follows.

flowchart TD
  A["Packet reception(flow ID)"] --> B{"Is it a DetNet flow?"}
  B -->|"No"| Z["Forward to ordinary queue(best-effort)"]
  B -->|"Yes"| C["Enter service sub-layer"]
  C --> D["Replication-needed segment?"]
  D -->|"Replication node"| E["Replicate packet(send on two paths)"]
  D -->|"Merge node"| F["Eliminate duplicates·reorder"]
  E --> G["Forwarding sub-layer"]
  F --> G
  G --> H["Assign explicit-route label"]
  H --> I["Place in reserved-resource queue(admission control)"]
  I --> J["Transmit via formal scheduler(guarantee latency bound)"]

Flow identification is the first step of DetNet. In the IP data plane, flows are identified by a 6-tuple (source/destination IP, protocol, port, DSCP, flow label), and in the MPLS data plane, flows and paths are jointly specified by a label stack of an S-Label (service label) and an F-Label (forwarding label). Only identified flows receive DetNet treatment, while the rest flow into the best-effort queue as is, so DetNet can coexist on the same physical network as existing traffic. This coexistence greatly lowers the adoption cost since there is no need to lay a new dedicated network.

The choice between the two data planes depends on the operating environment. The MPLS data plane (RFC 8964) naturally overlays onto a carrier backbone that already operates MPLS-TE and pseudowires, and because it can cleanly separate service and path with a label stack, it is suited to carrier-grade determinism. The IP data plane (RFC 8939), by contrast, can identify flows using only IP header information without additional tunneling in enterprise/industrial networks that lack MPLS infrastructure, making adoption lighter. To join the two planes, RFC 9056 (IP over MPLS) provides a convention that maps IP encapsulation onto the MPLS data plane, so an end-to-end DetNet service can be configured even in realistic topologies where enterprise segments (IP) and backbone segments (MPLS) are intermixed.

The control plane decides which flow is given which route, resources, and replication structure. In environments where flows are known in advance, such as industrial networks, a fully centralized model is common, in which a central controller (a PCE or an SDN controller) looks at the entire topology and resource status, computes paths, and pushes configuration to each node via a YANG data model. This is conceptually the same as TSN's CNC (Centralized Network Configuration). A distributed control plane (RSVP-TE extensions, etc.) is also defined, so a hybrid model is used in large-scale or dynamic-flow environments. If the control plane lacks an accurate resource model (the queue, bandwidth, and latency characteristics of each node), the latency-bound computation collapses, so the success of DetNet operation hinges on precise resource modeling and the strictness of admission control.

Whether the latency bound "actually" holds must be backed not by intuition but by mathematical proof. The theoretical tool widely used for this is Network Calculus. By defining an arrival curve that upper-bounds the load each flow imposes on the network and a service curve that represents the processing capacity each node guarantees, one can derive the maximum per-hop latency and the maximum backlog (buffer requirement) through a (min-plus) operation of the two curves. For example, the latency bound when a flow shaped by a token bucket (burst b, average rate r) passes through a latency-guaranteeing server (latency T, rate R) is given in closed form as T + b/R. Summing per-hop bounds in this way and accounting for the asymmetry of replication paths determines the end-to-end bound, and this becomes the basis on which admission control judges "will accepting this flow break the existing guarantees?" Ultimately, DetNet's reliability is rooted in the consistency between the traffic contract expressed as curves and the server capacity.

4. Relationship with TSN and Application Cases

DetNet and TSN are often confused, but their operating layer and scope differ. Examining their difference from the perspective of "what is different that causes that difference" clarifies the application strategy.

Category IEEE 802.1 TSN IETF DetNet
Operating layer Layer 2 (Ethernet bridge) Layer 3 (IP/MPLS router)
Scope Single L2 subnetwork (inside a factory cell) Across routing domains·WAN·subnets
Time sync Assumes 802.1AS (gPTP) as essential Can be designed to bound without sync
Redundancy 802.1CB (FRER) PREOF
Standardization body IEEE 802.1 WG IETF DetNet WG

TSN is strong at providing microsecond-grade determinism within a single Ethernet segment but cannot cross routing boundaries. If factory buildings A and B are connected by an IP backbone, the standard architecture is to handle the interior of each building with TSN, handle the inter-building backbone with DetNet, and map the two domains. In fact, DetNet's PREOF and FRER (802.1CB) are designed to use the same "replication-elimination" principle, so they can interwork. In short, the key is the role division of TSN inside the cell, DetNet between cells.

Application cases concentrate in fields where determinism is directly tied to safety and quality. First, in power system protection relaying, differential protection between substations requires transmission of sample values (IEC 61850 SV) within a few ms and losslessness, so applying DetNet to the IP/MPLS network linking wide-area substations guarantees a latency bound and dual-path losslessness. Differential protection relaying judges the fault section by comparing current samples at both ends, so if sample latency fluctuates or one side is lost, a malfunction (false trip) can cause a wide-area blackout, making determinism a safety requirement. Second, in professional broadcast/audio (AV), tens to hundreds of channels of uncompressed media must be transmitted synchronously on a per-frame basis, so applying DetNet to the inter-studio backbone enables jitter-free stream merging. Third, in 5G fronthaul/backhaul, 3GPP and the IETF are collaborating on standardization to guarantee, with DetNet, the strict latency budget (hundreds of μs) between radio base stations (DU-CU). Fourth, in smart factories, robot and motion-control flows are delivered deterministically across the entire factory backbone, maintaining control quality even during production-line reconfiguration. Fifth, in in-vehicle and inter-vehicle (autonomous driving) networks, sensor fusion and braking control require a bound of a few ms, so TSN/DetNet principles are spreading into vehicle backbone Ethernet and V2X segments. What these cases have in common is that "the worst value matters, not the average, and loss equals an accident," and it is precisely at this point that DetNet's value is qualitatively distinguished from best-effort.

To underscore the origin of the difference once more, the divergence between TSN and DetNet stems from the addressing scheme and the state-management approach. Because TSN switches frames at L2 bridges based on MAC addresses and VLANs, it is hard to leave a single broadcast domain, and the assumption that all bridges share a common time (gPTP) is natural. DetNet, by contrast, is a world where IP/MPLS routers relay packets hop by hop, so unless the path is explicitly fixed, the flow wavers with every routing convergence. That is why DetNet comes to require the additional apparatus of "explicit routes + per-hop resource reservation," and thanks precisely to that, it gains the practical value of wide-area determinism across routing boundaries that TSN cannot provide. A designer must understand this difference to correctly judge "up to where to cover with TSN and from where to stitch in DetNet."

5. Advanced: Standardization Trends and Scaling Challenges

After the DetNet WG's early standards (RFC 8655/8938/8939/8964) stabilized the data plane and architecture, recent discussion has moved toward scaling and refinement of latency guarantees. The most active area is the standardization of queuing mechanisms to guarantee the latency bound more tightly in a mathematical sense. CQF (Cyclic Queuing and Forwarding) and its variants, as well as the ATS (Asynchronous Traffic Shaping)·TQF family of techniques that provide a bound even in asynchronous environments, are being refined on both the IEEE and IETF sides. In particular, asynchronous approaches that seek to reduce CQF's burden of requiring all nodes to share time synchronization and to provide a bounded latency even without a synchronization assumption are drawing attention as the key to large-scale network adoption.

Collaboration is also broadening on the standardization-ecosystem side. DetNet (IETF) and TSN (IEEE 802.1) have aligned the replication-elimination principle and standardized mutual mapping, and on the industrial-application side, the IEC (power, process control) and 3GPP (5G) are defining profiles that place their own latency and reliability requirements on top of DetNet/TSN. For example, 3GPP standardized a way of modeling the 5G system as a single "TSN bridge" and integrating it into an industrial TSN domain, which sketches end-to-end determinism including the wireless segment. In this way, multiple standardization bodies implementing the same determinism principle at different layers and domains and stitching their boundaries with mapping is the path by which deterministic networking matures from a fragment technology into an ecosystem.

Another axis is combination with segment routing (SRv6). Expressing explicit routes with SRv6 instead of MPLS-TE enables source routing that carries the path in the packet header without keeping state in the core, which can mitigate the scalability problem of a core router having to individually maintain the path state of a huge number of DetNet flows. However, the SRv6 header overhead and the complexity of latency computation remain challenges. Alongside this, in the Scaling DetNet (large-scale aggregation) discussion, methods are being studied to guarantee the bound by grouping thousands or tens of thousands of flows into classes or aggregates rather than managing them individually, and this is a precondition for using DetNet in carrier-grade networks. As a theoretical tool for accurate bound computation, Network Calculus is widely used, deriving per-hop and end-to-end latency bounds from the service curve and arrival curve of each node. As a matter of fact, some queuing standards and SRv6-linkage documents are still in draft stage or are evolving, so it is advisable to verify concrete figures or adoption status against the latest RFCs and drafts.

In sum, the current technical maturity of DetNet can be summarized as "the data-plane and architecture standards are stable, while queuing, scaling, and security are still evolving." Commercial adoption is already underway in small-scale closed networks (industrial, power, AV), but to scale to wide-area carrier networks and multi-operator segments, a scalable resource abstraction and an end-to-end trust model must be further refined. In a professional-engineer answer, it is advisable to describe, in this way, a distinction between how far the standard is settled and what remains open.

The relationship between DetNet and network slicing is also worth organizing. If slicing logically partitions a single physical network to isolate per-slice performance, DetNet is a finer guarantee means that gives a deterministic latency to an individual flow "inside" that slice. In other words, if slicing is macroscopic isolation, DetNet is microscopic determinism, and the two are not competitors but are layered hierarchically. A representative design is a combination that handles a specific control flow with DetNet inside a 5G URLLC slice, which shows that deterministic networking develops in tandem with the core service-quality foundation of next-generation mobile communications.

6. Considerations and Implications

From a professional-engineer perspective, adopting DetNet is not a simple protocol choice but a paradigm shift in network design, and the following must be considered comprehensively.

  • Application strategy — layered role division. Since determinism is meaningful only when it holds end-to-end, one should divide the OT cell interior into TSN and the inter-domain backbone into DetNet, and place the flow mapping and redundancy interworking (FRER↔PREOF) of the two domains at the center of design. An attempt to cover the entire span with a single technology is unrealistic. Also, because equipment using legacy industrial protocols (PROFINET, EtherNet/IP, etc.) coexists, the protocol conversion at gateways and the time-synchronization transition (domain crossing) design must be reviewed together at the initial architecture stage.

  • Trade-off — efficiency vs. guarantee. Because pre-reserving resources and replicating paths essentially means setting aside bandwidth/buffer headroom in advance, it sacrifices the efficiency of statistical multiplexing. Replication doubles the traffic. Therefore, rather than "all flows," it is cost-rational to selectively apply it only to a small number of critical flows that absolutely require determinism and let the rest coexist as best-effort.

  • Operational complexity and observability. Since the determinism guarantee depends on a precise resource model, admission control, and time synchronization (where needed), a configuration error or model inaccuracy directly leads to a collapse of the guarantee. One must also build telemetry and observability that measure and verify per-flow latency, loss, and path state in real time, so that one can prove not "it was guaranteed" but "the guarantee is being kept."

  • Design verification first. With DetNet it is hard to confirm the worst value by post-deployment measurement alone (because the worst situation rarely reproduces). Therefore, one should perform advance bound computation and capacity design based on Network Calculus before deployment, and automate admission control to re-verify the bound whenever a flow is added or the topology changes. This requires DetNet's distinctive proof-based engineering culture, which is distinguished from "measurement-based best-effort tuning."

  • Security consideration — determinism itself is an attack surface. Because reserved resources are bound to specific flows, if an attacker spoofs a flow or induces excessive flow registration, resource exhaustion (DoS) can break other guarantees. Preventing tampering of flow-identification information, authenticating and ensuring the integrity of the control plane (the controller and the YANG configuration channel), and policy-based control of reservation requests are essential, and security design must be treated with the same priority as the determinism guarantee.

  • Outlook and related technologies. DetNet is expected to establish itself as the standard foundation of the OT-IT convergence backbone, in tandem with 5G/6G ultra-low latency (URLLC), the real-time synchronization of the industrial metaverse and digital twins, and the spread of autonomous manufacturing. As organic combination with SDN, SRv6, network slicing, and TSN matures, deterministic networking is likely to expand beyond special industrial networks into general carrier services (bounded-latency SLA products). However, end-to-end guarantees across multi-operator segments carry the problem of trust boundaries and the mutual disclosure of resource models, remaining the final gate for standardization and commercialization.

References

In one line: DetNet is an IETF deterministic-networking standard that combines resource reservation, explicit routes, and packet replication (PREOF) to guarantee a latency bound and losslessness even on IP/MPLS routed networks, extending Layer 2 TSN to Layer 3 to complete end-to-end determinism of the OT-IT convergence backbone.