<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-xiong-detnet-data-fields-edp-03" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.29.0 -->
  <front>
    <title abbrev="Data Fields for Enhanced DetNet ">Data Fields for DetNet Enhanced Data Plane</title>
    <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-data-fields-edp-03"/>
    <author initials="Q." surname="Xiong" fullname="Quan Xiong">
      <organization>ZTE Corporation</organization>
      <address>
        <email>xiong.quan@zte.com.cn</email>
      </address>
    </author>
    <author initials="A." surname="Liu" fullname="Aihua Liu">
      <organization>ZTE Corporation</organization>
      <address>
        <email>liu.aihua@zte.com.cn</email>
      </address>
    </author>
    <author initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author initials="D." surname="Yang" fullname="Dong Yang">
      <organization>Beijing Jiaotong University</organization>
      <address>
        <email>dyang@bjtu.edu.cn</email>
      </address>
    </author>
    <date year="2025" month="July" day="01"/>
    <workgroup>detnet</workgroup>
    <abstract>
      <?line 56?>

<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>
    <?line 66?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>According to <xref target="RFC8655"/>, 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"/>. As described in <xref target="RFC9320"/>, 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 is required to support a enhanced data plane method of flow identification and 
packet treatment.</t>
      <t>For scaling networks, <xref target="I-D.ietf-detnet-scaling-requirements"/> 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. 
Several data plane enhancement solutions and queuing mechanisms have been discussed in DetNet. 
And <xref target="I-D.ietf-detnet-dataplane-taxonomy"/> has defined the classification criteria and the suitable categories for 
DetNet data plane solutions.</t>
      <t>This document proposes the specific metadata which should be carried in DetNet Enhanced Data Plane (EDP) 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 anchor="conventions">
      <name>Conventions used in this document</name>
      <section anchor="requirements-language">
        <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 <contact fullname="{RFC2119"/>} <contact fullname="{RFC8174"/>} when, and only when, they appear in all 
capitals, as shown here.</t>
      </section>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>This document uses the terms defined in <xref target="RFC8655"/>, <xref target="RFC8938"/>, <xref target="I-D.ietf-detnet-scaling-requirements"/> and 
<xref target="I-D.ietf-detnet-dataplane-taxonomy"/>.</t>
      </section>
      <section anchor="abbreviations">
        <name>Abbreviations</name>
        <t>SRH:Segment Routing Header</t>
        <t>SRv6:Segment Routing for IPv6 forwarding plane</t>
        <t>DL:Deterministic Latency</t>
        <t>CSQF:Cycle Specified Queuing and Forwarding</t>
        <t>TQF:Timeslot Queuing and Forwarding</t>
        <t>C-SCORE:Work Conserving Stateless Core Fair Queuing</t>
        <t>EDF:Earliest Deadline First</t>
        <t>TAS:Time Aware Shaper</t>
        <t>ATS:Asynchronous Traffic Shaping</t>
        <t>CQF:Cyclic Queuing and Forwarding</t>
        <t>FQ:Fair Queuing</t>
        <t>TSN:Time-Sensitive Networking</t>
        <t>ECQF:Enhanced Cyclic Queuing and Forwarding</t>
        <t>gLBF:guaranteed Latency Based Forwarding</t>
        <t>EDP:DetNet Enhanced Data Plane</t>
      </section>
    </section>
    <section anchor="specific-metadata">
      <name>Specific Metadata for DetNet Enhanced Data Plane</name>
      <section anchor="aggregation-based-metadata">
        <name>Aggregation-based Metadata</name>
        <t>As per <xref target="RFC8655"/>, 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"/>, the deterministic services
   may demand different deterministic QoS requirements according to different levels of application requirements. 
   The flow identification with service-level aggregation and explicit aggregated flow identification should be supported.
   In DetNet MPLS, A-Label defined as per <xref target="RFC8964"/> can be added explicitly to the packets. But in other DetNet data plane, 
   no aggregated flow specific information is available.</t>
        <t>Furthermore, it is required to be dynamic and simplified to ensure the aggregated flows have compatible 
   DetNet flow-specific QoS characteristics. The 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"/>. This document proposes the aggregation-based metadata in enhanced data plane 
   for the DetNet nodes along the path to identify the aggregated flow and achieve the end-to-end QoS in scaling networks.</t>
      </section>
      <section anchor="deterministic-latency-metadata">
        <name>Deterministic Latency Metadata</name>
        <t>As described in <xref target="RFC9320"/>, 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. 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"/> 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. For example, the CQF variations for cyclic-based scheduling includes the ECQF [IEEE 802.1Qdv], 
TCQF <xref target="I-D.eckert-detnet-tcqf"/> and CSQF <xref target="I-D.chen-detnet-sr-based-bounded-latency"/>. The TAS variations for 
timeslot-based scheduling includes TQF <xref target="I-D.peng-detnet-packet-timeslot-mechanism"/>. The FQ variations for rate-based 
scheduling includes C-SCORE <xref target="I-D.joung-detnet-stateless-fair-queuing"/>, ATS [IEEE802.1Qcr] and 
gLBF <xref target="I-D.eckert-detnet-glbf"/>. The EDF variations for deadline-based scheduling includes 
EDF <xref target="I-D.peng-detnet-deadline-based-forwarding"/>.</t>
        <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"/>, 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.</t>
        <t><xref target="I-D.ietf-detnet-dataplane-taxonomy"/> has defined the classification criteria and the suitable categories for this solutions.
