<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC1195 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml"> nbsp    "&#160;">
  <!ENTITY RFC2212 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2212.xml"> zwsp   "&#8203;">
  <!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml"> nbhy   "&#8209;">
  <!ENTITY RFC6658 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6658.xml">
<!ENTITY RFC7806 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7806.xml">
<!ENTITY RFC8578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8578.xml">
<!ENTITY RFC8655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8655.xml">
<!ENTITY RFC8939 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8939.xml">
<!ENTITY RFC8964 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8964.xml">
<!ENTITY RFC9023 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9023.xml">
<!ENTITY I-D.ietf-detnet-ip SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-detnet-ip-05.xml">
<!ENTITY I-D.ietf-detnet-mpls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-detnet-mpls-05.xml"> wj     "&#8288;">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-detnet-bounded-latency-10" ipr="trust200902"> number="9320" submissionType="IETF" category="info" consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.13.0 -->
  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="DetNet Bounded Latency">DetNet Latency">Deterministic Networking (DetNet) Bounded Latency</title>
    <seriesInfo name="RFC" value="9320"/>
    <author initials="N" surname="Finn" fullname="Norman Finn">
      <organization>
        Huawei Technologies Co. Ltd
      </organization>
      <address>
        <postal>
          <street>3101 Rio Way</street>
          <city>Spring Valley</city>
          <region>California</region>
          <code>91977</code>
            <country>US</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 925 980 6430</phone>
        <email>nfinn@nfinnconsulting.com</email>
      </address>
    </author>
    <author initials="J-Y" initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le Boudec">
      <organization>
        EPFL
      </organization>
      <address>
        <postal>
          <street>IC Station 14</street>
            <city>Lausanne EPFL</city>
          <city>Lausanne</city>
          <code>1015</code>
          <country>Switzerland</country>
        </postal>
        <email>jean-yves.leboudec@epfl.ch</email>
      </address>
    </author>
    <author initials="E" surname="Mohammadpour" fullname="Ehsan Mohammadpour">
      <organization>
        EPFL
      </organization>
      <address>
        <postal>
          <street>IC Station 14</street>
            <city>Lausanne EPFL</city>
          <city>Lausanne</city>
          <code>1015</code>
          <country>Switzerland</country>
        </postal>
        <email>ehsan.mohammadpour@epfl.ch</email>
      </address>
    </author>
    <author initials="J" surname="Zhang" fullname="Jiayi Zhang">
      <organization>
        Huawei Technologies Co. Ltd
      </organization>
      <address>
        <postal>
          <street>Q27, No.156 Beiqing Road</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>zhangjiayi11@huawei.com</email>
      </address>
    </author>
    <author fullname="Bal&aacute;zs fullname="Balázs Varga" initials="B." surname="Varga">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Konyves K&aacute;lm&aacute;n Kálmán krt. 11/B</street>
          <city>Budapest</city>
          <country>Hungary</country>
          <code>1097</code>
        </postal>
        <email>balazs.a.varga@ericsson.com</email>
      </address>
    </author>
    <date month="April" day="8" year="2022" />

<area>Routing</area>

<workgroup>DetNet</workgroup>

<keyword>DetNet, bounded latency, zero month="November" year="2022"/>
    <area>rtg</area>
    <workgroup>detnet</workgroup>
    <keyword>DetNet</keyword>
    <keyword>bounded latency</keyword>
    <keyword>zero congestion loss</keyword>
    <abstract>
    <!--
    <t>
        This document presents a timing model for sources, destinations, and the DetNet transit nodes. Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing mechanisms which can be used by the management and control planes to provide DetNet qualities of service. Hence, it is possible for an implementer, user, or standards development organization to select a set of queuing mechanisms for each device in a DetNet network, and to select a resource reservation algorithm for that network, so that those elements can work together to provide the DetNet service.

    </t> -->
    <t>
        This document presents a timing model for sources, destinations, and DetNet 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>
  <!-- ***** MIDDLE MATTER ***** -->

<middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The ability for IETF Deterministic Networking (DetNet) or IEEE 802.1 Time-Sensitive
        Networking <xref target="IEEE8021TSN"/> target="IEEE8021TSN" format="default"/> to provide the DetNet services of bounded latency and zero congestion
        loss depends upon </t>
    <t>
        <list style="hanging">
            <t> A) configuring
      <ol spacing="normal" type="A">
        <li>configuring and allocating network resources for the exclusive use of DetNet flows; </t>
            <t> B) identifying, </li>
        <li>identifying, in the data plane, the resources to be utilized by any given packet;</t>
            <t> C) the packet; and</li>
        <li>the detailed behavior of those resources, especially transmission queue selection, so that latency bounds can be reliably assured.
            </t>
        </list>
    </t> assured.</li>
      </ol>
      <t>
        As explained in <xref target="RFC8655"/>, target="RFC8655" format="default"/>, DetNet
        flows are notably characterized by
      </t>
    <t>
        <list style="numbers">
            <t>a
      <ol spacing="normal" type="1">
	<li>a maximum bandwidth, guaranteed either by the transmitter or by strict input metering; </t>
            <t>a metering, and </li>
        <li>a requirement for a guaranteed worst-case end-to-end latency.</t>
        </list>
    </t> latency.</li>
      </ol>
      <t>  That latency guarantee,
        in turn, provides the opportunity for the network to supply enough buffer
        space to guarantee zero congestion loss.
        It
        In this document, it is assumed in this document  that the paths of DetNet flows are fixed. Before the transmission of a DetNet flow, it is possible to calculate
        end-to-end latency bounds and the amount of buffer space required at each hop to ensure zero congestion loss; this can be used by the applications identified in <xref target="RFC8578"/>.
    </t>
