rfc9320xml2.original.xml   rfc9320.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY nbsp "&#160;">
<!ENTITY RFC1195 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.1195.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC2212 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.2212.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2629.xml">
<!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/r
eference.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">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-detnet-bound
<?rfc strict="yes" ?> ed-latency-10" number="9320" submissionType="IETF" category="info" consensus="tr
<?rfc toc="yes"?> ue" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" to
<?rfc tocdepth="4"?> cDepth="4" symRefs="true" sortRefs="true" version="3">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-detnet-bounded-latency-10" ipr="trust20
0902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="DetNet Bounded Latency">DetNet Bounded Latency</title> <!-- xml2rfc v2v3 conversion 3.13.0 -->
<!-- ***** FRONT MATTER ***** -->
<author initials="N" surname="Finn" fullname="Norman Finn"> <front>
<organization> <title abbrev="DetNet Bounded Latency">Deterministic Networking (DetNet) Bou
nded Latency</title>
<seriesInfo name="RFC" value="9320"/>
<author initials="N" surname="Finn" fullname="Norman Finn">
<organization>
Huawei Technologies Co. Ltd Huawei Technologies Co. Ltd
</organization> </organization>
<address> <address>
<postal> <postal>
<street>3101 Rio Way</street> <street>3101 Rio Way</street>
<city>Spring Valley</city> <city>Spring Valley</city>
<region>California</region> <region>California</region>
<code>91977</code> <code>91977</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 925 980 6430</phone> <phone>+1 925 980 6430</phone>
<email>nfinn@nfinnconsulting.com</email> <email>nfinn@nfinnconsulting.com</email>
</address> </address>
</author> </author>
<author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le Boudec">
<author initials="J-Y" surname="Le Boudec" fullname="Jean-Yves Le Boudec"> <organization>
<organization>
EPFL EPFL
</organization> </organization>
<address> <address>
<postal> <postal>
<street>IC Station 14</street> <street>IC Station 14</street>
<city>Lausanne EPFL</city> <city>Lausanne</city>
<code>1015</code> <code>1015</code>
<country>Switzerland</country> <country>Switzerland</country>
</postal> </postal>
<email>jean-yves.leboudec@epfl.ch</email> <email>jean-yves.leboudec@epfl.ch</email>
</address> </address>
</author> </author>
<author initials="E" surname="Mohammadpour" fullname="Ehsan Mohammadpour">
<author initials="E" surname="Mohammadpour" fullname="Ehsan Mohammadpour"> <organization>
<organization>
EPFL EPFL
</organization> </organization>
<address> <address>
<postal> <postal>
<street>IC Station 14</street> <street>IC Station 14</street>
<city>Lausanne EPFL</city> <city>Lausanne</city>
<code>1015</code> <code>1015</code>
<country>Switzerland</country> <country>Switzerland</country>
</postal> </postal>
<email>ehsan.mohammadpour@epfl.ch</email> <email>ehsan.mohammadpour@epfl.ch</email>
</address> </address>
</author> </author>
<author initials="J" surname="Zhang" fullname="Jiayi Zhang">
<author initials="J" surname="Zhang" fullname="Jiayi Zhang"> <organization>
<organization>
Huawei Technologies Co. Ltd Huawei Technologies Co. Ltd
</organization> </organization>
<address> <address>
<postal> <postal>
<street>Q27, No.156 Beiqing Road</street> <street>Q27, No.156 Beiqing Road</street>
<city>Beijing</city> <city>Beijing</city>
<code>100095</code> <code>100095</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhangjiayi11@huawei.com</email> <email>zhangjiayi11@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Balázs Varga" initials="B." surname="Varga">
<author fullname="Bal&aacute;zs Varga" initials="B." surname="Varga"> <organization>Ericsson</organization>
<organization>Ericsson</organization> <address>
<address> <postal>
<postal> <street>Konyves Kálmán krt. 11/B</street>
<street>Konyves K&aacute;lm&aacute;n krt. 11/B</street> <city>Budapest</city>
<city>Budapest</city> <country>Hungary</country>
<country>Hungary</country> <code>1097</code>
<code>1097</code> </postal>
</postal> <email>balazs.a.varga@ericsson.com</email>
<email>balazs.a.varga@ericsson.com</email> </address>
</address> </author>
</author> <date month="November" year="2022"/>
<area>rtg</area>
<date month="April" day="8" year="2022" /> <workgroup>detnet</workgroup>
<keyword>DetNet</keyword>
<area>Routing</area> <keyword>bounded latency</keyword>
<keyword>zero congestion loss</keyword>
<workgroup>DetNet</workgroup> <abstract>
<keyword>DetNet, bounded latency, 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 u
sed by the management and control planes to provide DetNet qualities of service.
Hence, it is possible for an implementer, user, or standards development organi
zation 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> <t>
This document presents a timing model for sources, destinations, and Det This document presents a timing model for sources, destinations, and Det
Net transit nodes. Using the model, it provides a methodology to compute end-to- erministic Networking (DetNet) transit nodes. Using the model, it provides a met
end latency and backlog bounds for various queuing methods. The methodology can hodology to compute end-to-end latency and backlog bounds for various queuing me
be used by the management and control planes and by resource reservation algorit thods. The methodology can be used by the management and control planes and by r
hms to provide bounded latency and zero congestion loss for the DetNet service. esource reservation algorithms to provide bounded latency and zero congestion lo
</t> ss for the DetNet service.
</abstract> </t>
</front> </abstract>
</front>
<!-- ***** MIDDLE MATTER ***** --> <!-- ***** MIDDLE MATTER ***** -->
<middle> <middle>
<section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t>The ability for IETF Deterministic Networking (DetNet) or IEEE 802.1 Ti
<t>The ability for IETF Deterministic Networking (DetNet) or IEEE 802.1 Time me-Sensitive
-Sensitive Networking <xref target="IEEE8021TSN" format="default"/> to provide the
Networking <xref target="IEEE8021TSN"/> to provide the DetNet services o DetNet services of bounded latency and zero congestion
f bounded latency and zero congestion
loss depends upon </t> loss depends upon </t>
<t> <ol spacing="normal" type="A">
<list style="hanging"> <li>configuring and allocating network resources for the exclusive use o
<t> A) configuring and allocating network resources for the exclusiv f DetNet flows; </li>
e use of DetNet flows; </t> <li>identifying, in the data plane, the resources to be utilized by any
<t> B) identifying, in the data plane, the resources to be utilized given packet; and</li>
by any given packet;</t> <li>the detailed behavior of those resources, especially transmission qu
<t> C) the detailed behavior of those resources, especially transmis eue selection, so that latency bounds can be reliably assured.</li>
sion queue selection, so that latency bounds can be reliably assured. </ol>
</t> <t>
</list> As explained in <xref target="RFC8655" format="default"/>, DetNet
</t>
<t>
As explained in <xref target="RFC8655"/>, DetNet
flows are notably characterized by flows are notably characterized by
</t> </t>
<t> <ol spacing="normal" type="1">
<list style="numbers"> <li>a maximum bandwidth, guaranteed either by the transmitter or by stric
<t>a maximum bandwidth, guaranteed either by the transmitter or by s t input metering, and </li>
trict input metering; </t> <li>a requirement for a guaranteed worst-case end-to-end latency.</li>
<t>a requirement for a guaranteed worst-case end-to-end latency.</t> </ol>
</list> <t> That latency guarantee,
</t>
<t> That latency guarantee,
in turn, provides the opportunity for the network to supply enough buffe r in turn, provides the opportunity for the network to supply enough buffe r
space to guarantee zero congestion loss. space to guarantee zero congestion loss.
It is assumed in this document that the paths of DetNet flows are fixed. In this document, it is assumed that the paths of DetNet flows are fixe
Before the transmission of a DetNet flow, it is possible to calculate d. 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 eac end-to-end latency bounds and the amount of buffer space required at eac
h hop to ensure zero congestion loss; this can be used by the applications ident h hop to ensure zero congestion loss; this can be used by the applications ident
ified in <xref target="RFC8578"/>. ified in <xref target="RFC8578" format="default"/>.
</t> </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 e
ach hop to
ensure against congestion loss.
</t> -->
<t> <t>
This document presents a timing model for sources, destinations, and the This document presents a timing model for sources, destinations, and the
DetNet transit nodes; using this model, it provides a methodology to com DetNet transit nodes; using this model, it provides a methodology to com
pute end-to-end latency and backlog bounds for various queuing mechanisms that c pute end-to-end latency and backlog bounds for various queuing mechanisms that c
an be used by the management and control planes to provide DetNet qualities of s an be used by the management and control planes to provide DetNet qualities of s
ervice. The methodology used in this document account for the possibility of pac ervice. The methodology used in this document accounts for the possibility of pa
ket reordering within a DetNet node. The bounds on the amount of packet reorderi cket reordering within a DetNet node. The bounds on the amount of packet reorder
ng is out of the scope of this document and can be found in <xref target="Packet ing is out of the scope of this document and can be found in <xref target="Packe
ReorderingBounds"/>. Moreover, this document references specific queuing mechani tReorderingBounds" format="default"/>. Moreover, this document references specif
sms, mentioned in <xref target="RFC8655"/>, as proofs of concept that can be use ic queuing mechanisms, mentioned in <xref target="RFC8655" format="default"/>, a
d to control packet transmission at each output port and achieve the DetNet qual s proofs of concept that can be used to control packet transmission at each outp
ity of service. ut port and achieve the DetNet quality of service (QoS).
</t><t> </t>
<t>
Using the model presented in this document, it is possible for an Using the model presented in this document, it is possible for an
implementer, user, or standards development organization to select implementer, user, or standards development organization to select
a set of queuing mechanisms for each device in a DetNet network, a set of queuing mechanisms for each device in a DetNet network
and to select a resource reservation algorithm for that network, so that and to select a resource reservation algorithm for that network so that
those elements can work together to provide the DetNet service. <xref ta those elements can work together to provide the DetNet service. <xref ta
rget="example"/> provides an example application of the timing model introduced rget="example" format="default"/> provides an example application of the timing
in this document on a DetNet IP network with a combination of different queuing model introduced in this document on a DetNet IP network with a combination of d
mechanisms. ifferent queuing mechanisms.
</t><t> </t>
<t>
This document does not specify any resource reservation protocol or cont rol plane function. This document does not specify any resource reservation protocol or cont rol plane function.
<!-- It disregards the in-band packets that can be part of the stream su ch as OAM and necessary re-transmissions. -->
It does not describe all of the requirements for that protocol or contro l plane function. It does not describe all of the requirements for that protocol or contro l plane function.
It does describe requirements for such resource reservation methods, It does describe requirements for such resource reservation methods
and for queuing mechanisms that, if met, will enable them to work togeth er. and for queuing mechanisms that, if met, will enable them to work togeth er.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology and Definitions"> <name>Terminology and Definitions</name>
<t> <t>
This document uses the terms defined in <xref target="RFC8655"/>. Moreover, This document uses the terms defined in <xref target="RFC8655" format="defau
the following terms are used in this document: lt"/>. Moreover, the following terms are used in this document:
</t> </t>
<t> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>T-SPEC</dt>
<t hangText="T-SPEC"><vspace blankLines="0"/> <dd>TrafficSpecification, as defined in <xref target="RFC9016" section="
TrafficSpecification as defined in Section 5.5 of <xref target 5.5" sectionFormat="of" format="default"/>.
="RFC9016"/>. </dd>
</t> <dt>arrival curve</dt>
<t hangText="arrival curve"><vspace blankLines="0"/> <dd>An arrival curve function alpha(t) is an upper bound on the number o
An arrival curve function alpha(t) is an upper bound on the numb f bits seen at an observation point within any time interval t.
er of bits seen at an observation point within any time interval t. </dd>
</t> <dt>CQF</dt>
<t hangText="CQF"><vspace blankLines="0"/> <dd>Cyclic Queuing and Forwarding.
Cyclic Queuing and Forwarding. </dd>
</t> <dt>CBS</dt>
<t hangText="CBS"><vspace blankLines="0"/> <dd>Credit-Based Shaper.
Credit-based Shaper. </dd>
</t> <dt>TSN</dt>
<t hangText="TSN"><vspace blankLines="0"/> <dd>Time-Sensitive Networking.
Time-Sensitive Networking. </dd>
</t> <dt>PREOF</dt>
<t hangText="PREOF"><vspace blankLines="0"/> <dd>A collective name for Packet Replication, Elimination, and Ordering
A collective name for Packet Replication, Elimination, and Order Functions.
ing Functions. </dd>
</t> <dt>POF</dt>
<t hangText="Packet Ordering Function (POF)"><vspace blankLines="0"/ <dd>A Packet Ordering Function is a function that reorders packets withi
> n a DetNet flow that are received out of order. This function can be implemente
A function that reorders packets within a DetNet flow that are r d by a DetNet edge node, a DetNet relay node, or an end system.
eceived out of order. This function can be implemented by a DetNet edge node, a </dd>
DetNet relay node, or an end system. </dl>
</t> </section>
</list> <section numbered="true" toc="default">
</t> <name>DetNet Bounded Latency Model</name>
<section anchor="flow-admission" numbered="true" toc="default">
</section> <name>Flow Admission</name>
<section title="DetNet bounded latency model">
<section title="Flow admission" anchor="flow-admission">
<t> <t>
This document assumes that the following paradigm is used to admit D etNet flows: This document assumes that the following paradigm is used to admit D etNet flows:
</t><t> </t>
<list style="numbers"> <ol spacing="normal" type="1">
<t> <li>
Perform any configuration required by the DetNet transit nod es in the network for aggregates of DetNet flows. Perform any configuration required by the DetNet transit nod es in the network for aggregates of DetNet flows.
This configuration is done beforehand, and not tied to any p This configuration is done beforehand and not tied to any pa
articular DetNet flow. rticular DetNet flow.
</t><t> </li>
<li>
Characterize the new DetNet flow, particularly in terms of r equired bandwidth. Characterize the new DetNet flow, particularly in terms of r equired bandwidth.
</t><t> </li>
<li>
Establish the path that the DetNet flow will take through th e network Establish the path that the DetNet flow will take through th e network
from the source to the destination(s). This can be a point- to-point from the source to the destination(s). This can be a point- to-point
or a point-to-multipoint path. or a point-to-multipoint path.
</t><t> </li>
Compute the worst-case end-to-end latency for the DetNet flo <li>
w, using one Compute the worst-case end-to-end latency for the DetNet flo
of the methods, below (<xref target="static-calculation"/>, w using one
<xref target="dynamic-calculation"/>). In the process, of the methods below (Sections <xref target="static-calculat
ion" format="counter"/> and
<xref target="dynamic-calculation" format="counter"/>). In
the process,
determine whether sufficient resources are available for the DetNet flow to determine whether sufficient resources are available for the DetNet flow to
guarantee the required latency and to provide zero congestio n loss. guarantee the required latency and to provide zero congestio n loss.
</t><t> </li>
<li>
Assuming that the resources are available, commit those reso urces to the Assuming that the resources are available, commit those reso urces to the
DetNet flow. This may or may not require adjusting the para meters that control DetNet flow. This may require adjusting the parameters that control
the filtering and/or queuing mechanisms at each hop along th e DetNet flow's path. the filtering and/or queuing mechanisms at each hop along th e DetNet flow's path.
</t> </li>
</list> </ol>
</t>
<t> <t>
This paradigm can be implemented using peer-to-peer protocols or usi ng a This paradigm can be implemented using peer-to-peer protocols or usi ng a
central controller. In some situations, a lack of resources can req uire central controller. In some situations, a lack of resources can req uire
backtracking and recursing through the above list. backtracking and recursing through the above list.
</t><t> </t>
Issues such as service preemption of a DetNet flow in favor of anoth <t>
er, when Issues, such as service preemption of a DetNet flow in favor of anot
her, when
resources are scarce, are not considered here. Also not addressed is the question of 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. how to choose the path to be taken by a DetNet flow.
</t> </t>
<section title="Static latency-calculation" anchor="static-calculation"> <section anchor="static-calculation" numbered="true" toc="default">
<t> <name>Static Latency Calculation</name>
<list hangIndent="8" style="hanging"> <dl newline="true" spacing="normal" indent="8">
<t hangText="The static problem:"><vspace blankLines="0"/> <dt>The static problem:</dt>
<dd>
Given a network and a set of DetNet flows, compute an Given a network and a set of DetNet flows, compute an
end-to-end latency bound (if computable) for each DetNet flow, and compute end-to-end latency bound (if computable) for each DetNet flow and compute
the resources, particularly buffer space, required in ea ch DetNet transit node the resources, particularly buffer space, required in ea ch DetNet transit node
to achieve zero congestion loss. to achieve zero congestion loss.
</t> </dd>
</list> </dl>
</t><t> <t>
In this calculation, all of the DetNet flows are known before th e In this calculation, all of the DetNet flows are known before th e
calculation commences. This problem is of interest to relativel y calculation commences. This problem is of interest to relativel y
static networks, or static parts of larger networks. It provides static networks or static parts of larger networks. It provides
bounds on latency and buffer size. The calculations can be exte nded bounds on latency and buffer size. The calculations can be exte nded
to provide global optimizations, such as altering the path of on e to provide global optimizations, such as altering the path of on e
DetNet flow in order to make resources available to another DetN et DetNet flow in order to make resources available to another DetN et
flow with tighter constraints. flow with tighter constraints.
</t> </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 ca
n be refused,
or some other suitable action taken.
</t> -->
<t> <t>
This calculation may be more difficult to perform than the This calculation may be more difficult to perform than the
dynamic calculation (<xref target="dynamic-calculation"/>), beca use the dynamic calculation (<xref target="dynamic-calculation" format=" default"/>) because the
DetNet flows passing through one port on a DetNet transit node a ffect each other's DetNet flows passing through one port on a DetNet transit node a ffect each other's
latency. The effects can even be circular, from a node A to B t o C latency. The effects can even be circular, from node A to B to C
and back to A. On the other hand, the static calculation can of ten and back to A. On the other hand, the static calculation can of ten
accommodate queuing methods, such as transmission selection by accommodate queuing methods, such as transmission selection by
strict priority, that are unsuitable for the dynamic calculation . strict priority, that are unsuitable for the dynamic calculation .
</t> </t>
</section> </section>
<section title="Dynamic latency-calculation" anchor="dynamic-calculation <section anchor="dynamic-calculation" numbered="true" toc="default">
"> <name>Dynamic Latency Calculation</name>
<t> <dl newline="true" spacing="normal" indent="8">
<list hangIndent="8" style="hanging"> <dt>The dynamic problem:</dt>
<t hangText="The dynamic problem:"><vspace blankLines="0"/> <dd>
Given a network whose maximum capacity for DetNet flows is Given a network whose maximum capacity for DetNet flows is
bounded by a set of static configuration parameters appl ied to the bounded by a set of static configuration parameters appl ied to the
DetNet transit nodes, and given just one DetNet flow, co mpute the worst-case DetNet transit nodes and given just one DetNet flow, com pute the worst-case
end-to-end latency that can be experienced by that flow, no end-to-end latency that can be experienced by that flow, no
matter what other DetNet flows (within the network's con figured parameters) matter what other DetNet flows (within the network's con figured parameters)
might be created or deleted in the future. Also, comput e the resources, might be created or deleted in the future. Also, comput e the resources,
particularly buffer space, required in each DetNet trans it node particularly buffer space, required in each DetNet trans it node
to achieve zero congestion loss. to achieve zero congestion loss.
</t> </dd>
</list> </dl>
</t><t> <t>
This calculation is dynamic, in the sense that DetNet flows can be added or deleted This calculation is dynamic, in the sense that DetNet flows can be added or deleted
at any time, with a minimum of computation effort, and without a ffecting at any time, with a minimum of computation effort and without af fecting
the guarantees already given to other DetNet flows. the guarantees already given to other DetNet flows.
</t> </t>
<t> <t>
Dynamic latency-calculation can be done based on the static one Dynamic latency calculation can be done based on the static one
described in <xref target="static-calculation"/>; described in <xref target="static-calculation" format="default"/>;
when a new DetNet flow is created or deleted, the entire calcula tion for all DetNet flows is when a new DetNet flow is created or deleted, the entire calcula tion for all DetNet flows is
repeated. If an already-established DetNet flow would be pushed beyond its latency repeated. If an already-established DetNet flow would be pushed beyond its latency
requirements by the new DetNet flow request, then the new DetNet requirements by the new DetNet flow request, then the new DetNet
flow request can be refused, flow request can be refused
or some other suitable action taken. or some other suitable action can be taken.
</t> </t>
<t> <t>
The choice of queuing methods is critical to the applicability o f the The choice of queuing methods is critical to the applicability o f the
dynamic calculation. Some queuing methods (e.g., CQF, <xref tar dynamic calculation. Some queuing methods (e.g., CQF, <xref tar
get="cqf"/>) make get="cqf" format="default"/>) make
it easy to configure bounds on the network's capacity, and to ma it easy to configure bounds on the network's capacity and to mak
ke e
independent calculations for each DetNet flow. Some other queuin g methods (e.g., strict priority with the credit-based shaper independent calculations for each DetNet flow. Some other queuin g methods (e.g., strict priority with the credit-based shaper
defined in <xref target="IEEE8021Q"/> section 8.6.8.2) can be us ed for dynamic DetNet flow creation, defined in Section 8.6.8.2 of <xref target="IEEE8021Q" format="d efault"/>) can be used for dynamic DetNet flow creation
but yield poorer latency and buffer space guarantees than when t hat same but yield poorer latency and buffer space guarantees than when t hat same
queuing method is used for static DetNet flow creation queuing method is used for static DetNet flow creation
(<xref target="static-calculation"/>). (<xref target="static-calculation" format="default"/>).
</t> </t>
</section> </section>
</section> </section>
<section anchor="relay_model" title="Relay node model"> <section anchor="relay_model" numbered="true" toc="default">
<t>A model for the operation of a DetNet transit node is required, in or <name>Relay Node Model</name>
der to <t>A model for the operation of a DetNet transit node is required in ord
er to
define the latency and buffer calculations. define the latency and buffer calculations.
In <xref target="fig_timing_model"/> we see a breakdown of the per-h In <xref target="fig_timing_model" format="default"/>, we see a brea
op latency experienced by a packet passing through a DetNet transit node, in kdown of the per-hop latency experienced by a packet passing through a DetNet tr
terms that are suitable for computing both hop-by-hop latency an ansit node in
d per-hop buffer requirements.</t> terms that are suitable for computing both hop-by-hop latency and per-ho
<figure title="Timing model for DetNet or TSN" anchor="fig_timing_mo p buffer requirements.</t>
del"> <figure anchor="fig_timing_model">
<artwork align="center"><![CDATA[ <name>Timing Model for DetNet or TSN</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
DetNet transit node A DetNet transit node B DetNet transit node A DetNet transit node B
+-------------------------+ +------------------------+ +-------------------------+ +------------------------+
| Queuing | | Queuing | | Queuing | | Queuing |
| Regulator subsystem | | Regulator subsystem | | Regulator subsystem | | Regulator subsystem |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
-->+ | | | | | | | | | + +------>+ | | | | | | | | | + +---> -->+ | | | | | | | | | + +------>+ | | | | | | | | | + +--->
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | | | | | | |
+-------------------------+ +------------------------+ +-------------------------+ +------------------------+
|<->|<------>|<------->|<->|<---->|<->|<------>|<------>|<->|<-- |<->|<------>|<------->|<->|<---->|<->|<------>|<------>|<->|<--
2,3 4 5 6 1 2,3 4 5 6 1 2,3 2,3 4 5 6 1 2,3 4 5 6 1 2,3
1: Output delay 4: Processing delay 1: Output delay 4: Processing delay
2: Link delay 5: Regulation delay 2: Link delay 5: Regulation delay
3: Frame preemption delay 6: Queuing delay 3: Frame preemption delay 6: Queuing subsystem delay
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In <xref target="fig_timing_model"/>, we see two DetNet transit n <t>In <xref target="fig_timing_model" format="default"/>, we see two Det
odes that are connected via a link. In this model, the only queues, that we deal Net transit nodes that are connected via a link. In this model, the only queues
with explicitly, are attached to the output port; other queues a that we deal
re modeled as variations with explicitly are attached to the output port; other queues ar
e modeled as variations
in the other delay times (e.g., an input queue could be modeled as either a variation 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).) There are s ix delays that a packet in the link delay (2) or the processing delay (4)). There are s ix delays that a packet
can experience from hop to hop.</t> can experience from hop to hop.</t>
<t><list style="hanging"> <ol spacing="normal" type="1">
<t hangText="1. Output delay"><vspace blankLines="0"/> <li><t>Output delay</t>
The time taken from the selection of a packet for output fro <t>
m a queue to the This is the time taken from the selection of a packet for output fro
m
a queue to the
transmission of the first bit of the packet on the physical link. If the transmission of the first bit of the packet on the physical link. If the
queue is directly attached to the physical port, output dela y can be a constant. queue is directly attached to the physical port, output dela y can be a constant.
But, in many implementations, the queuing mechanism in a for However, in many implementations, a multiplexed connection se
warding ASIC is parates the queuing mechanism from a multi-port Network Interface Card (NIC).
separated from a multi-port MAC/PHY, in a second ASIC, by a
multiplexed connection.
This causes variations in the output delay that are hard for the forwarding node This causes variations in the output delay that are hard for the forwarding node
to predict or control. to predict or control.
</t> </t></li>
<t hangText="2. Link delay"><vspace blankLines="0"/> <li><t>Link delay</t>
The time taken from the transmission of the first bit of the <t>
packet to the 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 reception of the last bit, assuming that the transmission is not suspended by
a frame preemption event. This delay has two components, th a frame preemption event. This delay has two components: th
e e first-bit-out to first-bit-in delay and the first-bit-in to last-bit-in delay
first-bit-out to first-bit-in delay and the first-bit-in to that varies with packet size. The former is typically constant. However,
last-bit-in delay a virtual "link" could exhibit a variable link delay.</t></l
that varies with packet size. The former is typically measu i>
red by the Precision Time <li><t>Frame preemption delay</t>
Protocol and is constant (see <xref target="RFC8655"/>). Ho <t>
wever, If the packet is interrupted in order to transmit another packet or
a virtual "link" could exhibit a variable link delay.</t> packets
<t hangText="3. Frame preemption delay"><vspace blankLines="0"/> (e.g., frame preemption, as in <xref target="IEEE8023" format="defaul
If the packet is interrupted in order to transmit another pa t"/>, clause 99),
cket or packets, an arbitrary delay can result.</t></li>
(e.g., <xref target="IEEE8023"/> clause 99 frame preemption) <li><t>Processing delay</t>
an arbitrary delay can result.</t> <t>
<t hangText="4. Processing delay"><vspace blankLines="0"/>
This delay covers the time from the reception of the last bi t of the packet to the This delay covers the time from the reception of the last bi t of the packet to the
time the packet is enqueued in the regulator (queuing subsys time the packet is enqueued in the regulator (queuing subsys
tem, if there is no regulator) as shown in <xref target="fig_timing_model"/>. tem if there is no regulator), as shown in <xref target="fig_timing_model" forma
This delay can be variable, and depends on the details of th t="default"/>.
e operation of the forwarding node.</t> This delay can be variable and depends on the details of the
<t hangText="5. Regulator delay"><vspace blankLines="0"/> operation of the forwarding node.</t></li>
A regulator, also known as shaper in <xref target="RFC2475"/ <li><t>Regulator queuing delay</t>
>, delays some or all of the packets in a traffic stream in order to bring the s <t>
tream into compliance with an arrival curve; an arrival curve 'alpha(t)' is an u A regulator, also known as shaper in <xref target="RFC2475"
pper bound on the number of bits observed within any interval t. The regulator d format="default"/>, delays some or all of the packets in a traffic stream in ord
elay is the time spent from the insertion of the last bit of a packet into a reg er to bring the stream into compliance with an arrival curve; an arrival curve '
ulation queue until the time the packet is declared eligible according to its re alpha(t)' is an upper bound on the number of bits observed within any interval t
gulation constraints. We assume that this time can be calculated based on the de . The regulator delay is the time spent from the insertion of the last bit of a
tails of regulation policy. If there is no regulation, this time is zero.</t> packet into a regulation queue until the time the packet is declared eligible ac
<t hangText="6. Queuing subsystem delay"><vspace blankLines="0"/ cording to its regulation constraints. We assume that this time can be calculate
> d based on the details of regulation policy. If there is no regulation, this tim
e is zero.</t></li>
<li><t>Queuing subsystem delay</t>
<t>
This is the time spent for a packet from being declared elig ible until being This is the time spent for a packet from being declared elig ible until being
selected for output on the next link. We assume that this t ime is selected for output on the next link. We assume that this t ime is
calculable based on the details of the queuing mechanism. If there is no regulation, this time is from the insertion 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 o of the packet into a queue until it is selected for output o
n the next link.</t> n the next link.
</list></t> </t></li>
<t>Not shown in <xref target="fig_timing_model"/> are the other outp </ol>
ut queues that we <t>Not shown in <xref target="fig_timing_model" format="default"/> are t
he other output queues that we
presume are also attached to that same output port as the queue shown, and against presume are also attached to that same output port as the queue shown, and against
which this shown queue competes for transmission opportunities.< /t> which this shown queue competes for transmission opportunities.< /t>
<t>In this analysis, the measurement is from the point at which a pa cket is selected for output in a node to the point at which it is selected for o utput in the next downstream node (that is the definition of a "hop"). In gener al, <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 outpu t in the next downstream node (i.e., the definition of a "hop"). In general,
any queue selection method that is suitable for use in a DetNet network includes 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. 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 fo r additional Any variations in any of the delay times 1-4 result in a need fo r additional
buffers in the queue. If all delays 1-4 are constant, then any variation in the 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 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, of packet selection in the previous node. If delays 1-4 are not constant,
then additional buffers are required in the queue to absorb thes e variations. then additional buffers are required in the queue to absorb thes e variations.
Thus: Thus:
<list style="symbols"> </t>
<t>Variations in output delay (1) require buffers to absorb <ul spacing="normal">
that variation <li>Variations in the output delay (1) require buffers to absorb that
variation
in the next hop, so the output delay variations of the p revious hop (on each in the next hop, so the output delay variations of the p revious hop (on each
input port) must be known in order to calculate the buff er space required input port) must be known in order to calculate the buff er space required
on this hop.</t> on this hop.</li>
<t>Variations in processing delay (4) require additional out <li>Variations in the processing delay (4) require additional output b
put buffers uffers
in the queues of that same DetNet transit node. Dependi ng on the details in the queues of that same DetNet transit node. Dependi ng on the details
of the queuing subsystem delay (6) calculations, these v ariations need not be of the queuing subsystem delay (6) calculations, these v ariations need not be
visible outside the DetNet transit node. visible outside the DetNet transit node.
</t> </li>
</list></t> </ul>
</section> </section>
</section> </section>
<section anchor="e2eLatency" title="Computing End-to-end Delay Bounds"> <section anchor="e2eLatency" numbered="true" toc="default">
<section title="Non-queuing delay bound" anchor="nonqueuing"> <name>Computing End-to-End Delay Bounds</name>
<t>End-to-end latency bounds can be computed using the delay model in <xref <section anchor="nonqueuing" numbered="true" toc="default">
target="relay_model"/>. Here, it is important <name>Non-queuing Delay Bound</name>
to be aware that for several queuing mechanisms, the end-to-end latency <t>End-to-end latency bounds can be computed using the delay model in <x
bound is less than the sum of the ref target="relay_model" format="default"/>. Here, it is important
to be aware that, for several queuing mechanisms, the end-to-end latency
bound is less than the sum of the
per-hop latency bounds. per-hop latency bounds.
An end-to-end latency bound for one DetNet flow An end-to-end latency bound for one DetNet flow
can be computed as can be computed as
</t> </t>
<t> <t indent="3"> end_to_end_delay_bound = non_queuing_delay_bound + queuin
<list style="hanging"> g_delay_bound
<t> end_to_end_delay_bound = non_queuing_delay_bound + queuing_delay
_bound
</t> </t>
</list>
</t> <t>The two terms in the above formula are computed as follows. </t>
<t>The two terms in the above formula are computed as follows. </t> <t>
<t>
First, at the h-th hop along the path of this DetNet flow, obtain an upp er-bound First, at the h-th hop along the path of this DetNet flow, obtain an upp er-bound
per-hop_non_queuing_delay_bound[h] on the sum of the bounds over the del per-hop_non_queuing_delay_bound[h] on the sum of the bounds over delays
ays 1, 2, 3, and 4
1,2,3,4 of <xref target="fig_timing_model" format="default"/>. These upper boun
of <xref target="fig_timing_model"/>. These upper bounds are expected t ds are expected to
o
depend on the specific technology of the DetNet transit node at the h-th hop but not on 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 set non_qu euing_delay_bound = the sum the T-SPEC of this DetNet flow <xref target="RFC9016" format="default"/> . Then, set non_queuing_delay_bound = the sum
of per-hop_non_queuing_delay_bound[h] over all hops h. of per-hop_non_queuing_delay_bound[h] over all hops h.
</t> </t>
<t> <t>
Second, compute queuing_delay_bound as an upper bound to the sum of the 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 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 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 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 arriva mechanisms deployed along the path of this DetNet flow. Note that arriva
l curve of DetNet flow at source is immediately specified by the T-SPEC of this l curve of the DetNet flow at the source is immediately specified by the T-SPEC
flow. The computation of queuing_delay_bound of this flow. The computation of queuing_delay_bound
is described in <xref target="queuing"/> as a separate section. is described in <xref target="queuing" format="default"/> as a separate
</t> section.
</section> </t>
<section title="Queuing delay bound" anchor="queuing"> </section>
<t> <section anchor="queuing" numbered="true" toc="default">
For several queuing mechanisms, queuing_delay_bound is less than the sum <name>Queuing Delay Bound</name>
of upper bounds on the queuing delays (5,6) <t>
at every hop. This occurs with (1) per-flow queuing, and (2) aggregate For several queuing mechanisms, queuing_delay_bound is less than the sum
queuing with regulators, as explained in <xref target="perflow"/>, <xref target= of upper bounds on the queuing delays (5 and 6)
"perclass"/>, and <xref target="queue_model"/>. For other queuing mechanisms the at every hop. This occurs with (1) per-flow queuing and (2) aggregate q
only available value of queuing_delay_bound ueuing with regulators, as explained in Sections <xref target="perflow" format="
counter"/>, <xref target="perclass" format="counter"/>, and <xref target="queue_
model" format="counter"/>. For other queuing mechanisms, the only available valu
e of queuing_delay_bound
is the sum of the per-hop queuing delay bounds. is the sum of the per-hop queuing delay bounds.
</t> </t>
<t>
<t> The computation of per-hop queuing delay bounds must account for the fac
The computation of per-hop queuing delay bounds must account for the fac t that the arrival curve of a DetNet flow is no longer satisfied at the ingress
t 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 no
of a hop, since burstiness increases as one flow traverses one DetNet transit no de. If a regulator is placed at a hop, an arrival curve of a DetNet flow at the
de. 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 regul
entrance of the queuing subsystem of this hop is the one configured at the regul ator (also called shaping curve in <xref target="NetCalBook" format="default"/>)
ator (also called shaping curve in <xref target="NetCalBook"/>); otherwise, an a ; otherwise, an arrival curve of the flow can be derived using the delay jitter
rrival curve of the flow can be derived using the delay-jitter of the flow from of the flow from the last regulation point (the last regulator in the path of th
the last regulation point (the last regulator in the path of the flow if there i e flow if there is any, otherwise the source of the flow) to the ingress of the
s any, otherwise the source of the flow) to the ingress of the hop; more formall hop; more formally, assume a DetNet flow has an arrival curve at the last regula
y, assume a DetNet flow has arrival curve at the last regulation point equal to tion point equal to 'alpha(t)' and the delay jitter from the last regulation poi
'alpha(t)', and the delay-jitter from the last regulation point to the ingress o nt to the ingress of the hop is 'V'. Then, the arrival curve at the ingress of t
f the hop is 'V'. Then, the arrival curve at the ingress of the hop is 'alpha(t+ he hop is 'alpha(t+V)'.
V)'. </t>
</t> <t>
<t> For example, consider a DetNet flow with T-SPEC "Interval: tau, MaxPacke
For example, consider a DetNet flow with T-SPEC "Interval: tau, MaxPacke tsPerInterval: K, MaxPayloadSize: L" at the source. Then, a leaky-bucket arrival
tsPerInterval: K, MaxPayloadSize: L" at source. Then, a leaky-bucket arrival cur curve for such flow at the source is alpha(t)=r * t+ b, t&gt;0; alpha(0)=0, whe
ve for such flow at source is alpha(t)=r * t+ b, t>0; alpha(0)=0, where r is the re r is the rate and b is the bucket size, computed as
rate and b is the bucket size, computed as </t>
</t> <t indent="3">r = K * (L+L') / tau,
<t>
<list style="hanging">
<t>
r = K * (L+L') / tau,
</t> </t>
<t> <t indent="3">b = K * (L+L').
b = K * (L+L').
</t> </t>
</list>
</t>
<t>
where L' is the size of any added networking technology-specific encapsu
lation (e.g., MPLS label(s), UDP, and IP headers). Now, if the flow has delay-ji
tter of 'V' from the last regulation point to the ingress of a hop, an arrival c
urve at this point is r * t + b + r * V, implying that the burstiness is increas
ed by r*V. A more detailed information on arrival curves is available in <xref t
arget="NetCalBook"/>.
</t>
<section title="Per-flow queuing mechanisms" anchor="perflow">
<t> <t>
With such mechanisms, each flow uses a separate queue inside every n ode. The service for each queue is abstracted with a guaranteed rate and a laten cy. For every DetNet flow, a per-node latency bound as well as an end-to-end lat ency 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 pa th. An instance of per-flow queuing is IntServ's Guaranteed-Service, for which t he details of latency bound calculation are presented in <xref target="intserv"/ >. where L' is the size of any added networking technology-specific encapsu lation (e.g., MPLS label(s), UDP, or IP headers). Now, if the flow has a delay j itter 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 increa sed by r*V. More detailed information on arrival curves is available in <xref ta rget="NetCalBook" format="default"/>.
</t> </t>
</section> <section anchor="perflow" numbered="true" toc="default">
<name>Per-Flow Queuing Mechanisms</name>
<section title="Aggregate queuing mechanisms" anchor="perclass"> <t>
<t> With such mechanisms, each flow uses a separate queue inside every n
With such mechanisms, multiple flows are aggregated into macro-f ode. The service for each queue is abstracted with a guaranteed rate and a laten
lows and there is one FIFO queue per macro-flow. A practical example is the cred cy. For every DetNet flow, a per-node latency bound, as well as an end-to-end la
it-based shaper defined in section 8.6.8.2 of <xref target="IEEE8021Q"/> where a tency bound, can be computed from the traffic specification of this DetNet flow
macro-flow is called a "class". One key issue in this context is how to deal w at its source and from the values of rates and latencies at all nodes along its
ith the burstiness cascade: individual flows that share a resource dedicated to path. An instance of per-flow queuing is Guaranteed Service <xref target="RFC221
a macro-flow may see their burstiness increase, which may in turn cause increase 2" format="default"/>, for which the details of latency bound calculation are pr
d burstiness to other flows downstream of this resource. Computing delay upper b esented in <xref target="intserv" format="default"/>.
ounds for such cases is difficult, and in some conditions impossible <xref targe </t>
t="CharnyDelay"/><xref target="BennettDelay"/>. Also, when bounds are obtained, </section>
they depend on the complete configuration, and must be recomputed when one flow <section anchor="perclass" numbered="true" toc="default">
is added. (The dynamic calculation, <xref target="dynamic-calculation"/>.) <name>Aggregate Queuing Mechanisms</name>
</t> <t>
<t> With such mechanisms, multiple flows are aggregated into macro-f
A solution to deal with this issue for the DetNet flows is to re lows and there is one FIFO queue per macro-flow. A practical example is the cred
shape them at every hop. This can be done with per-flow regulators (e.g., leaky it-based shaper defined in Section 8.6.8.2 of <xref target="IEEE8021Q" format="d
bucket shapers), but this requires per-flow queuing and defeats the purpose of a efault"/>, where a macro-flow is called a "class". One key issue in this contex
ggregate queuing. An alternative is the interleaved regulator, which reshapes in t is how to deal with the burstiness cascade; individual flows that share a reso
dividual DetNet flows without per-flow queuing (<xref target="SpechtUBS"/>, <xre urce dedicated to a macro-flow may see their burstiness increase, which may in t
f target="IEEE8021Qcr"/>). With an interleaved regulator, the packet at the hea urn cause increased burstiness to other flows downstream of this resource. Compu
d of the queue is regulated based on ting delay upper bounds for such cases is difficult and, in some conditions, imp
its (flow) regulation constraints; it is released at the earliest time at which ossible <xref target="CharnyDelay" format="default"/> <xref target="BennettDelay
this is possible without violating the constraint. One key feature of per-flow o " format="default"/>. Also, when bounds are obtained, they depend on the complet
r interleaved regulator is that, it does not increase worst-case latency bounds e configuration and must be recomputed when one flow is added (i.e., the dynamic
<xref target="LeBoudecTheory"/>. Specifically, when an interleaved regulator is calculation in <xref target="dynamic-calculation" format="default"/>).
appended to a FIFO subsystem, it does not increase the worst-case delay of the l </t>
atter; in <xref target="fig_timing_model"/>, when the order of packets from outp <t>
ut of queuing subsystem at node A to the entrance of regulator at node B is pres A solution to deal with this issue for the DetNet flows is to re
erved, then the regulator does not increase the worst-case latency bounds; this shape them at every hop. This can be done with per-flow regulators (e.g., leaky-
is made possible if all the systems are FIFO or a DetNet packet-ordering functio bucket shapers), but this requires per-flow queuing and defeats the purpose of a
n (POF) is implemented just before the regulator. This property does not hold if ggregate queuing. An alternative is the interleaved regulator, which reshapes in
packet reordering occurs from the output of a queuing subsystem to the entrance dividual DetNet flows without per-flow queuing <xref target="SpechtUBS" format="
of next downstream interleaved regulator, e.g., at a non-FIFO switching fabric. default"/> <xref target="IEEE8021Qcr" format="default"/>. With an interleaved r
</t> egulator, the packet at the head of the queue is regulated based on
<t> its (flow) regulation constraints; it is released at the earliest time at which
<xref target="fig_detnet_e2e_example"/> shows an example of a ne this is possible without violating the constraint. One key feature of a per-flow
twork with 5 nodes, aggregate queuing mechanism and interleaved regulators as in or interleaved regulator is that it does not increase worst-case latency bounds
<xref target="fig_timing_model"/>. <xref target="LeBoudecTheory" format="default"/>. Specifically, when an interle
aved regulator is appended to a FIFO subsystem, it does not increase the worst-c
ase delay of the latter. In <xref target="fig_timing_model" format="default"/>,
when the order of packets from the output of a queuing subsystem at node A to th
e entrance of a regulator at node B is preserved, then the regulator does not in
crease the worst-case latency bounds. This is made possible if all the systems a
re FIFO or a DetNet Packet Ordering Function (POF) is implemented just before th
e regulator. This property does not hold if packet reordering occurs from the ou
tput of a queuing subsystem to the entrance of the next downstream interleaved r
egulator, e.g., at a non-FIFO switching fabric.
</t>
<t>
<xref target="fig_detnet_e2e_example" format="default"/> shows a
n example of a network with 5 nodes, an aggregate queuing mechanism, and interle
aved regulators, as in <xref 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: An end-to-end delay bound for DetNet flow f, traversing nodes 1 to 5, is calculated as follows:
</t> </t>
<t> <t indent="3"> end_to_end_latency_bound_of_flow_f = C12 + C23 + C34 + S
<list style="hanging"> 4
<t> end_to_end_latency_bound_of_flow_f = C12 + C23 + C34 + S
4
</t> </t>
</list> <t>
</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, 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 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"/>, Cij is a bound on sum of the delay <xref target="relay_model" format="default"/>, Cij is a bound on
s 1,2,3,6 of node i and 4,5 of node j. Similarly, S4 is a bound on a sum of delays 1, 2, 3, and 6 of node i and delays 4 and 5 of node j. Similarl
sum of the delays 1,2,3,6 of node 4. A practical example of queu y, S4 is a bound on
ing model and delay calculation is presented <xref target="TSNwithATSmodel"/>. sum of delays 1, 2, 3, and 6 of node 4. A practical example of t
</t> he queuing model and delay calculation is presented <xref target="TSNwithATSmode
<figure title="End-to-end delay computation example" anchor="fig_detnet_e2e_exam l" format="default"/>.
ple"> </t>
<artwork align="center"><![CDATA[ <figure anchor="fig_detnet_e2e_example">
<name>End-to-End Delay Computation Example</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
f f
-----------------------------> ----------------------------->
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| 1 |---| 2 |---| 3 |---| 4 |---| 5 | | 1 |---| 2 |---| 3 |---| 4 |---| 5 |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
\__C12_/\__C23_/\__C34_/\_S4_/ \__C12_/\__C23_/\__C34_/\_S4_/
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
REMARK: If packet reordering does not occur, the end-to-end late <t>
ncy bound calculation provided here gives a tighter latency upper-bound than wou If packet reordering does not occur, the end-to-end latency boun
ld be obtained by adding the latency bounds of each node in the path of a DetNet d calculation provided here gives a tighter latency upper bound than would be ob
flow <xref target="TSNwithATS"/>. tained by adding the latency bounds of each node in the path of a DetNet flow <x
</t> ref target="TSNwithATS" format="default"/>.
</t>
</section> </section>
</section> </section>
<section title="Ingress considerations" anchor="ingress"> <section anchor="ingress" numbered="true" toc="default">
<name>Ingress Considerations</name>
<t> <t>
A sender can be a DetNet node which uses exactly the same queuing me A sender can be a DetNet node that uses exactly the same queuing met
thods hods as its adjacent DetNet transit node so that the latency and buffer bounds c
as its adjacent DetNet transit node, so that the latency and buffer alculations at the first hop are indistinguishable from those at a later hop wit
bounds calculations hin the DetNet domain. On the other hand, the sender may be DetNet unaware; in w
at the first hop are indistinguishable from those at a later hop wit hich case, some conditioning of the DetNet flow may be necessary at the ingress
hin the DetNet transit node. The ingress conditioning typically consists of the regulato
DetNet domain. On the other hand, the sender may be DetNet-unaware, rs described in <xref target="relay_model" format="default"/>.
in which
case some conditioning of the DetNet flow may be necessary at the in
gress DetNet transit
node.
</t><t>
This ingress conditioning typically consists of a FIFO with an outpu
t regulator
that is compatible with the queuing employed by the DetNet transit n
ode on its output
port(s). For some queuing methods, this simply requires added buffe
r space in the queuing subsystem.
Ingress conditioning requirements for different queuing methods are
mentioned
in the sections, below, describing those queuing methods.
</t> </t>
</section> </section>
<section title="Interspersed DetNet-unaware transit nodes" anchor="non-detne <section anchor="non-detnet-nodes" numbered="true" toc="default">
t-nodes"> <name>Interspersed DetNet-Unaware Transit Nodes</name>
<t> <t>
It is sometimes desirable to build a network that has both DetNet-aw are It is sometimes desirable to build a network that has both DetNet-aw are
transit nodes and DetNet-unaware transit nodes, and for a DetNet flo transit nodes and DetNet-unaware transit nodes and for a DetNet flow
w to to
traverse an island of DetNet-unaware transit nodes, while still allo traverse an island of DetNet-unaware transit nodes while still allow
wing the ing the
network to offer delay and congestion loss guarantees. This is poss ible network to offer delay and congestion loss guarantees. This is poss ible
under certain conditions. under certain conditions.
</t><t> </t>
<t>
In general, when passing through a DetNet-unaware island, the island may cause 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 delay variation in excess of what would be caused by DetNet nodes. That
is, the DetNet flow might be "lumpier" after traversing the DetNet-u naware island. is, the DetNet flow might be "lumpier" after traversing the DetNet-u naware island.
DetNet guarantees for delay and buffer requirements can still be DetNet guarantees for delay and buffer requirements can still be
calculated and met if and only if the following are true: calculated and met if and only if the following are true:
</t><t> </t>
<list style="numbers"> <ol spacing="normal" type="1">
<t> <li>
The latency variation across the DetNet-unaware island must be The latency variation across the DetNet-unaware island must be
bounded and calculable. bounded and calculable.
</t><t> </li>
An ingress conditioning function (<xref target="ingress"/>) <li>
is required at the re-entry to the DetNet-aware domain. An ingress conditioning function (<xref target="ingress" for
mat="default"/>)
is required at the reentry to the DetNet-aware domain.
This will, at least, require some extra buffering to accommo date This will, at least, require some extra buffering to accommo date
the additional delay variation, and thus further increases t he the additional delay variation and thus further increases th e
latency bound. latency bound.
</t> </li>
</list> </ol>
</t><t> <t>
The ingress conditioning is exactly the same problem as that of a se nder The ingress conditioning is exactly the same problem as that of a se nder
at the edge of the DetNet domain. The requirement for bounds on the at the edge of the DetNet domain. The requirement for bounds on the
latency variation across the DetNet-unaware island is typically the most latency variation across the DetNet-unaware island is typically the most
difficult to achieve. Without such a bound, it is obvious that DetN et difficult to achieve. Without such a bound, it is obvious that DetN et
cannot deliver its guarantees, so a DetNet-unaware island that canno t cannot deliver its guarantees, so a DetNet-unaware island that canno t
offer bounded latency variation cannot be used to carry a DetNet flo w. offer bounded latency variation cannot be used to carry a DetNet flo w.
</t> </t>
</section>
</section> </section>
</section> <section anchor="achieving" numbered="true" toc="default">
<section anchor="achieving" title="Achieving zero congestion loss"> <name>Achieving Zero Congestion Loss</name>
<t> <t>
When the input rate to an output queue exceeds the output rate for a suf ficient When the input rate to an output queue exceeds the output rate for a suf ficient
length of time, the queue must overflow. This is congestion loss, and t his is length of time, the queue must overflow. This is congestion loss, and t his is
what deterministic networking seeks to avoid. what DetNet seeks to avoid.
</t> </t>
<t> <t>
To avoid congestion losses, an upper bound on the backlog present in the To avoid congestion losses, an upper bound on the backlog present in the
regulator and queuing subsystem of <xref target="fig_timing_model"/> regulator and queuing subsystem of <xref target="fig_timing_model" format="defa
ult"/>
must be computed during resource reservation. This bound depends on the set of flows that use these queues, 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 and an the details of the specific queuing mechanism, and an
upper bound on the processing delay (4). The queue must contain the packet i upper bound on the processing delay (4). The queue must contain the packet i
n transmission plus all other packets that n transmission, plus all other packets that
are waiting to be selected for output. A conservative backlog bound, that a are waiting to be selected for output. A conservative backlog bound that ap
pplies to all systems, can be derived as follows. plies to all systems can be derived as follows.
</t> </t>
<t>
<t> The backlog bound is counted in data units (bytes or words of multiple bytes
The backlog bound is counted in data units (bytes, or words of multiple byte ) that are relevant for buffer allocation.
s) that are relevant for buffer allocation.
For every flow or an aggregate of flows, we need one buffer space for the pa cket in transmission, plus space for the packets that are waiting to be selected for output. For every flow or an aggregate of flows, we need one buffer space for the pa cket in transmission, plus space for the packets that are waiting to be selected for output.
</t> </t>
<t>Let <t>Let
<list style="symbols"> </t>
<t> total_in_rate be the sum of the line rates of all input ports that send <ul spacing="normal">
traffic to this output port. The value of total_in_rate <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. is in data units (e.g., bytes) per second.
</t> </li>
<t>nb_input_ports be the number input ports that send traffic to this output <li>nb_input_ports be the number of input ports that send traffic to thi
port</t> s output port.</li>
<t>max_packet_length be the maximum packet size for packets that may be sent <li>max_packet_length be the maximum packet size for packets that may be
to this output port. This is counted in data units. sent to this output port. This is counted in data units.
</t> </li>
<t>max_delay456 be an upper bound, in seconds, on the sum of the processing <li>max_delay456 be an upper bound, in seconds, on the sum of the proces
delay (4) and the queuing delays (5,6) for any packet sing delay (4) and the queuing delays (5 and 6) for any packet
at this output port. at this output port.
</t> </li>
</ul>
</list> <t>Then, a bound on the backlog of traffic in the queue at this output por
</t> t is</t>
<t indent="3"> backlog_bound = (nb_input_ports * max_packet_length) + (t
<t>Then a bound on the backlog of traffic in the queue at this output port i otal_in_rate * max_delay456)
s</t>
<t>
<list style="hanging">
<t> backlog_bound = (nb_input_ports * max_packet_length) + (total_i
n_rate * max_delay456)
</t>
</list>
</t>
<t>The above bound is over the backlog caused by the traffic entering the qu
eue from the input ports of a DetNet node. If the DetNet node also generates pac
kets (e.g., creation of new packets, 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 conserva
tive backlog bound for this flow is:</t>
<t>
<list style="hanging">
<t> flow_backlog_bound = b + (r * max_delay6)
</t> </t>
</list> <t>The above bound is over the backlog caused by the traffic entering the
</t> queue from the input ports of a DetNet node. If the DetNet node also generates p
<t>where max_delay6 is an upper bound on the queuing delay (6). Finally, the ackets (e.g., creation of new packets or replication of arriving packets), the b
backlog bound at the queue is (backlog_bound + flow_backlog_bound).</t> --> ound must accordingly incorporate the introduced backlog.</t>
</section> </section>
<section anchor="queue_model" numbered="true" toc="default">
<section anchor="queue_model" title="Queuing techniques"> <name>Queuing Techniques</name>
<t>In this section, we present a general queuing data model as well as some <t>In this section, we present a general queuing data model, as well as so
examples of queuing mechanisms. For simplicity of latency bound computation, we me examples of queuing mechanisms. For simplicity of latency bound computation,
assume leaky-bucket arrival curve for each DetNet flow at source. 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 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> with a minimum guaranteed rate and a latency <xref target="NetCalBook" format="
<section anchor="data_model" title="Queuing data model"> default"/>.</t>
<section anchor="data_model" numbered="true" toc="default">
<t>Sophisticated queuing mechanisms are available in Layer 3 (L3, see, e.g., <name>Queuing Data Model</name>
<xref target="RFC7806"/> for an overview). <t>Sophisticated queuing mechanisms are available in Layer 3 (L3) (e.g.,
see <xref target="RFC7806" format="default"/> for an overview).
In general, we assume that "Layer 3" queues, shapers, meters, etc., are precisely the "regulators" In general, we assume that "Layer 3" queues, shapers, meters, etc., are precisely the "regulators"
shown in <xref target="fig_timing_model"/>. The "queuing subsystems" in this figure are FIFO. They are not the province solely of bridges; shown in <xref target="fig_timing_model" format="default"/>. The "queuin g subsystems" in this figure are FIFO. They are not the province solely of bridg es;
they are an essential part of any DetNet transit node. As illustrated b y numerous implementation examples, some of the they are an essential part of any DetNet transit node. As illustrated b y numerous implementation examples, some of the
"Layer 3" mechanisms described in documents such as <xref target="RFC780 6"/> are often integrated, "Layer 3" mechanisms described in documents, such as <xref target="RFC78 06" format="default"/>, are often integrated
in an implementation, with the "Layer 2" mechanisms also implemented in the same node. An integrated model 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 di fferent queuing mechanisms is needed in order to successfully predict the interactions among the di fferent queuing mechanisms
needed in a network carrying both DetNet flows and non-DetNet flows. needed in a network carrying both DetNet flows and non-DetNet flows.
</t> </t>
<t><xref target="fig_8021Q_data_model"/> shows the general model for the flo <t><xref target="fig_8021Q_data_model" format="default"/> shows the gene
w of packets through ral model for the flow of packets through
the queues of a DetNet transit node. The DetNet packets are mapped to a numb the queues of a DetNet transit node. The DetNet packets are mapped to a numb
er of regulators. Here, we assume that the PREOF (Packet Replication, Eliminatio er of regulators. Here, we assume that the Packet Replication, Elimination, and
n and Ordering Functions) are performed before the DetNet packets enter the regu Ordering Functions (PREOF) are performed before the DetNet packets enter the reg
lators. ulators.
All Packets are assigned to a set of queues. Packets compete for the selec All packets are assigned to a set of queues. Packets compete for the selec
tion to be passed to queues in the queuing subsystem. Packets again are selected tion to be passed to queues in the queuing subsystem. Packets again are selected
for output from the for output from the
queuing subsystem. queuing subsystem.
</t> </t>
<figure title="IEEE 802.1Q Queuing Model: Data flow" anchor="fig_8021Q_data_ <figure anchor="fig_8021Q_data_model">
model"> <name>IEEE 802.1Q Queuing Model: Data Flow</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
| |
+--------------------------------V----------------------------------+ +--------------------------------V----------------------------------+
| Queue assignment | | Queue assignment |
+--+------+----------+---------+-----------+-----+-------+-------+--+ +--+------+----------+---------+-----------+-----+-------+-------+--+
| | | | | | | | | | | | | | | |
+--V-+ +--V-+ +--V--+ +--V--+ +--V--+ | | | +--V-+ +--V-+ +--V--+ +--V--+ +--V--+ | | |
|Flow| |Flow| |Flow | |Flow | |Flow | | | | |Flow| |Flow| |Flow | |Flow | |Flow | | | |
| 0 | | 1 | ... | i | | i+1 | ... | n | | | | | 0 | | 1 | ... | i | | i+1 | ... | n | | | |
| reg| | reg| | reg | | reg | | reg | | | | | reg| | reg| | reg | | reg | | reg | | | |
+--+-+ +--+-+ +--+--+ +--+--+ +--+--+ | | | +--+-+ +--+-+ +--+--+ +--+--+ +--+--+ | | |
skipping to change at line 673 skipping to change at line 607
|queue| |queue| |queue| |queue| |queue| |queue| |queue| |queue| |queue| |queue|
| 1 | | 2 | | 3 | | 4 | | 5 | | 1 | | 2 | | 3 | | 4 | | 5 |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | | | | | |
+----------V----------------------V--------------V-------V-------V--+ +----------V----------------------V--------------V-------V-------V--+
| Transmission selection | | Transmission selection |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| |
V V
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Some relevant mechanisms are hidden in this figure, and are performed in <t>Some relevant mechanisms are hidden in this figure and are performed
the in the
queue boxes: queue boxes:
<list style="symbols">
<t>Discarding packets because a queue is full.
</t><t>
Discarding packets marked "yellow" by a metering function, in prefer
ence
to discarding "green" packets <xref target="RFC2697"/>.
</t> </t>
</list> <ul spacing="normal">
</t><t> <li>discarding packets because a queue is full
</li>
<li>
discarding packets marked "yellow" by a metering function in prefere
nce
to discarding "green" packets <xref target="RFC2697" format="default
"/>
</li>
</ul>
<t>
Ideally, neither of these actions are performed on DetNet packets. Full queues Ideally, neither of these actions are performed on DetNet packets. Full queues
for DetNet packets occurs only when a DetNet flow is misbehaving, and th for DetNet packets occur only when a DetNet flow is misbehaving, and the
e DetNet DetNet
QoS does not include "yellow" service for packets in excess of committed QoS does not include "yellow" service for packets in excess
rate. of a committed rate.
</t><t> </t>
<t>
The queue assignment function can be quite complex, even in a The queue assignment function can be quite complex, even in a
bridge <xref target="IEEE8021Q"/>, since the bridge <xref target="IEEE8021Q" format="default"/>, because of the
introduction of per-stream filtering and policing (<xref target="IEEE802 introduction of per-stream filtering and policing (<xref target="IEEE802
1Q"/> clause 8.6.5.1). 1Q" format="default"/>, clause 8.6.5.1).
In addition to the Layer 2 priority 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 particula r queue: 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 particula r queue:
<list style="symbols"> </t>
<t> <ul spacing="normal">
Input port. <li>
</t><t> input port
Selector based on a rotating schedule that starts at regular, ti </li>
me-synchronized <li>
intervals and has nanosecond precision. selector based on a rotating schedule that starts at regular, ti
</t><t> me-synchronized
MAC addresses, VLAN ID, IP addresses, Layer 4 port numbers, DSCP intervals and has nanosecond precision
<xref target="RFC8939"/>, <xref target="RFC8964"/>. </li>
</t><t> <li>
The queue assignment function can contain metering and policing MAC addresses, VLAN ID, IP addresses, Layer 4 port numbers, and
functions. Differentiated Services Code Point (DSCP) <xref target="RFC8939" format="default
</t><t> "/> <xref target="RFC8964" format="default"/>
MPLS and/or pseudo-wire labels <xref target="RFC6658"/>. </li>
</t> <li>
</list> the queue assignment function can contain metering and policing
</t><t> functions
</li>
<li>
MPLS and/or pseudowire labels <xref target="RFC6658" format="def
ault"/>
</li>
</ul>
<t>
The "Transmission selection" function decides which queue is to transfer its The "Transmission selection" function decides which queue is to transfer its
oldest packet to the output port when a transmission opportunity arises. oldest packet to the output port when a transmission opportunity arises.
</t> </t>
</section>
</section> <section anchor="preempt_intro" numbered="true" toc="default">
<section anchor="preempt_intro" title="Frame Preemption"> <name>Frame Preemption</name>
<t> <t>
In <xref target="IEEE8021Q"/> and <xref target="IEEE8023"/>, the transmissio In <xref target="IEEE8021Q" format="default"/> and <xref target="IEEE8023" f
n of a frame ormat="default"/>, the transmission of a frame
can be interrupted by one or more "express" frames, and then the interrupted can be interrupted by one or more "express" frames; then, the interrupted fr
frame can ame can
continue transmission. The frame preemption is modeled as continue transmission. The frame preemption is modeled as
consisting of two MAC/PHY stacks, one for packets that consisting of two MAC/PHY stacks: one for packets that
can be interrupted, and one for packets that can interrupt the interruptible can be interrupted and one for packets that can interrupt the interruptible
packets. packets.
Only one layer of frame preemption is supported -- a transmitter cannot have more than one 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 inte rrupting interrupted frame in progress. DetNet flows typically pass through the inte rrupting
MAC. For those DetNet flows with T-SPEC, latency bounds can be MAC. For those DetNet flows with T-SPEC, latency bounds can be
calculated by the methods provided in the following sections that account fo r the effect of frame preemption, according to the specific calculated by the methods provided in the following sections that account fo r the effect of frame preemption, according to the specific
queuing mechanism that is used in DetNet nodes. Best-effort queues pass thro ugh the queuing mechanism that is used in DetNet nodes. Best-effort queues pass thro ugh the
interruptible MAC, and can thus be preempted. interruptible MAC and can thus be preempted.
</t> </t>
</section> </section>
<section anchor="time_schedule_intro" numbered="true" toc="default">
<section anchor="time_schedule_intro" title="Time-Aware Shaper"> <name>Time-Aware Shaper</name>
<t> <t>
In <xref target="IEEE8021Q"/>, the notion of time-scheduling queue g In <xref target="IEEE8021Q" format="default"/>, the notion of time-s
ates is cheduling queue gates is
described in section 8.6.8.4. On each node, the transmission selecti described in Section 8.6.8.4. On each node, the transmission selecti
on for packets on for packets
is controlled by time-synchronized gates; each output queue is assoc iated with a gate. is controlled by time-synchronized gates; each output queue is assoc iated with a gate.
The gates can be either open or closed. The states of the gates are 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 ope ning and closing determined by the gate control list (GCL). The GCL specifies the ope ning and closing
times of the gates. The design of GCL must satisfy the requirement o f times of the gates. The design of the GCL must satisfy the requireme nt of
latency upper bounds of all DetNet flows; therefore, those DetNet fl ows that traverse a latency upper bounds of all DetNet flows; therefore, those DetNet fl ows that traverse a
network that uses this kind of shaper must have bounded latency, if the traffic and nodes are conformant. network that uses this kind of shaper must have bounded latency if t he traffic and nodes are conformant.
</t> </t>
<t> <t>
Note that scheduled traffic service relies on a synchronized Note that scheduled traffic service relies on a synchronized
network and coordinated GCL configuration. Synthesis of GCL on multi network and coordinated GCL configuration. Synthesis of the GCL on m
ple ultiple
nodes in network is a scheduling problem considering all DetNet flow nodes in a network is a scheduling problem considering all DetNet fl
s ows
traversing the network, which is a non-deterministic polynomial-time traversing the network, which is a nondeterministic polynomial-time
hard hard
(NP-hard) problem <xref target="Sch8021Qbv"/>. Also, at this writing (NP-hard) problem <xref target="Sch8021Qbv" format="default"/>. Also
, scheduled traffic service , at the time of writing, scheduled traffic service
supports no more than eight traffic queues, typically using up to se ven supports no more than eight traffic queues, typically using up to se ven
priority queues and at least one best effort. priority queues and at least one best effort.
</t> </t>
</section> </section>
<section anchor="TSNwithATSmodel" title="Credit-Based Shaper with Asynchrono <section anchor="TSNwithATSmodel" numbered="true" toc="default">
us Traffic Shaping"> <name>Credit-Based Shaper with Asynchronous Traffic Shaping</name>
<t> <t>
In this queuing model, it is assumed that the DetNet nodes are FIFO. 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="IEEE802 We consider the four traffic classes (Definition 3.268 of <xref target="IEEE802
1Q"/>): control-data traffic (CDT), 1Q" format="default"/>): control-data traffic (CDT),
class A, class B, and best effort (BE) in decreasing order of priori class A, class B, and best effort (BE) in decreasing order of priori
ty. Flows of classes A and B are DetNet flows that are less critical than CDT (s ty. Flows of classes A and B are DetNet flows that are less critical than CDT (s
uch as studio audio and video traffic, as in IEEE 802.1BA Audio-Video-Bridging). uch as studio audio and video traffic, as in IEEE 802.1BA Audio-Video-Bridging).
This model is a subset of Time-Sensitive Networking as described next. This model is a subset of Time-Sensitive Networking, as described next.
</t> </t>
<t> <t>
Based on the timing model described in <xref target="fig_timing_mode Based on the timing model described in <xref target="fig_timing_mode
l"/>, contention occurs only at the output port of a DetNet transit node; theref l" format="default"/>, contention occurs only at the output port of a DetNet tra
ore, the focus of the rest of this subsection is on the regulator and queuing su nsit node; therefore, the focus of the rest of this subsection is on the regulat
bsystem in the output port of a DetNet transit node. The input flows are identif or and queuing subsystem in the output port of a DetNet transit node. The input
ied using the information in (Section 5.1 of <xref target="RFC8939"/>). Then the flows are identified using the information in (<xref target="RFC8939" section="5
y are aggregated into eight macro flows based .1" sectionFormat="of" format="default"/>). Then, they are aggregated into eight
on their service requirements; we refer to each macro flow as a clas macro-flows based
s. on their service requirements; we refer to each macro-flow as a clas
s.
The output port performs aggregate scheduling with eight queues (qu euing subsystems): one for CDT, one for class A flows, one for class B flows, an d five for BE traffic denoted as BE0-BE4. The queuing policy for each queuing su bsystem is FIFO. In addition, each node output port also performs per-flow regul ation for The output port performs aggregate scheduling with eight queues (qu euing subsystems): one for CDT, one for class A flows, one for class B flows, an d five for BE traffic denoted as BE0-BE4. The queuing policy for each queuing su bsystem is FIFO. In addition, each node output port also performs per-flow regul ation for
class A and B flows using an interleaved regulator (IR), called Asyn class A and B flows using an interleaved regulator (IR). This regula
chronous Traffic Shaper <xref target="IEEE8021Qcr"/>. Thus, at each output port tion is called
of a node, there is one interleaved regulator per-input asynchronous traffic shaping <xref target="IEEE8021Qcr" format="default"/>. T
port and per-class; the interleaved regulator is mapped to the regul hus, at each output port of a node, there is one interleaved regulator per input
ator depicted in <xref target="fig_timing_model"/>. The detailed picture of sche port and per class; the interleaved regulator is mapped to the regul
duling and regulation architecture at a node output port is given by <xref targe ator depicted in <xref target="fig_timing_model" format="default"/>. The detaile
t="fig_TSN_node"/>. The packets received at a node input port for a given class d picture of scheduling and regulation architecture at a node output port is giv
are enqueued in the respective interleaved regulator at the output port. en by <xref target="fig_TSN_node" format="default"/>. The packets received at a
Then, the packets from all the flows, including CDT and BE flows, ar node input port for a given class are enqueued in the respective interleaved reg
e enqueued in queuing subsystem; there is no regulator for CDT and BE flows. ulator at the output port.
Then, the packets from all the flows, including CDT and BE flows, ar
e enqueued in a queuing subsystem; there is no regulator for CDT and BE flows.
</t> </t>
<figure title="The architecture of an output port inside a relay node wi <figure anchor="fig_TSN_node">
th interleaved regulators (IRs) and credit-based shaper (CBS)" anchor="fig_TSN_n <name>The Architecture of an Output Port inside a Relay Node with Inte
ode"> rleaved Regulators (IRs) and a Credit-Based Shaper (CBS)</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
| | | | | | | | | | | | | | | |
|IR| |IR| |IR| |IR| |IR| |IR| |IR| |IR|
| | | | | | | | | | | | | | | |
+-++XXX++-+ +-++XXX++-+ +-++XXX++-+ +-++XXX++-+
| | | | | | | |
| | | | | | | |
+---+ +-v-XXX-v-+ +-v-XXX-v-+ +-----+ +-----+ +-----+ +-----+ +-----+ +---+ +-v-XXX-v-+ +-v-XXX-v-+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | |Class| |Class| |Class| |Class| |Class| | | | | | | |Class| |Class| |Class| |Class| |Class|
|CDT| | Class A | | Class B | | BE4 | | BE3 | | BE2 | | BE1 | | BE0 | |CDT| | Class A | | Class B | | BE4 | | BE3 | | BE2 | | BE1 | | BE0 |
skipping to change at line 789 skipping to change at line 734
| | | | | | | | | | | | | | | |
| +-v-+ +-v-+ | | | | | | +-v-+ +-v-+ | | | | |
| |CBS| |CBS| | | | | | | |CBS| |CBS| | | | | |
| +-+-+ +-+-+ | | | | | | +-+-+ +-+-+ | | | | |
| | | | | | | | | | | | | | | |
+-v--------v-----------v---------v-------V-------v-------v-------v--+ +-v--------v-----------v---------v-------V-------v-------v-------v--+
| Strict Priority selection | | Strict Priority selection |
+--------------------------------+----------------------------------+ +--------------------------------+----------------------------------+
| |
V V
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Each of the queuing subsystems for classes A and B, contains a Credi Each of the queuing subsystems for classes A and B contains a credit
t-Based Shaper (CBS). The CBS serves a packet from a class according to the avai -based shaper (CBS). The CBS serves a packet from a class according to the avail
lable credit able credit
for that class. As described in Section 8.6.8.2 and Annex L.1 of <xr for that class. As described in Section 8.6.8.2 and Annex L.1 of <xr
ef target="IEEE8021Q"/>, the credit for each class A or B increases based on the ef target="IEEE8021Q" format="default"/>, the credit for each class A or B incre
idle slope (as guaranteed rate), and decreases based on the sendslope (typicall ases based on the idle slope (as guaranteed rate) and decreases based on the sen
y equal to the difference between the guaranteed and the output link rates), bot dslope (typically equal to the difference between the guaranteed and the output
h of which link rates), both of which
are parameters of the CBS. The CDT and BE0-BE4 flows are served by s eparate queuing subsystems. Then, packets from all flows are are parameters of the CBS. The CDT and BE0-BE4 flows are served by s eparate queuing subsystems. Then, packets from all flows are
served by a transmission selection subsystem that serves packets fro m each class based on its priority. All subsystems are non-preemptive. served by a transmission selection subsystem that serves packets fro m each class based on its priority. All subsystems are non-preemptive.
Guarantees for classes A and B traffic can be provided only if CDT t raffic is bounded; it is assumed that the CDT traffic has a leaky bucket arrival curve with two parameters r_h as rate and b_h as bucket size, i.e., the amount of bits entering a node within a time interval t is bounded by r_h * t + b_h. Guarantees for class A and B traffic can be provided only if CDT is bounded. It is assumed that the CDT has a leaky-bucket arrival curve with two pa rameters: r_h as rate and b_h as bucket size. That is, the amount of bits enteri ng a node within a time interval t is bounded by r_h * t + b_h.
</t> </t>
<t> <t>
Additionally, it is assumed that the classes A and B flows are also regulated at their source according to a leaky bucket arrival curve. At the sour ce, the traffic satisfies its regulation constraint, i.e., the delay due to inte rleaved regulator at the source is ignored. Additionally, it is assumed that the class A and B flows are also re gulated at their source according to a leaky-bucket arrival curve. At the source , the traffic satisfies its regulation constraint, i.e., the delay due to interl eaved regulator at the source is ignored.
</t> </t>
<t> <t>
At each DetNet transit node implementing an interleaved regulator, p At each DetNet transit node implementing an interleaved regulator, p
ackets of multiple flows are processed in one FIFO queue; the packet at the head ackets of multiple flows are processed in one FIFO queue. The packet at the head
of the queue is regulated based on its leaky bucket parameters; it i of the queue is regulated based on its leaky-bucket parameters. It i
s released at the earliest time at which this is possible without violating s released at the earliest time at which this is possible without violating
the constraint. the constraint.
</t> </t>
<t> <t>
The regulation parameters for a flow (leaky bucket rate and buck The regulation parameters for a flow (leaky-bucket rate and buck
et size) are the same at its source and at all DetNet transit nodes along its pa et size) are the same at its source and at all DetNet transit nodes along its pa
th in the case where all clocks are perfect. However, in reality there is clock th in the case where all clocks are perfect. However, in reality, there is clock
non-ideality throughout the DetNet domain even with clock synchronization. This non-ideality throughout the DetNet domain, even with clock synchronization. Thi
phenomenon causes inaccuracy in the rates configured at the regulators that may s phenomenon causes inaccuracy in the rates configured at the regulators that ma
lead to network instability. To avoid that, when configuring the regulators, the y lead to network instability. To avoid instability, the rates are set as the so
rates are set as the source rates with some positive margin. <xref target="Thom urce rates with some positive margin when configuring regulators. <xref target="
asTime"/> describes and provides solutions to this issue. ThomasTime" format="default"/> describes and provides solutions to this issue.
</t> </t>
<section title="Delay Bound Calculation" anchor="delayTSNwithATS"> <section anchor="delayTSNwithATS" numbered="true" toc="default">
<t> <name>Delay Bound Calculation</name>
A delay bound of the queuing subsystem ((4) in <xref target="fig <t>
_timing_model"/>) of a given DetNet node for a flow of classes A or B can be com A delay bound of the queuing subsystem ((4) in <xref target="fig
puted if the following condition holds: _timing_model" format="default"/>) of a given DetNet node for a flow of class A
</t> or B can be computed if the following condition holds:
<t> </t>
<list style="hanging"> <t indent="3">The sum of leaky-bucket rates of all flows of this class
<t> sum of leaky bucket rates of all flows of this class at at this transit node &lt;= R, where R is given below for every class
this transit node &lt;= R, where R is given below for every class.
</t> </t>
</list> <t>If the condition holds, the delay bounds for a flow of class X (A o
</t> r B) is d_X and calculated as:</t>
<t>If the condition holds, the delay bounds for a flow of class X (A <t indent="3"> d_X = T_X + (b_t_X-L_min_X)/R_X - L_min_X/c</t>
or B) is d_X and calculated as:</t> <t>
<t> where L_min_X is the minimum packet lengths of class X (A or B);
<list style="hanging"> c is the output link transmission rate; and b_t_X is the sum of the b term (buc
<t> d_X = T_X + (b_t_X-L_min_X)/R_X - L_min_X/c</t> ket size) for all the flows of the class X. Parameters R_X and T_X are calculate
</list> d as follows for class A and B, separately.
</t> </t>
<t> <t>If the flow is of class A:</t>
where L_min_X is the minimum packet lengths of class X (A or B); <t indent="3"> R_A = I_A * (c-r_h)/ c</t>
c is the output link transmission rate; b_t_X is the sum of the b term (bucket <t indent="3">T_A = (L_nA + b_h + r_h * L_n/c)/(c-r_h)</t>
size) for all the flows of the class X. Parameters R_X and T_X are calculated as <t>where I_A is the idle slope for class A; L_nA is the maximum packet
follows for class A and class B, separately: length of class B and BE packets; L_n is the maximum packet length of classes A
</t> , B, and BE; and r_h is the rate and b_h is the bucket size of CDT leaky-bucket
arrival curve. </t>
<t>If the flow is of class A:</t> <t>If the flow is of class B:</t>
<t> <t indent="3">R_B = I_B * (c-r_h)/ c</t>
<list style="hanging"> <t indent="3">T_B = (L_BE + L_A + L_nA * I_A/(c_h-I_A) + b_h + r_h * L
<t> R_A = I_A * (c-r_h)/ c</t> _n/c)/(c-r_h)</t>
<t>T_A = (L_nA + b_h + r_h * L_n/c)/(c-r_h)</t> <t>
</list> where I_B is the idle slope for class B; L_A is the maximum pack
</t> et length of class A; and L_BE is the maximum packet length of class BE.
<t>where I_A is the idle slope for class A; L_nA is the maximum pack </t>
et length of class B and BE packets; L_n is the maximum packet length of classes <t>Then, as discussed in <xref target="perclass" format="default"/>, a
A,B, and BE; r_h is the rate and b_h is the bucket size of CDT traffic leaky bu n interleaved regulator does not increase the delay bound of the upstream queuin
cket arrival curve. </t> g subsystem; therefore, an end-to-end delay bound for a DetNet flow of class X (
<t>If the flow is of class B:</t> A or B) is the sum of d_X_i for all node i in the path of the flow, where d_X_i
<t> is the delay bound of queuing subsystem in node i, which is computed as above. A
<list style="hanging"> ccording to the notation in <xref target="perclass" format="default"/>, the dela
<t>R_B = I_B * (c-r_h)/ c</t> y bound of the queuing subsystem in a node i and interleaved regulator in node j
<t>T_B = (L_BE + L_A + L_nA * I_A/(c_h-I_A) + b_h + r_h * L_ , i.e., Cij, is:</t>
n/c)/(c-r_h)</t> <t indent="3">Cij = d_X_i</t>
</list> <t>More information of delay analysis in such a DetNet transit node is
</t> described in <xref target="TSNwithATS" format="default"/>.</t>
<t>
where I_B is the idle slope for class B; L_A is the maximum pack
et length of class A; L_BE is the maximum packet length of class BE.
</t>
<t>Then, as discussed in <xref target="perclass"/>; an interleaved r
egulator does not increase the delay bound of the upstream queuing subsystem; th
erefore an end-to-end delay bound for a DetNet flow of class X (A or B) is the s
um of d_X_i for all node i in the path the flow, where d_X_i is the delay bound
of queuing subsystem in node i which is computed as above. According to the nota
tion in <xref target="perclass"/>, the delay bound of queuing subsystem in a nod
e 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 calcul
ated by the formula from <xref target="perclass"/>, where for Cij:</t> -->
<t>
<list style="hanging">
<t>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>
</section> </section>
<section anchor="admissionTSNwithATS" numbered="true" toc="default">
<section title="Flow Admission" anchor="admissionTSNwithATS"> <name>Flow Admission</name>
<t> <t>
The delay bound calculation requires some information about each The delay bound calculation requires some information about each
node. For each node, it is required to know the idle slope of CBS for each clas node. For each node, it is required to know the idle slope of the CBS for each
s A and B (I_A and I_B), as well as the transmission rate of the output link (c) class A and B (I_A and I_B), as well as the transmission rate of the output link
. Besides, it is necessary to have the information on each class, i.e., maximum (c). Besides, it is necessary to have the information on each class, i.e., maxi
packet length of classes A, B, and BE. Moreover, the leaky bucket parameters of mum packet length of classes A, B, and BE. Moreover, the leaky-bucket parameters
CDT (r_h,b_h) must be known. To admit a flow/flows of classes A and B, their del of CDT (r_h, b_h) must be known. To admit a flow or flows of classes A and B, t
ay requirements must be guaranteed not to be violated. As described in <xref tar heir delay requirements must be guaranteed not to be violated. As described in <
get="flow-admission"/>, the two problems, static and dynamic, are addressed sepa xref target="flow-admission" format="default"/>, the two problems (static and dy
rately. In either of the problems, the rate and delay must be guaranteed. Thus, namic) are addressed separately. In either of the problems, the rate and delay m
</t> ust be guaranteed. Thus,
<t> </t>
<list hangIndent="8" style="hanging"> <dl newline="true" spacing="normal" indent="8">
<t hangText="The static admission control:"><vspace blankLin <dt>The static admission control:</dt>
es="0"/> <dd>
The leaky bucket parameters of all class A or B flows are kn The leaky-bucket parameters of all class A or B flows are kn
own, therefore, for each class A or B flow f, a delay bound can be calculated. T own; therefore, for each flow f of either class A or B, a delay bound
he computed delay bound for every class A or B flow must not be more than its de can be calculated. The computed delay bound for every flow
lay requirement. Moreover, the sum of the rate of each flow (r_f) must not be mo of class A or B must not be more than its delay requirement. Moreover
re than the rate allocated to each class (R). If these two conditions hold, the , the sum of the rate of each flow (r_f) must not be more than the rate allocate
configuration is declared admissible. d to each class (R). If these two conditions hold, the configuration is declared
</t> admissible.
<t hangText="The dynamic admission control:"><vspace blankLi </dd>
nes="0"/> <dt>The dynamic admission control:</dt>
For dynamic admission control, we allocate to every node and <dd>
class A or B, static value for rate (R) and maximum bucket size (b_t). In addit <dl newline="true" spacing="normal">
ion, for every node and every class A and B, two counters are maintained: <dt> For dynamic admission control, we allocate
</t> a static value for rate (R) and a maximum bucket
<t> size (b_t) to every node and each class A or B.
<list style="hanging"> In addition, for every node and each class A
<t>R_acc is equal to the sum of the leaky-bucket rat or B, two counters are maintained:
es of all flows of this class already admitted at this node; At all times, we mu </dt>
st have:</t> <dd>
<t><list style="hanging"> <t>R_acc is equal to the sum of the leaky-bucket rates of all fl
<t>R_acc &lt;=R, (Eq. 1)</t> ows of this class already admitted at this node; at all times, we must have:</t>
</list></t> <t>R_acc &lt;= R, (Eq. 1)</t>
<t>b_acc is equal to the sum of the bucket sizes of <t>b_acc is equal to the sum of the bucket sizes of all flows of
all flows of this class already admitted at this node; At all times, we must hav this class already admitted at this node; at all times, we must have:</t>
e:</t> <t>b_acc &lt;= b_t. (Eq. 2)</t>
<t><list style="hanging"> </dd>
<t>b_acc &lt;=b_t. (Eq. 2)</t> </dl>
</list></t> <t>
</list> A new class A or B flow is admitted at this node if Eqs. (1) and (
</t> 2) continue to be satisfied after adding its leaky-bucket rate and bucket size t
<t> o R_acc and b_acc. A class A or B flow is admitted in the network if it is admit
A new class A or B flow is admitted at this node, if Eqs. ( ted at all nodes along its path. When this happens, all variables R_acc and b_ac
1) and (2) continue to be satisfied after adding its leaky bucket rate and bucke c along its path must be incremented to reflect the addition of the flow. Simila
t size to R_acc and b_acc. A class A or B flow is admitted in the network, if it rly, when a class A or B flow leaves the network, all variables R_acc and b_acc
is admitted at all nodes along its path. When this happens, all variables R_acc along its path must be decremented to reflect the removal of the flow.
and b_acc along its path must be incremented to reflect the addition of the flo </t></dd>
w. Similarly, when a class A or B flow leaves the network, all variables R_acc a </dl>
nd b_acc along its path must be decremented to reflect the removal of the flow. <t>
</t> The choice of the static values of R and b_t at all nodes and cl
</list> asses must be done in a prior configuration phase: R controls the bandwidth allo
</t> cated to this class at this node, and b_t affects the delay bound and the buffer
<t> requirement. The value of R must be set such that
The choice of the static values of R and b_t at all nodes and cl </t>
asses must be done in a prior configuration phase; R controls the bandwidth allo <t indent="3">R &lt;= I_X*(c-r_h)/c</t>
cated to this class at this node, b_t affects the delay bound and the buffer req <t>
uirement. The value of R must be set such that where I_X is the idleslope of credit-based shaper for class X={A
</t> ,B}, c is the transmission rate of the output link, and r_h is the leaky-bucket
<t><list style="hanging"> rate of the CDT class.
<t>R &lt;= I_X*(c-r_h)/c</t> </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 and r_h is the leaky-bucket r
ate of the CDT class.
<!-- must not be greater than R_X for class X={A,B}, that is com
puted in <xref target="delayTSNwithATS"/>. -->
</t>
</section> </section>
</section>
</section> <section anchor="intserv" numbered="true" toc="default">
<name>Guaranteed Service</name>
<section title="Guaranteed-Service IntServ" anchor="intserv"> <t>The Guaranteed Service is defined in <xref target="RFC2212" format="d
<t> efault"/>. The flow, at the source, has a leaky-bucket arrival curve with two pa
Guaranteed-Service Integrated service (IntServ) is an architecture t rameters: r as rate and b as bucket size, i.e., the amount of bits entering a no
hat specifies the elements to guarantee quality of service (QoS) on networks <xr de within a time interval t is bounded by r * t + b. </t>
ef target="RFC2212"/>.
</t>
<t>The flow, at the source, has a leaky bucket arrival curve with two pa
rameters r as rate and b as bucket size, i.e., the amount of bits entering a nod
e 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 gua ranteed rate R and maximum service latency of T. This can be interpreted in a wa y that the bits might have to wait up to T before being served with a rate great er or equal to R. The delay bound of the flow traversing the node is T + b / R.< /t> <t>If a resource reservation on a path is applied, a node provides a gua ranteed rate R and maximum service latency of T. This can be interpreted in a wa y that the bits might have to wait up to T before being served with a rate great er or equal to R. The delay bound of the flow traversing the node is T + b / R.< /t>
<t> <t>Consider a Guaranteed Service <xref target="RFC2212" format="default"
Consider a Guaranteed-Service IntServ path including a sequence of n /> path including a sequence of nodes, where the i-th node provides a guaranteed
odes, where the i-th node provides a guaranteed rate R_i and maximum service la rate R_i and maximum service latency of T_i.
tency of T_i. Then, the end-to-end delay bound for a flow on this can be calcula Then, the end-to-end delay bound for a flow on this can be calculated as sum(T_
ted as sum(T_i) + b / min(R_i). i) + b / min(R_i).
</t> </t>
<t> <t>The provided delay bound is based on a simple case of Guaranteed Serv
The provided delay bound is based on a simple case of Guaranteed-Ser ice, where only a guaranteed rate and maximum service latency and a leaky-bucket
vice IntServ where only a guaranteed rate and maximum service latency and a leak arrival curve are available. If more information about the flow is known, e.g.
y bucket arrival curve are available. If more information about the flow is know , the peak rate, the delay bound is more complicated; the details are available
n, e.g., the peak rate, the delay bound is more complicated; the details are ava in <xref target="RFC2212" format="default"/> and Section 1.4.1 of <xref target="
ilable in <xref target="RFC2212"/> and Section 1.4.1 of <xref target="NetCalBook NetCalBook" format="default"/>.
"/>.
</t> </t>
</section> </section>
<section title="Cyclic Queuing and Forwarding" anchor="cqf"> <section anchor="cqf" numbered="true" toc="default">
<t> <name>Cyclic Queuing and Forwarding</name>
Annex T of <xref target="IEEE8021Q"/> describes Cyclic Queuing <t>
Annex T of <xref target="IEEE8021Q" format="default"/> describes Cyclic
Queuing
and Forwarding (CQF), which provides bounded latency and zero congestio n loss using and Forwarding (CQF), which provides bounded latency and zero congestio n loss using
the time-scheduled gates of <xref target="IEEE8021Q"/> section 8.6.8.4. For a given class of DetNet the time-scheduled gates of Section 8.6.8.4 of <xref target="IEEE8021Q" format="default"/>. For a given class of DetNet
flows, a set of two or more buffers is provided at the output queue lay er of flows, a set of two or more buffers is provided at the output queue lay er of
<xref target="fig_8021Q_data_model"/>. A cycle time T_c is configured for each class of DetNet <xref 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 c, and all of the buffer sets in a class of DetNet
flows swap buffers simultaneously throughout the DetNet domain flows swap buffers simultaneously throughout the DetNet domain
at that cycle rate, all in phase. In such a mechanism, the regulator, m at that cycle rate, all in phase. In such a mechanism, the regulator, a
entioned in <xref target="fig_timing_model"/>, is not required. s mentioned in <xref target="fig_timing_model" format="default"/>, is not requir
</t> ed.
<t> </t>
<t>
In the case of two-buffer CQF, each class of DetNet flows c has two buff ers, namely buffer1 and buffer2. In a cycle (i) when buffer1 accumulates receive d 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 t he received packets and buffer1 transmits the packets received in cycle (i). The duration of each cycle is T_c. In the case of two-buffer CQF, each class of DetNet flows c has two buff ers, namely buffer1 and buffer2. In a cycle (i) when buffer1 accumulates receive d 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 t he received packets and buffer1 transmits the packets received in cycle (i). The duration of each cycle is T_c.
</t> </t>
<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 fra gment) size from lower priority queues, which might be received within a cycle. 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 fra gment) 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), 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 defined in <xref target="fig_timing_model which is the sum of delays 1, 2, 3, and 4 defined in <xref target="fig_timing_mo
"/>. The value of DT guarantees that the last packet of one cycle in a node is f del" format="default"/>. The value of DT guarantees that the last packet of one
ully delivered to a buffer of the next node in the same cycle. A two-buffer CQF cycle in a node is fully delivered to a buffer of the next node in the same cycl
is recommended if DT is small compared to T_c. For a large DT, CQF with more buf e. A two-buffer CQF is recommended if DT is small compared to T_c. For a large D
fers can be used, and a cycle identification label can be added to the packets. T, CQF with more buffers can be used, and a cycle identification label can be ad
</t> ded to the packets.
<t> </t>
The per-hop latency is determined by the cycle time T_c: a packet transm <t>
itted from a node at a cycle (i), is transmitted from the next node at cycle (i+ The per-hop latency is determined by the cycle time T_c: a packet transm
1). Then, if the packet traverses h hops, the maximum latency experienced by the itted from a node at a cycle (i) is transmitted from the next node at cycle (i+1
packet is from ). Then, if the packet traverses h hops, the maximum latency experienced by the
the beginning of cycle (i) to the end of cycle (i+h); also, the minimum packet is from
latency is from the end of cycle (i) before the DT, to the beginning of cycle ( the beginning of cycle (i) to the end of cycle (i+h); also, the minimum
i+h). Then, the maximum latency is: latency is from the end of cycle (i), before the DT, to the beginning of cycle
<list style="hanging"> (i+h). Then, the maximum latency is:
<t>(h+1) T_c</t> </t>
</list> <t indent="3">(h+1) T_c</t>
</t> <t> and the minimum latency is:</t>
<t> and the minimum latency is:</t> <t indent="3">(h-1) T_c + DT.</t>
<t>
<list style="hanging">
<t>(h-1) T_c + DT.</t>
</list>
</t>
<!-- <t>
The per-hop latency is trivially determined by the cycle time T_c: a pac
ket 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, th
e 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> <t>
Ingress conditioning (<xref target="ingress"/>) may be required if the Ingress conditioning (<xref target="ingress" format="default"/>) may be
source of a DetNet flow does not, itself, employ CQF. Since there are no per-flo required if the source of a DetNet flow does not itself employ CQF. Since there
w parameters in the CQF technique, per-hop configuration is not required in the are no per-flow parameters in the CQF technique, per-hop configuration is not r
CQF forwarding nodes. equired in the CQF forwarding nodes.
</t> </t>
</section> </section>
</section> </section>
<section anchor="example" numbered="true" toc="default">
<section title="Example application on DetNet IP network" anchor="example"> <name>Example Application on DetNet IP Network</name>
<t> <t>
This section provides an example application of the timing model present This section provides an example application of the timing model present
ed in this document to control the admission of a DetNet flow on a DetNet-enable ed in this document to control the admission of a DetNet flow on a DetNet-enable
d IP network. Consider <xref target="fig_ip_detnet_simple"/>, taken from Section d IP network. Consider <xref target="fig_ip_detnet_simple" format="default"/>, t
3 of <xref target="RFC8939"/>, that shows a simple IP network: aken from <xref target="RFC8939" section="3" sectionFormat="of" format="default"
</t> />, which shows a simple IP network:
<t> </t>
<list style="symbols"> <ul spacing="normal">
<t> <li>
The end-system 1 implements Guaranteed-Service IntServ as in <xr End system 1 implements Guaranteed Service <xref target="RFC2212" form
ef target="intserv"/> between itself and relay node 1. at="default"/>, as in <xref target="intserv" format="default"/>, between itself
</t> and relay node 1.
<t> </li>
Sub-network 1 is a TSN network. The nodes in subnetwork 1 implem <li>
ent credit-based shapers with asynchronous traffic shaping as in <xref target="T Sub-network 1 is a TSN network. The nodes in sub-network 1 imple
SNwithATSmodel"/>. ment credit-based shapers with asynchronous traffic shaping, as in <xref target=
</t> "TSNwithATSmodel" format="default"/>.
<t> </li>
Sub-network 2 is a TSN network. The nodes in subnetwork 2 implem <li>
ent cyclic queuing and forwarding with two buffers as in <xref target="cqf"/>. Sub-network 2 is a TSN network. The nodes in sub-network 2 imple
</t> ment Cyclic Queuing and Forwarding with two buffers, as in <xref target="cqf" fo
<t> rmat="default"/>.
The relay nodes 1 and 2 implement credit-based shapers with asyn </li>
chronous traffic shaping as in <xref target="TSNwithATSmodel"/>. They also perfo <li>
rm the aggregation and mapping of IP DetNet flows to TSN streams (Section 4.4 of The relay nodes 1 and 2 implement credit-based shapers with asyn
<xref target="RFC9023"/>). chronous traffic shaping, as in <xref target="TSNwithATSmodel" format="default"/
</t> >. They also perform the aggregation and mapping of IP DetNet flows to TSN strea
</list> ms (<xref target="RFC9023" section="4.4" sectionFormat="of" format="default"/>).
</t> </li>
</ul>
<figure title="A Simple DetNet-Enabled IP Network, taken from RFC8939" anc <figure anchor="fig_ip_detnet_simple">
hor="fig_ip_detnet_simple"> <name>A Simple DetNet-Enabled IP Network, Taken from RFC 8939</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
DetNet IP Relay Relay DetNet IP DetNet IP Relay Relay DetNet IP
End-System Node 1 Node 2 End-System End System Node 1 Node 2 End System
1 2 1 2
+----------+ +----------+ +----------+ +----------+
| Appl. |<------------ End-to-End Service ----------->| Appl. | | Appl. |<------------ End-to-End Service ----------->| Appl. |
+----------+ ............ ........... +----------+ +----------+ ............ ........... +----------+
| Service |<-: Service :-- DetNet flow --: Service :->| Service | | Service |<-: Service :-- DetNet flow --: Service :->| Service |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
|Forwarding| |Forwarding| |Forwarding| |Forwarding| |Forwarding| |Forwarding| |Forwarding| |Forwarding|
+--------.-+ +-.------.-+ +-.---.----+ +-------.--+ +--------.-+ +-.------.-+ +-.---.----+ +-------.--+
: Link : \ ,-----. / \ ,-----. / : Link : \ ,-----. / \ ,-----. /
+......+ +----[ Sub- ]----+ +-[ Sub- ]-+ +......+ +----[ Sub- ]----+ +-[ Sub- ]-+
[Network] [Network] [Network] [Network]
`--1--' `--2--' `--1--' `--2--'
|<--------------------- DetNet IP --------------------->| |<--------------------- DetNet IP --------------------->|
|<--- d1 --->|<--------------- d2_p --------------->|<-- d3_p -->| |<--- d1 --->|<--------------- d2_p --------------->|<-- d3_p -->|
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Consider a fully centralized control plane for the network of <xref tar
<t>Consider a fully centralized control plane for the network of <xref target="f get="fig_ip_detnet_simple" format="default"/>, as described in <xref target="I-D
ig_ip_detnet_simple"/> as described in Section 3.2 of <xref target="I-D.ietf-det .ietf-detnet-controller-plane-framework" section="3.2" sectionFormat="of" format
net-controller-plane-framework"/>. Suppose end-system 1 wants to create a DetNet ="default"/>. Suppose end system 1 wants to create a DetNet flow with a traffic
flow with traffic specification destined to end-system 2 with end-to-end delay specification destined to end system 2 with end-to-end delay bound requirement D
bound requirement D. Therefore, the control plane receives a flow establishment . Therefore, the control plane receives a flow establishment request and calcula
request and calculates a number of valid paths through the network (Section 3.2 tes a number of valid paths through the network (<xref target="I-D.ietf-detnet-c
of <xref target="I-D.ietf-detnet-controller-plane-framework"/>). To select a pro ontroller-plane-framework" section="3.2" sectionFormat="of" format="default"/>).
per path, the control plane needs to compute an end-to-end delay bound at every To select a proper path, the control plane needs to compute an end-to-end delay
node of each selected path p. bound at every node of each selected path p.
</t> </t>
<t> <t>
The end-to-end delay bound is d1 + d2_p + d3_p, where d1 is the delay bound The end-to-end delay bound is d1 + d2_p + d3_p, where d1 is the delay bound
from end-system 1 to the entrance of relay node 1, d2_p is the delay bound for p from end system 1 to the entrance of relay node 1, d2_p is the delay bound for p
ath p from relay node 1 to entrance of the first node in sub-network 2, and d3_p ath p from relay node 1 to the entrance of the first node in sub-network 2, and
the delay bound of path p from the first node in sub-network 2 to end-system 2. d3_p is the delay bound of path p from the first node in sub-network 2 to end sy
The computation of d1 is explained in <xref target="intserv"/>. Since the relay stem 2. The computation of d1 is explained in <xref target="intserv" format="def
node 1, sub-network 1 and relay node 2 implement aggregate queuing, we use the ault"/>. Since the relay node 1, sub-network 1, and relay node 2 implement aggre
results in <xref target="perclass"/> and <xref target="TSNwithATSmodel"/> to com gate queuing, we use the results in Sections <xref target="perclass" format="cou
pute d2_p for the path p. Finally, d3_p is computed using the delay bound comput nter"/> and <xref target="TSNwithATSmodel" format="counter"/> to compute d2_p fo
ation of <xref target="cqf"/>. Any path p such that d1 + d2_p + d3_p &le; D sati r the path p. Finally, d3_p is computed using the delay bound computation of <xr
sfies the delay bound requirement of the flow. If there is no such path, the con ef target="cqf" format="default"/>. Any path p, such that d1 + d2_p + d3_p &lt;=
trol plane may compute new set of valid paths and redo the delay bound computati D, satisfies the delay bound requirement of the flow. If there is no such path,
on or reject the DetNet flow. the control plane may compute a new set of valid paths and redo the delay bound
computation or reject the DetNet flow.
</t> </t>
<t> <t>
As soon as the control plane selects a path that satisfies the delay bound c As soon as the control plane selects a path that satisfies the delay bound c
onstraint, it allocates and reserves the resources in the path for the DetNet fl onstraint, it allocates and reserves the resources in the path for the DetNet fl
ow (Section 4.2 <xref target="I-D.ietf-detnet-controller-plane-framework"/>). ow (<xref target="I-D.ietf-detnet-controller-plane-framework" format="default" s
ectionFormat="of" section="4.2"/>).
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security considerations"> <t>
<t> Detailed security considerations for DetNet are cataloged in <xref target="R
Detailed security considerations for DetNet are cataloged in <xref target="R FC9055" format="default"/>, and more general security considerations are describ
FC9055"/>, and more general security considerations are described in <xref targe ed in <xref target="RFC8655" format="default"/>.
t="RFC8655"/>. </t>
</t> <t>
<t> Security aspects that are unique to DetNet are those whose aim is to pro
Security aspects that are unique to DetNet are those whose aim is to pro vide the specific QoS aspects of DetNet, specifically bounded end-to-end deliver
vide the specific QoS aspects of DetNet, specifically bounded end-to-end deliver y latency and zero congestion loss. Achieving such loss rates and bounded latenc
y latency and zero congestion loss. Achieving such loss rates and bounded latenc y may not be possible in the face of a highly capable adversary, such as the one
y 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" format
envisioned by the Internet Threat Model of BCP 72 <xref target="RFC3552"/> that ="default"/>, which can arbitrarily drop or delay any or all traffic. In order t
can arbitrarily drop or delay any or all traffic. In order to present meaningfu o present meaningful security considerations, we consider a somewhat weaker atta
l security considerations, we consider a somewhat weaker attacker who does not c cker who does not control the physical links of the DetNet domain but may have t
ontrol the physical links of the DetNet domain but may have the ability to contr he ability to control or change the behavior of some resources within the bounda
ol or change the behavior of some resources within the boundary of the DetNet do ry of the DetNet domain.
main. </t>
</t> <t>
<t> Latency bound calculations use parameters that reflect physical quantiti
Latency bound calculations use parameters that reflect physical quantiti es. If an attacker finds a way to change the physical quantities, unknown to the
es. 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
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 mak
latency violation and/or congestion losses. An example of such attacks is to mak e some traffic sources under the control of the attacker send more traffic than
e 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 condi
their assumed T-SPECs. This type of attack is typically avoided by ingress condi tioning at the edge of a DetNet domain. However, it must be insured that such in
tioning at the edge of a DetNet domain. However, it must be insured that such in gress conditioning is done per flow and that the buffers are segregated such tha
gress conditioning is done per-flow and that the buffers are segregated such tha t if one flow exceeds its T-SPEC, it does not cause buffer overflow for other fl
t if one flow exceeds its T-SPEC, it does not cause buffer overflow for other fl ows.
ows. </t>
</t>
<!-- <t>
In principle, detnet node must segregate DetNet flows from other flows s
uch that non-DetNet flows do not affect DetNet flows.
</t> -->
<t>
Some queuing mechanisms require time synchronization and operate correct
ly only if the time synchronization works correctly. In the case of CQF, the cor
rect alignments of cycles can fail if an attack against time synchronization foo
ls a node into having an incorrect offset. Some of these attacks can be prevente
d by cryptographic authentication as in Annex K of <xref target="IEEE1588"/> for
the Precision Time Protocol (PTP). However, the attacks that change the physica
l latency of the links used by the time synchronization protocol are still possi
ble even if the time synchronization protocol is protected by authentication and
cryptography <xref target="DelayAttack"/>. Such attacks can be detected only by
their effects on latency bound violations and congestion losses, which do not o
ccur in normal DetNet operation.
</t>
<!-- <t>
A security consideration for this document is to secure the resource res
ervation signaling for DetNet flows. Any forgery or manipulation of packets duri
ng reservation may lead the flow not to be admitted or face delay bound violatio
n. Security mitigation for this issue is described in Section 7.6 of <xref targe
t="RFC9055"/>.
</t> -->
</section>
<section title="IANA considerations">
<t> <t>
This document has no IANA actions. Some queuing mechanisms require time synchronization and operate correct
</t> ly only if the time synchronization works correctly. In the case of CQF, the cor
</section> rect alignments of cycles can fail if an attack against time synchronization foo
ls a node into having an incorrect offset. Some of these attacks can be prevente
<section title="Acknowledgement"> d by cryptographic authentication as in Annex K of <xref target="IEEE1588" forma
<t>We would like to thank Lou Berger, Tony Przygienda, John Scudder, Watson t="default"/> for the Precision Time Protocol (PTP). However, the attacks that c
Ladd, Yoshifumi Nishida, Ralf Weber, Robert Sparks, Gyan Mishra, Martin Duke, &E hange the physical latency of the links used by the time synchronization protoco
acute;ric Vyncke, Lars Eggert, Roman Danyliw, and Paul Wouters for their useful l are still possible even if the time synchronization protocol is protected by a
feedback on this document.</t> uthentication and cryptography <xref target="DelayAttack" format="default"/>. Su
</section> ch attacks can be detected only by their effects on latency bound violations and
congestion losses, which do not occur in normal DetNet operation.
<section title="Contributors"> </t>
<t>RFC 7322 limits the number of authors listed on the front page to a maxim
um of 5. The editor wishes to thank and acknowledge the following author for con
tributing text to this document</t>
<figure> <artwork><![CDATA[
Janos Farkas
Ericsson
Email: janos.farkas@ericsson.com
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
</middle> <name>IANA considerations</name>
<t>
<!-- *****BACK MATTER ***** --> This document has no IANA actions.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-detnet-controller-plane-framework" to="DETNET
<?rfc include='reference.RFC.2212.xml'?> -CONTROL-PLANE"/>
<?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'?>
<reference anchor="IEEE8021Q" target="https://ieeexplore.ieee.org/document/8
403927">
<front>
<title>IEEE Std 802.1Q-2018: IEEE Standard for Local and metropolitan
area networks - Bridges and Bridged Networks</title>
<author>
<organization>IEEE 802.1</organization>
</author>
<date year="2018" />
</front>
</reference>
<!-- <?rfc include='reference.RFC9055.xml'?> -->
</references>
<references title="Informative References"> <references>
<?rfc include='reference.RFC.2697.xml'?> <name>References</name>
<?rfc include='reference.RFC.3552.xml'?> <references>
<?rfc include='reference.RFC.8578.xml'?> <name>Normative References</name>
<?rfc include='reference.RFC.9055.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.9023.xml'?> 212.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
016.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
658.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
806.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
655.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
939.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
964.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
475.xml"/>
<!-- <?rfc include='reference.I-D.ietf-detnet-controller-plane-framework.xml <reference anchor="IEEE8021Q" target="https://ieeexplore.ieee.org/docume
'?> --> nt/8403927">
<reference anchor="I-D.ietf-detnet-controller-plane-framework" target="https <front>
://datatracker.ietf.org/doc/html/draft-ietf-detnet-controller-plane-framework"> <title>IEEE Standard for Local and Metropolitan Area Networks--Bridg
<front> es and Bridged Networks</title>
<title>Deterministic Networking (DetNet) Controller Plane Framework dr <author>
aft-ietf-detnet-controller-plane-framework-01</title> <organization>IEEE</organization>
<author> </author>
<organization>A. Malis, X. Geng, M. Chen, F. Qin, and B. Varga</orga <date year="2018" month="July"/>
nization> </front>
</author> <seriesInfo name="IEEE Std" value="802.1Q-2018"/>
<date /> <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>
</front> </reference>
</reference>
<!-- &I-D.draft-malis-detnet-controller-plane-framework; -->
<reference anchor="IEEE8021Qcr" </references>
target="https://1.ieee802.org/tsn/802-1qcr/"> <references>
<front> <name>Informative References</name>
<title>IEEE P802.1Qcr: Bridges and Bridged Networks - Amendment: Asy <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
nchronous Traffic Shaping</title> 697.xml"/>
<author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<organization>IEEE 802.1</organization> 552.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date year="2017" /> 578.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</reference> 055.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
023.xml"/>
<reference anchor="IEEE1588" target="https://ieeexplore.ieee.org/document/45 <reference anchor="I-D.ietf-detnet-controller-plane-framework">
79760"> <front>
<front> <title>Deterministic Networking (DetNet) Controller Plane Framework</title>
<title>IEEE Standard for a Precision Clock Synchronization Protocol fo <author initials="A" surname="Malis" fullname="Andrew G. Malis">
r Networked Measurement and Control Systems</title> <organization>Independent</organization>
<author> </author>
<organization>IEEE Std 1588-2008</organization> <author initials="A" surname="Geng" fullname="Xuesong Geng" role="editor">
</author> <organization>Huawei</organization>
<date year="2008" /> </author>
</front> <author initials="M" surname="Chen" fullname="Mach (Guoyi) Chen">
</reference> <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-fram
ework-02"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-detnet-con
troller-plane-framework-02.txt"/>
</reference>
<reference anchor="IEEE8023" target="http://ieeexplore.ieee.org/document/845 <reference anchor="IEEE8021Qcr" target="https://ieeexplore.ieee.org/document
7469"> /9253013">
<front> <front>
<title>IEEE Std 802.3-2018: IEEE Standard for Ethernet</title> <title>802.1Qcr-2020 - IEEE Standard for Local and Metropolitan Area
Networks--Bridges and Bridged Networks
Amendment 34:Asynchronous Traffic Shaping</title>
<author> <author>
<organization>IEEE 802.3</organization> <organization>IEEE 802.1</organization>
</author> </author>
<date year="2018" /> <date year="2020" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor="IEEE8021TSN" target="http://www.ieee802.org/1/"> <reference anchor="IEEE1588" target="https://ieeexplore.ieee.org/documen
<front> t/4579760">
<title>IEEE 802.1 Time-Sensitive Networking (TSN) Task Group</title> <front>
<author> <title>IEEE Standard for a Precision Clock Synchronization Protocol
<organization>IEEE 802.1</organization> for Networked Measurement and Control Systems</title>
</author> <author>
<date /> <organization>IEEE</organization>
</front> </author>
</reference> <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="TSNwithATS" target="https://ieeexplore.ieee.org/document/ <reference anchor="IEEE8023" target="http://ieeexplore.ieee.org/document
8493026"> /8457469">
<front> <front>
<title>Latency and Backlog Bounds in Time-Sensitive Networking with Cr <title>IEEE Standard for Ethernet</title>
edit Based Shapers and Asynchronous Traffic Shaping</title> <author>
<author> <organization>IEEE</organization>
<organization>E. Mohammadpour, E. Stai, M. Mohiuddin, and J.-Y. Le B </author>
oudec</organization> <date year="2018" month="August"/>
</author> </front>
<date /> <seriesInfo name="IEEE Std" value="802.3-2018"/>
</front> <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457469"/>
</reference> </reference>
<reference anchor="PacketReorderingBounds" target="https://ieeexplore.ieee.o <reference anchor="IEEE8021TSN" target="https://1.ieee802.org/tsn/">
rg/document/9640523"> <front>
<front> <title>802.1 Time-Sensitive Networking (TSN) Task Group</title>
<title>On Packet Reordering in Time-Sensitive Networks</title> <author>
<author> <organization>IEEE 802.1</organization>
<organization>E. Mohammadpour, and J.-Y. Le Boudec</organization> </author>
</author> </front>
<date /> </reference>
</front>
</reference>
<reference anchor="DelayAttack" target="https://ieeexplore.ieee.org/document <reference anchor="TSNwithATS" target="https://ieeexplore.ieee.org/docum
/7520408"> ent/8493026">
<front> <front>
<title>Cyber-attack on packet-based time synchronization protocols: Th <title>Latency and Backlog Bounds in Time-Sensitive Networking with
e undetectable Delay Box</title> Credit Based Shapers and Asynchronous Traffic Shaping</title>
<author> <author initials="E" surname="Mohammadpour" fullname="Ehsan Mohammad
<organization>S. Barreto, A. Suresh, and J.-Y. Le Boudec</organizati pour">
on> <organization/>
</author> </author>
<date /> <author initials="E" surname="Stai" fullname="Eleni Stai">
</front> <organization/>
</reference> </author>
<author initials="M" surname="Mohiuddin" fullname="Maaz Mohiuddin">
<organization/>
</author>
<author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le B
oudec">
<organization/>
</author>
<date year="2018" month="September"/>
</front>
<seriesInfo name="DOI" value="10.1109/ITC30.2018.10053"/>
</reference>
<reference anchor="NetCalBook" target="https://leboudec.github.io/netcal/"> <reference anchor="PacketReorderingBounds" target="https://ieeexplore.ie
<front> ee.org/document/9640523">
<title>Network calculus: a theory of deterministic queuing systems for <front>
the internet</title> <title>On Packet Reordering in Time-Sensitive Networks</title>
<author> <author initials="E" surname="Mohammadpour" fullname="Ehsan Mohammad
<organization>J.-Y. Le Boudec and P. Thiran</organization> pour">
</author> <organization/>
<date year="2001"/> </author>
</front> <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le B
</reference> oudec">
<organization/>
</author>
<date year="2021" month="December"/>
</front>
<seriesInfo name="DOI" value="10.1109/TNET.2021.3129590"/>
</reference>
<reference anchor="LeBoudecTheory" target="https://ieeexplore.ieee.org/docum <reference anchor="DelayAttack" target="https://ieeexplore.ieee.org/docu
ent/8519761"> ment/7520408">
<front> <front>
<title>A Theory of Traffic Regulators for Deterministic Networks with <title>Cyber-attack on packet-based time synchronization protocols:
Application to Interleaved Regulators</title> The undetectable Delay Box</title>
<author> <author initials="S" surname="Barreto" fullname="Sergio Barreto">
<organization>J.-Y. Le Boudec</organization> <organization/>
</author> </author>
<date /> <author initials="A" surname="Suresh" fullname="Aswin Suresh">
</front> <organization/>
</reference> </author>
<author initials="J.-Y." fullname="Jean-Yves Le Boudec">
<organization/>
</author>
<date year="2016" month="May"/>
</front>
<seriesInfo name="DOI" value="10.1109/I2MTC.2016.7520408"/>
</reference>
<reference anchor="Sch8021Qbv" target="https://dl.acm.org/doi/10.1145/299746 <reference anchor="NetCalBook" target="https://leboudec.github.io/netcal
5.2997470"> /latex/netCalBook.pdf">
<front> <front>
<title>Scheduling Real-Time Communication in IEEE 802.1Qbv Time Sensit <title>Network Calculus: A Theory of Deterministic Queuing Systems f
ive Networks</title> or the Internet</title>
<author> <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le
<organization>S. Craciunas, R. Oliver, M. Chmelik, and W. Steiner</o Boudec">
rganization> <organization/>
</author> </author>
<date /> <author initials="P" surname="Thiran" fullname="Patrick Thiran">
</front> <organization/>
</reference> </author>
<date year="2001"/>
</front>
<refcontent>Springer Science &amp; Business Media, vol. 2050</refconten
t>
</reference>
<reference anchor="CharnyDelay" target="https://link.springer.com/chapter/10 <reference anchor="LeBoudecTheory" target="https://ieeexplore.ieee.org/d
.1007/3-540-39939-9_1"> ocument/8519761">
<front> <front>
<title>Delay Bounds in a Network with Aggregate Scheduling</title> <title>A Theory of Traffic Regulators for Deterministic Networks Wit
<author> h Application to Interleaved Regulators</title>
<organization>A. Charny and J.-Y. Le Boudec</organization> <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le
</author> Boudec">
<date /> <organization/>
</front> </author>
</reference> <date year="2018" month="November"/>
</front>
<seriesInfo name="DOI" value="10.1109/TNET.2018.2875191"/>
</reference>
<reference anchor="BennettDelay" target="https://dl.acm.org/citation.cfm?id= <reference anchor="Sch8021Qbv" target="https://dl.acm.org/doi/10.1145/29
581870"> 97465.2997470">
<front> <front>
<title>Delay Jitter Bounds and Packet Scale Rate Guarantee for Expedit <title>Scheduling Real-Time Communication in IEEE 802.1Qbv Time Sens
ed Forwarding</title> itive Networks</title>
<author> <author initials="S" surname="Craciunas" fullname="Silviu S. Craciun
<organization>J.C.R. Bennett, K. Benson, A. Charny, W.F. Courtney, a as">
nd J.-Y. Le Boudec</organization> <organization></organization>
</author> </author>
<date /> <author initials="R" surname="Oliver" fullname="Ramon Serna Oliver">
</front> <organization/>
</reference> </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="ThomasTime" target="https://dl.acm.org/doi/10.1145/339369 <reference anchor="CharnyDelay" target="https://link.springer.com/chapte
1.3394206"> r/10.1007/3-540-39939-9_1">
<front> <front>
<title>On Time Synchronization Issues in Time-Sensitive Networks with <title>Delay Bounds in a Network with Aggregate Scheduling</title>
Regulators and Nonideal Clocks</title> <author initials="A" surname="Charny" fullname="Anna Charny">
<author> <organization/>
<organization>L. Thomas and J.-Y. Le Boudec</organization> </author>
</author> <author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le B
<date /> oudec">
</front> <organization/>
</reference> </author>
<date year="2002" month="September"/>
</front>
<seriesInfo name="DOI" value="10.1007/3-540-39939-9_1"/>
</reference>
<reference anchor="SpechtUBS" target="https://ieeexplore.ieee.org/abstract/d <reference anchor="BennettDelay" target="https://dl.acm.org/citation.cfm
ocument/7557870"> ?id=581870">
<front> <front>
<title>Urgency-Based Scheduler for Time-Sensitive Switched Ethernet Ne <title>Delay jitter bounds and packet scale rate guarantee for exped
tworks</title> ited forwarding</title>
<author> <author initials="J. C. R." surname="Bennett" fullname="Jon C. R. Be
<organization>J. Specht and S. Samii</organization> nnett">
</author> <organization/>
<date /> </author>
</front> <author initials="K" surname="Benson" fullname="Kent Benson">
</reference> <organization/>
</author>
<author initials="A" surname="Charny" fullname="Anna Charny">
<organization/>
</author>
<author initials="W. F." surname="Courtney" fullname="William F. Cour
tney">
<organization/>
</author>
<author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le B
oudec">
<organization/>
</author>
<date year="2002" month="August"/>
</front>
<seriesInfo name="DOI" value="10.1109/TNET.2002.801404"/>
</reference>
</references> <reference anchor="ThomasTime" target="https://dl.acm.org/doi/10.1145/33
93691.3394206">
<front>
<title>On Time Synchronization Issues in Time-Sensitive Networks wit
h Regulators and Nonideal Clocks</title>
<author initials="L" surname="Thomas" fullname="Ludovic Thomas">
<organization/>
</author>
<author initials="J.-Y." surname="Le Boudec" fullname="Jean-Yves Le B
oudec">
<organization/>
</author>
<date year="2020" month="June"/>
</front>
<seriesInfo name="DOI" value="10.1145/3393691.339420"/>
</reference>
</back> <reference anchor="SpechtUBS" target="https://ieeexplore.ieee.org/abstra
ct/document/7557870">
<front>
<title>Urgency-Based Scheduler for Time-Sensitive Switched Ethernet
Networks</title>
<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 fulln
ame="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"/>, <contac
t fullname="Lars Eggert"/>, <contact fullname="Roman Danyliw"/>, and <contact fu
llname="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 max
imum of 5. The editor wishes to thank and acknowledge the following author for c
ontributing text to this document:</t>
<contact fullname="Janos Farkas">
<organization>Ericsson</organization>
<address>
<email>janos.farkas@ericsson.com</email>
</address>
</contact>
</section>
</back>
</rfc> </rfc>
 End of changes. 171 change blocks. 
1352 lines changed or deleted 1320 lines changed or added

This html diff was produced by rfcdiff 1.48.