This proposes the deterministic latency metadata align with the categories in enhanced data plane for the DetNet nodes along 
the path to 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 anchor="data-fields">
      <name>Data Fields for DetNet Enhanced Data Plane</name>
      <section anchor="detnet-option-types-and-data-fields">
        <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 as Figure 1.</t>
        <artwork><![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                  ~   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
              Figure 1 DetNet Header for Enhanced Data Plane
]]></artwork>
        <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-Type, TBD1, as defined in section 4.2.</t>
        <t>Deterministic Latency Option-Type, TBD2, as defined in section 4.3.</t>
        <t>DetNet-Length: 8-bit unsigned integer, defined the Length of the DetNet Header 4-octet units.</t>
        <t>DetNet Option and Data Space: variable, it MUST be aligned by 4 octets. It 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 Option consists of a fixed-size "Option Header" 
   and a variable-size "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>
      <section anchor="aggregation-option">
        <name>Aggregation Option</name>
        <t>The format of Aggregation Option Header is shown in Figure 2.</t>
        <artwork><![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    | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
              Figure 2 Aggregation Option Header
]]></artwork>
        <t>Aggregation type(16 bits): indicates the aggregation type of packet treatment ensuring the deterministic latency as Figure 3 
shown. This type can also indicate the aggregated class.</t>
        <artwork><![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 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        
                   Figure 3  Aggregation Type
]]></artwork>
        <t>Flag: 8-bit flags field. When E is set to 1, it indicates the explicit aggregated flow identification.</t>
        <t>Data Len:8-bit unsigned integer. Length of option data, in octets.</t>
        <t>The related option data is defined as Aggregation Option Data in Figure 4.</t>
        <artwork><![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                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
               Figure 4 Aggregation Option Data
]]></artwork>
        <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 anchor="deterministic-latency-option">
        <name>Deterministic Latency Option</name>
        <t>The format of Deterministic Latency Option  Header is shown in Figure 5.</t>
        <artwork><![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    | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
               Figure 5 Deterministic Latency Option header
]]></artwork>
        <t>Deterministic Latency Type(16 bits): indicates the type of deterministic latency information with related queuing and 
scheduling metadata and it aglined with the suitable categories as defined in <xref target="I-D.ietf-detnet-dataplane-taxonomy"/> and 
shown in Figure 6.</t>
        <artwork><![CDATA[
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Value  | Deterministic Latency Type                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0000  | Unassigned                                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0001  | Right-bounded category                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0002  | Flow level periodic bounded category       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0003  | Class level periodic bounded category      |  
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0004  | Flow level non-periodic bounded category   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0x0005  | Class level non-periodic bounded category  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        |0x0006  | Flow level rate based unbounded category   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        
        |0x0007  | Flow level rate based left-bounded category|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

               Figure 6 Deterministic Latency Type
]]></artwork>
        <t>Flag: 8-bit flags field.
Data Len: 8-bit unsigned integer. Length of option data, in octets.</t>
        <t>The related option data is defined as Deterministic Latency option data which 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 anchor="data-field-in-right-bounded-category">
          <name>Data Field in Right-bounded Category</name>
          <t>As per <xref target="I-D.ietf-detnet-dataplane-taxonomy"/>, for solutions in the right-bounded category, a packet has only a maximum
time bound.</t>
          <t>When the type is set to 0x0001, indicates the queuing and scheduling solutions in right-bounded category. 
The data field and related information may be carried and designed as following shown:</t>
          <artwork><![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 time bound                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   
          Figure 7 Data Field in Right-bounded Category
]]></artwork>
          <t>Maximum time bound: 32bits, indicates the required maximum time bound of a packet.</t>
        </section>
        <section anchor="date-field-in-flow-level-periodic-bounded-category">
          <name>Date Field in Flow Level Periodic Bounded Category</name>
          <t>As per <xref target="I-D.ietf-detnet-dataplane-taxonomy"/>, the flow Level periodic bounded solutions define a set of time slots, 
which will be scheduled for flows or flow aggregates.</t>
          <t>When the type is set to 0x0002, indicates the queuing and scheduling solutions in flow level periodic bounded category. 
The data field and related information may be carried and designed as following shown:</t>
          <artwork><![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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      Figure 8 Data Field in Flow Level Periodic Bounded Category
]]></artwork>
          <t>Timeslot ID: indicates the identifier of the timeslot scheduled for a flow.</t>
        </section>
        <section anchor="date-field-in-class-level-periodic-bounded-category">
          <name>Date Field in Class Level Periodic Bounded Category</name>
          <t>As per <xref target="I-D.ietf-detnet-dataplane-taxonomy"/>, the periodic bounded solutions can be further categorized by 