<!--     <t>
        To be used by the applications identified in
        <xref target="RFC8578"/>, it is possible to calculate,
        before the transmission of a DetNet flow commences, both the worst-case
        end-to-end network latency, and the amount of buffer space required at each hop to
        ensure against congestion loss. target="RFC8578" format="default"/>.
      </t> -->
    <t>
        This document presents a timing model for sources, destinations, and the
        DetNet transit nodes; using this model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing mechanisms that can be used by the management and control planes to provide DetNet qualities of service. The methodology used in this document account accounts for the possibility of packet reordering within a DetNet node. The bounds on the amount of packet reordering is out of the scope of this document and can be found in <xref target="PacketReorderingBounds"/>. target="PacketReorderingBounds" format="default"/>. Moreover, this document references specific queuing mechanisms, mentioned in <xref target="RFC8655"/>, target="RFC8655" format="default"/>, as proofs of concept that can be used to control packet transmission at each output port and achieve the DetNet quality of service.
    </t><t> service (QoS).
      </t>
      <t>
        Using the model presented in this document, it is possible for an
        implementer, user, or standards development organization to select
        a set of queuing mechanisms for each device in a DetNet network, network
        and to select a resource reservation algorithm for that network, network so that
        those elements can work together to provide the DetNet service. <xref target="example"/> target="example" format="default"/> provides an example application of the timing model introduced in this document on a DetNet IP network with a combination of different queuing mechanisms.
    </t><t>
      </t>
      <t>
        This document does not specify any resource reservation protocol or control plane function.
        <!-- It disregards the in-band packets that can be part of the stream such as OAM and necessary re-transmissions. -->
        It does not describe all of the requirements for that protocol or control plane function.
        It does describe requirements for such resource reservation methods, methods
        and for queuing mechanisms that, if met, will enable them to work together.
      </t>
    </section>
    <section title="Terminology numbered="true" toc="default">
      <name>Terminology and Definitions"> Definitions</name>
      <t>
    This document uses the terms defined in <xref target="RFC8655"/>. target="RFC8655" format="default"/>. Moreover, the following terms are used in this document:
      </t>
    <t>
       <list style="hanging">
            <t hangText="T-SPEC"><vspace blankLines="0"/>
                  TrafficSpecification
      <dl newline="true" spacing="normal">
        <dt>T-SPEC</dt>
        <dd>TrafficSpecification, as defined in Section 5.5 of <xref target="RFC9016"/>.
            </t>
            <t hangText="arrival curve"><vspace blankLines="0"/>
                An target="RFC9016" section="5.5" sectionFormat="of" format="default"/>.
            </dd>
        <dt>arrival curve</dt>
        <dd>An arrival curve function alpha(t) is an upper bound on the number of bits seen at an observation point within any time interval t.
            </t>
            <t hangText="CQF"><vspace blankLines="0"/>
                Cyclic
            </dd>
        <dt>CQF</dt>
        <dd>Cyclic Queuing and Forwarding.
            </t>
            <t hangText="CBS"><vspace blankLines="0"/>
                Credit-based
            </dd>
        <dt>CBS</dt>
        <dd>Credit-Based Shaper.
            </t>
            <t hangText="TSN"><vspace blankLines="0"/>
                Time-Sensitive
            </dd>
        <dt>TSN</dt>
        <dd>Time-Sensitive Networking.
            </t>
            <t hangText="PREOF"><vspace blankLines="0"/>
                A
            </dd>
        <dt>PREOF</dt>
        <dd>A collective name for Packet Replication, Elimination, and Ordering Functions.
            </t>
            <t hangText="Packet
            </dd>
        <dt>POF</dt>
        <dd>A Packet Ordering Function (POF)"><vspace blankLines="0"/>
                A is a function that reorders packets within a DetNet flow that are received out of order.  This function can be implemented by a DetNet edge node, a DetNet relay node, or an end system.
            </t>
        </list>
    </t>
            </dd>
      </dl>
    </section>
    <section title="DetNet bounded latency model"> numbered="true" toc="default">
      <name>DetNet Bounded Latency Model</name>
      <section title="Flow admission" anchor="flow-admission"> anchor="flow-admission" numbered="true" toc="default">
        <name>Flow Admission</name>
        <t>
            This document assumes that the following paradigm is used to admit DetNet flows:
        </t><t>
            <list style="numbers">
                <t>
        </t>
        <ol spacing="normal" type="1">
	  <li>
                    Perform any configuration required by the DetNet transit nodes in the network for aggregates of DetNet flows.
                    This configuration is done beforehand, beforehand and not tied to any particular DetNet flow.
                </t><t>
                </li>
          <li>
                    Characterize the new DetNet flow, particularly in terms of required bandwidth.
                </t><t>
                </li>
          <li>
                    Establish the path that the DetNet flow will take through the network
                    from the source to the destination(s).  This can be a point-to-point
                    or a point-to-multipoint path.
                </t><t>
                </li>
          <li>
                    Compute the worst-case end-to-end latency for the DetNet flow, flow using one
                    of the methods, methods below (<xref target="static-calculation"/>, (Sections <xref target="static-calculation" format="counter"/> and
                    <xref target="dynamic-calculation"/>). target="dynamic-calculation" format="counter"/>).  In the process,
                    determine whether sufficient resources are available for the DetNet flow to
                    guarantee the required latency and to provide zero congestion loss.
                </t><t>
                </li>
          <li>
                    Assuming that the resources are available, commit those resources to the
                    DetNet flow.  This may or may not require adjusting the parameters that control
                    the filtering and/or queuing mechanisms at each hop along the DetNet flow's path.
                </t>
            </list>
        </t>
                </li>
        </ol>
        <t>
            This paradigm can be implemented using peer-to-peer protocols or using a
            central controller.  In some situations, a lack of resources can require
            backtracking and recursing through the above list.
        </t><t>
            Issues
        </t>
        <t>
            Issues, such as service preemption of a DetNet flow in favor of another, when
            resources are scarce, are not considered here. Also not addressed is the question of
            how to choose the path to be taken by a DetNet flow.
        </t>
        <section title="Static latency-calculation" anchor="static-calculation">
            <t>
                <list hangIndent="8" style="hanging">
                    <t hangText="The anchor="static-calculation" numbered="true" toc="default">
          <name>Static Latency Calculation</name>
          <dl newline="true" spacing="normal" indent="8">
            <dt>The static problem:"><vspace blankLines="0"/> problem:</dt>
            <dd>
                        Given a network and a set of DetNet flows, compute an
                        end-to-end latency bound (if computable) for each DetNet flow, flow and compute
                        the resources, particularly buffer space, required in each DetNet transit node
                        to achieve zero congestion loss.
                    </t>
                </list>
            </t><t>
                    </dd>
          </dl>
          <t>
                In this calculation, all of the DetNet flows are known before the
                calculation commences.  This problem is of interest to relatively
                static networks, networks or static parts of larger networks. It provides
                bounds on latency and buffer size.  The calculations can be extended
                to provide global optimizations, such as altering the path of one
                DetNet flow in order to make resources available to another DetNet
                flow with tighter constraints.
          </t>
            <!-- <t>
                The static latency calculation is not limited only to static
                networks; the entire calculation for all DetNet flows can be
                repeated each time a new DetNet flow is created or deleted.  If
                some already-established DetNet flow would be pushed beyond its latency
                requirements by the new DetNet flow, then the new DetNet flow can be refused,
                or some other suitable action taken.
            </t> -->
            <t>
                This calculation may be more difficult to perform than the
                dynamic calculation (<xref target="dynamic-calculation"/>), target="dynamic-calculation" format="default"/>) because the
                DetNet flows passing through one port on a DetNet transit node affect each other's
                latency.  The effects can even be circular, from a node A to B to C
                and back to A.  On the other hand, the static calculation can often
                accommodate queuing methods, such as transmission selection by
                strict priority, that are unsuitable for the dynamic calculation.
          </t>
        </section>
        <section title="Dynamic latency-calculation" anchor="dynamic-calculation">
            <t>
                <list hangIndent="8" style="hanging">
                    <t hangText="The anchor="dynamic-calculation" numbered="true" toc="default">
          <name>Dynamic Latency Calculation</name>
          <dl newline="true" spacing="normal" indent="8">
            <dt>The dynamic problem:"><vspace blankLines="0"/> problem:</dt>
            <dd>
                        Given a network whose maximum capacity for DetNet flows is
                        bounded by a set of static configuration parameters applied to the
                        DetNet transit nodes, nodes and given just one DetNet flow, compute the worst-case
                        end-to-end latency that can be experienced by that flow, no
                        matter what other DetNet flows (within the network's configured parameters)
                        might be created or deleted in the future.  Also, compute the resources,
                        particularly buffer space, required in each DetNet transit node
                        to achieve zero congestion loss.
                    </t>
                </list>
            </t><t>
                    </dd>
          </dl>
          <t>
                This calculation is dynamic, in the sense that DetNet flows can be added or deleted
                at any time, with a minimum of computation effort, effort and without affecting
                the guarantees already given to other DetNet flows.
          </t>
          <t>
                Dynamic latency-calculation latency calculation can be done based on the static one described in <xref target="static-calculation"/>; target="static-calculation" format="default"/>;
                when a new DetNet flow is created or deleted, the entire calculation for all DetNet flows is
                repeated.  If an already-established DetNet flow would be pushed beyond its latency
                requirements by the new DetNet flow request, then the new DetNet flow request can be refused, refused
                or some other suitable action can be taken.
          </t>
          <t>
                The choice of queuing methods is critical to the applicability of the
                dynamic calculation.  Some queuing methods (e.g., CQF, <xref target="cqf"/>) target="cqf" format="default"/>) make
                it easy to configure bounds on the network's capacity, capacity and to make
                independent calculations for each DetNet flow. Some other queuing methods (e.g., strict priority with the credit-based shaper
                defined in Section 8.6.8.2 of <xref target="IEEE8021Q"/> section 8.6.8.2) target="IEEE8021Q" format="default"/>) can be used for dynamic DetNet flow creation, creation
                but yield poorer latency and buffer space guarantees than when that same
                queuing method is used for static DetNet flow creation
                (<xref target="static-calculation"/>). target="static-calculation" format="default"/>).
          </t>
        </section>
      </section>
      <section anchor="relay_model" title="Relay node model"> numbered="true" toc="default">
        <name>Relay Node Model</name>
        <t>A model for the operation of a DetNet transit node is required, required in order to
            define the latency and buffer calculations.
            In <xref target="fig_timing_model"/> target="fig_timing_model" format="default"/>, we see a breakdown of the per-hop latency experienced by a packet passing through a DetNet transit node, node in
        terms that are suitable for computing both hop-by-hop latency and per-hop buffer requirements.</t>
        <figure title="Timing model anchor="fig_timing_model">
          <name>Timing Model for DetNet or TSN" anchor="fig_timing_model"> TSN</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
      DetNet transit node A            DetNet transit node B
   +-------------------------+       +------------------------+
   |              Queuing    |       |              Queuing   |
   |   Regulator subsystem   |       |   Regulator subsystem  |
   |   +-+-+-+-+ +-+-+-+-+   |       |   +-+-+-+-+ +-+-+-+-+  |
-->+   | | | | | | | | | +   +------>+   | | | | | | | | | +  +--->
   |   +-+-+-+-+ +-+-+-+-+   |       |   +-+-+-+-+ +-+-+-+-+  |
   |                         |       |                        |
   +-------------------------+       +------------------------+
   |<->|<------>|<------->|<->|<---->|<->|<------>|<------>|<->|<--
