<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc
 xmlns:xi="http://www.w3.org/2001/XInclude"
     category="std"
     docName="draft-han-detnet-tc-dev-handling-00"
     ipr="trust200902"
     obsoletes=""
     updates=""
     submissionType="IETF"
     xml:lang="en"
     tocInclude="true"
     tocDepth="4"
     symRefs="true"
     sortRefs="true"
     version="3">

	<!-- ***** FRONT MATTER ***** -->

	<front>

		<title abbrev="Handling of traffic characteristic deviation for DetNet">Handling of traffic characteristic deviation for DetNet</title>
		<seriesInfo name="Internet-Draft" value="draft-han-detnet-tc-dev-handling-00"/>
	
		<author fullname="Zhengxin Han" initials="Z" surname="Han">
			<organization>China Unicom</organization>

			<address>
				<postal>
					<street/>
          
					<city>Beijing</city>
          
					<region/>
  
					<code/>

					<country>China</country>
				</postal>

				<phone/>

				<email>hanzx21@chinaunicom.cn</email>
			</address>
		</author>
	
		<author fullname="Chang Liu" initials="C" surname="Liu">
			<organization>China Unicom</organization>
			<address>
				<postal>
					<street/>
					<city>Beijing</city>
					<region/>
					<code/>
					<country>China</country>
				</postal>
				<phone/>
				<email>liuc131@chinaunicom.cn</email>
			</address>
		</author>
		
	
		<author fullname="Jinjie Yan" initials="J" surname="Yan">
			<organization>ZTE Corporation</organization>
			<address>
				<postal>
					<street/>
					<city/>
					<region/>
					<code/>
					<country>China</country>
				</postal>
				<phone/>
				<email>yan.jinjie@zte.com.cn</email>
			</address>
		</author>
		
		
		<author fullname="Jinoo Joung" initials="J" surname="Joung">
			<organization>Sangmyung University</organization>
			<address>
				<email>jjoung@smu.ac.kr</email>
			</address>
		</author>

		<author fullname="Ran Pang" initials="R" surname="Pang">
			<organization>China Unicom</organization>
			<address>
				<postal>
					<street/>
					<city>Beijing</city>
					<region/>
					<code/>
					<country>China</country>
				</postal>
				<phone/>
				<email>pangran@chinaunicom.cn</email>
			</address>
		</author>
	
		<author fullname="Xiangyang Zhu" initials="X" surname="ZHU">
			<organization>ZTE Corporation</organization>
			<address>
				<postal>
					<street/>
					<city/>
					<region/>
					<code/>
					<country>China</country>
				</postal>
				<phone/>
				<email>zhu.xiangyang@zte.com.cn</email>
			</address>
		</author>
	

		<area>Routing</area>
		<workgroup>DetNet</workgroup>
		<keyword/>
   
		<abstract>
   
			<t>