the traffic granularity with class level subcategory. The class Level periodic bounded solutions define
a set of cycles and each cycle will be scheduled for flows or flow aggregates within a class level.</t>
          <t>When the type is set to 0x0003, indicates the queuing and scheduling solutions in class level periodic bounded category. 
The data field and related information may be carried and designed as following shown:</t>
          <artwork><![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 ID                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
     Figure 9 Data Field in Class Level Periodic Bounded Category 
]]></artwork>
          <t>Cycle ID (32bits): indicates the identifer which the queue applied for a node to forward DetNet flows within a class level.</t>
        </section>
        <section anchor="date-field-in-flow-level-non-periodic-bounded-category">
          <name>Date Field in Flow Level Non-periodic Bounded Category</name>
          <t>As per <xref target="I-D.ietf-detnet-dataplane-taxonomy"/>, flow level non-periodic bounded solutions guarantee the minimum and maximum
bounds of a packet in a flow or flow aggregate.</t>
          <t>When the type is set to 0x0004, indicates the queuing and scheduling solutions in flow level non-periodic bounded category 
The data field and related information may be carried and designed as following shown:</t>
          <artwork><![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 time bound                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Minimum time bound                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   
   Figure 10 Data Field in Flow Level Non-periodic Bounded Category 
   
]]></artwork>
          <t>Maximum time bound: 32bits, indicates the maximum time bound of a packet in a flow or flow aggregates.</t>
          <t>Minimum time bound: 32bits, indicates the minimum time bound of a packet in a flow or flow aggregates.</t>
        </section>
        <section anchor="date-field-in-class-level-non-periodic-bounded-category">
          <name>Date Field in Class Level Non-periodic Bounded Category</name>
          <t>As per <xref target="I-D.ietf-detnet-dataplane-taxonomy"/>, class level non-periodic bounded solutions guarantee the minimum and maximum
bounds of a packet within a class level.</t>
          <t>When the type is set to 0x0005, indicates the queuing and scheduling solutions in class level non-periodic bounded category.
The data field and related information may be carried and designed as following shown:</t>
          <artwork><![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 time bound                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Minimum time bound                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      Figure 11 Data Field in Class Level Non-periodic Bounded Category
]]></artwork>
          <t>Maximum time bound: 32bits, indicates the maximum time bound of a packet within a class level .</t>
          <t>Minimum time bound: 32bits, indicates the minimum time bound of a packet within a class level.</t>
        </section>
        <section anchor="date-field-in-flow-level-rate-based-unbounded-category">
          <name>Date Field in Flow Level Rate-based Unbounded Category</name>
          <t>In flow level rate based unbounded category, the latency bound is primarily influenced by the ratio of a flow's maximum 
packet size, its allocated service rate and completion time.</t>
          <t>When the type is set to 0x0006, indicates the queuing and scheduling solutions in flow level rate based unbounded category.
The data field and related information may be carried and designed as following shown:</t>
          <artwork><![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                         |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Finish time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
    Figure 12 Data Field in Flow Level Rate-based Unbounded Category
]]></artwork>
          <t>Maximum packet size: 32 bits, indicates the maximum packet size of a flow.</t>
          <t>Service rate: 32 bits, indicates the allocated service rate of a flow.</t>
          <t>Finish time: 32 bits, indicates the required service completion time of a flow.</t>
        </section>
        <section anchor="date-field-in-flow-level-rate-based-left-bounded-category">
          <name>Date Field in Flow Level Rate-based Left-bounded Category</name>
          <t>In flow level rate based left-bounded category, the latency bound is primarily influenced by the ratio of a flow's maximum 
packet size, its allocated service rate, start time and completion time.</t>
          <t>When the type is set to 0x0007, indicates the queuing and scheduling solutions in flow level Rate based left-bounded category.
The data field and related information may be carried and designed as following shown:</t>
          <artwork><![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                         |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Finish time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |                         Eligible time                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   
  Figure 13 Data Field in Flow Level Rate-based Left-bounded Category
]]></artwork>
          <t>Maximum packet size: 32 bits, indicates the maximum packet size of a flow.</t>
          <t>Service rate: 32 bits, indicates the allocated service rate of a flow.</t>
          <t>Finish time: 32 bits, indicates the required service completion time of a flow.</t>
          <t>Eligible time: 32bits, indicates the required service start time of a flow.</t>
        </section>
      </section>
    </section>
    <section anchor="encapsulation-considerations">
      <name>Encapsulation Considerations for DetNet Enhanced Data Plane</name>
      <section anchor="metadata-for-detnet-enhanced-data-plane">
        <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 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 anchor="encoding-for-detnet-enhanced-data-plane">
        <name>Encoding for DetNet Enhanced Data Plane</name>
        <section anchor="reuse-of-the-existing-dscptc-field">
          <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 as per <xref target="I-D.eckert-detnet-tcqf"/>. The mapping from DSCP and the metadata such as queuing information MUST 
be provided in the controller plane.</t>
        </section>
        <section anchor="new-common-data-fields">
          <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 MNA <xref target="I-D.sxg-mpls-mna-deterministic-latency"/>, IPv6 <xref target="I-D.xiong-detnet-6man-queuing-option"/> and