2,3  4      5        6      1    2,3   4      5        6     1   2,3
          1: Output delay             4: Processing delay
          2: Link delay               5: Regulation delay
          3: Frame preemption delay   6: Queuing subsystem delay
]]></artwork>
        </figure>
        <t>In <xref target="fig_timing_model"/>, target="fig_timing_model" format="default"/>, we see two DetNet transit nodes that are connected via a link. In this model, the only queues, queues that we deal
                with explicitly, explicitly are attached to the output port; other queues are modeled as variations
                in the other delay times (e.g., an input queue could be modeled as either a variation
                in the link delay (2) or the processing delay (4).) (4)).  There are six delays that a packet
                can experience from hop to hop.</t>
            <t><list style="hanging">
                <t hangText="1. Output delay"><vspace blankLines="0"/>
                    The
        <ol spacing="normal" type="1">
          <li><t>Output delay</t>
          <t>
            This is the time taken from the selection of a packet for output from
	    a queue to the
                    transmission of the first bit of the packet on the physical link.  If the
                    queue is directly attached to the physical port, output delay can be a constant.
                    But,
		    However, in many implementations, a multiplexed connection separates the queuing mechanism in a forwarding ASIC is
                    separated from a multi-port MAC/PHY, in a second ASIC, by a multiplexed connection. Network Interface Card (NIC).
                    This causes variations in the output delay that are hard for the forwarding node
                    to predict or control.
                </t>
                <t hangText="2. Link delay"><vspace blankLines="0"/>
                    The
                </t></li>
		<li><t>Link delay</t>
          <t>
            This is the time taken from the transmission of the first bit of the
	    packet to the
                    reception of the last bit, assuming that the transmission is not suspended by
                    a frame preemption event.  This delay has two components, components: the first-bit-out to first-bit-in delay and the first-bit-in to last-bit-in delay that varies with packet  size.  The former is typically measured by the Precision Time
                    Protocol and is constant (see <xref target="RFC8655"/>). constant.  However,
                    a virtual "link" could exhibit a variable link delay.</t>
                <t hangText="3. Frame delay.</t></li>
          <li><t>Frame preemption delay"><vspace blankLines="0"/> delay</t>
          <t>
            If the packet is interrupted in order to transmit another packet or packets, packets
	    (e.g., frame preemption, as in <xref target="IEEE8023"/> target="IEEE8023" format="default"/>, clause 99 frame preemption) 99),
                    an arbitrary delay can result.</t>
                <t hangText="4. Processing delay"><vspace blankLines="0"/> result.</t></li>
          <li><t>Processing delay</t>
          <t>
                    This delay covers the time from the reception of the last bit of the packet to the
                    time the packet is enqueued in the regulator (queuing subsystem, subsystem if there is no regulator) regulator), as shown in <xref target="fig_timing_model"/>. target="fig_timing_model" format="default"/>.
                    This delay can be variable, variable and depends on the details of the operation of the forwarding node.</t>
                <t hangText="5. Regulator delay"><vspace blankLines="0"/> node.</t></li>
          <li><t>Regulator queuing delay</t>
          <t>
                    A regulator, also known as shaper in <xref target="RFC2475"/>, target="RFC2475" format="default"/>, delays some or all of the packets in a traffic stream in order to bring the stream into compliance with an arrival curve; an arrival curve 'alpha(t)' is an upper bound on the number of bits observed within any interval t. The regulator delay is the time spent from the insertion of the last bit of a packet into a regulation queue until the time the packet is declared eligible according to its regulation constraints. We assume that this time can be calculated based on the details of regulation policy. If there is no regulation, this time is zero.</t>
                <t hangText="6. Queuing zero.</t></li>
          <li><t>Queuing subsystem delay"><vspace blankLines="0"/> delay</t>
          <t>
                    This is the time spent for a packet from being declared eligible until being
                    selected for output on the next link.  We assume that this time is
                    calculable based on the details of the queuing mechanism. If there is no regulation, this time is from the insertion
                    of the packet into a queue until it is selected for output on the next link.</t>
            </list></t> link.
		  </t></li>
		</ol>
        <t>Not shown in <xref target="fig_timing_model"/> target="fig_timing_model" format="default"/> are the other output queues that we
                presume are also attached to that same output port as the queue shown, and against
                which this shown queue competes for transmission opportunities.</t>
        <t>In this analysis, the measurement is from the point at which a packet is selected for output in a node to the point at which it is selected for output in the next downstream node (that is (i.e., the definition of a "hop").  In general,
                any queue selection method that is suitable for use in a DetNet network includes
                a detailed specification as to exactly when packets are selected for transmission.
                Any variations in any of the delay times 1-4 result in a need for additional
                buffers in the queue.  If all delays 1-4 are constant, then any variation in the
                time at which packets are inserted into a queue depends entirely on the timing
                of packet selection in the previous node.  If the delays 1-4 are not constant,
                then additional buffers are required in the queue to absorb these variations.
                Thus:
                <list style="symbols">
                    <t>Variations
        </t>
        <ul spacing="normal">
          <li>Variations in the output delay (1) require buffers to absorb that variation
                        in the next hop, so the output delay variations of the previous hop (on each
                        input port) must be known in order to calculate the buffer space required
                        on this hop.</t>
                    <t>Variations hop.</li>
          <li>Variations in the processing delay (4) require additional output buffers
                        in the queues of that same DetNet transit node.  Depending on the details
                        of the queuing subsystem delay (6) calculations, these variations need not be
                        visible outside the DetNet transit node.
                    </t>
                </list></t>
                    </li>
        </ul>
      </section>
    </section>
    <section anchor="e2eLatency" title="Computing End-to-end numbered="true" toc="default">
      <name>Computing End-to-End Delay Bounds"> Bounds</name>
      <section title="Non-queuing delay bound" anchor="nonqueuing"> anchor="nonqueuing" numbered="true" toc="default">
        <name>Non-queuing Delay Bound</name>
        <t>End-to-end latency bounds can be computed using the delay model in <xref target="relay_model"/>. target="relay_model" format="default"/>. Here, it is important
        to be aware that that, for several queuing mechanisms, the end-to-end latency bound is less than the sum of the
        per-hop latency bounds.
        An end-to-end latency bound for one DetNet flow
        can be computed as
        </t>
    <t>
        <list style="hanging">
            <t>
        <t indent="3"> end_to_end_delay_bound = non_queuing_delay_bound + queuing_delay_bound
            </t>
        </list>
    </t>

        <t>The two terms in the above formula are computed as follows. </t>
        <t>
        First, at the h-th hop along the path of this DetNet flow, obtain an upper-bound
        per-hop_non_queuing_delay_bound[h] on the sum of the bounds over the delays
        1,2,3,4
        1, 2, 3, and 4
        of  <xref target="fig_timing_model"/>. target="fig_timing_model" format="default"/>. These upper bounds are expected to
        depend on the specific technology of the DetNet transit node at the h-th hop but not on
        the T-SPEC of this DetNet flow <xref target="RFC9016"/>. Then target="RFC9016" format="default"/>. Then, set non_queuing_delay_bound = the sum
        of per-hop_non_queuing_delay_bound[h] over all hops h.
        </t>
        <t>
        Second, compute queuing_delay_bound as an upper bound to the sum of the
        queuing delays along the path. The value of queuing_delay_bound depends
        on the information on the arrival curve of this DetNet flow and possibly
        of other flows in the network, as well as the specifics of the queuing
        mechanisms deployed along the path of this DetNet flow. Note that arrival curve of the DetNet flow at the source is immediately specified by the T-SPEC of this flow. The computation of queuing_delay_bound
        is described in <xref target="queuing"/> target="queuing" format="default"/> as a separate section.
        </t>
      </section>
      <section title="Queuing delay bound" anchor="queuing"> anchor="queuing" numbered="true" toc="default">
        <name>Queuing Delay Bound</name>
        <t>
        For several queuing mechanisms, queuing_delay_bound is less than the sum of upper bounds on the queuing delays (5,6) (5 and 6)
        at every hop.  This occurs with (1) per-flow queuing, queuing and (2) aggregate queuing with regulators, as explained in Sections <xref target="perflow"/>, target="perflow" format="counter"/>, <xref target="perclass"/>, target="perclass" format="counter"/>, and <xref target="queue_model"/>. target="queue_model" format="counter"/>. For other queuing mechanisms mechanisms, the only available value of queuing_delay_bound
        is the sum of the per-hop queuing delay bounds.
        </t>
        <t>
        The computation of per-hop queuing delay bounds must account for the fact that the arrival curve of a DetNet flow is no longer satisfied at the ingress of a hop, since burstiness increases as one flow traverses one DetNet transit node. If a regulator is placed at a hop, an arrival curve of a DetNet flow at the entrance of the queuing subsystem of this hop is the one configured at the regulator (also called shaping curve in <xref target="NetCalBook"/>); target="NetCalBook" format="default"/>); otherwise, an arrival curve of the flow can be derived using the delay-jitter delay jitter of the flow from the last regulation point (the last regulator in the path of the flow if there is any, otherwise the source of the flow) to the ingress of the hop; more formally, assume a DetNet flow has an arrival curve at the last regulation point equal to 'alpha(t)', 'alpha(t)' and the delay-jitter delay jitter from the last regulation point to the ingress of the hop is 'V'. Then, the arrival curve at the ingress of the hop is 'alpha(t+V)'.
        </t>
        <t>
        For example, consider a DetNet flow with T-SPEC "Interval: tau, MaxPacketsPerInterval: K, MaxPayloadSize: L" at the source. Then, a leaky-bucket arrival curve for such flow at the source is alpha(t)=r * t+ b, t>0; t&gt;0; alpha(0)=0, where r is the rate and b is the bucket size, computed as
        </t>
    <t>
        <list style="hanging">
           <t>
                r
        <t indent="3">r =  K * (L+L') / tau,
           </t>
           <t>
                b
           <t indent="3">b = K * (L+L').
           </t>
         </list>
    </t>
        <t>
        where L' is the size of any added networking technology-specific encapsulation (e.g., MPLS label(s), UDP, and or IP headers). Now, if the flow has delay-jitter a delay jitter of 'V' from the last regulation point to the ingress of a hop, an arrival curve at this point is r * t + b + r * V, implying that the burstiness is increased by r*V. A more More detailed information on arrival curves is available in <xref target="NetCalBook"/>. target="NetCalBook" format="default"/>.
        </t>
        <section title="Per-flow queuing mechanisms" anchor="perflow"> anchor="perflow" numbered="true" toc="default">
          <name>Per-Flow Queuing Mechanisms</name>
<t>
            With such mechanisms, each flow uses a separate queue inside every node. The service for each queue is abstracted with a guaranteed rate and a latency. For every DetNet flow, a per-node latency bound bound, as well as an end-to-end latency bound bound, can be computed from the traffic specification of this DetNet flow at its source and from the values of rates and latencies at all nodes along its path. An instance of per-flow queuing is IntServ's Guaranteed-Service, Guaranteed Service <xref target="RFC2212" format="default"/>, for which the details of latency bound calculation are presented in <xref target="intserv"/>. target="intserv" format="default"/>.
          </t>
        </section>
        <section title="Aggregate queuing mechanisms" anchor="perclass"> anchor="perclass" numbered="true" toc="default">
          <name>Aggregate Queuing Mechanisms</name>
          <t>
                With such mechanisms, multiple flows are aggregated into macro-flows and there is one FIFO queue per macro-flow. A practical example is the credit-based shaper defined in section Section 8.6.8.2 of <xref target="IEEE8021Q"/> target="IEEE8021Q" format="default"/>, where a macro-flow is called a "class".  One key issue in this context is how to deal with the burstiness cascade: cascade; individual flows that share a resource dedicated to a macro-flow may see their burstiness increase, which may in turn cause increased burstiness to other flows downstream of this resource. Computing delay upper bounds for such cases is difficult, and difficult and, in some conditions conditions, impossible <xref target="CharnyDelay"/><xref target="BennettDelay"/>. target="CharnyDelay" format="default"/> <xref target="BennettDelay" format="default"/>. Also, when bounds are obtained, they depend on the complete configuration, configuration and must be recomputed when one flow is added. (The added (i.e., the dynamic calculation, calculation in <xref target="dynamic-calculation"/>.) target="dynamic-calculation" format="default"/>).
          </t>
          <t>
                A solution to deal with this issue for the DetNet flows is to reshape them at every hop. This can be done with per-flow regulators (e.g., leaky bucket leaky-bucket shapers), but this requires per-flow queuing and defeats the purpose of aggregate queuing. An alternative is the interleaved regulator, which reshapes individual DetNet flows without per-flow queuing (<xref target="SpechtUBS"/>, <xref target="IEEE8021Qcr"/>). target="SpechtUBS" format="default"/> <xref target="IEEE8021Qcr" format="default"/>. With  an interleaved regulator, the packet at the head of the queue is regulated based on
its (flow) regulation constraints; it is released at the earliest time at which this is possible without violating the constraint. One key feature of a per-flow or interleaved regulator is that, that it does not increase worst-case latency bounds <xref target="LeBoudecTheory"/>. target="LeBoudecTheory" format="default"/>. Specifically, when an interleaved regulator is appended to a FIFO subsystem, it does not increase the worst-case delay of the latter; in latter. In <xref target="fig_timing_model"/>, target="fig_timing_model" format="default"/>, when the order of packets from the output of a queuing subsystem at node A to the entrance of a regulator at node B is preserved, then the regulator does not increase the worst-case latency bounds; this bounds. This is made possible if all the systems are FIFO or a DetNet packet-ordering function Packet Ordering Function (POF) is implemented just before the regulator. This property does not hold if packet reordering occurs from the output of a queuing subsystem to the entrance of the next downstream interleaved regulator, e.g., at a non-FIFO switching fabric.
          </t>
          <t>
                <xref target="fig_detnet_e2e_example"/> target="fig_detnet_e2e_example" format="default"/> shows an example of a network with 5 nodes, an aggregate queuing mechanism mechanism, and interleaved regulators regulators, as in <xref target="fig_timing_model"/>. target="fig_timing_model" format="default"/>.
                An end-to-end delay bound for DetNet flow f, traversing nodes 1 to 5, is calculated as follows:
          </t>
            <t>
                <list style="hanging">
                    <t>
	  <t indent="3"> end_to_end_latency_bound_of_flow_f = C12 + C23 + C34 + S4
                    </t>
                </list>
            </t>
          <t>
                In the above formula, Cij is a bound on the delay of the queuing subsystem in node i and interleaved regulator of node j,
                and S4 is a bound on the delay of the queuing subsystem in node 4 for DetNet flow f. In fact, using the delay definitions in
                <xref target="relay_model"/>, target="relay_model" format="default"/>, Cij is a bound on a sum of the delays 1,2,3,6 1, 2, 3, and 6 of node i and 4,5 delays 4 and 5 of node j. Similarly, S4 is a bound on
                sum of the delays 1,2,3,6 1, 2, 3, and 6 of node 4. A practical example of the queuing model and delay calculation is presented <xref target="TSNwithATSmodel"/>. target="TSNwithATSmodel" format="default"/>.
          </t>
          <figure title="End-to-end delay computation example" anchor="fig_detnet_e2e_example">
            <name>End-to-End Delay Computation Example</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
            f
  ----------------------------->
+---+   +---+   +---+   +---+   +---+
| 1 |---| 2 |---| 3 |---| 4 |---| 5 |
+---+   +---+   +---+   +---+   +---+
   \__C12_/\__C23_/\__C34_/\_S4_/
]]></artwork>
          </figure>

          <t>
                REMARK:
                If packet reordering does not occur, the end-to-end latency bound calculation provided here gives a tighter latency upper-bound upper bound than would be obtained by adding the latency bounds of each node in the path of a DetNet flow <xref target="TSNwithATS"/>. target="TSNwithATS" format="default"/>.
          </t>
        </section>
      </section>
      <section title="Ingress considerations" anchor="ingress"> anchor="ingress" numbered="true" toc="default">
        <name>Ingress Considerations</name>
        <t>
            A sender can be a DetNet node which that uses exactly the same queuing methods as its adjacent DetNet transit node, node so that the latency and buffer bounds calculations at the first hop are indistinguishable from those at a later hop within the DetNet domain. On the other hand, the sender may be DetNet-unaware, DetNet unaware; in which
            case case, some conditioning of the DetNet flow may be necessary at the ingress DetNet transit node.
        </t><t>
            This The ingress conditioning typically consists of a FIFO with an output regulator
            that is compatible with the queuing employed by the DetNet transit node on its output
            port(s).  For some queuing methods, this simply requires added buffer space in the queuing subsystem.
            Ingress conditioning requirements for different queuing methods are mentioned regulators described in the sections, below, describing those queuing methods. <xref target="relay_model" format="default"/>.
        </t>
      </section>
      <section title="Interspersed DetNet-unaware transit nodes" anchor="non-detnet-nodes"> anchor="non-detnet-nodes" numbered="true" toc="default">
        <name>Interspersed DetNet-Unaware Transit Nodes</name>
        <t>
            It is sometimes desirable to build a network that has both DetNet-aware
            transit nodes and DetNet-unaware transit nodes, nodes and for a DetNet flow to
            traverse an island of DetNet-unaware transit nodes, nodes while still allowing the
            network to offer delay and congestion loss guarantees.  This is possible
            under certain conditions.
        </t><t>
        </t>
        <t>
            In general, when passing through a DetNet-unaware island, the island may cause
            delay variation in excess of what would be caused by DetNet nodes.  That
            is, the DetNet flow might be "lumpier" after traversing the DetNet-unaware island.
            DetNet guarantees for delay and buffer requirements can still be
            calculated and met if and only if the following are true:
        </t><t>
            <list style="numbers">
                <t>
        </t>
        <ol spacing="normal" type="1">
	  <li>
                    The latency variation across the DetNet-unaware island must be
                    bounded and calculable.
                </t><t>
                </li>
          <li>
                    An ingress conditioning function (<xref target="ingress"/>) target="ingress" format="default"/>)
                    is required at the re-entry reentry to the DetNet-aware domain.
                    This will, at least, require some extra buffering to accommodate
                    the additional delay variation, variation and thus further increases the
                    latency bound.
                </t>
            </list>
        </t><t>
                </li>
        </ol>
        <t>
            The ingress conditioning is exactly the same problem as that of a sender
            at the edge of the DetNet domain.  The requirement for bounds on the
            latency variation across the DetNet-unaware island is typically the most
            difficult to achieve.  Without such a bound, it is obvious that DetNet
            cannot deliver its guarantees, so a DetNet-unaware island that cannot
            offer bounded latency variation cannot be used to carry a DetNet flow.
        </t>
      </section>
    </section>
    <section anchor="achieving" title="Achieving zero congestion loss"> numbered="true" toc="default">
      <name>Achieving Zero Congestion Loss</name>
      <t>
        When the input rate to an output queue exceeds the output rate for a sufficient
        length of time, the queue must overflow.  This is congestion loss, and this is
        what deterministic networking DetNet seeks to avoid.
      </t>
      <t>
        To avoid congestion losses, an upper bound on the backlog present in the regulator and queuing subsystem of <xref target="fig_timing_model"/> target="fig_timing_model" format="default"/>
    must be computed during resource reservation. This bound depends on the set of flows that use these queues,
    the details of the specific queuing mechanism mechanism, and an
    upper bound on the processing delay (4). The queue must contain the packet in transmission transmission, plus all other packets that
    are waiting to be selected for output. A conservative backlog  bound,  bound that applies to all systems, systems can be derived as follows.
      </t>
      <t>
    The backlog bound is counted in data units (bytes, (bytes or words of multiple bytes) that are relevant for buffer allocation.
    For every flow or an aggregate of flows, we need one buffer space for the packet in transmission, plus space for the packets that are waiting to be selected for output.
      </t>
      <t>Let
    <list style="symbols">
    <t>
      </t>
      <ul spacing="normal">
        <li> total_in_rate be the sum of the line rates of all input ports that send traffic to this output port. The value of total_in_rate
    is in data units (e.g., bytes) per second.
    </t>
    <t>nb_input_ports
    </li>
        <li>nb_input_ports be the number of input ports that send traffic to this output port</t>
    <t>max_packet_length port.</li>
        <li>max_packet_length be the maximum packet size for packets that may be sent to this output port. This is counted in data units.
    </t>
    <t>max_delay456
    </li>
        <li>max_delay456 be an upper bound, in seconds, on the sum of the processing delay (4) and the queuing delays (5,6) (5 and 6) for any packet
     at this output port.
    </t>

    </list>
    </t>

    <t>Then
    </li>
      </ul>
      <t>Then, a bound on the backlog of traffic in the queue at this output port is</t>
       <t>
         <list style="hanging">
           <t>
      <t indent="3"> backlog_bound = (nb_input_ports *  max_packet_length)  + (total_in_rate * max_delay456)
           </t>
         </list>
       </t>
      <t>The above bound is over the backlog caused by the traffic entering the queue from the input ports of a DetNet node. If the DetNet node also generates packets (e.g., creation of new packets, packets or replication of arriving packets), the bound must accordingly incorporate the introduced backlog.</t>
    <!-- <t>; for example, if the DetNet node generates packets conforming to a leaky-bucket arrival curve r * t + b (with rate r and bucket size b), a conservative backlog bound for this flow is:</t>
    <t>
         <list style="hanging">
           <t> flow_backlog_bound = b  + (r * max_delay6)
           </t>
         </list>
    </t>
    <t>where max_delay6 is an upper bound on the queuing delay (6). Finally, the backlog bound at the queue is (backlog_bound + flow_backlog_bound).</t> -->
 </section>
    <section anchor="queue_model" title="Queuing techniques"> numbered="true" toc="default">
      <name>Queuing Techniques</name>
      <t>In this section, we present a general queuing data model model, as well as some examples of queuing mechanisms. For simplicity of latency bound computation, we assume a leaky-bucket arrival curve for each DetNet flow at the source.
     Also, at each DetNet transit node, the service for each queue is abstracted with a minimum guaranteed rate and a latency <xref target="NetCalBook"/>.</t> target="NetCalBook" format="default"/>.</t>
      <section anchor="data_model" title="Queuing data model"> numbered="true" toc="default">
        <name>Queuing Data Model</name>
        <t>Sophisticated queuing mechanisms are available in Layer 3 (L3, see, e.g., (L3) (e.g., see <xref target="RFC7806"/> target="RFC7806" format="default"/> for an overview).
        In general, we assume that "Layer 3" queues, shapers, meters, etc., are precisely the "regulators"
        shown in <xref target="fig_timing_model"/>. target="fig_timing_model" format="default"/>. The "queuing subsystems" in this figure are FIFO. They are not the province solely of bridges;
        they are an essential part of any DetNet transit node.  As illustrated by numerous implementation examples, some of the
        "Layer 3" mechanisms described in documents documents, such as <xref target="RFC7806"/> target="RFC7806" format="default"/>, are often integrated, integrated
        in an implementation, with the "Layer 2" mechanisms also implemented in the same node.  An integrated model
        is needed in order to successfully predict the interactions among the different queuing mechanisms
        needed in a network carrying both DetNet flows and non-DetNet flows.
        </t>
        <t><xref target="fig_8021Q_data_model"/> target="fig_8021Q_data_model" format="default"/> shows the general model for the flow of packets through
    the queues of a DetNet transit node. The DetNet packets are mapped to a number of regulators. Here, we assume that the PREOF (Packet Packet Replication, Elimination Elimination, and Ordering Functions) Functions (PREOF) are performed before the DetNet packets enter the regulators.
     All Packets packets are assigned to a set of queues.  Packets compete for the selection to be passed to queues in the queuing subsystem. Packets again are selected for output from the
    queuing subsystem.
        </t>
        <figure title="IEEE anchor="fig_8021Q_data_model">
          <name>IEEE 802.1Q Queuing Model: Data flow" anchor="fig_8021Q_data_model"> Flow</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                                 |
+--------------------------------V----------------------------------+
|                          Queue assignment                         |
+--+------+----------+---------+-----------+-----+-------+-------+--+
   |      |          |         |           |     |       |       |
+--V-+ +--V-+     +--V--+   +--V--+     +--V--+  |       |       |
|Flow| |Flow|     |Flow |   |Flow |     |Flow |  |       |       |
|  0 | |  1 | ... |  i  |   | i+1 | ... |  n  |  |       |       |
| reg| | reg|     | reg |   | reg |     | reg |  |       |       |
+--+-+ +--+-+     +--+--+   +--+--+     +--+--+  |       |       |
   |      |          |         |           |     |       |       |
+--V------V----------V--+   +--V-----------V--+  |       |       |
|  Trans.  selection    |   | Trans. select.  |  |       |       |
+----------+------------+   +-----+-----------+  |       |       |
           |                      |              |       |       |
        +--V--+                +--V--+        +--V--+ +--V--+ +--V--+
        | out |                | out |        | out | | out | | out |
        |queue|                |queue|        |queue| |queue| |queue|
        |  1  |                |  2  |        |  3  | |  4  | |  5  |
        +--+--+                +--+--+        +--+--+ +--+--+ +--+--+
           |                      |              |       |       |
+----------V----------------------V--------------V-------V-------V--+
|                      Transmission selection                       |
+---------------------------------+---------------------------------+
                                  |
                                  V
]]></artwork>
        </figure>
        <t>Some relevant mechanisms are hidden in this figure, figure and are performed in the
        queue boxes:
        <list style="symbols">
        <t>Discarding
        </t>
        <ul spacing="normal">
          <li>discarding packets because a queue is full.
        </t><t>
            Discarding full
        </li>
          <li>
            discarding packets marked "yellow" by a metering function, function in preference
            to discarding "green" packets <xref target="RFC2697"/>.
        </t>
        </list>
    </t><t> target="RFC2697" format="default"/>
        </li>
        </ul>
        <t>
        Ideally, neither of these actions are performed on DetNet packets.  Full queues
        for DetNet packets occurs occur only when a DetNet flow is misbehaving, and the DetNet
        QoS does not include "yellow" service for packets in excess
	of a committed rate.
    </t><t>
        </t>
        <t>
        The queue assignment function can be quite complex, even in a
        bridge <xref target="IEEE8021Q"/>, since target="IEEE8021Q" format="default"/>, because of the
        introduction of per-stream filtering and policing (<xref target="IEEE8021Q"/> target="IEEE8021Q" format="default"/>, clause 8.6.5.1).
        In addition to the Layer 2 priority
        expressed in the 802.1Q VLAN tag, a DetNet transit node can utilize the information from the non-exhaustive list below to assign a packet to a particular queue:
        <list style="symbols">
            <t>
                Input port.
            </t><t>
                Selector
        </t>
        <ul spacing="normal">
          <li>
                input port
            </li>
          <li>
                selector based on a rotating schedule that starts at regular, time-synchronized
                intervals and has nanosecond precision.
            </t><t> precision
            </li>
          <li>
                MAC addresses, VLAN ID, IP addresses, Layer 4 port numbers, DSCP <xref target="RFC8939"/>, <xref target="RFC8964"/>.
            </t><t>
                The and Differentiated Services Code Point (DSCP) <xref target="RFC8939" format="default"/> <xref target="RFC8964" format="default"/>
            </li>
          <li>
                the queue assignment function can contain metering and policing
                functions.
            </t><t>
                functions
            </li>
          <li>
                MPLS and/or pseudo-wire pseudowire labels <xref target="RFC6658"/>.
            </t>
        </list>
    </t><t> target="RFC6658" format="default"/>
            </li>
        </ul>
        <t>
        The "Transmission selection" function decides which queue is to transfer its
        oldest packet to the output port when a transmission opportunity arises.
        </t>
      </section>
      <section anchor="preempt_intro" title="Frame Preemption"> numbered="true" toc="default">
        <name>Frame Preemption</name>
        <t>
    In <xref target="IEEE8021Q"/> target="IEEE8021Q" format="default"/> and <xref target="IEEE8023"/>, target="IEEE8023" format="default"/>, the transmission of a frame
    can be interrupted by one or more "express" frames, and then frames; then, the interrupted frame can
    continue transmission.  The frame preemption is modeled as
    consisting of two MAC/PHY stacks, stacks: one for packets that
    can be interrupted, interrupted and one for packets that can interrupt the interruptible packets.
    Only one layer of frame preemption is supported -- a transmitter cannot have more than one
    interrupted frame in progress.  DetNet flows typically pass through the interrupting
    MAC. For those DetNet flows with T-SPEC, latency bounds can be
    calculated by the methods provided in the following sections that account for the effect of frame preemption, according to the specific
    queuing mechanism that is used in DetNet nodes. Best-effort queues pass through the
    interruptible MAC, MAC and can thus be preempted.
        </t>
      </section>
      <section anchor="time_schedule_intro" title="Time-Aware Shaper"> numbered="true" toc="default">
        <name>Time-Aware Shaper</name>
        <t>
            In <xref target="IEEE8021Q"/>, target="IEEE8021Q" format="default"/>, the notion of time-scheduling queue gates is
            described in section Section 8.6.8.4. On each node, the transmission selection for packets
            is controlled by time-synchronized gates; each output queue is associated with a gate.
            The gates can be either open or closed. The states of the gates are
            determined by the gate control list (GCL). The GCL specifies the opening and closing
            times of the gates. The design of the GCL must satisfy the requirement of
            latency upper bounds of all DetNet flows; therefore, those DetNet flows that traverse a
            network that uses this kind of shaper must have bounded latency, latency if the traffic and nodes are conformant.
        </t>
        <t>
            Note that scheduled traffic service relies on a synchronized
            network and coordinated GCL configuration. Synthesis of the GCL on multiple
            nodes in a network is a scheduling problem considering all DetNet flows
            traversing the network, which is a non-deterministic nondeterministic polynomial-time hard
            (NP-hard) problem <xref target="Sch8021Qbv"/>. target="Sch8021Qbv" format="default"/>. Also, at this the time of writing, scheduled traffic service
            supports no more than eight traffic queues, typically using up to seven
            priority queues and at least one best effort.
        </t>
      </section>
      <section anchor="TSNwithATSmodel" title="Credit-Based numbered="true" toc="default">
        <name>Credit-Based Shaper with Asynchronous Traffic Shaping"> Shaping</name>
        <t>
            In this queuing model, it is assumed that the DetNet nodes are FIFO. We consider the four traffic classes (Definition 3.268 of <xref target="IEEE8021Q"/>): target="IEEE8021Q" format="default"/>): control-data traffic (CDT),
            class A, class B, and best effort (BE) in decreasing order of priority. Flows of classes A and B are DetNet flows that are less critical than CDT (such as studio audio and video traffic, as in IEEE 802.1BA Audio-Video-Bridging). This model is a subset of Time-Sensitive Networking Networking, as described next.
        </t>
        <t>
            Based on the timing model described in <xref target="fig_timing_model"/>, target="fig_timing_model" format="default"/>, contention occurs only at the output port of a DetNet transit node; therefore, the focus of the rest of this subsection is on the regulator and queuing subsystem in the output port of a DetNet transit node. The input flows are identified using the information in (Section 5.1 of <xref target="RFC8939"/>). Then (<xref target="RFC8939" section="5.1" sectionFormat="of" format="default"/>). Then, they are aggregated into eight macro flows macro-flows based
            on their service requirements; we refer to each macro flow macro-flow as a class.
             The output port performs aggregate scheduling with eight queues (queuing subsystems): one for CDT, one for class A flows, one for class B flows, and five for BE traffic denoted as BE0-BE4. The queuing policy for each queuing subsystem is FIFO. In addition, each node output port also performs per-flow regulation for
            class A and B flows using an interleaved regulator (IR), (IR). This regulation is called Asynchronous Traffic Shaper
   asynchronous traffic shaping <xref target="IEEE8021Qcr"/>. target="IEEE8021Qcr" format="default"/>. Thus, at each output port of a node, there is one interleaved regulator per-input per input
            port and per-class; per class; the interleaved regulator is mapped to the regulator depicted in <xref target="fig_timing_model"/>. target="fig_timing_model" format="default"/>. The detailed picture of scheduling and regulation architecture at a node output port is given by <xref target="fig_TSN_node"/>. target="fig_TSN_node" format="default"/>. The packets received at a node input port for a given class are enqueued in the respective interleaved regulator at the output port.
            Then, the packets from all the flows, including CDT and BE flows, are enqueued in a queuing subsystem; there is no regulator for CDT and BE flows.
        </t>
        <figure title="The architecture anchor="fig_TSN_node">
          <name>The Architecture of an output port Output Port inside a relay node Relay Node with interleaved regulators Interleaved Regulators (IRs) and credit-based shaper (CBS)" anchor="fig_TSN_node">
        <artwork><![CDATA[ a Credit-Based Shaper (CBS)</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      +--+   +--+ +--+   +--+
      |  |   |  | |  |   |  |
      |IR|   |IR| |IR|   |IR|
      |  |   |  | |  |   |  |
      +-++XXX++-+ +-++XXX++-+
        |     |     |     |
        |     |     |     |
+---+ +-v-XXX-v-+ +-v-XXX-v-+ +-----+ +-----+ +-----+ +-----+ +-----+
|   | |         | |         | |Class| |Class| |Class| |Class| |Class|
|CDT| | Class A | | Class B | | BE4 | | BE3 | | BE2 | | BE1 | | BE0 |
|   | |         | |         | |     | |     | |     | |     | |     |
+-+-+ +----+----+ +----+----+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
  |        |           |         |       |       |       |       |
  |      +-v-+       +-v-+       |       |       |       |       |
  |      |CBS|       |CBS|       |       |       |       |       |
  |      +-+-+       +-+-+       |       |       |       |       |
  |        |           |         |       |       |       |       |
+-v--------v-----------v---------v-------V-------v-------v-------v--+
|                     Strict Priority selection                     |
+--------------------------------+----------------------------------+
                                 |
                                 V
]]></artwork>
        </figure>
        <t>
            Each of the queuing subsystems for classes A and B, B contains a Credit-Based Shaper credit-based shaper (CBS). The CBS serves a packet from a class according to the available credit
            for that class. As described in Section 8.6.8.2 and Annex L.1 of <xref target="IEEE8021Q"/>, target="IEEE8021Q" format="default"/>, the credit for each class A or B increases based on the idle slope (as guaranteed rate), rate) and decreases based on the sendslope (typically equal to the difference between the guaranteed and the output link rates), both of which
            are parameters of the CBS. The CDT and BE0-BE4 flows are served by separate queuing subsystems. Then, packets from all flows are
            served by a transmission selection subsystem that serves packets from each class based on its priority. All subsystems are non-preemptive.
            Guarantees for classes class A and B traffic can be provided only if CDT traffic is bounded; it bounded. It is assumed that the CDT traffic has a leaky bucket leaky-bucket arrival curve with two parameters parameters: r_h as rate and b_h as bucket size, i.e., size. That is, the amount of bits entering a node within a time interval t is bounded by r_h * t + b_h.
        </t>
        <t>
            Additionally, it is assumed that the classes class A and B flows are also regulated at their source according to a leaky bucket leaky-bucket arrival curve. At the source, the traffic satisfies its regulation constraint, i.e., the delay due to interleaved regulator at the source is ignored.
        </t>
        <t>
            At each DetNet transit node implementing an interleaved regulator, packets of multiple flows are processed in one FIFO queue; the queue. The packet at the head
            of the queue is regulated based on its leaky bucket parameters; it leaky-bucket parameters. It is released at the earliest time at which this is possible without violating
            the constraint.
        </t>
        <t>
                The regulation parameters for a flow (leaky bucket (leaky-bucket rate and bucket size) are the same at its source and at all DetNet transit nodes along its path in the case where all clocks are perfect. However, in reality reality, there is clock non-ideality throughout the DetNet domain domain, even with clock synchronization. This phenomenon causes inaccuracy in the rates configured at the regulators that may lead to network instability. To avoid that, when configuring the regulators, instability, the rates are set as the source rates with some positive margin. margin when configuring regulators. <xref target="ThomasTime"/> target="ThomasTime" format="default"/> describes and provides solutions to this issue.
        </t>
        <section title="Delay anchor="delayTSNwithATS" numbered="true" toc="default">
          <name>Delay Bound Calculation" anchor="delayTSNwithATS"> Calculation</name>
          <t>
                A delay bound of the queuing subsystem ((4) in <xref target="fig_timing_model"/>) target="fig_timing_model" format="default"/>) of a given DetNet node for a flow of classes class A or B can be computed if the following condition holds:
          </t>
            <t>
                <list style="hanging">
                    <t>
	  <t indent="3">The sum of leaky bucket leaky-bucket rates of all flows of this class at this transit node &lt;= R, where R is given below for every class.
                    </t>
                </list> class
                    </t>
          <t>If the condition holds, the delay bounds for a flow of class X (A or B) is d_X and calculated as:</t>
            <t>
                <list style="hanging">
                    <t>
          <t indent="3"> d_X = T_X + (b_t_X-L_min_X)/R_X - L_min_X/c</t>
                </list>
            </t>
          <t>
                where L_min_X is the minimum packet lengths of class X (A or B); c is the output link transmission rate; and b_t_X is the sum of the b term (bucket size) for all the flows of the class X. Parameters R_X and T_X are calculated as follows for class A and class B, separately: separately.
          </t>
          <t>If the flow is of class A:</t>
            <t>
               <list style="hanging">
                    <t>
          <t indent="3"> R_A = I_A * (c-r_h)/ c</t>
                    <t>T_A
          <t indent="3">T_A = (L_nA + b_h + r_h * L_n/c)/(c-r_h)</t>
                </list>
            </t>
          <t>where I_A is the idle slope for class A; L_nA is the maximum packet length of class B and BE packets; L_n is the maximum packet length of classes A,B, A, B, and BE; and r_h is the rate and b_h is the bucket size of CDT traffic leaky bucket leaky-bucket arrival curve. </t>
          <t>If the flow is of class B:</t>
            <t>
               <list style="hanging">
                    <t>R_B
          <t indent="3">R_B = I_B * (c-r_h)/ c</t>
                    <t>T_B
          <t indent="3">T_B = (L_BE + L_A + L_nA * I_A/(c_h-I_A) + b_h + r_h * L_n/c)/(c-r_h)</t>
                </list>
            </t>
          <t>
                where I_B is the idle slope for class B; L_A is the maximum packet length of class A; and L_BE is the maximum packet length of class BE.
          </t>
          <t>Then, as discussed in <xref target="perclass"/>; target="perclass" format="default"/>, an interleaved regulator does not increase the delay bound of the upstream queuing subsystem; therefore therefore, an end-to-end delay bound for a DetNet flow of class X (A or B) is the sum of d_X_i for all node i in the path of the flow, where d_X_i is the delay bound of queuing subsystem in node i i, which is computed as above. According to the notation in <xref target="perclass"/>, target="perclass" format="default"/>, the delay bound of the queuing subsystem in a node i and interleaved regulator in node j, i.e., Cij, is:</t>
            <!-- <t>Then, an end-to-end delay bound of class X (A or B)is calculated by the formula from <xref target="perclass"/>, where for Cij:</t> -->
            <t>
                <list style="hanging">
                    <t>Cij
	  <t indent="3">Cij = d_X_i</t>
                </list>
            </t>
          <t>More information of delay analysis in such a DetNet transit node is described in <xref target="TSNwithATS"/>.</t> target="TSNwithATS" format="default"/>.</t>
        </section>
        <section title="Flow Admission" anchor="admissionTSNwithATS"> anchor="admissionTSNwithATS" numbered="true" toc="default">
          <name>Flow Admission</name>
          <t>
                The delay bound calculation requires some information about each node. For each node, it is required to know the idle slope of the CBS for each class A and B (I_A and I_B), as well as the transmission rate of the output link (c). Besides, it is necessary to have the information on each class, i.e., maximum packet length of classes A, B, and BE. Moreover, the leaky bucket leaky-bucket parameters of CDT (r_h,b_h) (r_h, b_h) must be known. To admit a flow/flows flow or flows of classes A and B, their delay requirements must be guaranteed not to be violated. As described in <xref target="flow-admission"/>, target="flow-admission" format="default"/>, the two problems, static problems (static and dynamic, dynamic) are addressed separately. In either of the problems, the rate and delay must be guaranteed. Thus,
          </t>
            <t>
                <list hangIndent="8" style="hanging">
                    <t hangText="The
          <dl newline="true" spacing="normal" indent="8">
            <dt>The static admission control:"><vspace blankLines="0"/> control:</dt>
            <dd>
                    The leaky bucket leaky-bucket parameters of all class A or B flows are known, known; therefore, for each flow f of either class A or B flow f, B, a delay bound
           can be calculated.  The computed delay bound for every flow
           of class A or B flow must not be more than its delay requirement. Moreover, the sum of the rate of each flow (r_f) must not be more than the rate allocated to each class (R). If these two conditions hold, the configuration is declared admissible.
                    </t>
                    <t hangText="The
                    </dd>
            <dt>The dynamic admission control:"><vspace blankLines="0"/> control:</dt>
            <dd>
	      <dl newline="true" spacing="normal">
                <dt>  For dynamic admission control, we allocate to every node and class A or B,
          a static value for rate (R) and a maximum bucket
          size (b_t). (b_t) to every node and each class A or B.
          In addition, for every node and every each class A and
          or B, two counters are maintained:
                    </t>
                    <t>
                        <list style="hanging">
                    </dt>
            <dd>
                <t>R_acc is equal to the sum of the leaky-bucket rates of all flows of this class already admitted at this node; At at all times, we must have:</t>
                            <t><list style="hanging">
                <t>R_acc &lt;=R, &lt;= R, (Eq. 1)</t>
                             </list></t>
                <t>b_acc is equal to the sum of the bucket sizes of all flows of this class already admitted at this node; At at all times, we must have:</t>
                            <t><list style="hanging">
                <t>b_acc &lt;=b_t. &lt;= b_t.  (Eq. 2)</t>
                             </list></t>
                        </list>
                    </t>
                </dd>
              </dl>
	      <t>
              A new class A or B flow is admitted at this node, node if Eqs. (1) and (2) continue to be satisfied after adding its leaky bucket leaky-bucket rate and bucket size to R_acc and b_acc. A class A or B flow is admitted in the network, network if it is admitted at all nodes along its path. When this happens, all variables R_acc and b_acc along its path must be incremented to reflect the addition of the flow. Similarly, when a class A or B flow leaves the network, all variables R_acc and b_acc along its path must be decremented to reflect the removal of the flow.
                    </t>
                </list>
            </t>
                    </t></dd>
          </dl>
          <t>
                The choice of the static values of R and b_t at all nodes and classes must be done in a prior configuration phase; phase: R controls the bandwidth allocated to this class at this node, and b_t affects the delay bound and the buffer requirement. The value of R must be set such that
          </t>
            <t><list style="hanging">
                <t>R
	  <t indent="3">R &lt;= I_X*(c-r_h)/c</t>
            </list></t>
          <t>
                where I_X is the idleslope of credit-based shaper for class X={A,B}, c is the transmission rate of the output link link, and r_h is the leaky-bucket rate of the CDT class.
                <!-- must not be greater than R_X for class X={A,B}, that is computed in <xref target="delayTSNwithATS"/>. -->
          </t>
        </section>
      </section>
      <section title="Guaranteed-Service IntServ" anchor="intserv">
        <t>
            Guaranteed-Service Integrated service (IntServ) anchor="intserv" numbered="true" toc="default">
        <name>Guaranteed Service</name>
        <t>The Guaranteed Service is an architecture that specifies the elements to guarantee quality of service (QoS) on networks defined in <xref target="RFC2212"/>.
        </t>
        <t>The target="RFC2212" format="default"/>. The flow, at the source, has a leaky bucket leaky-bucket arrival curve with two parameters parameters: r as rate and b as bucket size, i.e., the amount of bits entering a node within a time interval t is bounded by r * t + b. </t>
        <t>If a resource reservation on a path is applied, a node provides a guaranteed rate R and maximum service latency of T. This can be interpreted in a way that the bits might have to wait up to T before being served with a rate greater or equal to R. The delay bound of the flow traversing the node is T + b / R.</t>
       <t>
            Consider
        <t>Consider a Guaranteed-Service IntServ Guaranteed Service <xref target="RFC2212" format="default"/> path including a sequence of nodes, where the i-th node provides a guaranteed rate R_i and maximum service latency of T_i.
 Then, the end-to-end delay bound for a flow on this can be calculated as sum(T_i) + b / min(R_i).
        </t>
        <t>
            The
        <t>The provided delay bound is based on a simple case of Guaranteed-Service IntServ Guaranteed Service, where only a guaranteed rate and maximum service latency and a leaky bucket leaky-bucket arrival curve are available.  If more information about the flow is known, e.g., the peak rate, the delay bound is more complicated; the details are available in <xref target="RFC2212"/> target="RFC2212" format="default"/> and Section 1.4.1 of <xref target="NetCalBook"/>. target="NetCalBook" format="default"/>.
        </t>
      </section>
      <section title="Cyclic anchor="cqf" numbered="true" toc="default">
        <name>Cyclic Queuing and Forwarding" anchor="cqf"> Forwarding</name>
        <t>
         Annex T of <xref target="IEEE8021Q"/> target="IEEE8021Q" format="default"/> describes Cyclic Queuing
         and Forwarding (CQF), which provides bounded latency and zero congestion loss using
         the time-scheduled gates of Section 8.6.8.4 of <xref target="IEEE8021Q"/> section 8.6.8.4. target="IEEE8021Q" format="default"/>.  For a given class of DetNet
         flows, a set of two or more buffers is provided at the output queue layer of
         <xref target="fig_8021Q_data_model"/>. target="fig_8021Q_data_model" format="default"/>.  A cycle time T_c is configured for each class of DetNet
         flows c, and all of the buffer sets in a class of DetNet
         flows swap buffers simultaneously throughout the DetNet domain
         at that cycle rate, all in phase. In such a mechanism, the regulator, as mentioned in <xref target="fig_timing_model"/>, target="fig_timing_model" format="default"/>, is not required.
        </t>
        <t>
        In the case of two-buffer CQF, each class of DetNet flows c has two buffers, namely buffer1 and buffer2. In a cycle (i) when buffer1 accumulates received packets from the node's reception ports, buffer2 transmits the already stored packets from the previous cycle (i-1). In the next cycle (i+1), buffer2 stores the received packets and buffer1 transmits the packets received in cycle (i). The duration of each cycle is T_c.
        </t>
        <t>
        The cycle time T_c must be carefully chosen; it needs to be large enough to accommodate all the DetNet traffic, plus at least one maximum packet (or fragment) size from lower priority queues, which might be received within a cycle.
        Also, the value of T_c includes a time interval, called dead time (DT), which is the sum of the delays 1,2,3,4 1, 2, 3, and 4 defined in <xref target="fig_timing_model"/>. target="fig_timing_model" format="default"/>. The value of DT guarantees that the last packet of one cycle in a node is fully delivered to a buffer of the next node in the same cycle. A two-buffer CQF is recommended if DT is small compared to T_c. For a large DT, CQF with more buffers can be used, and a cycle identification label can be added to the packets.
        </t>
        <t>
        The per-hop latency is determined by the cycle time T_c: a packet transmitted from a node at a cycle (i), (i) is transmitted from the next node at cycle (i+1). Then, if the packet traverses h hops, the maximum latency experienced by the packet is from
         the beginning of cycle (i) to the end of cycle (i+h); also, the minimum latency is from the end of cycle (i) (i), before the DT, to the beginning of cycle (i+h). Then, the maximum latency is:
        <list style="hanging">
            <t>(h+1) T_c</t>
        </list>
        </t>
          <t indent="3">(h+1) T_c</t>
        <t> and the minimum latency is:</t>
    <t>
        <list style="hanging">
            <t>(h-1)
          <t indent="3">(h-1) T_c + DT.</t>
        </list>
    </t>
     <!-- <t>
        The per-hop latency is trivially determined by the cycle time T_c: a packet transmitted from a node at a cycle (i), is transmitted from the next node at cycle (i+1).
        Hence, the maximum latency experienced by a given packet is from
         the beginning of cycle (i) to the end of cycle (i+1), or 2T_c; also, the minimum latency is from the end of cycle (i) to the beginning of cycle (i+1), i.e., zero. Then, if the packet traverses h hops, the maximum latency is:
        <list style="hanging">
            <t>(h+1) T_c</t>
        </list>
     </t>
    <t> and the minimum latency is:</t>
    <t>
        <list style="hanging">
            <t>(h-1) T_c</t>
        </list>
    </t>
    <t>which gives a latency variation of 2T_c.</t> -->
     <t>
         Ingress conditioning (<xref target="ingress"/>) target="ingress" format="default"/>) may be required if the source of a DetNet flow does not, itself, not itself employ CQF. Since there are no per-flow parameters in the CQF technique, per-hop configuration is not required in the CQF forwarding nodes.
        </t>
      </section>
    </section>
    <section title="Example application anchor="example" numbered="true" toc="default">
      <name>Example Application on DetNet IP network" anchor="example"> Network</name>
      <t>
        This section provides an example application of the timing model presented in this document to control the admission of a DetNet flow on a DetNet-enabled IP network. Consider <xref target="fig_ip_detnet_simple"/>, target="fig_ip_detnet_simple" format="default"/>, taken from Section 3 of <xref target="RFC8939"/>, that target="RFC8939" section="3" sectionFormat="of" format="default"/>, which shows a simple IP network:
      </t>
    <t>
        <list style="symbols">
            <t>
                The end-system
      <ul spacing="normal">
        <li>
          End system 1 implements Guaranteed-Service IntServ Guaranteed Service <xref target="RFC2212" format="default"/>, as in <xref target="intserv"/> target="intserv" format="default"/>, between itself and relay node 1.
            </t>
            <t>
        </li>
        <li>
                Sub-network 1 is a TSN network. The nodes in subnetwork sub-network 1 implement credit-based shapers with asynchronous traffic shaping shaping, as in <xref target="TSNwithATSmodel"/>.
            </t>
            <t> target="TSNwithATSmodel" format="default"/>.
            </li>
        <li>
                Sub-network 2 is a TSN network. The nodes in subnetwork sub-network 2 implement cyclic queuing Cyclic Queuing and forwarding Forwarding with two buffers buffers, as in <xref target="cqf"/>.
            </t>
            <t> target="cqf" format="default"/>.
            </li>
        <li>
                The relay nodes 1 and 2 implement credit-based shapers with asynchronous traffic shaping shaping, as in <xref target="TSNwithATSmodel"/>. target="TSNwithATSmodel" format="default"/>. They also perform the aggregation and mapping of IP DetNet flows to TSN streams (Section 4.4 of <xref target="RFC9023"/>).
            </t>
        </list>
    </t> (<xref target="RFC9023" section="4.4" sectionFormat="of" format="default"/>).
            </li>
      </ul>
      <figure title="A anchor="fig_ip_detnet_simple">
        <name>A Simple DetNet-Enabled IP Network, taken Taken from RFC8939" anchor="fig_ip_detnet_simple">
        <artwork><![CDATA[ RFC 8939</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 DetNet IP       Relay                        Relay       DetNet IP
 End-System
 End System      Node 1                       Node 2      End-System      End System
     1                                                        2
+----------+                                             +----------+
|   Appl.  |<------------ End-to-End Service ----------->|   Appl.  |
+----------+  ............                 ...........   +----------+
| Service  |<-: Service  :-- DetNet flow --: Service  :->| Service  |
+----------+  +----------+                 +----------+  +----------+
|Forwarding|  |Forwarding|                 |Forwarding|  |Forwarding|
+--------.-+  +-.------.-+                 +-.---.----+  +-------.--+
         : Link :       \      ,-----.      /     \   ,-----.   /
         +......+        +----[  Sub- ]----+       +-[  Sub- ]-+
                              [Network]              [Network]
                               `--1--'                `--2--'

         |<--------------------- DetNet IP --------------------->|

|<--- d1 --->|<--------------- d2_p --------------->|<-- d3_p -->|
]]></artwork>
      </figure>
      <t>Consider a fully centralized control plane for the network of <xref target="fig_ip_detnet_simple"/> target="fig_ip_detnet_simple" format="default"/>, as described in Section 3.2 of <xref target="I-D.ietf-detnet-controller-plane-framework"/>. target="I-D.ietf-detnet-controller-plane-framework" section="3.2" sectionFormat="of" format="default"/>. Suppose end-system end system 1 wants to create a DetNet flow with a traffic specification destined to end-system end system 2 with end-to-end delay bound requirement D. Therefore, the control plane receives a flow establishment request and calculates a number of valid paths through the network (Section 3.2 of <xref target="I-D.ietf-detnet-controller-plane-framework"/>). (<xref target="I-D.ietf-detnet-controller-plane-framework" section="3.2" sectionFormat="of" format="default"/>). To select a proper path, the control plane needs to compute an end-to-end delay bound at every node of each selected path p.