Deterministic Networking (DetNet) relies on resource reservation to guarantee bounded-latency forwarding, yet traffic characteristic deviations from microbursts and flow aggregation frequently occur at aggregation nodes. Native handling approaches like direct packet discard or best-effort forwarding lead to severe service degradation.
			</t>
			<t>
	This document proposes an enhanced traffic characteristic deviation  solution for DetNet.  This solution specifies two complementary data-plane policies: the squeezing policy defers deviated traffic to subsequent timeslots within a configurable threshold while preserving deterministic attributes to absorb transient bursts; the degrading policy reclassifies over-threshold traffic to lower-priority queues for graceful handling, avoiding unnecessary packet loss. These policies can be enabled independently or combined, ensuring the preferential scheduling and preservation of deterministic service traffic under deviation conditions.


	
			</t>
	  
		</abstract>
	</front>
	<middle>
		<section numbered="true" toc="default"><name>Introduction</name>
			<t>
	DetNet is capable of providing real-time application services with deterministic guarantees such as bounded latency, low jitter, and low packet loss rate, as per 				<xref target="RFC8655"/>. One of the major technologies of DetNet is resource allocation, as per <xref target="RFC8938"/>, which reserves necessary resources for specified DetNet flows to mitigate packet loss and jitter caused by network congestion. The control plane orchestrates the paths of DetNet flows to avoid resource conflicts. The data plane then transmits DetNet flows based on this orchestration result, employing mechanisms like traffic shaping, flow admission control, and forwarding information encapsulation to maintain the required QoS.
			</t>
			<t>
	In the ideal operational model, fine-grained admission control and per-hop traffic shaping strictly align incoming traffic with the reserved timeslot capacity. Even at flow aggregation nodes, conforming traffic of the same service class will not exceed the pre-allocated resource limit, thus delivering strict end-to-end deterministic guarantees.
			</t>
			<t>
	However, this ideal state is difficult to achieve in practical deployments. Traffic characteristic deviations from the reservation baseline arise at multiple layers of the network — from source traffic generation, to control plane planning, to data plane forwarding — and gradually accumulate and amplify along the path. Temporary deviations of traffic characteristics from the reservation baseline are inherent operational behaviors rather than network faults, originating from multiple sources:
			</t>
			<ul>
				<li>
		Inherent source traffic deviation forms the root cause. The DetNet resource reservation model typically relies on simplified assumptions such as fixed-length packets and uniform arrival intervals for traffic planning. In practice, however, deterministic service flows naturally have variable packet lengths and uneven arrival times. The superposition of packet length fluctuation and arrival time non-uniformity directly generates microbursts at per-hop egress queues, meaning even a single properly admitted flow may exceed the reserved capacity of its target timeslot at the instantaneous level.
				</li>
				<li>
		Admission control precision deviation acts as the key transmission link. Current mainstream DetNet admission control mechanisms usually operate at second-level time granularity and make admission decisions based on the average bandwidth of flow profiles. This coarse granularity fails to capture millisecond-level microburst characteristics embedded in traffic. As a result, flows that fully meet the average bandwidth requirement but carry inherent microbursts will be admitted into the network, and their instantaneous traffic can easily exhaust the reserved timeslot capacity when mapped to egress queues.
				</li>
				<li>
		Aggregation node superposition deviation serves as the direct trigger of severe performance degradation. Every node on the end-to-end DetNet path can act as an aggregation point where multiple independent flows share the same egress port and timeslot resources. The microbursts of individual flows may overlap in time at the aggregation node, and the superimposed instantaneous traffic will far exceed the total reserved capacity of the timeslot. In addition, network control packets such as ARP messages usually have higher scheduling priority than deterministic service packets, which will preempt reserved timeslot resources, further squeeze available forwarding capacity for service traffic, and aggravate the risk of queue overflow.
				</li>
			</ul>
			<t>
	Current industry solutions to address these challenges have clear limitations. On the control plane, over-provisioning resources based on peak traffic and deploying service protection mechanisms can offset the impact of bursts to a certain extent, but they rely on a large amount of redundant resource reservation, resulting in extremely low network resource utilization and weakening the economic value of deterministic networking. In addition, control plane re-orchestration and re-admission work on a slow time scale, which cannot respond to transient microbursts in real time. On the data plane, existing handling mechanisms for out-of-profile traffic are relatively primitive: nodes either directly discard excess packets that exceed the timeslot capacity, or buffer them until the next available scheduling cycle. Both approaches will cause severe degradation of the QoS of affected flows, and in extreme scenarios, their forwarding performance may even be inferior to that of traditional Best-Effort (BE) services.Therefore, an enhanced, automated data plane mechanism for handling traffic characteristic deviations is critical for the practical deployment of DetNet.
			</t>
			<t>
	This draft focuses on periodic queuing mechanisms as defined in				<xref target="I-D.ietf-detnet-dataplane-taxonomy"/>, a category of DetNet data plane solutions that reserve resources and schedule packets based on periodically repeated timeslots and rely on network time synchronization.
			</t>
			<t>
	This document proposes a complete traffic characteristic deviation handling solution for the DetNet data plane, which defines two complementary core policies: the squeezing policy and the degrading policy. The two policies can be enabled independently or in combination, with configurable activation thresholds and operating parameters set by the control plane or network operators.
			</t>
			<t>
	The proposed solution ensures that in-profile deterministic flows always receive priority scheduling, while temporarily deviated traffic is handled gracefully instead of being discarded directly. This mechanism minimizes packet loss caused by microbursts and aggregation superposition, realizes smooth degradation of deterministic services, and improves the overall operational robustness and resource utilization efficiency of DetNet networks.
			</t>
	
			<t>
	The rest of this document is organized as follows: Section 2 specifies the requirements language; Section 3 defines the terminology used in this document; Section 4 describes the deviation condition detection mechanism; Section 5 details the design of the two handling policies; Section 6 presents the overall solution framework and processing procedure; Section 7 provides a deployment example; and subsequent sections cover security considerations, IANA considerations and references.
			</t>

	
	
		</section>


    
		<section numbered="true" toc="default"><name>Requirements Language</name>
	  
			<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in				<xref target="RFC2119" format="default">RFC 2119</xref>.
			</t>
	   
      
		</section>
	
		<section anchor="Terminology" numbered="true" toc="default"><name>Terminology</name>
			<t>The terminology is defined as<xref target="RFC8655" pageno="false" format="default"/>.</t>
			<t>
	The following terminology is used in this document:
			</t>
			<t>
	Traffic Characteristic Deviation: A state where the actual traffic characteristics (e.g., per-period traffic volume, packet arrival rate) of a deterministic flow exceed the range corresponding to the reserved resources of the forwarding node, which may cause queue overflow under native scheduling logic.

			</t>
		</section>
	
	
		<section numbered="true" toc="default"><name>Deviation Condition Detection</name>
			<t>
	Real-time deviation detection in the data plane serves as the foundational trigger for the traffic characteristic deviation handling mechanism. It identifies per-hop forwarding states where instantaneous traffic exceeds pre-reserved resource limits, to trigger subsequent differentiated handling policies while preserving the scheduling priority of in-profile deterministic traffic.
			</t>
			<t>
	 Per-time-slot reservation parameters delivered by the control plane serve as the unified judgment baseline.