SRv6 <xref target="I-D.xiong-detnet-spring-srh-extensions"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Security considerations for DetNet are covered in the DetNet Architecture <xref target="RFC8655"/> and DetNet data plane
<xref target="RFC8938"/>, <xref target="RFC8939"/>, <xref target="RFC8964"/> and DetNet security considerations <xref target="RFC9055"/>. The security considerations 
specified in <xref target="I-D.ietf-detnet-scaling-requirements"/> are also applicable to the procedures defined in this document.</t>
    </section>
    <section anchor="iana-considerations">
      <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">
      <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>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="RFC2119">
        <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">
        <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="RFC2212">
        <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="RFC8938">
        <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="RFC8939">
        <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="RFC8964">
        <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="RFC9320">
        <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="RFC9055">
        <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="RFC8655">
        <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="I-D.xiong-detnet-6man-queuing-option">
        <front>
          <title>IPv6 Option for Scaling Deterministic Networks</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="1" month="July" year="2024"/>
          <abstract>
            <t>   The DetNet-specific metadata should be carried in enhanced data plane
   based on the enhancement requirements in scaling deterministic
   networks.  This document outlines how the DetNet-specific metadata
   are encapsulated in IPv6 [RFC8200] and specifies formats and
   principles for the IPv6 DetNet Options to provide deterministic
   services.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-6man-queuing-option-06"/>
      </reference>
      <reference anchor="I-D.sxg-mpls-mna-deterministic-latency">
        <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="15" month="June" year="2025"/>
          <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-03"/>
      </reference>
      <reference anchor="I-D.eckert-detnet-tcqf">
        <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="3" month="March" year="2025"/>
          <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-07"/>
      </reference>
      <reference anchor="I-D.peng-detnet-deadline-based-forwarding">
        <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="chris cheng" initials="C." surname="cheng">
            <organization>Zhejiang P&amp;T College</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="25" month="June" year="2025"/>
          <abstract>
            <t>   This document describes a deadline based deterministic forwarding
   mechanism for IP/MPLS network with the corresponding resource
   reservation, admission control, scheduling and policing processes to
   provide guaranteed latency bound.  It employs a latency compensation
   technique with a stateless core, to replace reshaping, making it
   suitable for the Differentiated Services (Diffserv) architecture
   [RFC2475].

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-peng-detnet-deadline-based-forwarding-17"/>
      </reference>
      <reference anchor="I-D.peng-detnet-packet-timeslot-mechanism">
        <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="24" month="June" year="2025"/>
          <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 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
   scheme based on available timeslot resources.  It defines a cyclic
   period consisting of multiple timeslots where a flow is assigned to
   be transmited 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-peng-detnet-packet-timeslot-mechanism-12"/>
      </reference>
      <reference anchor="I-D.ietf-detnet-scaling-requirements">
        <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="1" month="June" year="2025"/>
          <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, a 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-08"/>
      </reference>
      <reference anchor="I-D.xiong-detnet-spring-srh-extensions">
        <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="1" month="July" year="2024"/>
          <abstract>
            <t>   The DetNet data fields such as the Deterministic Latency Option 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-02"/>
      </reference>
      <reference anchor="I-D.chen-detnet-sr-based-bounded-latency">
        <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">
        <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="20" month="June" year="2025"/>
          <abstract>
            <t>   This document specifies the framework and the operational procedure
   for deterministic networking with a set of rate based work conserving
   packet schedulers.  The framework guarantees end-to-end (E2E) latency
   bounds to flows.  The schedulers in core nodes do not need to
   maintain flow states.  Instead, the entrance node of a flow marks an
   ideal service completion time according to a fluid model, called
   Finish Time (FT), of a packet in the packet header.  The subsequent
   core nodes update FT by adding delay factors, which are functions of
   the flow and the nodes.  The packets in the queue of the scheduler
   are served in the ascending order of FT.  This mechanism is called
   the stateless fair queuing.  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 such as the maximum
   burst size and the service rate, except the link capacities and the
   maximum packet length among other flows sharing each output link with
   the flow.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-joung-detnet-stateless-fair-queuing-05"/>
      </reference>
      <reference anchor="I-D.ietf-detnet-dataplane-taxonomy">
        <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="2" month="March" year="2025"/>
          <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-03"/>
      </reference>
      <reference anchor="I-D.eckert-detnet-glbf">
        <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>Sympotech</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="3" month="March" year="2025"/>
          <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-04"/>
      </reference>
      <reference anchor="I-D.xiong-detnet-flow-aggregation">
        <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="25" month="February" year="2025"/>
          <abstract>
            <t>   This document describes the objectives and requirements of flow
   aggregation in scaling networks.  It proposes a scheme by aggregating
   DetNet flows based on DetNet flow-specific classification in enhanced
   DetNet, and suggests the flow identification of aggregated-class be
   used to indicate the required treatment and forwarding behaviors in
   scaling networks.  Toward the end, the draft discuss how the novel
   flow aggregation scheme could be applied to realize the flow
   aggregation in a 5GS logical DetNet node participating in enhanced
   DetNet.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-xiong-detnet-flow-aggregation-02"/>
      </reference>
    </references>
    <?line 569?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1dW3PbxpJ+ZxX/w5T1sEktwbUuVmw+bEWWqBOdkmxZlHM2