</t>
      <t>
    The end-to-end delay bound is d1 + d2_p + d3_p, where d1 is the delay bound from end-system end system 1 to the entrance of relay node 1, d2_p is the delay bound for path p from relay node 1 to the entrance of the first node in sub-network 2, and d3_p is the delay bound of path p from the first node in sub-network 2 to end-system end system 2. The computation of d1 is explained in <xref target="intserv"/>. target="intserv" format="default"/>. Since the relay node 1, sub-network 1 1, and relay node 2 implement aggregate queuing, we use the results in Sections <xref target="perclass"/> target="perclass" format="counter"/> and <xref target="TSNwithATSmodel"/> target="TSNwithATSmodel" format="counter"/> to compute d2_p for the path p. Finally, d3_p is computed using the delay bound computation of <xref target="cqf"/>. target="cqf" format="default"/>. Any path p p, such that d1 + d2_p + d3_p &le; D &lt;= D, satisfies the delay bound requirement of the flow. If there is no such path, the control plane may compute a new set of valid paths and redo the delay bound computation or reject the DetNet flow.
</t>
      <t>
    As soon as the control plane selects a path that satisfies the delay bound constraint, it allocates and reserves the resources in the path for the DetNet flow (Section 4.2 <xref target="I-D.ietf-detnet-controller-plane-framework"/>). (<xref target="I-D.ietf-detnet-controller-plane-framework" format="default" sectionFormat="of" section="4.2"/>).