For each egress port, the control plane pre-configures the maximum authorized forwarding capacity (in bits or packets) per timeslot based on end-to-end flow reservations and network-wide slot planning. This capacity remains fixed across scheduling cycles, providing a stable reference for deviation judgment.
			</t>
			<t>
	 Detection runs per packet before enqueuing to the target timeslot:
			</t>
			<ol>
				<li>
		Target timeslot mapping: When a DetNet packet arrives, the node determines its target egress timeslot based on the timeslot identifier in the packet header and per-hop mapping rules configured by the control plane.
				</li>
				<li>
		Timeslot capacity check: The node checks the current accumulated traffic volume within the target timeslot against the reserved per-timeslot capacity budget.
				</li>
				<li>
		Deviation judgment: If enqueuing the packet does not exceed the reserved capacity, the packet is admitted normally. Otherwise, a traffic characteristic deviation condition is confirmed, the packet is marked as deviated, and the corresponding handling policy is triggered.
				</li>
			</ol>
			<t>
	Deviation detection only identifies temporary timeslot resource overrun, and does not directly execute default actions such as packet discarding. After detecting a deviation, the node processes deviated packets according to pre-configured handling policies (squeezing or degrading policy defined in this document).
			</t>
			<t>
	This design minimizes packet loss and latency degradation caused by transient microbursts, while guaranteeing the deterministic scheduling priority of in-profile traffic within the timeslot.
			</t>
	 
 
		</section>
	
	
	
		<section numbered="true" toc="default"><name>Deviated Traffic Handling Policy</name>
			<t>
	Two  handling policies are defined for deviated traffic, which can be enabled independently or in combination with configurable parameters set by the control plane:
			</t>
			<ul>
				<li>
	Squeezing Policy: Temporarily defers deviated packets to the next timeslot for transmission, while retaining their original scheduling identifiers.
				</li>
				<li>
	Degrading Policy: Redirects deviated packets to a lower-priority forwarding class and modifies their scheduling parameters when the accumulation of deviated packets exceeds a predefined threshold.
				</li>
			</ul>
			<t>
	These policies provide flexibility in activation: they can be enabled concurrently, individually, or disabled entirely. If neither policy is enabled, the default mechanism, such as discarding the packets or treating them as a BE flow, will be utilized.
			</t>
   
			<section numbered="true" toc="default"><name>Squeezing Policy</name>
	 
				<t>
	 The squeezing policy provides temporary elastic capacity for timeslot allocations to absorb transient microbursts, avoiding immediate packet loss caused by short-term traffic deviation.The squeezing threshold is a configurable parameter delivered by the control plane, which defines the maximum extra traffic volume (measured in bits or packets) that a single timeslot can accommodate beyond its reserved capacity. It acts as an elastic buffer zone between standard reservation and degrading handling: 
				</t>
				<ul>
					<li>
		It allows temporary traffic overrun within a controlled range, preserving the deterministic scheduling attribute of deviated packets as much as possible;

					</li>
					<li>
		Its value can be configured based on total link bandwidth, end-to-end service latency tolerance, and statistical characteristics of network microbursts.
					</li>
				</ul>
				<t>
	 When the accumulated traffic volume within a timeslot exceeds the reserved capacity but remains below the squeezing threshold, the system applies the squeezing policy. Specifically, the system retains the original timeslot identifier in the packet (i.e., tag retention), defers the deviated packets to a subsequent timeslot for transmission, and records the volume of squeezed traffic. Downstream nodes MAY use the retained tag to identify squeezed packets and restore their original scheduling context or reordering state.
				</t>
				<t>
	 Assume each timeslot allows 4000 bits of forwarding capacity, and the squeezing threshold is set to 2000 bits. Consider a service flow where each packet is fixed at 1000 bits: packets 1 to 4 are assigned to timeslot 1, and packets 5 to 7 are assigned to timeslot 2. Due to aggregated traffic, assume the current depth of queue 1 (corresponding to timeslot 1) is 2000 bits.
				</t>

	 
				<figure title="Squeezing policy" align="center">
					<artwork align="center"><![CDATA[
		 
|<----timeslot1---->|<----timeslot2---->|<----timeslot3---->|
+---------+---------+-------------------+-------------------+
|/////////|         |                   |                   |
+---------+---------+-------------------+-------------------+

packet sequence of the flow
+----+----+----+----+----+----+----+
| P7 | P6 | P5 | P4 | P3 | P2 | P1 |     --->                   
+----+----+----+----+----+----+----+
P1 P2 P3 P4 -> target timeslot ： 1
P5 P6 P7    -> target timeslot ： 2

				|
				\/
        +---------+----+----+----+----+
Queue 1	|/////////| P1 | P2 | P3 | P4 |                     
        +---------+----+----+----+----+
        +----+----+----+                   
Queue 2	| P5 | P6 | P7 |                          
        +----+----+----+ 

|-----timeslot1-----|-----timeslot2-----|-----timeslot3-----|
+---------+----+----+----+----+----+----+----+--------------+
|/////////| P1 | P2 | P3 | P4 | P5 | P6 | P7 |              |
+---------+----+----+----+----+----+----+----+--------------+
					|<------->|         
				 squeezing threshold
				 
					   ]]></artwork>
				</figure>
				<t>
	 Figure 1 illustrates the processing flow: Packets 1 and 2 are enqueued into Queue 1, bringing the total occupancy to 4000 bits and reaching the reserved capacity. When packets 3 and 4 arrive, they are identified as deviated packets.
				</t>
				<t>
	Since the squeezing policy is enabled with a 2000-bit threshold, packets 3 and 4  are identified as deviated. Since the squeezing policy is enabled with a 2000-bit threshold, these packets retain their original timeslot 1 identifier and are deferred to timeslot 2 for transmission. The accumulated traffic volume deferred from timeslot 1 to timeslot 2 is 2000 bits. Subsequently, packets 5, 6, and 7 (targeted for timeslot 2) arrive and enter Queue 2. When Queue 2 reaches its 4000-bit reserved capacity, packet 7 is marked as deviated, enqueued for squeezing, and transmitted in timeslot 3.
				</t>
				<t>
	 At aggregation nodes, continuous bursts may lead to successive squeezing and trigger a chain reaction. Without safeguards, packets squeezed from one timeslot to the next may accumulate indefinitely, undermining deterministic forwarding guarantees. Two safeguard mechanisms are introduced to prevent unbounded accumulation:
				</t>
				<ul>
					<li>
		Synchronization Threshold Mechanism: Defines a threshold (N) as the maximum number of consecutive timeslots permitted to be affected by squeezing. If squeezing occurs over N consecutive slots, the current queue must be resynchronized with the timeslot schedule to restore consistency and prevent unlimited delay accumulation.
					</li>
					<li>
		Exponential Decay Mechanism:  When consecutive squeezing occurs, the allowed squeezing threshold decays exponentially. Specifically, the first affected timeslot permits a predefined squeezing capacity; for each subsequent consecutive timeslot, the allowed squeezing capacity is reduced by 50% of the previous slot. Decay continues until the permitted capacity falls below the minimum packet size, at which point further squeezing is disabled and alternative handling (e.g., degrading) is triggered.
					</li>
				</ul>
	 
				<figure title="Illustration of synchronization threshold" align="center">
					<artwork align="center"><![CDATA[
		 
|----timeslot1----|----timeslot2----|----timeslot3----|----timeslot4----|
|---------queue1---------|-----queue2------|----queue3-----|---queue4---|
|<--------------------------------------------------------------------->|
                            synchronization threshold
							
		 					   ]]></artwork>
				</figure>
	 
				<figure title="Illustration of Exponential Decay Mechanism" align="center">
					<artwork align="center"><![CDATA[
		 
|----timeslot1----|----timeslot2----|----timeslot3----|----timeslot4----|
|----------queue1---------|----queue2---|----queue3-----|-----queue4----|
                  |<----->|         |<->|             |-|         
                      T              T/2              T/4
							
		 					   ]]></artwork>
				</figure>
	 
	
			</section>
	 
			<section numbered="true" toc="default"><name>Degrading Policy</name>
	 
	 
	
				<t>
	 The data plane supports the degrading policy and allows for the configuration of its parameters. This policy can be used either independently or in conjunction with the squeezing policy.


				</t>
				<ul>
					<li>
	 Combined deployment with squeezing policy: Degrading is triggered for deviated traffic that exceeds the squeezing threshold, serving as the second line of defense after squeezing.
					</li>
					<li>
	 Independent deployment: Degrading is applied directly to deviated packets that exceed the reserved timeslot capacity, without the squeezing phase.
					</li>
				</ul>
				<t>
	 Degrading is implemented by redirecting deviated packets to a lower-priority forwarding class or queue, and updating the corresponding scheduling identifier carried in the packet.
				</t>
			</section>
	 
			<section numbered="true" toc="default"><name>Combined Processing Logic</name>
				<t>
	 When both squeezing and degrading policies are enabled, the node performs hierarchical processing according to the following logic:
				</t>
				<ol>
					<li>
	  Upon packet arrival, determine whether the packet is deviated by checking the target timeslot occupancy against the reserved capacity.
					</li>
					<li>
	 If the accumulated squeezed traffic volume of the target timeslot is below the squeezing threshold, and the consecutive squeezing count has not reached the synchronization threshold or exponential decay limit, apply the squeezing policy to process the packet.
					</li>
					<li>
						<t>
	 If any of the following conditions are met, immediately trigger the degrading policy:
						</t>
						<ul>
							<li>
			The accumulated squeezed volume exceeds the squeezing threshold;
							</li>
							<li>
			Consecutive squeezing has reached the synchronization threshold;
							</li>
							<li>
			The allowed squeezing capacity after exponential decay is insufficient to accommodate the current packet.
							</li>
						</ul>
					</li>
				</ol>
	 
			</section>
   
		</section>
   
		<section numbered="true" toc="default"><name>Traffic Characteristic Deviation Handling Solution</name>
   
			<section numbered="true" toc="default"><name>Policy Selection and Configuration</name>
				<t>
	 The following deviation handling policies are defined in this document:
				</t>
				<ul>
					<li>
	  Degrading Policy: Process packets according to the degrading policy, which includes treating the packets as BE flow.
					</li>
					<li>
	  Squeezing Policy: This policy provides temporary capacity expansion to avoid data loss due to unexpected traffic.
					</li>
					<li>
	  Discarding Policy: Discard deviated packets.
					</li>
	  
				</ul>
	 
				<t>
	 If neither the squeezing nor degrading policy is enabled, deviated packets shall be processed by the default mechanism (e.g., direct discarding).When multiple policies are enabled, the processing priority shall follow the order of squeezing first, then degrading, and finally default fallback mechanisms. All policy parameters (including reserved capacity per timeslot, squeezing threshold, synchronization threshold, exponential decay coefficient, degradation level, etc.) shall be uniformly delivered by the control plane.
				</t>

	 
			</section>
	 
			<section numbered="true" toc="default"><name>Deviation Information Reporting</name>
				<t>
	 Once the data plane automatically handles deviations using the squeezing policy or the degrading policy, it should promptly report these deviation events to the controller. This enables the controller to perceive detailed insights into the network deviation conditions and take appropriate actions, such as re-orchestration, flow entry re-configuration, resource expansion. In addition to reporting to the controller, the data plane may also transmit the deviation information to the downstream nodes. This allows downstream nodes to adjust their forwarding behavior or restore the original parameters of the packets according to the received deviation information. The deviation information reported by the data plane includes, but is not limited to:
				</t>
				<ul>
					<li>
 	  Basic information: node ID, port ID, etc.
					</li>
					<li>
 	  Deviation condition information: flow ID and packet sequence number, etc.
					</li>
					<li>
						<t>
 	  Deviated traffic handling policy information: 
						</t>
						<ul>
							<li>
		 Policy Type: Specifies the handling policy employed (e.g., squeezing, degrading, or default policies like discarding).
							</li>
							<li>
								<t>
		 Related parameters: 
								</t>
								<ul>
									<li>For squeezing policy: Includes data such as the number of squeezed bits and the quantity of squeezed packets.
									</li>
									<li>For the degrading policy: Includes data such as the priority levels before and after degrading, and the number of degraded packets.
									</li>
									<li>For default policies: Includes information such as the number of discarded packets or treated as BE flows.
									</li>
								</ul>
							</li>
						</ul>
					</li>
				</ul>
			</section>
	 
			<section numbered="true" toc="default"><name>Deviated Traffic Handling Procedure</name>
				<t>
	 When a node in the data plane receives a DetNet packet, it first checks for deviation conditions. If a deviation is detected, the node proceeds to handle the packet.
				</t>
				<ol>
					<li>
	 Identify Supported Policies: The node determines which deviated traffic handling policies are supported locally. 
					</li>
					<li>
						<t>
	 Policy-based Packet Processing.
						</t>
						<ul>
							<li>
	   No Enhanced Policies Enabled: If the enhanced deviated traffic handling policies (i.e., the squeezing policy and the degrading policy) are not enabled, the deviated traffic shall be processed by the default mechanisms, such as direct discarding or treating the packets as Best-Effort (BE) flows.
							</li>
							<li>
	   Single Policy Enabled: Process the deviated packet using the enabled policy.
							</li>
							<li>
	   Both Policies Enabled: If both the squeezing policy and degrading policy are enabled, the local node first checks whether the number of deviated packets exceeds the squeezing threshold. If not, the squeezing policy is applied; otherwise, the degrading policy is applied.
							</li>
						</ul>
					</li>
					<li>

	 Information Transmission: After processing the deviated packets, the node SHOULD send the deviation information to the controller and/or the downstream node.
					</li>
				</ol>
	 
			</section>
   
   
		</section>
   
   
		<section numbered="true" toc="default"><name>Example</name>
		
			<t>
			The following example uses generic terminology for periodic queueing mechanisms. In concrete implementations, these terms map to existing mechanisms as follows. In TCQF<xref target="I-D.ietf-detnet-tcqf"/>, the cycle corresponds to the logical Timeslot, and the cycle identifier carried in the MPLS TC, IPv6 Option, or DSCP field corresponds to the Slot Tag. In TQF<xref target="I-D.ietf-detnet-packet-timeslot-mechanism"/>, the timeslot id carried in the packet header corresponds to the Slot Tag. Both mechanisms support deferring excess traffic to a subsequent logical timeslot while retaining the original tag for downstream mapping.
			</t>
			<t>
			A DetNet flow is configured with a per-timeslot capacity of 4000 bits. Background traffic occupies 3000 bits of  Queue 1. Four packets from the flow, each of 1000 bits, arrives at the ingress and is placed into  Queue 1.
			</t>
			<t>
	Processing Procedure:
			</t>
			<figure title="Example of Using the Traffic Characteristic Deviation" align="center">
				<artwork align="center"><![CDATA[
				
Queue 1
+------------+----+----+----+
|////////////| P1 | P2 | P3 |
+------------+----+----+----+
 /// : Background traffic (3000 bits, tag TS1)
 P1  : Native, tag TS1
 P2  : Squeezed, tag RETAINED = TS1
 P3  : Squeezed, tag RETAINED = TS1

BE Queue 
+-----+
| P4  |
+-----+
 P4  : Degraded

Logical Transmission Timeline
 
|<---- Timeslot 1  ---->|<---- Timeslot 2  ---->|<---- Timeslot 3  ---->|
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|/////|/////|/////| P1  | P2  | P3  |     |     |     |     |     |     |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

BE Traffic (outside deterministic slot structure)
+-----+
| P4  |  (transmitted during available link capacity gap)
+-----+   
	  
							   ]]></artwork>
			</figure>
			<ol>
				<li>
					Ingress queueing and FIFO scheduling.  Four packets arrive at the node.  
					At the Timeslot 1 boundary, the scheduler processes these packets in FIFO order against the logical capacity of Timeslot 1. After accounting for 3000 bits of background traffic, only 1000 bits remain; therefore P1 is scheduled for transmission during the Timeslot 1. The traffic in Timeslot 1 now reaches the per-timeslot capacity limit of 4000 bits.
				</li>
				<li>
					Squeezing decision for within-threshold excess with tag retention.  P2 and P3 (2000 bits) represent the excess beyond the remaining logical capacity of Timeslot 1. The cumulative excess (2000 bits) does not exceed the configured squeeze_threshold. The Squeezing Policy is triggered; these packets are retained in Queue 1. They are scheduled for transmission during the Timeslot 2.
				</li>
				<li>
				
					Degrading decision for beyond-threshold excess.  P4 (1000 bits) causes the cumulative excess traffic for Timeslot 1 to reach 3000 bits, which exceeds the squeeze_threshold.  The Degrading Policy is triggered; P4 is removed from Queue 1 and reclassified to the BE Queue. 
				</li>
				
			</ol>
		</section>
   
   
		<section numbered="true" toc="default"><name>Security Considerations</name>
			<t>TBA</t>
		</section>
		<section numbered="true" toc="default"><name>IANA Considerations</name>
			<t>TBA</t>
		</section>
		<section numbered="true" toc="default"><name>Acknowledgements</name>
			<t>TBA</t>
		</section>
   
	</middle>
  
	<!--  *****BACK MATTER ***** -->

	<back>
 
		<references>
			<name>References</name>
			<references>
				<name>Normative References</name>
				<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
				<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
				<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"/>
		
		
			
				<reference anchor="I-D.ietf-detnet-dataplane-taxonomy" target="https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dataplane-taxonomy-05">
					<front>
						<title>Dataplane Enhancement Taxonomy</title>
						<author initials="J." surname="Joung" fullname="Jinoo Joung">
							<organization>Sangmyung University</organization>
						</author>
						<author initials="X." surname="Geng" fullname="Xuesong Geng">
							<organization>Huawei</organization>
						</author>
						<author initials="S." surname="Peng" fullname="Shaofu Peng">
							<organization>ZTE Corporation</organization>
						</author>
						<author initials="T. T." surname="Eckert" fullname="Toerless Eckert">
							<organization>Futurewei Technologies</organization>
						</author>
						<date month="January" day="8" year="2026"/>
						<abstract>
							<t>This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also mentioned. Reference topologies for evaluation of the solutions are given as well.</t>
						</abstract>
					</front>
					<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-dataplane-taxonomy-05"/>
				</reference>
        
 	
			</references>
			<references>
				<name>Informative References</name>
				<reference anchor="I-D.ietf-detnet-tcqf" target="https://datatracker.ietf.org/doc/html/draft-ietf-detnet-tcqf-00">