u5WHITAkEYMAjYskxnZ++/ZlZjAAAZK26JxTJ2aqYhIYzPT0dH99mUHL87xu
524gDrudIPFjOVcDEaRyknsPYRJPvUDlscq9QObSm4QqCjJPBQvvKbT3ZT4Q
WR50O1kxnodZBg/kywV0cDG8Pe928jCP4McZPCrO6VExSVJxpvJXKhfDeCZj
XwV8/zqSsep25HicKqDmv7sdsfJg+QT10O3cT4FWoq/bgWeLfJakA/zqCZ7I
m0LG4n9wHthfkkL7/70ditMkXSSpzOEGXldzGUYDQfPtv4dHfvw9V30/mff9
WMDH7fEknBVSXIbFFh1GYdGX2N7pD2+Xvd3Idyqbib/JOJiFtsfTMPMTMVpm
uZpnPXER+32n13RKrX/0sRX2WqHvDOYgfpHOhF+q8LcQLv49lEmOd9/G4Z1K
szBfOr0GS3jmx/FvedFXQYETZ0rjJJ3DvO4U8JUGCuOJe0ncnJ8e7O+/MN+f
7/9wZK8f7B/Y6y8Onzvfy/Yvjm37F4cHTwdCmF9Pnz2zrY719wvvrF+Ry+O5
jL33hSpgil6ywBWwDbOHqTdfRJk3jyW2V+k8jMMsD30vkrmK/aUeDRsr/51K
c9Nt7r+fODcXytEEJYMojJU3lpkKPODGvUwDGL6l/UJCz9BjOFdZlOTeXPkg
xmE2d9qHKp+Y9pkvI5xMqt4XYarmKs6zgRAsiA0cyBYpNs/SmaceYFaohfSA
ae3PVGwbp5rscVLEAfy7yojf4E7ZeQ73I5Vl3kSGqWH0wCXGpR1RYoGa7OXy
IYmT+dIlpMriaTSe6Hk1T2wSJfeenE5TNSXNGhhdBGn3PCHHWZ5Kn1T/dqY0
KAA7lB9OQl/MVS6RHpHNkiIKxFgJX6ZpCPgRxkIZLKEmC0YfYo1IYpFDf7oF
8l+4a9EXt7MwEwCWBd1bpMkiyVRGD4E6zhPUHQ1y1DvDpgC1FSyhAlEyE1nh
z4TMxEk5R/GaG2Bb6qSUWXHJS6WbIBl2PD0aAqanAdMH5BvDnOARucgKXGec
eJ4IKe4ksCFfimSC1OeJn0QlNVfXlyMAneu7Y6JidANfAAdUfp+k77J+uQDz
MAgihb/2AKPyNAkKn4j/sBc6Pz9hixPfT0hJBBDw4YNW6U+feqI6x1c8DDb8
jif1PfBMAbQCv2ROPL64FpFcqpTIC1REaCYyld6FvhL3sxDmAdO6CwN4Bhjw
kOPKRUsB8sQLEiVZJnSf0IfWBaF1QdyH+QxERAo9aVhrAEnguLuoJDKZmAHH
xkrFQsudwnWDh3mOAHqfPvXFCYiLyvw0HLPw0U1EO2QAy1rg5YmnGogJFIAJ
rKeWyjsZFQoXTqsiMkAu+SkYWUaI8DgBam0aWcwB6b0qojxcRE03y9looQ5w
uaaFTGWcK0Vd1ukLUdovhsPh86cH/X1xO3olvrsFrPNGCEVoJpxF/V7cyuyd
+FuaFIu+eFnwgqoHXHyaiysLOdAVJ1EyDXGdUiUm0sdWkUynimBSoWAW8zHI
AnAkTgK9oBGhCPSCCiwAJeJMuyc9/DVBeMgAFoMCkbYHxg+MJ1xDxAGDS4oK
hKWgXijIZC1lJKCLAkagGbtEWN0QJQ5BY4MaxMSsWICHkINQNSAPYtUsCXAS
SIIAyY1zBDHpgAHbEaBfyRyBhzTxHNwibTAsGT2Qr22MyqdPtN6lZK5DPddz
szMAl9HOoWcBxEA2NGibTXWhjShZQQNO4sTUgwTzrVhFqCtQrWpnJOla9b1I
3alIOBaDxlIPiyj0w3wTXaWZ0Gulgj4MeAJdNGgK9pwlUYGP2pUWQTiZqBR5
Z90k1NsEew3UBLyGADmUrzNX4DcnYqaiBU+7iH0eA4QDNKpIVxVF868Hg/pR
QSgLE0XIJ4lH6kHEZCyntJY9oXIfpzYCfqUg144gustfTk8282AmQbkJLkDX
/CLLGN14ZoZ3q7K46iRYSWQOkSGNJCisXRyQUJhxKIkUvJ8VYS7HEdr0XE2T
FDECRbRqeXlSdiLkRhuPY40VX10UtiqNnkR7OCO+G55df08kV7qHyKlith/j
JGx2EeqjrToJYic+QsVD2IOQKL5D/UL5KbRk5BWWf9jzyzbkJeztiRsXcy4h
JilAao2L906BcQY/IhNPrt6Obp/0+F/x6jV9vxm+eXtxMzzD76OfTi4v7Rfd
otuBn6/fXuoW+K189vT11dXw1Rk/DldF7dLVyS9PehqLn7y+vr14/erk8snq
tNBSscYDJ1W6SFXOWl9xAV6eXkM/+0egH+QNYAz1CT7mN8ZR9PsevHdtkmLw
YfgnSNFSyMVCyRQ7k1GEyywXoBMRGrAMRfU+BhhJVV9z9pbkBO3pUjBDXaoL
I5woTqUqWk9Ge2uOW/MZZoaZth0SGHJPKBMQksBnrt6Obn4ajNSUqL5JCnIc
foKYTKX4JIriym0EBhLWMlgzLj/gxeWgUYnw3unozfngdOkDzoysf/dGIyHO
6tx2SCyF1rc6zmttVs7k1Budvr4ZDv6BPiboC9kxeGJkgi7MKyhxDpGX7c3E
QMOz88FQphHgHqi0DknFeZhmeTlE/QMUnoyIQnFyj3I6mskF8+3kdjQ4yZax
P0thIYpM3Go/CZvo6Z1qZsDVTZMrRzx/M3AnQGwavRq0uog0ORzJAuqGIbud
6eXL84F1HgKLgi8pnKu2BUQerEtAMXiNjAG4MgZgfeIKsMzYDM/YDINoDnBz
7G07xQbAI4gOYBGqelZ6CBU3sYDFNp4kNnF9HQBq/QS5sai6AJXQseN9ktea
Urgt2HHOVp5D/oZzDKAUuZZyHEYhGILxErwKiOkoiIOxgWZvliwEpQjAYzvR
lpl8K4cwGmyOMQp6yj6ItUyXxM+649ovWbEdsDCfqs6QdgYzO2yg5uRyWtes
2v5NMqo6utINVcunyLkkbgHuRsYvqSYGaMxbw4M/11WlsS+slWcLfeJdyjEM
5Piepai9OAYLY1wAGWBQZwgAQwOTp1WmqCPjYA1FiuKiFdHsaZlKVki3vpTr
EYPlkXcyjNCDY8rpf+dFit3PAfXAmV2JodCJ1pEaud8gpRFDMtwk31hVtEKT
oB1V8IIWMPqYokYYzBH60gtHaQD/FvNK4G6igOioLoyD8C4MCnCXuU8t0e5Y
INI2OhM2l5RBdxQrwZgmSWHG05obO9145PmyuGm306w+9AJKKOOK3HBzvbA0
CGvP2lQaJiXW+L9yBbKsI9ycOuOBiQElcOl4nDISLEqYlUjMdJZNa0ULK/1Z
CNOvZ0ZwbWD4FdTQONvsCbtYu8M0TFP2xYQmTUmXbmd92sUEUjbvYjxtMNji
/y5sfuXN+O7Xnjh9iRftNe/g6f4RXAYb7l72019RLcGWVq7OftXBq8AI4WKV
oVrqMCIje0GhgNbb2DJEznFdwQCAvzlFqRdlJoY1pNvBceZm3pxEA148IjtB
KSFQm2g1N1GVym6nHvqJKxkvy6lkGnBNwtxNqa1fGZDgVEG/WkBdE6kTRJQA
NFHwSiID18MhA2n3ycPRqlYmpnQ8r5VyaBdS8EoGd7S+t3idebq6h6Gdb/Rj
dZttdgMYHhQJX41U3NXTGxnt5N7a0bbaCDHDnb+pj4Y5Wj1Ot9M0knah9Whb
bF2gqq/qiY5Q0JFsZCXuVRgqwfOuk1ndEmpkCXnsDUxp3U2iSKh0o9G7wtiv
SUhNeN2Uk+xZX42tMTlrZPRjiFHGmBeCMFWSd8Aeyoo8U6oomZfItQD7OEe0
zRoyIiTPCXlQjBljoAQViM0BwA4mwBIY951CVwrUCnlpPA03RONFcbgZgNVk
bcUOlGInGAWKIfhLPUjXNSFmjjFELlNv6/NuTe4YheAI4WZrkiXDGYgd5pbM
Isx6+9ziLnOF3U49W8hC3zzxhi22bbOcm9LJfe0SavH/k7OIlNFx04bkLFV8
pA0cAWGbxuVGjNN/iwe1xnkCzHXcJww/li2OBk1sqvUiVZzQ20BpGDuOPg3g
uF+4f9jmE/XpREC5RnufcdIDAmbnRMmn0oXD9py99G4p/0lJzjJlyTHzbblT
EThij23NrJskzUGrJJ6E6RxVXU2S1PiaJg3KHsM/ZiGIxpxvSz4RkfBuzeft
LPfcvWFNy4xSVlWSMnCNdazj466TTuwJnRH2cssRlrEMmD3FqGefnOA//viD
1+NpQ+5nv+HaQcO1Q9PFPtw+FEfimTgWP4jn4sXnXKNO/tN75H/Uy0cDIigP
7u9LMKOgEh8t6TfD0fDm5+FZdUIfNZI8mhrdzx8rLKuIrRVYMQKVUqsM/kPs
iqAycHY+RiIMVZwarZ2fchJeRmicmJg4PRDiuTeGILwAsZxyLhgwTKU9RliT
BqrqLEqojQVV9bxWPeRkoAY0vU+0gLvbHyzsg5K21Q0QorMnbl+e7feErCSt
M8VHEY76BzotY+bXultS9nbQ3tthX+isXUUIB+t5pa2RFlgwzg7j9PoceYmf
K+whzLN+fUWaZWvAfug44mwJbYVgSiJiGsCJORLUK2DZRa4xKmPsAECj/Arn
fcZLlyQa2AFDjA3BHHFm0NnT0E+BV1ZrWdkIp+330Fi0q5Nf0I5iGpAfRmLG
S8fto9Hxlt4GoxbGhvGozgYZEYW5mHkSYE4hzCuDa74RtmY5p+/EJHwAVzsL
f1fiiW7Aq/CEp045CMvbakPk/hMeQq+cXROdEapspuEBgjAukiIDm40pT4XO
M8QlS/D/+DG4SiZGz1vGZGPOtGmOiGydpHOsjMnLrSaZ9ZzNnhm7ijjxhh1E
PYXQ7BdBxxo/DqoWZRcmZSc2ZUeoaayGyxOhDYxw7ovzSE7h1xB/05qAEvP9
nZIj2pH8oH3haIGEwTe3GarGd/vHAkAp+35A2UufIr/6rgHpEO7x1k6XlPFD
u7Nb+h+HGLGgBGmMp15RaGUEAZ8ZvZ7wI++8EuWW8vb5rC0f/Ch+plNSpWfg
ssZdZWq9ixGfPjyFD454ozDJC7Nr/+xqxH0e8SUg0H0YgGUpT2p9pREPeMS/
hznIQ/twOxzxkEc8ozzrugF3NuIRj3iJhwVpVAT435pmvKsRn+GIbyMwlF60
ftQvH1G04wx9rCKv6IrWym4HodA4OhP4nvGZFYyTABOHZEU4gtzn3ZsK6Gy5
t8X+lUHaQbNb1XdcKcdL6NEGFTs8xvyZcNB1JsLMTVM0oKsxvpopR38NW2g+
LkMuasFU4+fj16RmWOYfGAReFgFmOP5FqPnZ7o0007VbavCzor5GStsk2Spw
dWEH4vAA3QOKDex56VJNYYoQjLwHO2r3HzmM3KTAlQxWt7NQKfqglNB1CCiy
+pWLM9KzlgVvJrdyJNpJVel9OV4Sk1qrEc5Qs3FFv2TgcsesRkK3UydCHzlp
279sc+bXtRZr/PpnPOt/ZzBrZo1x+1Ch2anXCir+dMfersX6VZyVPj7ZxNZp
tTr6xrlvdt/dbQRKVBtb+d45aVXZfymz25gJQFMelRtHbfl0WTtNuFUiXw9d
E95jY4jrgvjFbtHqYpngYaMgVT5f7pg1UKCDCaDgbYz7F+T6bPrsnoJ9pOAm
nM5ysz9slnX5J1FwgBSco43h4zBgSsIEBFy00LN7Cg6RglPnRM4GEj7uVhaJ
hqMaF+Ik9taRsXsuPKtzYQMJj6dA1Ek4rjEBk2j6jFURfxUmmMfrlPzQTkmk
Jqu6shNmtJmQ4zUgtTFwc+Kslvz1TgOtZkrd9rV398zGnt48BxequpvuvIwM
PZBryolqCEF1PhmuOOf89F42ZV0n5nBdVksut+e70Jyadyp0ry71OkmryQ8o
jUtnE5LUZHL5aX0ciLLR5a4+b+7hJc06iZuoEZCNpldvQWQ20dZ+yptkdm/P
3Y7F8atIfqqlU5+Laz4z0WSae3x01x5P0NvHaaOd6AH/dWYRt+bpDQZMlD+E
82LOR4kYPkiMKI9g/ZYyncDWqFdzblwvxfFRKpQ1U9UXLLLlezeVnWNXqHRO
3yTe+d01rSPV9cFFMbtV/64bsQ2fK15L5xBOq1B+3NE27Mq2p8bCH7YUeI2K
q5SbSK8uafYM8nx1srShxCKu92JI71RJBpmKSzIV18Zkvny8Ftqj9pfNfkmp
BwzBQCaqE24+IvV4Ai/D8z6MgvdhFNEBJlYkfY6Lz3HqL2X4nG3W1oMv0dbJ
Fp7e19Tdv5Timo99X6k91bcjxa3ordbZ5zWd3U5ZtAY7pNcjXydlpbfbzbHT
mohLk4Uxk21SYXZ9v44Or1Fc7VBM+K0IG1P/bg4o0rT0a1rTVMZFJFM8tknh
uPsaQVaMS/25NefitkWObsdCBx5U1ieQlATYoN+fCR5leQWHxM2IcvgliOJv
E7l9g5RdQQq/KbnNnsFXgBSNKC9qiLKV7gqLKXYK37EvsJJT08gC+siW04ii
4vfCLKzUA5HKO3atKrDWfXjlRt07gJ/JhpxCqUrVEiAYGKEbxEdvtC/PB7Bd
f4jeTOZBVlBgs74fPdKDWJ+i+KbxO9H4P9/7X0OLlsp/SiRiTl0+bfdn1mqv
qESOnxOcrI9J1ukgu/GrbGsdaZXBnzXSJs9q1/Dmb0pYPhbfvsyRefZYR2Yt
svW/Ids3ZNsNLbVQbX9/jWe1QXc/O+WyAdWaNE/sFs5alXuDk3ZTvrL41m5M
uCh2UXFT1u5jcIRo0s9MI72HFM4h0otoCzcqFJ2x15lrKkKqjznDKP+RWVba
CmJ4nhkPaOHrRVHiEzCYF9OJHIQCfFs+UnxEFBi0GdaOH+mvrWXE10e1vwqu
EZ5oiXDk4WtjyZoU1MgVvbbP7l7i2UTOOe76zBgV2snZOcwakD1odyA3IEsN
Y53FRQQU61DWFQQLHaTy7uK0dtMCI9WeHL62dmQT7aafGgrVutwWhy/dbdmt
oLhxI/efg8Y9fGcby/3g/L8ImX94JDLfbODLN5fzGzTvgpp/KWgWYhM5wyic
UjWhtfTsPNVgDMXhVoaiBfr+eraislobN3ptnaYSeqvd4dvuQ/d1carfh69v
O2VB1r7+XnnZ3PMrT5v34besPmeO4Ky8w6VfLq+8fzVWM3kXJkUqJL/Uus2L
Xnn1ULcpTsTVIsoDOW7Fo/aqEfa1TWMi3HoiuufWshl8/qX21j08QEdT+a0N
t4iEKUrHryzz0qAVYlODtzLgWxJhxbh+5R0Za9JWC+NSGT4YfqpiCHl9W01C
n842t81+AJZUiKJamYLmIlE4aOWQrUu3WyqAKglwCabyBJEPT4QBLrTpvbny
7YXDTspxmRHNG8ROZTUqpx3Ow1yZEmyrpW/1u6gkpfb0U3XtsWA2r75ZdMfx
KEuEufU5ZT5rqJ7ULhirYkF1mCp1INoL0/Tra+/UiTFbyCa5adDBFDXETWVz
8LnKI6eeXlgt96vl01HbbmdFcc2GqganDLTW19uvLTpdLYTXdu7b5TP98RaP
Cur3xShpKyziG+beheqeVU62nC+3hPL0SrqN4lvY4CvlwlXYxfMLzBvOgLZJ
YIq5rsfCPaojXGTKLNzQFJg/G51e/9ftKVtNbIrNbCUDuClI3nRrdmapCKHM
kpjW1xYepKU2R2toPzyjoolYdD5A3v6uauILfL+4vjvSZ9vzVAak2DKiYo1O
xSaufFgXK5SpJbS6XzmGj/5+MZ2qTCtpSnOnV+hTsHo4Alo7WmqGV5qqdNPp
TaXDeP3mgGPEjTSZ6wc13pV1UKqoXVFLwpRuxz0YqY8McnH9KAIaWBvqhzBe
wVxPddGUsrIMvQuBZPDrNxUlxKMQIRVhBhJnuO1KNTxpOQt0KYzOV5hzBgiK
zotVbGmtRhXD9H23wkBDaSP73jMXA0gCoy4atuvlvqv2yZ4A1S1CrifH9Qdx
arQOtXI1iJemSLdzyFV3YXV32zrfupZ/t6NLfYurVydaTjb/TR3ceqFiyw11
KBv+Wg+/7MGFm5seafzzNqZMNEQofkFnXmru14e9TN9pcq3sU36r04bVkakG
Tymv+s5J6s/AHPo5oqxTtNeUY69CPJauqpTM1n//yPlBZVidh7MW6rhc5VMc
i9e4rSEIqi1W3fjKTVuZ7lSx4OoKtxp46JQSluwIYMaVl3kqhc/1ilycgKys
rEYoQVwaVoJau1W7JJYjA3kCqJviXwmhP2sViCdO8XqNA090rQFuVimVuFpH
yvbKXhZhuh7GlKFBRQVXMDQFJVs6YqOADUwdUzIsDAZu5Srjz5VZDXcE5HUb
JynxgVVtBrb+S0vxG93woGy4scKNiV5O/Hdxch+pYKqLaH7Yk7VLn2grGufA
f1otE/eEJFH4TnGhMNteXCuY4GVY9MRLmM6t5PP4VAsCnkyKKb5ehr4DSTro
1ZLq1k2KiGCR6iebPyw0ho67nf8HGaJwYZluAAA=

-->

</rfc>