</t>
    </section>
    <section title="Security considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
    Detailed security considerations for DetNet are cataloged in <xref target="RFC9055"/>, target="RFC9055" format="default"/>, and more general security considerations are described in <xref target="RFC8655"/>. target="RFC8655" format="default"/>.
      </t>
      <t>
        Security aspects that are unique to DetNet are those whose aim is to provide the specific QoS aspects of DetNet, specifically bounded end-to-end delivery latency and zero congestion loss. Achieving such loss rates and bounded latency may not be possible in the face of a highly capable adversary, such as the one envisioned by the Internet Threat Model of BCP 72 <xref target="RFC3552"/> that target="RFC3552" format="default"/>, which can arbitrarily drop or delay any or all traffic. In order to present meaningful security considerations, we consider a somewhat weaker attacker who does not control the physical links of the DetNet domain but may have the ability to control or change the behavior of some resources within the boundary of the DetNet domain.
      </t>
      <t>
        Latency bound calculations use parameters that reflect physical quantities. If an attacker finds a way to change the physical quantities, unknown to the control and management planes, the latency calculations fail and may result in latency violation and/or congestion losses. An example of such attacks is to make some traffic sources under the control of the attacker send more traffic than their assumed T-SPECs. This type of attack is typically avoided by ingress conditioning at the edge of a DetNet domain. However, it must be insured that such ingress conditioning is done per-flow per flow and that the buffers are segregated such that if one flow exceeds its T-SPEC, it does not cause buffer overflow for other flows.
      </t>
    <!-- <t>
        In principle, detnet node must segregate DetNet flows from other flows such that non-DetNet flows do not affect DetNet flows.
    </t> -->
    <t>
        Some queuing mechanisms require time synchronization and operate correctly only if the time synchronization works correctly. In the case of CQF, the correct alignments of cycles can fail if an attack against time synchronization fools a node into having an incorrect offset. Some of these attacks can be prevented by cryptographic authentication as in Annex K of <xref target="IEEE1588"/> target="IEEE1588" format="default"/> for the Precision Time Protocol (PTP). However, the attacks that change the physical latency of the links used by the time synchronization protocol are still possible even if the time synchronization protocol is protected by authentication and cryptography <xref target="DelayAttack"/>. target="DelayAttack" format="default"/>. Such attacks can be detected only by their effects on latency bound violations and congestion losses, which do not occur in normal DetNet operation.
      </t>
 <!--    <t>
        A security consideration for this document is to secure the resource reservation signaling for DetNet flows. Any forgery or manipulation of packets during reservation may lead the flow not to be admitted or face delay bound violation. Security mitigation for this issue is described in Section 7.6 of <xref target="RFC9055"/>.
    </t> -->