<front>
<title>Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets</title>
<author initials="T. T." surname="Eckert" fullname="Toerless Eckert">
<organization>Futurewei Technologies USA</organization>
</author>
<author initials="Y." surname="Li" fullname="Yizhou Li">
<organization>Huawei Technologies</organization>
</author>
<author initials="S." surname="Bryant" fullname="Stewart Bryant">
<organization>University of Surrey ICS</organization>
</author>
<author initials="A. G." surname="Malis" fullname="Andrew G. Malis">
<organization>Malis Consulting</organization>
</author>
<author initials="J." surname="Ryoo" fullname="Jeong-dong Ryoo">
<organization>ETRI</organization>
</author>
<author initials="P." surname="Liu" fullname="Peng Liu">
<organization>China Mobile</organization>
</author>
<author initials="G." surname="Li" fullname="Guangpeng Li">
<organization>Huawei Technologies</organization>
</author>
<author initials="S." surname="Ren" fullname="Shoushou Ren">
<organization>Huawei Technologies</organization>
</author>
<date month="January" day="16" year="2026"/>
<abstract>
<t> This memo specifies a forwarding method for bounded latency and bounded jitter for Deterministic Networks and is a variant of the IEEE TSN Cyclic Queuing and Forwarding (CQF) method. Tagged CQF (TCQF) supports more than 2 cycles and indicates the cycle number via an existing or new packet header field called the tag to replace the cycle mapping in CQF which is based purely on synchronized reception clock. This memo standardizes TCQF as a mechanism independent of the tagging method used. It also specifies tagging via the (1) the existing MPLS packet Traffic Class (TC) field for MPLS packets, (2) the IP/IPv6 DSCP field for IP/IPv6 packets, and (3) a new TCQF Option header for IPv6 packets. Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations as well as low accuracy clock synchronization. </t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-tcqf-00"/>
</reference>


