<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-xiong-detnet-data-fields-edp-02" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 -->
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <title abbrev="Data Fields for DetNet Enhanced Data Plane">Data Fields for DetNet Enhanced Data Plane</title>
    <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-data-fields-edp-02"/>
    <author fullname="Quan Xiong" initials="Q" surname="Xiong">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street>No.6 Huashi Park Rd</street>
          <city>Wuhan</city>
          <region>Hubei</region>
          <code>430223</code>
          <country>China</country>
        </postal>
        <phone/>
        <email>xiong.quan@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Aihua Liu" initials="A" surname="Liu">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone/>
        <email>liu.aihua@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Rakesh Gandhi" initials="R" surname="Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Canada</country>
        </postal>
        <phone/>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author fullname="Dong Yang" initials="D" surname="Yang">
      <organization>Beijing Jiaotong University</organization>
      <address>
        <postal>
          <street/>
          <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone/>
        <email>dyang@bjtu.edu.cn</email>
      </address>
    </author>
    <date year="2024"/>
    <area>Routing</area>
    <workgroup>DETNET</workgroup>
    <keyword/>
    <abstract>
      <t>The DetNet-specific metadata should be carried in enhanced data plane
	based on the enhancement requirements. This document proposes the common 
	DetNet data fields and option types such as Aggregation Option and 
	Deterministic Latency Option. The common DetNet Data-Fields can be
	encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 
	networks.</t>
    </abstract>
  </front>
  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>According to <xref target="RFC8655" format="default"/>, Deterministic Networking 
	(DetNet) operates at the IP layer and delivers service which provides 
	extremely low data loss rates and bounded latency within a network domain. 
    DetNet data planes has been specified in <xref target="RFC8938" format="default"/>.
	As described in <xref target="RFC9320" format="default"/>, the end-to-end bounded 
	latency depends on the value of queuing delay bound along with the 
	queuing mechanisms. Multiple queuing mechanisms has been proposed to 
	guarantee the bounded latency in IEEE802.1 TSN (Time-Sensitive Networking) 
	Task Group. But the existing deterministic technologies are facing 
	large-scale number of nodes and long-distance transmission, 
	traffic scheduling, dynamic flows, and other controversial issues in 
	large-scale networks. The DetNet Enhanced Data Plane (EDP)is required to 
	support a data plane method of flow identification and packet treatment.</t>
      <t><xref target="I-D.ietf-detnet-dataplane-taxonomy" format="default"/>
	has discussed the data plane enhancement solutions and queuing
	mechanisms in DetNet, and also described the classification 
	criteria and the suitability of the solutions for various 
	services. For scaling networks, <xref target="I-D.ietf-detnet-scaling-requirements" format="default"/> 
	has described the enhancement requirements for DetNet enhanced 
	data plane, such as aggregated flow identification and deterministic
	latency guarantees. For example, the flow identification with 
	service-level aggregation and explicit aggregated flow identification
	should be supported. And queuing mechanisms and solutions require
	different information to be defined as the DetNet-specific metadata 
	to help the functions of ensuring deterministic latency, including 
	regulation, queue management, etc. </t>
      <t>This document discusses the specific metadata which should be 
	carried in enhanced data plane and proposes the common DetNet data 
	fields and option types such as Aggregation Option and Deterministic
	Latency Option. The common DetNet Data-Fields can be encapsulated
	into a variety of protocols such as MPLS, IPv6 and SRv6 networks.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Conventions used in this document</name>
      <section numbered="true" toc="default">
        <name>Terminology</name>
        <t>The terminology is defined as <xref target="RFC8655" format="default"/>, <xref target="RFC8938" format="default"/>
	and <xref target="I-D.ietf-detnet-scaling-requirements" format="default"/>.</t>
        <t>Deterministic Latency (DL): The bound of network latency and delay
    variation between two DetNet endpoints.</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", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in BCP
    14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when,
    and only when, they appear in all capitals, as shown here.</t>
        <t>Abbreviations and definitions used in this document:</t>
        <dl newline="false" spacing="normal" indent="15" pn="section-2-3">
          <dt>SRH:</dt>
          <dd>Segment Routing Header</dd>
          <dt>SRv6:</dt>
          <dd>Segment Routing for IPv6 forwarding plane</dd>
          <dt>DL:</dt>
          <dd>Deterministic Latency</dd>
          <dt>CSQF:</dt>
          <dd>Cycle Specified Queuing and Forwarding</dd>
          <dt>TQF:</dt>
          <dd>Timeslot Queuing and Forwarding</dd>
          <dt>C-SCORE:</dt>
          <dd>Work Conserving Stateless Core Fair Queuing</dd>
          <dt>EDF:</dt>
          <dd>Earliest Deadline First</dd>
          <dt>TAS:</dt>
          <dd>Time Aware Shaper</dd>
          <dt>ATS:</dt>
          <dd>Asynchronous Traffic Shaping</dd>
          <dt>CQF:</dt>
          <dd>Cyclic Queuing and Forwarding</dd>
          <dt>FQ:</dt>
          <dd>Fair Queuing</dd>
          <dt>TSN:</dt>
          <dd>Time-Sensitive Networking</dd>
          <dt>ECQF:</dt>
          <dd>Enhanced Cyclic Queuing and Forwarding</dd>
          <dt>gLBF:</dt>
          <dd>guaranteed Latency Based Forwarding</dd>
          <dt>PDV:</dt>
          <dd>Packet Delay-Variation</dd>
          <dt>EDP:</dt>
          <dd>DetNet Enhanced Data Plane</dd>
        </dl>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Specific Metadata for DetNet Enhanced Data Plane</name>
      <section numbered="true" toc="default">
        <name>Aggregation-based Metadata</name>
        <t>As per <xref target="RFC8655" format="default"/>, 
   the DetNet data plane must support the aggregation of DetNet flows 
   in order to support larger numbers of DetNet flows and improve 
   scalability by reducing the per-hop states. And the flow aggregation
   may be necessary for scaling networks. As per <xref target="I-D.ietf-detnet-scaling-requirements" format="default"/>, 
   the deterministic services may demand different deterministic QoS
   requirements according to different levels of application requirements. 
   For example, industrial applications may demand tight jitter, strict
   latency limit requirements. The video applications may demand relative
   loose latency requirements and so on. The flow identification with 
   service-level aggregation and explicit aggregated flow identification
   should be supported.</t>
        <t>The flow identification is required to be dynamic and simplified to
   ensure the aggregated flows have compatible DetNet flow-specific QoS
   characteristics. In DetNet MPLS, A-Label defined as per <xref target="RFC8964" format="default"/>
   can be added explicitly to the packets. But in other DetNet data plane,
   no aggregated flow specific information is available. And for the data 
   plane, individual flows may be aggregated for treatment based on shared
   service specification on aggregated-class level which identified by an
   aggregation class as per <xref target="I-D.xiong-detnet-flow-aggregation" format="default"/>. 
   The aggregation-based metadata should be defined as the DetNet-specific
   metadata for DetNet enhanced data plane. The DetNet nodes along 
   the path can identify the aggregated flow to achieve the end-to-end QoS
   in scaling networks.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Deterministic Latency Metadata</name>
        <t>As described in <xref target="RFC9320" format="default"/>, the end-to-end 
	bounded latency depends on the queuing delay bound and the queuing
	mechanisms. Multiple queuing mechanisms have been proposed such as
	TAS [IIEEE802.1Qbv], CBS [IEEE802.1Q-2014],ATS [IEEE802.1Qcr], 
    CQF [IEEE802.1Qch] and so on.</t>
        <t>In scaling networks which has large variation in latency among 
	hops, great number of flows and multiple domains, 
	<xref target="I-D.ietf-detnet-scaling-requirements" format="default"/>
	has described the technical requirements for enhanced data plane
	solutions. Many variations and extensions of queuing mechanisms 
	have been proposed to resolve the scalability issues in DetNet. 
	<xref target="I-D.ietf-detnet-dataplane-taxonomy" format="default"/>
	has described the classification criteria of the solutions.
	As shown in Figure 1, the CQF variations for cyclic-based scheduling 
	includes the ECQF [IEEE 802.1Qdv], Multi-CQF <xref target="I-D.dang-queuing-with-multiple-cyclic-buffers" format="default"/>,
	TCQF <xref target="I-D.eckert-detnet-tcqf" format="default"/> and 
	CSQF <xref target="I-D.chen-detnet-sr-based-bounded-latency" format="default"/>.
	The TAS variations for timeslot-based scheduling includes TQF 
	<xref target="I-D.peng-detnet-packet-timeslot-mechanism" format="default"/>.
	The FQ variations for rate-based scheduling includes C-SCORE <xref target="I-D.joung-detnet-stateless-fair-queuing" format="default"/>
	ATS [IEEE802.1Qcr] and gLBF <xref target="I-D.eckert-detnet-glbf" format="default"/>.
	The EDF variations for deadline-based scheduling includes
    EDF<xref target="I-D.peng-detnet-deadline-based-forwarding" format="default"/> and Local Deadline <xref target="I-D.stein-srtsn" format="default"/>.
	The Damper variations for damper-based scheduling includes 
	Damper <xref target="I-D.mohammadpour-detnet-bounded-delay-variation" format="default"/>
	and gLBF <xref target="I-D.eckert-detnet-glbf" format="default"/>.</t>
        <figure>
          <name>Queuing and Scheduling Mechanisms</name>
          <artwork align="center" name="Type" type="" alt=""><![CDATA[
      
+---------------------------------------------------------------------------------------------+
| Scheduling Type         | Queuing Type        | Queuing Mechanisms     |  Metadata          |
+---------------------------------------------------------------------------------------------+
|Cyclic-based scheduling  |CQF and variations   |CSQF/TCQF/Multi-CQF/ECQF|Cycle Information   |
+---------------------------------------------------------------------------------------------+
|Timeslot-based scheduling|TAS and variations   |TQF                     |Timeslot Information|
+---------------------------------------------------------------------------------------------+
|Deadline-based scheduling|EDF and variations   |EDF/Local Deadline      |Deadline Information|
+---------------------------------------------------------------------------------------------+
|Rate-based scheduling    |FQ and variations    |C-SCORE/ATS/gLBF        |Ratio Information   |
+---------------------------------------------------------------------------------------------+
|Damper-based scheduling  |Damper and variations|Damper/gLBF             |Damper Information  |
+---------------------------------------------------------------------------------------------+	

			 
			     ]]></artwork>
        </figure>
        <t>And when queuing mechanisms used in large-scale networks,
    the per-flow states can not be maintained with scalability issues.
	Some queuing parameters should be carried for coordination between 
	nodes so as to make appropriate packet forwarding and scheduling 
	decisions to meet the time bounds. As per <xref target="I-D.ietf-detnet-scaling-requirements" format="default"/>,
	the information used by functions ensuring deterministic
    latency should be supported as such queuing-based information.
	And queuing mechanisms and solutions require different information
	to help the functions of ensuring deterministic latency, including 
	regulation, queue management. The deterministic latency metadata 
	should be defined as the DetNet-specific metadata for DetNet 
	enhanced data plane. The DetNet forwarding nodes along the 
	path can apply the queuing mechanisms and get the related 
	deterministic latency metadata in the packet to achieve the
	end-to-end bounded latency.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Data Fields for DetNet Enhanced Data Plane</name>
      <section numbered="true" toc="default">
        <name>DetNet Option-Types and Data-Fields</name>
        <t>The enhanced functions and related metadata for DetNet should be
   confirmed before the encapsulations. While more than one metadata should
   be carried in enhanced data plane, the common DetNet header should be 
   considered to cover all option-types and data. </t>
        <figure>
          <name>DetNet Header for Enhanced Data Plane</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DetNet-Type   | DetNet-Length |         RESERVED              |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   ~                 DetNet Option and Data Space                  ~   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			 
			     ]]></artwork>
        </figure>
        <t>DetNet-Type:  8-bit unsigned integer, defining the DetNet Option-type
   for enhanced DetNet. This document defines two options and option-types:</t>
        <t>Aggregation Option as defined in section 5. </t>
        <t>Deterministic Latency Option as defined in section 6. </t>
        <t>DetNet-Length: 8-bit unsigned integer, defined the Length of the DetNet 
   Header 4-octet units.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Aggregation Option</name>
      <figure>
        <name>Aggregation Option Header</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Aggregation  Type        |       Flag  |E|   Data Len    | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			 
			     ]]></artwork>
      </figure>
      <t>Aggregation type(16 bits): indicates the aggregation type of 
	packet treatment ensuring the deterministic latency as following 
	shown. This type can also indicate the aggregated class.</t>
      <figure>
        <name>Aggregation Type </name>
        <artwork align="center" name="Type" type="" alt=""><![CDATA[

        
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Value |         Aggregation Type            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0000 |  Reserved                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0100 |  Bandwidth guarantee                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0200 |  Jitter guarantee                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0300 |  Delay guarantee                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0400 |  Low delay and jitter guarantee     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0500 |Ultra-low delay and jitter guarantee |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		
		]]></artwork>
      </figure>
      <t keepWithPrevious="true"/>
      <t>Flag: 8-bit flags field. When E is set to 1, it indicates the
	explicit aggregated flow identification. The related option
    data is defined as following section.</t>
      <t>Data Len:8-bit unsigned integer. Length of option data, in octets. </t>
      <figure>
        <name>Aggregation Option Data</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Aggregation ID                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              End-to-end Delay Budget                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              End-to-end Delay Variation Budget                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			 
			     ]]></artwork>
      </figure>
      <t>Aggregation ID: 32bits. It provides explicit and unique identifier
   for aggregated flow identification. DetNet nodes performing aggregation
   using aggregation ID.</t>
      <t>End-to-end Delay Budget: 32bits. It provides the value of end-to-end 
   delay budget for the aggregated flow.</t>
      <t>End-to-end Delay Variation Budget: 32bits. It provides the value of
   end-to-end delay variation budget for the aggregated flow.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Deterministic Latency Option</name>
      <t>The DetNet Deterministic Latency Option carries data that is added
   by the DetNet encapsulating node and interpreted by the decapsulating
   node. The DetNet transit nodes MAY process the data by forwarding the
   option data determined by option type and may modify it. The DetNet 
   Deterministic Latency Option consist of a fixed-size "Deterministic 
   Latency Option Header" and a variable-size "Deterministic Latency 
   Option Data". The Header and Data may be encapsulated continuously 
   or separately. A Data or more than one Data in lists can be carried 
   in packets.</t>
      <section numbered="true" toc="default">
        <name>Deterministic Latency Option Header</name>
        <t>DetNet Deterministic Latency Option header:</t>
        <figure>
          <name>Deterministic Latency Option header</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Deterministic Latency Type    |   Flag        |   Data Len    | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			 
			     ]]></artwork>
        </figure>
        <t>Deterministic Latency Type(16 bits): indicates the type of 
   deterministic latency information and related queuing and scheduling
   metadata.</t>
        <figure>
          <name>Deterministic Latency Type</name>
          <artwork align="center" name="Type" type="" alt=""><![CDATA[
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Value  |  Deterministic Latency Type        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0000  |  Unassigned                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0001  |  Cycle Information                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0002  |  Timeslot Information              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0003  |  Deadline Information              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0004  |  Ratio Information                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0005  |  Damper Information                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+					 
			     ]]></artwork>
        </figure>
        <t>Flag: 8-bit flags field.</t>
        <t>Data Len: 8-bit unsigned integer. Length of option data, in octets. </t>
      </section>
      <section numbered="true" toc="default">
        <name>Deterministic Latency Option Data</name>
        <t>DetNet Deterministic Latency Action option data MUST be aligned by 4 octets:</t>
        <figure>
          <name>Deterministic latency Option Data Field</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~     Deterministic latency option data field (variable)        ~     
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			 
			     ]]></artwork>
        </figure>
        <t>Deterministic latency option data: Variable-length field. 
   It provides function-based or queuing-based information for a node 
   to forward a DetNet flow. The data of which is determined by the 
   deterministic latency type. The DetNet option data can be provided
   one time or in list. The examples of different types of data is as
   following sections shown.</t>
        <section numbered="true" toc="default">
          <name>Cycle Information</name>
          <t>When the type is set to 0x0001, indicates the Cyclic-based queuing
   and scheduling solutions. The cycle information may be carried and designed
   as following shown:</t>
          <figure>
            <name>Cycle Information</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
   
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Cycle Profile ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Cycle ID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   		]]></artwork>
          </figure>
          <t>Cycle Profile ID (32bits): indicates the profile ID which the 
	cyclic queue applied at a node.</t>
          <t>Cycle ID (32bits): indicates the Cycle ID for a node to 
	forward a DetNet flow.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Timeslot Information</name>
          <t>When the type is set to 0x0002, indicates the timeslot-based 
	queuing and scheduling solutions. The timeslot information may 
	be carried and designed as follow:</t>
          <figure>
            <name>Timeslot Information</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
 	
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Timeslot ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    		]]></artwork>
          </figure>
          <t>Timeslot ID: indicates the identifier of the timeslot as defined in <xref target="I-D.peng-detnet-packet-timeslot-mechanism" format="default"/>.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Deadline Information</name>
          <t>When the type is set to 0x0003, indicates the deadline-based 
	queuing and scheduling solutions. The deadline information may 
	be carried and designed as follow:</t>
          <figure>
            <name>Deadline Information</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
 	
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags |M|D|  Planned Deadline/Local Deadline              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Accumulated Planned Deadline / Accumulated Deadline Deviation |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Accumulated Actual Residence Time / Reserved         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
 
    		]]></artwork>
          </figure>
          <t>Planned and deadline Deviation has been provided as defined in
	<xref target="I-D.peng-6man-deadline-option" format="default"/>.
	Local deadline has been proposed in <xref target="I-D.stein-srtsn" format="default"/>.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Ratio Information</name>
          <t>When the type is set to 0x0004, indicates the rate-based 
	queuing and scheduling solutions. The ratio information may 
	be carried and designed as follow:</t>
          <figure>
            <name>Ratio Information</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
 	
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Maximum packet size                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Service rate                         |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    		]]></artwork>
          </figure>
          <t>Maximum packet size and service rate has been described as per
	C-SCORE <xref target="I-D.joung-detnet-stateless-fair-queuing" format="default"/>
	which the latency bound is primarily influenced by the ratio of a 
	flow's maximum packet size to its allocated service rate.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Damper Information</name>
          <t>When the type is set to 0x0005, indicates the damper-based 
	queuing and scheduling solutions. The damper information may 
	be carried and designed as follow:</t>
          <figure>
            <name>Damper Information</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
 	
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Timestamp                             |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Budget delay                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    		]]></artwork>
          </figure>
          <t>Damper information such as timestamps and budget delay should be
	carried to compute the compensate PDV by means of dampers as per
	<xref target="I-D.mohammadpour-detnet-bounded-delay-variation" format="default"/>.</t>
        </section>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Encapsulation Considerations for DetNet Enhanced Data Plane</name>
      <section numbered="true" toc="default">
        <name>Metadata for DetNet Enhanced Data Plane</name>
        <t>The packet treatment should indicate the behaviour action ensuring 
	the deterministic latency at DetNet nodes such as queuing-based 
	mechanisms. The deterministic latency action type and related parameters
	such as queuing-based information should be carried as metadta in data plane. 
	And the definitions may follow these polices. </t>
        <t>The data plane enhancement must be generic and the format must be 
	applied to all functions and queuing mechanisms. The metadata and 
	definitions should be common among different candidate queuing solutions.</t>
        <t>Information and metadata MUST be simplified and limited to be carried
	in DetNet packets for provided deterministic latency related scheduling 
	along the forwarding path. For example, the queuing-based information
	should be carried in metadata for coordination between nodes.</t>
        <t>The requirement of the flow or service may be not suitable to be carried explicitly
	in DetNet data plane. The packet treatment should schedule the resources and indicate the 
	behaviour to ensure the deterministic latency in forwarding sub-layer. So the queuing 
	mechanisms could be viewed as a type of deterministic resources. The resources type and
	queuing type should be explicitly indicated.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Encoding for DetNet Enhanced Data Plane</name>
        <t>DetNet needs to encode specific aggregated flow and deterministic 
    latency	metadata in packets by reusing the existing fields or new
	fields.</t>
        <section numbered="true" toc="default">
          <name>Reuse of the Existing DSCP/TC Field</name>
          <t>Reusing the DSCP or existing field is reasonable and simple 
	to define and easy to standardize. For example, in IPv4 and 
	traditional MPLS networks, it is not suitable to carry new metadata 
	and it is suggested to reuse the original bits such as DSCP <xref target="I-D.eckert-detnet-tcqf" format="default"/>. 
	The mapping from DSCP and the metadata such as queuing information MUST 
	be provided in the controller plane.</t>
        </section>
        <section numbered="true" toc="default">
          <name>New Common Data Fields</name>
          <t>DSCP value may be not sufficient and hard to distinguish 
	between the original DiffServ service and the deterministic service.
	The DetNet-specific metadata can also be encoded as a common data fields 
	and the definition of data fields is independent from the encapsulating 
	protocols. The data fields could be encapsulated into a variety of 
	protocols, such as MPLS 2.0 <xref target="I-D.sxg-mpls-mna-deterministic-latency" format="default"/>, 
	IPv6 <xref target="I-D.xiong-detnet-6man-queuing-option" format="default"/>, 
	SRv6 <xref target="I-D.xiong-detnet-spring-srh-extensions" format="default"/> and so on. </t>
        </section>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Security considerations for DetNet are covered in the DetNet
   Architecture <xref target="RFC8655" format="default"/> and DetNet data plane
   <xref target="RFC8938" format="default"/>, <xref target="RFC8939" format="default"/>, 
   <xref target="RFC8964" format="default"/> and DetNet security considerations
   <xref target="RFC9055" format="default"/>. The security considerations 
   specified in <xref target="I-D.ietf-detnet-scaling-requirements" format="default"/> are also
   applicable to the procedures defined in this document.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has defined a registry group named "DetNet Data Fields".
   This group includes the DetNet Option-Type registry. 
   This registry defines code points for the DetNet 
   Option-Type field for identifying DetNet-Option-Types. 
   The following code points are defined in this document:</t>
      <t>TBD1:  DetNet Aggregation Option-Type</t>
      <t>TBD2:  DetNet Deterministic Latency Option-Type</t>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to acknowledge Peng Liu, Bin Tan for his thorough
    review and very helpful comments.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>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.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>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.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC8655" target="https://www.rfc-editor.org/info/rfc8655" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml">
        <front>
          <title>Deterministic Networking Architecture</title>
          <author fullname="N. Finn" initials="N." surname="Finn"/>
          <author fullname="P. Thubert" initials="P." surname="Thubert"/>
          <author fullname="B. Varga" initials="B." surname="Varga"/>
          <author fullname="J. Farkas" initials="J." surname="Farkas"/>
          <date month="October" year="2019"/>
          <abstract>
            <t>This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8655"/>
        <seriesInfo name="DOI" value="10.17487/RFC8655"/>
      </reference>
      <reference anchor="RFC8938" target="https://www.rfc-editor.org/info/rfc8938" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane Framework</title>
          <author fullname="B. Varga" initials="B." role="editor" surname="Varga"/>
          <author fullname="J. Farkas" initials="J." surname="Farkas"/>
          <author fullname="L. Berger" initials="L." surname="Berger"/>
          <author fullname="A. Malis" initials="A." surname="Malis"/>
          <author fullname="S. Bryant" initials="S." surname="Bryant"/>
          <date month="November" year="2020"/>
          <abstract>
            <t>This document provides an overall framework for the Deterministic Networking (DetNet) data plane. It covers concepts and considerations that are generally common to any DetNet data plane specification. It describes related Controller Plane considerations as well.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8938"/>
        <seriesInfo name="DOI" value="10.17487/RFC8938"/>
      </reference>
      <reference anchor="RFC2212" target="https://www.rfc-editor.org/info/rfc2212" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2212.xml">
        <front>
          <title>Specification of Guaranteed Quality of Service</title>
          <author fullname="S. Shenker" initials="S." surname="Shenker"/>
          <author fullname="C. Partridge" initials="C." surname="Partridge"/>
          <author fullname="R. Guerin" initials="R." surname="Guerin"/>
          <date month="September" year="1997"/>
          <abstract>
            <t>This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2212"/>
        <seriesInfo name="DOI" value="10.17487/RFC2212"/>
      </reference>
      <reference anchor="RFC9320" target="https://www.rfc-editor.org/info/rfc9320" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9320.xml">
        <front>
          <title>Deterministic Networking (DetNet) Bounded Latency</title>
          <author fullname="N. Finn" initials="N." surname="Finn"/>
          <author fullname="J.-Y. Le Boudec" initials="J.-Y." surname="Le Boudec"/>
          <author fullname="E. Mohammadpour" initials="E." surname="Mohammadpour"/>
          <author fullname="J. Zhang" initials="J." surname="Zhang"/>
          <author fullname="B. Varga" initials="B." surname="Varga"/>
          <date month="November" year="2022"/>
          <abstract>
            <t>This document presents a timing model for sources, destinations, and Deterministic Networking (DetNet) transit nodes. Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods. The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9320"/>
        <seriesInfo name="DOI" value="10.17487/RFC9320"/>
      </reference>
      <reference anchor="RFC8964" target="https://www.rfc-editor.org/info/rfc8964" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane: MPLS</title>
          <author fullname="B. Varga" initials="B." role="editor" surname="Varga"/>
          <author fullname="J. Farkas" initials="J." surname="Farkas"/>
          <author fullname="L. Berger" initials="L." surname="Berger"/>
          <author fullname="A. Malis" initials="A." surname="Malis"/>
          <author fullname="S. Bryant" initials="S." surname="Bryant"/>
          <author fullname="J. Korhonen" initials="J." surname="Korhonen"/>
          <date month="January" year="2021"/>
          <abstract>
            <t>This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8964"/>
        <seriesInfo name="DOI" value="10.17487/RFC8964"/>
      </reference>
      <reference anchor="RFC9055" target="https://www.rfc-editor.org/info/rfc9055" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml">
        <front>
          <title>Deterministic Networking (DetNet) Security Considerations</title>
          <author fullname="E. Grossman" initials="E." role="editor" surname="Grossman"/>
          <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
          <author fullname="A. Hacker" initials="A." surname="Hacker"/>
          <date month="June" year="2021"/>
          <abstract>
            <t>A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e., "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties.</t>
            <t>This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection.</t>
            <t>This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9055"/>
        <seriesInfo name="DOI" value="10.17487/RFC9055"/>
      </reference>
      <reference anchor="RFC8939" target="https://www.rfc-editor.org/info/rfc8939" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane: IP</title>
          <author fullname="B. Varga" initials="B." role="editor" surname="Varga"/>
          <author fullname="J. Farkas" initials="J." surname="Farkas"/>
          <author fullname="L. Berger" initials="L." surname="Berger"/>
          <author fullname="D. Fedyk" initials="D." surname="Fedyk"/>
          <author fullname="S. Bryant" initials="S." surname="Bryant"/>
          <date month="November" year="2020"/>
          <abstract>
            <t>This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938).</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8939"/>
        <seriesInfo name="DOI" value="10.17487/RFC8939"/>
      </reference>
      <reference anchor="I-D.xiong-detnet-6man-queuing-option" target="https://datatracker.ietf.org/doc/html/draft-xiong-detnet-6man-queuing-option-05" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.xiong-detnet-6man-queuing-option.xml">
        <front>
          <title>IPv6 Option for DetNet Data Fields</title>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Junfeng Zhao" initials="J." surname="Zhao">
            <organization>CAICT</organization>
          </author>
          <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
            <organization>Cisco Systems, Inc.</organization>
          </author>
          <date day="12" month="October" year="2023"/>
          <abstract>
            <t>The DetNet data fields defined in Deterministic Latency Action (DLA) can be used in enhanced Deterministic Networking (DetNet) to provide QoS treatment to achieve deterministic latency. This document defines how DetNet data fields are encapsulated in IPv6 option.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-6man-queuing-option-05"/>
      </reference>
      <reference anchor="I-D.sxg-mpls-mna-deterministic-latency" target="https://datatracker.ietf.org/doc/html/draft-sxg-mpls-mna-deterministic-latency-00" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.sxg-mpls-mna-deterministic-latency.xml">
        <front>
          <title>MPLS Network Action for Deterministic Latency</title>
          <author fullname="Xueyan Song" initials="X." surname="Song">
            <organization>ZTE Corp.</organization>
          </author>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corp.</organization>
          </author>
          <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
            <organization>Cisco Systems, Inc.</organization>
          </author>
          <date day="28" month="May" year="2024"/>
          <abstract>
            <t>This document specifies formats and principles for the MPLS Network Action for Deterministic Latency to provide guaranteed latency services. They are used to make scheduling decisions for time- sensitive services running on Deterministic Network (DetNet) nodes that operate within a single or multiple domains.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-sxg-mpls-mna-deterministic-latency-00"/>
      </reference>
      <reference anchor="I-D.eckert-detnet-tcqf" target="https://datatracker.ietf.org/doc/html/draft-eckert-detnet-tcqf-05" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.eckert-detnet-tcqf.xml">
        <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 fullname="Toerless Eckert" initials="T. T." surname="Eckert">
            <organization>Futurewei Technologies USA</organization>
          </author>
          <author fullname="Yizhou Li" initials="Y." surname="Li">
            <organization>Huawei Technologies</organization>
          </author>
          <author fullname="Stewart Bryant" initials="S." surname="Bryant">
            <organization>University of Surrey ICS</organization>
          </author>
          <author fullname="Andrew G. Malis" initials="A. G." surname="Malis">
            <organization>Malis Consulting</organization>
          </author>
          <author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
            <organization>ETRI</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Guangpeng Li" initials="G." surname="Li">
            <organization>Huawei Technologies</organization>
          </author>
          <author fullname="Shoushou Ren" initials="S." surname="Ren">
            <organization>Huawei Technologies</organization>
          </author>
          <author fullname="Fan Yang" initials="F." surname="Yang">
            <organization>Huawei Technologies</organization>
          </author>
          <date day="5" month="January" year="2024"/>
          <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-eckert-detnet-tcqf-05"/>
      </reference>
      <reference anchor="I-D.dang-queuing-with-multiple-cyclic-buffers" target="https://datatracker.ietf.org/doc/html/draft-dang-queuing-with-multiple-cyclic-buffers-00" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.dang-queuing-with-multiple-cyclic-buffers.xml">
        <front>
          <title>A Queuing Mechanism with Multiple Cyclic Buffers</title>
          <author fullname="Bingyang Liu" initials="B." surname="Liu">
            <organization>Huawei</organization>
          </author>
          <author fullname="Joanna Dang" initials="J." surname="Dang">
            <organization>Huawei</organization>
          </author>
          <date day="22" month="February" year="2021"/>
          <abstract>
            <t>This document presents a queuing mechanism with multiple cyclic buffers.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-dang-queuing-with-multiple-cyclic-buffers-00"/>
      </reference>
      <reference anchor="I-D.joung-detnet-asynch-detnet-framework" target="https://datatracker.ietf.org/doc/html/draft-joung-detnet-asynch-detnet-framework-04" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.joung-detnet-asynch-detnet-framework.xml">
        <front>
          <title>Asynchronous Deterministic Networking Framework for Large-Scale Networks</title>
          <author fullname="Jinoo Joung" initials="J." surname="Joung">
            <organization>Sangmyung University</organization>
          </author>
          <author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
            <organization>ETRI</organization>
          </author>
          <author fullname="Taesik Cheung" initials="T." surname="Cheung">
            <organization>ETRI</organization>
          </author>
          <author fullname="Yizhou Li" initials="Y." surname="Li">
            <organization>Huawei</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <date day="17" month="March" year="2024"/>
          <abstract>
            <t>This document describes various solutions of Asynchronous Deterministic Networking (ADN) for large-scale networks. The solutions in this document do not need strict time-synchronization of network nodes, while guaranteeing end-to-end latency or jitter. The functional architecture and requirements for such solutions are specified.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-joung-detnet-asynch-detnet-framework-04"/>
      </reference>
      <reference anchor="I-D.peng-detnet-deadline-based-forwarding" target="https://datatracker.ietf.org/doc/html/draft-peng-detnet-deadline-based-forwarding-10" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.peng-detnet-deadline-based-forwarding.xml">
        <front>
          <title>Deadline Based Deterministic Forwarding</title>
          <author fullname="Shaofu Peng" initials="S." surname="Peng">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Zongpeng Du" initials="Z." surname="Du">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Kashinath Basu" initials="K." surname="Basu">
            <organization>Oxford Brookes University</organization>
          </author>
          <author fullname="zuopin cheng" initials="" surname="cheng">
            <organization>New H3C Technologies</organization>
          </author>
          <author fullname="Dong Yang" initials="D." surname="Yang">
            <organization>Beijing Jiaotong University</organization>
          </author>
          <author fullname="Chang Liu" initials="C." surname="Liu">
            <organization>China Unicom</organization>
          </author>
          <date day="20" month="June" year="2024"/>
          <abstract>
            <t>This document describes a deterministic forwarding mechanism to IP/ MPLS network, as well as corresponding resource reservation, admission check, policing, etc, to provide guaranteed latency. Especially, latency compensation with core stateless is discussed to replace reshaping to be suitable for Diff-Serv architecture [RFC2475].</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-peng-detnet-deadline-based-forwarding-10"/>
      </reference>
      <reference anchor="I-D.peng-detnet-packet-timeslot-mechanism" target="https://datatracker.ietf.org/doc/html/draft-peng-detnet-packet-timeslot-mechanism-07" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.peng-detnet-packet-timeslot-mechanism.xml">
        <front>
          <title>Timeslot Queueing and Forwarding Mechanism</title>
          <author fullname="Shaofu Peng" initials="S." surname="Peng">
            <organization>ZTE</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Kashinath Basu" initials="K." surname="Basu">
            <organization>Oxford Brookes University</organization>
          </author>
          <author fullname="Aihua Liu" initials="A." surname="Liu">
            <organization>ZTE</organization>
          </author>
          <author fullname="Dong Yang" initials="D." surname="Yang">
            <organization>Beijing Jiaotong University</organization>
          </author>
          <author fullname="Guoyu Peng" initials="G." surname="Peng">
            <organization>Beijing University of Posts and Telecommunications</organization>
          </author>
          <date day="20" month="June" year="2024"/>
          <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. In this case, the service flow does not occupy a fixed timeslot, and the length of the timeslot is not fixed, but depends on the size of the packet. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS, and its delay performance is dependent on the used queueing mechanism. This document further describes a generic time division multiplexing scheme in IP/MPLS networks, which we call timeslot queueing and forwarding (TQF) mechanism. TQF is an enhancement based on TSN TAS, which defines a cyclic period consisting of multiple timeslots, and a flow is assigned to be transmited within one or more dedicated timeslots.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-peng-detnet-packet-timeslot-mechanism-07"/>
      </reference>
      <reference anchor="I-D.stein-srtsn" target="https://datatracker.ietf.org/doc/html/draft-stein-srtsn-01" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.stein-srtsn.xml">
        <front>
          <title>Segment Routed Time Sensitive Networking</title>
          <author fullname="Yaakov (J) Stein" initials="Y. J." surname="Stein">
            <organization>RAD</organization>
          </author>
          <date day="29" month="August" year="2021"/>
          <abstract>
            <t>Routers perform two distinct user-plane functionalities, namely forwarding (where the packet should be sent) and scheduling (when the packet should be sent). One forwarding paradigm is segment routing, in which forwarding instructions are encoded in the packet in a stack data structure, rather than programmed into the routers. Time Sensitive Networking and Deterministic Networking provide several mechanisms for scheduling under the assumption that routers are time synchronized. The most effective mechanisms for delay minimization involve per-flow resource allocation. SRTSN is a unified approach to forwarding and scheduling that uses a single stack data structure. Each stack entry consists of a forwarding portion (e.g., IP addresses or suffixes) and a scheduling portion (deadline by which the packet must exit the router). SRTSN thus fully implements network programming for time sensitive flows, by prescribing to each router both to-where and by-when each packet should be sent.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-stein-srtsn-01"/>
      </reference>
      <reference anchor="I-D.ietf-detnet-scaling-requirements" target="https://datatracker.ietf.org/doc/html/draft-ietf-detnet-scaling-requirements-06" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-detnet-scaling-requirements.xml">
        <front>
          <title>Requirements for Scaling Deterministic Networks</title>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Yizhou Li" initials="Y." surname="Li">
            <organization>Huawei</organization>
          </author>
          <author fullname="Toerless Eckert" initials="T. T." surname="Eckert">
            <organization>Futurewei Technologies USA</organization>
          </author>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
            <organization>ETRI</organization>
          </author>
          <author fullname="zhushiyin" initials="" surname="zhushiyin">
            <organization>New H3C Technologies</organization>
          </author>
          <author fullname="Xuesong Geng" initials="X." surname="Geng">
            <organization>Huawei</organization>
          </author>
          <date day="22" month="May" year="2024"/>
          <abstract>
            <t>Aiming at scaling deterministic networks, this document describes the technical and operational requirements when the network has large variation in latency among hops, great number of flows and/or multiple domains without the same time source. Different deterministic levels of applications co-exist and are transported in such a network. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-scaling-requirements-06"/>
      </reference>
      <reference anchor="I-D.xiong-detnet-large-scale-enhancements" target="https://datatracker.ietf.org/doc/html/draft-xiong-detnet-large-scale-enhancements-04" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.xiong-detnet-large-scale-enhancements.xml">
        <front>
          <title>Enhanced DetNet Data Plane Framework for Scaling Deterministic Networks</title>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Zongpeng Du" initials="Z." surname="Du">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Junfeng Zhao" initials="J." surname="Zhao">
            <organization>CAICT</organization>
          </author>
          <author fullname="Dong Yang" initials="D." surname="Yang">
            <organization>Beijing Jiaotong University</organization>
          </author>
          <date day="26" month="February" year="2024"/>
          <abstract>
            <t>The Enhanced Deterministic Networking (EDN) is required to provide the enhancement of flow identification and packet treatment for Deterministic Networking (DetNet) to achieve the DetNet QoS in scaling networks. This document proposes the enhancement of the framework to support the functions and metadata for enhanced DetNet data plane.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-large-scale-enhancements-04"/>
      </reference>
      <reference anchor="I-D.peng-6man-deadline-option" target="https://datatracker.ietf.org/doc/html/draft-peng-6man-deadline-option-01" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.peng-6man-deadline-option.xml">
        <front>
          <title>Deadline Option</title>
          <author fullname="Shaofu Peng" initials="S." surname="Peng">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Bin Tan" initials="B." surname="Tan">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <date day="11" month="July" year="2022"/>
          <abstract>
            <t>This document introduces new IPv6 options for Hop-by-Hop Options header, to carry deadline related information for deterministic flows.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-peng-6man-deadline-option-01"/>
      </reference>
      <reference anchor="I-D.xiong-detnet-spring-srh-extensions" target="https://datatracker.ietf.org/doc/html/draft-xiong-detnet-spring-srh-extensions-01" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.xiong-detnet-spring-srh-extensions.xml">
        <front>
          <title>Segment Routing Header Extensions for DetNet Data Fields</title>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Haisheng Wu" initials="H." surname="Wu">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Dong Yang" initials="D." surname="Yang">
            <organization>Beijing Jiaotong University</organization>
          </author>
          <date day="13" month="October" year="2023"/>
          <abstract>
            <t>The DetNet data fields defined in Deterministic Latency Action (DLA) can be used in enhanced Deterministic Networking (DetNet) to provide QoS treatment to achieve deterministic latency. This document defines how DetNet data fields are encapsulated as part of the Segment Routing with IPv6 data plane (SRv6) header.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-spring-srh-extensions-01"/>
      </reference>
      <reference anchor="I-D.chen-detnet-sr-based-bounded-latency" target="https://datatracker.ietf.org/doc/html/draft-chen-detnet-sr-based-bounded-latency-03" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.chen-detnet-sr-based-bounded-latency.xml">
        <front>
          <title>Segment Routing (SR) Based Bounded Latency</title>
          <author fullname="Mach Chen" initials="M." surname="Chen">
            <organization>Huawei</organization>
          </author>
          <author fullname="Xuesong Geng" initials="X." surname="Geng">
            <organization>Huawei</organization>
          </author>
          <author fullname="Zhenqiang Li" initials="Z." surname="Li">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Jinoo Joung" initials="J." surname="Joung">
            <organization>Sangmyung University</organization>
          </author>
          <author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
            <organization>ETRI</organization>
          </author>
          <date day="7" month="July" year="2023"/>
          <abstract>
            <t>One of the goals of DetNet is to provide bounded end-to-end latency for critical flows. This document defines how to leverage Segment Routing (SR) to implement bounded latency. Specifically, the SR Identifier (SID) is used to specify transmission time (cycles) of a packet. When forwarding devices along the path follow the instructions carried in the packet, the bounded latency is achieved. This is called Cycle Specified Queuing and Forwarding (CSQF) in this document. Since SR is a source routing technology, no per-flow state is maintained at intermediate and egress nodes, SR-based CSQF naturally supports flow aggregation that is deemed to be a key capability to allow DetNet to scale to large networks.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-chen-detnet-sr-based-bounded-latency-03"/>
      </reference>
      <reference anchor="I-D.joung-detnet-stateless-fair-queuing" target="https://datatracker.ietf.org/doc/html/draft-joung-detnet-stateless-fair-queuing-02" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.joung-detnet-stateless-fair-queuing.xml">
        <front>
          <title>Latency Guarantee with Stateless Fair Queuing</title>
          <author fullname="Jinoo Joung" initials="J." surname="Joung">
            <organization>Sangmyung University</organization>
          </author>
          <author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
            <organization>ETRI</organization>
          </author>
          <author fullname="Taesik Cheung" initials="T." surname="Cheung">
            <organization>ETRI</organization>
          </author>
          <author fullname="Yizhou Li" initials="Y." surname="Li">
            <organization>Huawei</organization>
          </author>
          <author fullname="Peng Liu" initials="P." surname="Liu">
            <organization>China Mobile</organization>
          </author>
          <date day="29" month="February" year="2024"/>
          <abstract>
            <t>This document specifies the framework and the operational procedure for deterministic networking with work conserving packet schedulers that guarantee end-to-end latency bounds to flows. Schedulers in core nodes of the network do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update FT by adding a delay factor, which is a function of the flow and upstream nodes. The packets in the queue are served in the ascending order of the FT. This technique is called Fair Queuing (FQ). The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters, except the link capacities and the maximum packet lengths among other flows sharing each output link with the flow.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-joung-detnet-stateless-fair-queuing-02"/>
      </reference>
      <reference anchor="I-D.ietf-detnet-dataplane-taxonomy" target="https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dataplane-taxonomy-00" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-detnet-dataplane-taxonomy.xml">
        <front>
          <title>Dataplane Enhancement Taxonomy</title>
          <author fullname="Jinoo Joung" initials="J." surname="Joung">
            <organization>Sangmyung University</organization>
          </author>
          <author fullname="Xuesong Geng" initials="X." surname="Geng">
            <organization>Huawei</organization>
          </author>
          <author fullname="Shaofu Peng" initials="S." surname="Peng">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Toerless Eckert" initials="T. T." surname="Eckert">
            <organization>Futurewei Technologies</organization>
          </author>
          <date day="24" month="May" year="2024"/>
          <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 briefly mentioned.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-dataplane-taxonomy-00"/>
      </reference>
      <reference anchor="I-D.eckert-detnet-glbf" target="https://datatracker.ietf.org/doc/html/draft-eckert-detnet-glbf-02" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.eckert-detnet-glbf.xml">
        <front>
          <title>Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks</title>
          <author fullname="Toerless Eckert" initials="T. T." surname="Eckert">
            <organization>Futurewei Technologies USA</organization>
          </author>
          <author fullname="Alexander Clemm" initials="A." surname="Clemm">
            <organization>Futurewei Technologies USA</organization>
          </author>
          <author fullname="Stewart Bryant" initials="S." surname="Bryant">
            <organization>Independent</organization>
          </author>
          <author fullname="Stefan Hommes" initials="S." surname="Hommes">
            <organization>ZF Friedrichshafen AG</organization>
          </author>
          <date day="5" month="January" year="2024"/>
          <abstract>
            <t>This memo proposes a mechanism called "guaranteed Latency Based Forwarding" (gLBF) as part of DetNet for hop-by-hop packet forwarding with per-hop deterministically bounded latency and minimal jitter. gLBF is intended to be useful across a wide range of networks and applications with need for high-precision deterministic networking services, including in-car networks or networks used for industrial automation across on factory floors, all the way to ++100Gbps country-wide networks. Contrary to other mechanisms, gLBF does not require network wide clock synchronization, nor does it need to maintain per-flow state at network nodes, avoiding drawbacks of other known methods while leveraging their advantages. Specifically, gLBF uses the queuing model and calculus of Urgency Based Scheduling (UBS, [UBS]), which is used by TSN Asynchronous Traffic Shaping [TSN-ATS]. gLBF is intended to be a plug-in replacement for TSN-ATN or as a parallel mechanism beside TSN-ATS because it allows to keeping the same controller-plane design which is selecting paths for TSN-ATS, sizing TSN-ATS queues, calculating latencies and admitting flows to calculated paths for calculated latencies. In addition to reducing the jitter compared to TSN-ATS by additional buffering (dampening) in the network, gLBF also eliminates the need for per-flow, per-hop state maintenance required by TSN-ATS. This avoids the need to signal per-flow state to every hop from the controller-plane and associated scaling problems. It also reduces implementation cost for high-speed networking hardware due to the avoidance of additional high-speed speed read/write memory access to retrieve, process and update per-flow state variables for a large number of flows.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-eckert-detnet-glbf-02"/>
      </reference>
      <reference anchor="I-D.mohammadpour-detnet-bounded-delay-variation" target="https://datatracker.ietf.org/doc/html/draft-mohammadpour-detnet-bounded-delay-variation-00" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.mohammadpour-detnet-bounded-delay-variation.xml">
        <front>
          <title>DetNet Bounded Packet-Delay-Variation</title>
          <author fullname="Ehsan Mohammadpour" initials="E." surname="Mohammadpour">
            <organization>EPFL</organization>
          </author>
          <author fullname="Jean-Yves Le Boudec" initials="J." surname="Le Boudec">
            <organization>EPFL</organization>
          </author>
          <date day="10" month="September" year="2021"/>
          <abstract>
            <t>Some DetNet use-cases (applications) require guaranteed bounds on packet delay-variation, not just on latency. This document gives a methodology to derive guaranteed packet delay-variation bounds in DetNet and apply it to a number of proposed mechanisms. When the required packet delay-variations is very low, clock non-idealities affect the bounds, even in a synchronized DetNet networks. This document also gives a methodology to account for such an effect.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-mohammadpour-detnet-bounded-delay-variation-00"/>
      </reference>
      <reference anchor="I-D.xiong-detnet-flow-aggregation" target="https://datatracker.ietf.org/doc/html/draft-xiong-detnet-flow-aggregation-00" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.xiong-detnet-flow-aggregation.xml">
        <front>
          <title>Flow Aggregation for Enhanced DetNet</title>
          <author fullname="Quan Xiong" initials="Q." surname="Xiong">
            <organization>ZTE Corporation</organization>
          </author>
          <author fullname="Tianji Jiang" initials="T." surname="Jiang">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Jinoo Joung" initials="J." surname="Joung">
            <organization>Sangmyung University</organization>
          </author>
          <date day="1" month="March" year="2024"/>
          <abstract>
            <t>This document describes the flow aggregation scenarios and proposes a method by aggregating DetNet flows based on DetNet flow-specific classification in enhanced DetNet and the flow identification of aggregated-class can be used to indicate the required treatment and forwarding behaviors in scaling networks.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-flow-aggregation-00"/>
      </reference>
    </references>
  </back>
</rfc>