</section>
    <section title="IANA considerations"> numbered="true" toc="default">
      <name>IANA considerations</name>
      <t>
	This document has no IANA actions.
      </t>
    </section>

<section title="Acknowledgement">
    <t>We would like to thank Lou Berger, Tony Przygienda, John Scudder, Watson Ladd, Yoshifumi Nishida, Ralf Weber, Robert Sparks, Gyan Mishra, Martin Duke, &Eacute;ric Vyncke, Lars Eggert, Roman Danyliw, and Paul Wouters for their useful feedback on this document.</t>
</section>

<section title="Contributors">
    <t>RFC 7322 limits the number of authors listed on the front page to a maximum of 5. The editor wishes to thank and acknowledge the following author for contributing text to this document</t>
    <figure> <artwork><![CDATA[
   Janos Farkas
   Ericsson
   Email: janos.farkas@ericsson.com
   ]]></artwork>
      </figure>
</section>
  </middle>
  <!--  *****BACK MATTER ***** -->

<back>

<references title="Normative References">
    <?rfc include='reference.RFC.2212.xml'?>
    <?rfc include='reference.RFC.9016.xml'?>
    <?rfc include='reference.RFC.6658.xml'?>
    <?rfc include='reference.RFC.7806.xml'?>
    <?rfc include='reference.RFC.8655.xml'?>
    <?rfc include='reference.RFC.8939.xml'?>
    <?rfc include='reference.RFC.8964.xml'?>
    <?rfc include='reference.RFC.2475.xml'?>