<reference anchor="I-D.ietf-detnet-packet-timeslot-mechanism" target="https://datatracker.ietf.org/doc/html/draft-ietf-detnet-packet-timeslot-mechanism-01">
<front>
<title>Timeslot Queueing and Forwarding Mechanism</title>
<author initials="S." surname="Peng" fullname="Shaofu Peng">
<organization>ZTE</organization>
</author>
<author initials="P." surname="Liu" fullname="Peng Liu">
<organization>China Mobile</organization>
</author>
<author initials="K." surname="Basu" fullname="Kashinath Basu">
<organization>Oxford Brookes University</organization>
</author>
<author initials="A." surname="Liu" fullname="Aihua Liu">
<organization>ZTE</organization>
</author>
<author initials="D." surname="Yang" fullname="Dong Yang">
<organization>Beijing Jiaotong University</organization>
</author>
<author initials="G." surname="Peng" fullname="Guoyu Peng">
<organization>Beijing University of Posts and Telecommunications</organization>
</author>
<author initials="J." surname="Zhao" fullname="Junfeng Zhao">
<organization>CAICT</organization>
</author>
<date month="June" day="27" year="2026"/>
<abstract>
<t> IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS. This document describes a generic time division multiplexing scheme for layer-3 in an IP/MPLS networks, called timeslot queueing and forwarding (TQF) mechanism. TQF is an enhancement based on TSN TAS and allows the data plane to create a flexible timeslot mapping based on available timeslot resources. It defines a cyclic period consisting of multiple timeslots where a flow is assigned to be transmitted within one or more dedicated timeslots. The objective of TQF is to better handle large scaling requirements. </t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-packet-timeslot-mechanism-01"/>
</reference>
				
        
 	
			</references>
		</references>
 
	</back>
</rfc>