<displayreference target="I-D.ietf-detnet-controller-plane-framework" to="DETNET-CONTROL-PLANE"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2212.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9016.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6658.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7806.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml"/>

        <reference anchor="IEEE8021Q" target="https://ieeexplore.ieee.org/document/8403927">
          <front>
            <title>IEEE Std 802.1Q-2018: IEEE Standard for Local and metropolitan area networks - Bridges Metropolitan Area Networks--Bridges and Bridged Networks</title>
            <author>
            <organization>IEEE 802.1</organization>
              <organization>IEEE</organization>
            </author>
            <date year="2018" /> month="July"/>
          </front>
	  <seriesInfo name="IEEE Std" value="802.1Q-2018"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>
        </reference>
    <!-- <?rfc include='reference.RFC9055.xml'?> -->

</references>

<references title="Informative References">
    <?rfc include='reference.RFC.2697.xml'?>
    <?rfc include='reference.RFC.3552.xml'?>
    <?rfc include='reference.RFC.8578.xml'?>
    <?rfc include='reference.RFC.9055.xml'?>
    <?rfc include='reference.RFC.9023.xml'?>

    <!-- <?rfc include='reference.I-D.ietf-detnet-controller-plane-framework.xml'?> -->
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2697.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8578.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9023.xml"/>

<reference anchor="I-D.ietf-detnet-controller-plane-framework" target="https://datatracker.ietf.org/doc/html/draft-ietf-detnet-controller-plane-framework"> anchor="I-D.ietf-detnet-controller-plane-framework">
<front>
<title>Deterministic Networking (DetNet) Controller Plane Framework draft-ietf-detnet-controller-plane-framework-01</title>
          <author>
            <organization>A. Malis, X. Geng, M. Chen, F. Qin, and B. Varga</organization> Framework</title>
<author initials="A" surname="Malis" fullname="Andrew G. Malis">
<organization>Independent</organization>
</author>
<author initials="A" surname="Geng" fullname="Xuesong Geng" role="editor">
<organization>Huawei</organization>
</author>
<author initials="M" surname="Chen" fullname="Mach (Guoyi) Chen">
<organization>Huawei</organization>
</author>
<author initials="F" surname="Qin" fullname="Fengwei Qin">
<organization>China Mobile</organization>
</author>
<author initials="B" surname="Varga" fullname="Balazs Varga">
<organization>Ericsson</organization>
</author>
<date /> month="June" day="28" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-controller-plane-framework-02"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-detnet-controller-plane-framework-02.txt"/>
</reference>
    <!-- &I-D.draft-malis-detnet-controller-plane-framework; -->

    <reference anchor="IEEE8021Qcr"
        target="https://1.ieee802.org/tsn/802-1qcr/"> target="https://ieeexplore.ieee.org/document/9253013">
          <front>
            <title>IEEE P802.1Qcr: Bridges
            <title>802.1Qcr-2020 - IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks - Amendment: Asynchronous
     Amendment 34:Asynchronous Traffic Shaping</title>
            <author>
              <organization>IEEE 802.1</organization>
            </author>
            <date year="2017" /> year="2020" month="November"/>
          </front>
        </reference>

        <reference anchor="IEEE1588" target="https://ieeexplore.ieee.org/document/4579760">
          <front>
            <title>IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems</title>
            <author>
            <organization>IEEE Std 1588-2008</organization>
              <organization>IEEE</organization>
            </author>
            <date year="2008" /> month="July"/>
          </front>
	  <seriesInfo name="IEEE Std" value="1588-2008"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4579760"/>
        </reference>

        <reference anchor="IEEE8023" target="http://ieeexplore.ieee.org/document/8457469">
          <front>
            <title>IEEE Std 802.3-2018: IEEE Standard for Ethernet</title>
            <author>
                <organization>IEEE 802.3</organization>
              <organization>IEEE</organization>
            </author>
            <date year="2018" /> month="August"/>
          </front>
	  <seriesInfo name="IEEE Std" value="802.3-2018"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457469"/>
        </reference>

        <reference anchor="IEEE8021TSN" target="http://www.ieee802.org/1/"> target="https://1.ieee802.org/tsn/">
          <front>
          <title>IEEE 802.1
            <title>802.1 Time-Sensitive Networking (TSN) Task Group</title>
            <author>
              <organization>IEEE 802.1</organization>
            </author>
          <date />
          </front>
        </reference>

        <reference anchor="TSNwithATS" target="https://ieeexplore.ieee.org/document/8493026">
          <front>
            <title>Latency and Backlog Bounds in Time-Sensitive Networking with Credit Based Shapers and Asynchronous Traffic Shaping</title>
          <author>
            <organization>E. Mohammadpour, E. Stai, M. Mohiuddin, and J.-Y.
            <author initials="E" surname="Mohammadpour" fullname="Ehsan Mohammadpour">
              <organization/>
            </author>
	    <author initials="E" surname="Stai" fullname="Eleni Stai">
	      <organization/>
	    </author>
	    <author initials="M" surname="Mohiuddin" fullname="Maaz Mohiuddin">
	      <organization/>
	    </author>
	    <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le Boudec</organization> Boudec">
	      <organization/>
	    </author>
            <date /> year="2018" month="September"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/ITC30.2018.10053"/>
        </reference>

        <reference anchor="PacketReorderingBounds" target="https://ieeexplore.ieee.org/document/9640523">
          <front>
            <title>On Packet Reordering in Time-Sensitive Networks</title>
          <author>
            <organization>E. Mohammadpour, and J.-Y.
            <author initials="E" surname="Mohammadpour" fullname="Ehsan Mohammadpour">
              <organization/>
            </author>
	    <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le Boudec</organization> Boudec">
	      <organization/>
	    </author>
            <date /> year="2021" month="December"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/TNET.2021.3129590"/>
        </reference>

        <reference anchor="DelayAttack" target="https://ieeexplore.ieee.org/document/7520408">
          <front>
            <title>Cyber-attack on packet-based time synchronization protocols: The undetectable Delay Box</title>
          <author>
            <organization>S. Barreto, A. Suresh, and J.-Y.
            <author initials="S" surname="Barreto" fullname="Sergio Barreto">
              <organization/>
            </author>
	    <author initials="A" surname="Suresh" fullname="Aswin Suresh">
	      <organization/>
	    </author>
	    <author initials="J.-Y." fullname="Jean-Yves Le Boudec</organization> Boudec">
	      <organization/>
	    </author>
            <date /> year="2016" month="May"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/I2MTC.2016.7520408"/>
        </reference>

        <reference anchor="NetCalBook" target="https://leboudec.github.io/netcal/"> target="https://leboudec.github.io/netcal/latex/netCalBook.pdf">
          <front>
            <title>Network calculus: a theory Calculus: A Theory of deterministic queuing systems Deterministic Queuing Systems for the internet</title>
          <author>
            <organization>J.-Y. Internet</title>
            <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le Boudec and P. Thiran</organization> Boudec">
              <organization/>
            </author>
	    <author initials="P" surname="Thiran" fullname="Patrick Thiran">
	      <organization/>
	    </author>
            <date year="2001"/>
          </front>
	  <refcontent>Springer Science &amp; Business Media, vol. 2050</refcontent>
        </reference>

        <reference anchor="LeBoudecTheory" target="https://ieeexplore.ieee.org/document/8519761">
          <front>
            <title>A Theory of Traffic Regulators for Deterministic Networks with With Application to Interleaved Regulators</title>
          <author>
            <organization>J.-Y.
            <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le Boudec</organization> Boudec">
              <organization/>
            </author>
            <date /> year="2018" month="November"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/TNET.2018.2875191"/>
        </reference>

        <reference anchor="Sch8021Qbv" target="https://dl.acm.org/doi/10.1145/2997465.2997470">
          <front>
            <title>Scheduling Real-Time Communication in IEEE 802.1Qbv Time Sensitive Networks</title>
          <author>
            <organization>S. Craciunas, R. Oliver, M. Chmelik, and W. Steiner</organization>
            <author initials="S" surname="Craciunas" fullname="Silviu S. Craciunas">
              <organization></organization>
            </author>
	    <author initials="R" surname="Oliver" fullname="Ramon Serna Oliver">
	      <organization/>
	    </author>
	    <author initials="M" surname="Chmelik" fullname="Martin Chmelík">
	      <organization/>
	    </author>
	    <author initials="W" surname="Steiner" fullname="Wilfried Steiner">
	      <organization/>
	    </author>
            <date /> year="2016" month="October"/>
          </front>
	  <seriesInfo name="DOI" value="10.1145/2997465.2997470"/>
        </reference>

        <reference anchor="CharnyDelay" target="https://link.springer.com/chapter/10.1007/3-540-39939-9_1">
          <front>
            <title>Delay Bounds in a Network with Aggregate Scheduling</title>
          <author>
            <organization>A. Charny and J.-Y.
            <author initials="A" surname="Charny" fullname="Anna Charny">
	      <organization/>
	    </author>
	    <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le Boudec</organization> Boudec">
              <organization/>
            </author>
            <date /> year="2002" month="September"/>
          </front>
	  <seriesInfo name="DOI" value="10.1007/3-540-39939-9_1"/>
        </reference>

        <reference anchor="BennettDelay" target="https://dl.acm.org/citation.cfm?id=581870">
          <front>
            <title>Delay Jitter Bounds jitter bounds and Packet Scale Rate Guarantee packet scale rate guarantee for Expedited Forwarding</title>
          <author>
            <organization>J.C.R. Bennett, K. Benson, A. Charny, W.F. Courtney, and J.-Y. expedited forwarding</title>
            <author initials="J. C. R." surname="Bennett" fullname="Jon C. R. Bennett">
              <organization/>
            </author>
	    <author initials="K" surname="Benson" fullname="Kent Benson">
	      <organization/>
	    </author>
	    <author initials="A" surname="Charny" fullname="Anna Charny">
	      <organization/>
	    </author>
	    <author initials="W. F." surname="Courtney" fullname="William F. Courtney">
	      <organization/>
	    </author>
	    <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le Boudec</organization> Boudec">
	      <organization/>
	    </author>
            <date /> year="2002" month="August"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/TNET.2002.801404"/>
        </reference>

        <reference anchor="ThomasTime" target="https://dl.acm.org/doi/10.1145/3393691.3394206">
          <front>
            <title>On Time Synchronization Issues in Time-Sensitive Networks with Regulators and Nonideal Clocks</title>
          <author>
            <organization>L. Thomas and J.-Y.
            <author initials="L" surname="Thomas" fullname="Ludovic Thomas">
              <organization/>
            </author>
	    <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le Boudec</organization> Boudec">
	      <organization/>
	    </author>
            <date /> year="2020" month="June"/>
          </front>
	  <seriesInfo name="DOI" value="10.1145/3393691.339420"/>
        </reference>

        <reference anchor="SpechtUBS" target="https://ieeexplore.ieee.org/abstract/document/7557870">
          <front>
            <title>Urgency-Based Scheduler for Time-Sensitive Switched Ethernet Networks</title>
          <author>
            <organization>J. Specht and S. Samii</organization>
            <author initials="J" surname="Specht" fullname="Johannes Specht">
              <organization/>
            </author>
	    <author initials="S" surname="Samii" fullname="Soheil Samii">
	      <organization/>
	    </author>
            <date /> year="2016" month="July"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/ECRTS.2016.27"/>
        </reference>
      </references>
    </references>

    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>We would like to thank <contact fullname="Lou Berger"/>, <contact fullname="Tony Przygienda"/>, <contact fullname="John Scudder"/>, <contact fullname="Watson Ladd"/>, <contact fullname="Yoshifumi Nishida"/>, <contact fullname="Ralf Weber"/>, <contact fullname="Robert Sparks"/>, <contact fullname="Gyan Mishra"/>, <contact fullname="Martin Duke"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Paul Wouters"/> for their useful feedback on this document.</t>
    </section>
    <section numbered="false" toc="default">
      <name>Contributors</name>
      <t>RFC 7322 limits the number of authors listed on the front page to a maximum of 5. The editor wishes to thank and acknowledge the following author for contributing text to this document:</t>
      <contact fullname="Janos Farkas">
	<organization>Ericsson</organization>
	<address>
	  <email>janos.farkas@ericsson.com</email>
	</address>
      </contact>
    </section>
  </back>
</rfc>