rfc8655xml2.original.xml   rfc8655.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc, <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
which is available here: http://xml.resource.org. --> nsus="true" docName="draft-ietf-detnet-architecture-13" indexInclude="true" ipr=
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ "trust200902" number="8655" prepTime="2019-10-11T11:14:10" scripts="Common,Latin
]> " sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> true" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture-13
<rfc category="std" ipr="trust200902" docName="draft-ietf-detnet-architecture-13 " rel="prev"/>
"> <link href="https://dx.doi.org/10.17487/rfc8655" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified-"no" ?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<front> <front>
<title>Deterministic Networking Architecture</title> <title>Deterministic Networking Architecture</title>
<author initials="N" surname="Finn" fullname="Norman Finn" > <seriesInfo name="RFC" value="8655" stream="IETF"/>
<organization> <author initials="N" surname="Finn" fullname="Norman Finn">
Huawei <organization showOnFrontPage="true">Huawei</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>United States of America</country>
<country>US</country> </postal>
</postal> <phone>+1 925 980 6430</phone>
<phone>+1 925 980 6430</phone> <email>nfinn@nfinnconsulting.com</email>
<email>norman.finn@mail01.huawei.com</email> </address>
</address> </author>
</author> <author initials="P" surname="Thubert" fullname="Pascal Thubert">
<author initials="P" surname="Thubert" fullname="Pascal Thubert"> <organization abbrev="Cisco" showOnFrontPage="true">
<organization abbrev="Cisco">
Cisco Systems Cisco Systems
</organization> </organization>
<address> <address>
<postal> <postal>
<street>Village d'Entreprises Green Side</street> <street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street> <street>400, Avenue de Roumanille</street>
<street>Batiment T3</street> <street>
Batiment T3</street>
<city>Biot - Sophia Antipolis</city> <city>Biot - Sophia Antipolis</city>
<code>06410</code> <code>06410</code>
<country>FRANCE</country> <country>France</country>
</postal> </postal>
<phone>+33 4 97 23 26 34</phone> <phone>+33 4 97 23 26 34</phone>
<email>pthubert@cisco.com</email> <email>pthubert@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Bal&aacute;zs Varga" initials="B." surname="Varga"> <author fullname="Balázs Varga" initials="B." surname="Varga">
<organization>Ericsson</organization> <organization showOnFrontPage="true">Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Magyar tudosok korutja 11</street> <street>Magyar tudosok korutja 11</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>balazs.a.varga@ericsson.com</email> <email>balazs.a.varga@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="J&aacute;nos Farkas" initials="J." surname="Farkas"> <author fullname="János Farkas" initials="J." surname="Farkas">
<organization>Ericsson</organization> <organization showOnFrontPage="true">Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Magyar tudosok korutja 11</street> <street>Magyar tudosok korutja 11</street>
<city>Budapest</city> <city>Budapest</city>
<country>Hungary</country> <country>Hungary</country>
<code>1117</code> <code>1117</code>
</postal> </postal>
<email>janos.farkas@ericsson.com</email> <email>janos.farkas@ericsson.com</email>
</address> </address>
</author> </author>
<date/> <date month="10" year="2019"/>
<area>Internet</area>
<area>Internet</area> <workgroup>DetNet</workgroup>
<keyword>TSN, Bounded Lantency, Reliable Networking, Available Networking</k
<workgroup>DetNet</workgroup> eyword>
<abstract pn="section-abstract">
<abstract> <t pn="section-abstract-1">
<t>
This document provides the overall architecture for This document provides the overall architecture for
Deterministic Networking (DetNet), which Deterministic Networking (DetNet), which provides a capability
provides a capability to carry specified unicast or multicast to carry specified unicast or multicast data flows for
data flows for real-time applications with extremely low data los real-time applications with extremely low data loss rates and
s rates and bounded bounded latency within a network domain. Techniques used
latency within a network domain. Techniques used include: 1) res include 1) reserving data-plane resources for individual (or
erving data plane resources for individual aggregated) DetNet flows in some or all of the intermediate
(or aggregated) DetNet flows in some or all of the intermediate n nodes along the path of the flow, 2) providing explicit routes
odes along for DetNet flows that do not immediately change with the
the path of the flow; 2) providing explicit routes for DetNet flo network topology, and 3) distributing data from DetNet flow
ws that do not packets over time and/or space to ensure delivery of each
immediately change with the network topology; and 3) distributing packet's data in spite of the loss of a path. DetNet operates
data from DetNet flow packets at the IP layer and delivers service over lower-layer
over time and/or space to ensure delivery of each packet's data i technologies such as MPLS and Time-Sensitive
n spite of the loss of a path. Networking (TSN) as defined by IEEE 802.1.
DetNet operates at the IP layer and delivers service over lower layer te </t>
chnologies such as MPLS </abstract>
and IEEE 802.1 Time-Sensitive Networking (TSN). <boilerplate>
</t> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
</abstract> "exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8655"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info"/>) in effect o
n the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-boilerplate.3">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-bo
ilerplate.3-1">
<li pn="section-boilerplate.3-1.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.1.1"><xref derive
dContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref de
rivedContent="Introduction" format="title" sectionFormat="of" target="name-intro
duction">Introduction</xref></t>
</li>
<li pn="section-boilerplate.3-1.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.2.1"><xref derive
dContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref de
rivedContent="Terminology" format="title" sectionFormat="of" target="name-termin
ology">Terminology</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-boilerplate.3-1.2.2">
<li pn="section-boilerplate.3-1.2.2.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.2.2.1.1"><xre
f derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/
>.  <xref derivedContent="Terms Used in This Document" format="title" sectionFor
mat="of" target="name-terms-used-in-this-document">Terms Used in This Document</
xref></t>
</li>
<li pn="section-boilerplate.3-1.2.2.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.2.2.2.1"><xre
f derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/
>.  <xref derivedContent="Dictionary of Terms Used by TSN and DetNet" format="ti
tle" sectionFormat="of" target="name-dictionary-of-terms-used-by">Dictionary of
Terms Used by TSN and DetNet</xref></t>
</li>
</ul>
</li>
<li pn="section-boilerplate.3-1.3">
<t keepWithNext="true" pn="section-boilerplate.3-1.3.1"><xref derive
dContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref de
rivedContent="Providing the DetNet Quality of Service" format="title" sectionFor
mat="of" target="name-providing-the-detnet-qualit">Providing the DetNet Quality
of Service</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-boilerplate.3-1.3.2">
<li pn="section-boilerplate.3-1.3.2.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.3.2.1.1"><xre
f derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/
>.  <xref derivedContent="Primary Goals Defining the DetNet QoS" format="title"
sectionFormat="of" target="name-primary-goals-defining-the-">Primary Goals Defin
ing the DetNet QoS</xref></t>
</li>
<li pn="section-boilerplate.3-1.3.2.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.3.2.2.1"><xre
f derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/
>.  <xref derivedContent="Mechanisms to Achieve DetNet QoS" format="title" secti
onFormat="of" target="name-mechanisms-to-achieve-detne">Mechanisms to Achieve De
tNet QoS</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-boilerplate.3-1.3.2.2.2">
<li pn="section-boilerplate.3-1.3.2.2.2.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.3.2.2.2.1
.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="sec
tion-3.2.1"/>.  <xref derivedContent="Resource Allocation" format="title" sectio
nFormat="of" target="name-resource-allocation">Resource Allocation</xref></t>
</li>
<li pn="section-boilerplate.3-1.3.2.2.2.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.3.2.2.2.2
.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="sec
tion-3.2.2"/>.  <xref derivedContent="Service Protection" format="title" section
Format="of" target="name-service-protection">Service Protection</xref></t>
</li>
<li pn="section-boilerplate.3-1.3.2.2.2.3">
<t keepWithNext="true" pn="section-boilerplate.3-1.3.2.2.2.3
.1"><xref derivedContent="3.2.3" format="counter" sectionFormat="of" target="sec
tion-3.2.3"/>.  <xref derivedContent="Explicit Routes" format="title" sectionFor
mat="of" target="name-explicit-routes">Explicit Routes</xref></t>
</li>
</ul>
</li>
<li pn="section-boilerplate.3-1.3.2.3">
<t keepWithNext="true" pn="section-boilerplate.3-1.3.2.3.1"><xre
f derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/
>.  <xref derivedContent="Secondary Goals for DetNet" format="title" sectionForm
at="of" target="name-secondary-goals-for-detnet">Secondary Goals for DetNet</xre
f></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-boilerplate.3-1.3.2.3.2">
<li pn="section-boilerplate.3-1.3.2.3.2.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.3.2.3.2.1
.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="sec
tion-3.3.1"/>.  <xref derivedContent="Coexistence with Normal Traffic" format="t
itle" sectionFormat="of" target="name-coexistence-with-normal-tra">Coexistence w
ith Normal Traffic</xref></t>
</li>
<li pn="section-boilerplate.3-1.3.2.3.2.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.3.2.3.2.2
.1"><xref derivedContent="3.3.2" format="counter" sectionFormat="of" target="sec
tion-3.3.2"/>.  <xref derivedContent="Fault Mitigation" format="title" sectionFo
rmat="of" target="name-fault-mitigation">Fault Mitigation</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-boilerplate.3-1.4">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.1"><xref derive
dContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref de
rivedContent="DetNet Architecture" format="title" sectionFormat="of" target="nam
e-detnet-architecture">DetNet Architecture</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-boilerplate.3-1.4.2">
<li pn="section-boilerplate.3-1.4.2.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.1.1"><xre
f derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/
>.  <xref derivedContent="DetNet Stack Model" format="title" sectionFormat="of"
target="name-detnet-stack-model">DetNet Stack Model</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-boilerplate.3-1.4.2.1.2">
<li pn="section-boilerplate.3-1.4.2.1.2.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.1.2.1
.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="sec
tion-4.1.1"/>.  <xref derivedContent="Representative Protocol Stack Model" forma
t="title" sectionFormat="of" target="name-representative-protocol-sta">Represent
ative Protocol Stack Model</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.1.2.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.1.2.2
.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="sec
tion-4.1.2"/>.  <xref derivedContent="DetNet Data-Plane Overview" format="title"
sectionFormat="of" target="name-detnet-data-plane-overview">DetNet Data-Plane O
verview</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.1.2.3">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.1.2.3
.1"><xref derivedContent="4.1.3" format="counter" sectionFormat="of" target="sec
tion-4.1.3"/>.  <xref derivedContent="Network Reference Model" format="title" se
ctionFormat="of" target="name-network-reference-model">Network Reference Model</
xref></t>
</li>
</ul>
</li>
<li pn="section-boilerplate.3-1.4.2.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.2.1"><xre
f derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/
>.  <xref derivedContent="DetNet Systems" format="title" sectionFormat="of" targ
et="name-detnet-systems">DetNet Systems</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-boilerplate.3-1.4.2.2.2">
<li pn="section-boilerplate.3-1.4.2.2.2.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.2.2.1
.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="sec
tion-4.2.1"/>.  <xref derivedContent="End System" format="title" sectionFormat="
of" target="name-end-system">End System</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.2.2.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.2.2.2
.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="sec
tion-4.2.2"/>.  <xref derivedContent="DetNet Edge, Relay, and Transit Nodes" for
mat="title" sectionFormat="of" target="name-detnet-edge-relay-and-trans">DetNet
Edge, Relay, and Transit Nodes</xref></t>
</li>
</ul>
</li>
<li pn="section-boilerplate.3-1.4.2.3">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.3.1"><xre
f derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/
>.  <xref derivedContent="DetNet Flows" format="title" sectionFormat="of" target
="name-detnet-flows">DetNet Flows</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-boilerplate.3-1.4.2.3.2">
<li pn="section-boilerplate.3-1.4.2.3.2.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.3.2.1
.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="sec
tion-4.3.1"/>.  <xref derivedContent="DetNet Flow Types" format="title" sectionF
ormat="of" target="name-detnet-flow-types">DetNet Flow Types</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.3.2.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.3.2.2
.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="sec
tion-4.3.2"/>.  <xref derivedContent="Source Transmission Behavior" format="titl
e" sectionFormat="of" target="name-source-transmission-behavio">Source Transmiss
ion Behavior</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.3.2.3">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.3.2.3
.1"><xref derivedContent="4.3.3" format="counter" sectionFormat="of" target="sec
tion-4.3.3"/>.  <xref derivedContent="Incomplete Networks" format="title" sectio
nFormat="of" target="name-incomplete-networks">Incomplete Networks</xref></t>
</li>
</ul>
</li>
<li pn="section-boilerplate.3-1.4.2.4">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.4.1"><xre
f derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/
>.  <xref derivedContent="Traffic Engineering for DetNet" format="title" section
Format="of" target="name-traffic-engineering-for-det">Traffic Engineering for De
tNet</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-boilerplate.3-1.4.2.4.2">
<li pn="section-boilerplate.3-1.4.2.4.2.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.4.2.1
.1"><xref derivedContent="4.4.1" format="counter" sectionFormat="of" target="sec
tion-4.4.1"/>.  <xref derivedContent="The Application Plane" format="title" sect
ionFormat="of" target="name-the-application-plane">The Application Plane</xref><
/t>
</li>
<li pn="section-boilerplate.3-1.4.2.4.2.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.4.2.2
.1"><xref derivedContent="4.4.2" format="counter" sectionFormat="of" target="sec
tion-4.4.2"/>.  <xref derivedContent="The Controller Plane" format="title" secti
onFormat="of" target="name-the-controller-plane">The Controller Plane</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.4.2.3">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.4.2.3
.1"><xref derivedContent="4.4.3" format="counter" sectionFormat="of" target="sec
tion-4.4.3"/>.  <xref derivedContent="The Network Plane" format="title" sectionF
ormat="of" target="name-the-network-plane">The Network Plane</xref></t>
</li>
</ul>
</li>
<li pn="section-boilerplate.3-1.4.2.5">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.5.1"><xre
f derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/
>.  <xref derivedContent="Queuing, Shaping, Scheduling, and Preemption" format="
title" sectionFormat="of" target="name-queuing-shaping-scheduling-">Queuing, Sha
ping, Scheduling, and Preemption</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.6">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.6.1"><xre
f derivedContent="4.6" format="counter" sectionFormat="of" target="section-4.6"/
>.  <xref derivedContent="Service Instance" format="title" sectionFormat="of" ta
rget="name-service-instance">Service Instance</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.7">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.7.1"><xre
f derivedContent="4.7" format="counter" sectionFormat="of" target="section-4.7"/
>.  <xref derivedContent="Flow Identification at Technology Borders" format="tit
le" sectionFormat="of" target="name-flow-identification-at-tech">Flow Identifica
tion at Technology Borders</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-boilerplate.3-1.4.2.7.2">
<li pn="section-boilerplate.3-1.4.2.7.2.1">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.7.2.1
.1"><xref derivedContent="4.7.1" format="counter" sectionFormat="of" target="sec
tion-4.7.1"/>.  <xref derivedContent="Exporting Flow Identification" format="tit
le" sectionFormat="of" target="name-exporting-flow-identificati">Exporting Flow
Identification</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.7.2.2">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.7.2.2
.1"><xref derivedContent="4.7.2" format="counter" sectionFormat="of" target="sec
tion-4.7.2"/>.  <xref derivedContent="Flow Attribute Mapping between Layers" for
mat="title" sectionFormat="of" target="name-flow-attribute-mapping-betw">Flow At
tribute Mapping between Layers</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.7.2.3">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.7.2.3
.1"><xref derivedContent="4.7.3" format="counter" sectionFormat="of" target="sec
tion-4.7.3"/>.  <xref derivedContent="Flow-ID Mapping Examples" format="title" s
ectionFormat="of" target="name-flow-id-mapping-examples">Flow-ID Mapping Example
s</xref></t>
</li>
</ul>
</li>
<li pn="section-boilerplate.3-1.4.2.8">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.8.1"><xre
f derivedContent="4.8" format="counter" sectionFormat="of" target="section-4.8"/
>.  <xref derivedContent="Advertising Resources, Capabilities, and Adjacencies"
format="title" sectionFormat="of" target="name-advertising-resources-capab">Adve
rtising Resources, Capabilities, and Adjacencies</xref></t>
</li>
<li pn="section-boilerplate.3-1.4.2.9">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.9.1"><xre
f derivedContent="4.9" format="counter" sectionFormat="of" target="section-4.9"/
>.  <xref derivedContent="Scaling to Larger Networks" format="title" sectionForm
at="of" target="name-scaling-to-larger-networks">Scaling to Larger Networks</xre
f></t>
</li>
<li pn="section-boilerplate.3-1.4.2.10">
<t keepWithNext="true" pn="section-boilerplate.3-1.4.2.10.1"><xr
ef derivedContent="4.10" format="counter" sectionFormat="of" target="section-4.1
0"/>. <xref derivedContent="Compatibility with Layer 2" format="title" sectionFo
rmat="of" target="name-compatibility-with-layer-2">Compatibility with Layer 2</x
ref></t>
</li>
</ul>
</li>
<li pn="section-boilerplate.3-1.5">
<t keepWithNext="true" pn="section-boilerplate.3-1.5.1"><xref derive
dContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref de
rivedContent="Security Considerations" format="title" sectionFormat="of" target=
"name-security-considerations">Security Considerations</xref></t>
</li>
<li pn="section-boilerplate.3-1.6">
<t keepWithNext="true" pn="section-boilerplate.3-1.6.1"><xref derive
dContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref de
rivedContent="Privacy Considerations" format="title" sectionFormat="of" target="
name-privacy-considerations">Privacy Considerations</xref></t>
</li>
<li pn="section-boilerplate.3-1.7">
<t keepWithNext="true" pn="section-boilerplate.3-1.7.1"><xref derive
dContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref de
rivedContent="IANA Considerations" format="title" sectionFormat="of" target="nam
e-iana-considerations">IANA Considerations</xref></t>
</li>
<li pn="section-boilerplate.3-1.8">
<t keepWithNext="true" pn="section-boilerplate.3-1.8.1"><xref derive
dContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref de
rivedContent="Informative References" format="title" sectionFormat="of" target="
name-informative-references">Informative References</xref></t>
</li>
<li pn="section-boilerplate.3-1.9">
<t keepWithNext="true" pn="section-boilerplate.3-1.9.1"><xref derive
dContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref
derivedContent="Acknowledgements" format="title" sectionFormat="of" target="name
-acknowledgements">Acknowledgements</xref></t>
</li>
<li pn="section-boilerplate.3-1.10">
<t keepWithNext="true" pn="section-boilerplate.3-1.10.1"><xref deriv
edContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref
derivedContent="Authors' Addresses" format="title" sectionFormat="of" target="n
ame-authors-addresses">Authors' Addresses</xref></t>
</li>
</ul>
</section>
</boilerplate>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">
This document provides the overall architecture for Deterministic
Networking (DetNet), which provides a capability for the delivery of
data flows with extremely low packet loss rates and bounded end-to-end
delivery latency. DetNet is for networks that are under a single
administrative control or within a closed group of administrative
control; these include campus-wide networks and private WANs. DetNet
is not for large groups of domains such as the Internet. </t>
<t pn="section-1-2">
DetNet operates at the IP layer and delivers service over lower-layer
technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking
(TSN).
<!-- **************************************************************** --> DetNet provides a reliable and available service by dedicating network
<!-- **************************************************************** --> resources such as link bandwidth and buffer space to DetNet flows and/or
<!-- **************************************************************** --> classes of DetNet flows, and by replicating packets along multiple paths.
<!-- **************************************************************** --> Unused reserved resources are available to non-DetNet packets as long as all
<section anchor='introduction' title="Introduction"> guarantees are fulfilled. </t>
<t pn="section-1-3"> The <xref target="RFC8557" format="default" sectionFo
rmat="of" derivedContent="RFC8557">"Deterministic
Networking Problem Statement"</xref> introduces DetNet, and <xref target="RFC857
8" format="default" sectionFormat="of" derivedContent="RFC8578">"Deterministic N
etworking Use Cases"</xref> summarizes the
need for it. See <xref target="I-D.ietf-detnet-data-plane-framework" format="de
fault" sectionFormat="of" derivedContent="DETNET-FRAMEWORK"/> for specific techn
iques
that can be used to identify DetNet flows and assign them to specific paths
through a network. </t>
<t pn="section-1-4"> A goal of DetNet is a converged network in all
respects, including the convergence of sensitive non-IP networks onto a common
network infrastructure. The presence of DetNet flows does not preclude
non-DetNet flows, and the benefits offered DetNet flows should not, except in
extreme cases, prevent existing Quality-of-Service (QoS) mechanisms from
operating in a normal fashion, subject to the bandwidth required for the
DetNet flows. A single source-destination pair can trade both DetNet and
non-DetNet flows. End systems and applications need not instantiate special
interfaces for DetNet flows. Networks are not restricted to certain
topologies; connectivity is not restricted. Any application that generates a
data flow that can be usefully characterized as having a maximum bandwidth
should be able to take advantage of DetNet, as long as the necessary resources
can be reserved.
<t> Reservations can be made by the application itself, via network management,
This document provides the overall architecture for Deterministic centrally by an application's controller, or by other means, for instance, by
Networking (DetNet), which provides a capability for the delivery of dat placing on-demand reservation via a distributed Control Plane, e.g.,
a leveraging the Resource Reservation Protocol (RSVP) <xref target="RFC2205" forma
flows with extremely t="default" sectionFormat="of" derivedContent="RFC2205"/>.
low packet loss rates and bounded end-to-end delivery latency.
DetNet is for networks that are under a single administrative con
trol or
within a closed group of administrative control; these include ca
mpus-wide
networks and private WANs. DetNet is not for large groups of doma
ins such
as the Internet.
</t><t>
DetNet operates at the IP layer and delivers service over
lower layer technologies such as MPLS and IEEE 802.1 Time-Sensitive Netw
orking (TSN).
DetNet accomplishes these goals by dedicating network resources such as
link bandwidth
and buffer space to DetNet flows and/or
classes of DetNet flows, and by replicating packets along multipl
e paths.
Unused reserved resources are available to non-DetNet
packets as long as all guarantees are fulfilled.
</t><t>
The <xref target="I-D.ietf-detnet-problem-statement">Deterministi
c Networking
Problem Statement</xref> introduces Deterministic Networking, and
<xref target="I-D.ietf-detnet-use-cases">Deterministic Networking
Use Cases</xref> summarizes the need for it.
See <xref target="I-D.ietf-detnet-dp-sol-mpls"/> and
<xref target="I-D.ietf-detnet-dp-sol-ip"/> for specific technique
s
that can be used to identify DetNet flows and assign them to spec
ific paths
through a network.
</t><t>
A goal of DetNet is a converged network in all respects including
the convergence of sensitive non-IP networks
onto a common network infrastructure. The presence
of DetNet flows does not preclude non-DetNet flows, and the benef
its offered
DetNet flows should not, except in extreme cases, prevent existin
g Quality of
Service (QoS) mechanisms from operating in a
normal fashion, subject to the bandwidth required for the DetNet
flows. A
single source-destination pair can trade both DetNet and non-DetN
et flows.
End systems and applications need not instantiate special interfa
ces for DetNet flows.
Networks are not restricted to certain topologies; connectivity i
s not restricted.
Any application that generates a data flow that can be usefully
characterized as having a maximum bandwidth should be able to tak
e advantage
of DetNet, as long as the necessary resources can be reserved. R
eservations
can be made by the application itself, via network management, by
an
application's controller, or by other means, e.g., a dynamic cont
rol plane
(e.g., <xref target="RFC2205"/>). QoS requirements of DetNet flow
s can be met if all
network nodes in a DetNet domain implement DetNet capabilities. D
etNet nodes can
be interconnected with different sub-network technologies
(<xref target="sec_dt_dp"/>), where the nodes of the subnet are n
ot
DetNet aware (<xref target="netref"/>).
</t><t>
Many applications that are intended to be served by Deterministic
Networking require the ability
to synchronize the clocks in end systems to a sub-microsecond acc
uracy. Some
of the queue control techniques defined in <xref target="QueuingM
odels"/> also
require time synchronization among network nodes. The means used
to achieve
time synchronization are not addressed in this document. DetNet
can accommodate
various time synchronization techniques and profiles that are def
ined elsewhere
to address the needs of different market segments.
</t>
</section>
<section title="Terminology"> QoS requirements of DetNet flows can be met if all network
<section title="Terms used in this document"> nodes in a DetNet domain implement DetNet capabilities. DetNet nodes can be
<t> interconnected with different sub-network technologies (<xref target="sec_dt_dp"
format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>) where the
nodes of the subnet are not DetNet aware
(<xref target="netref" format="default" sectionFormat="of" derivedContent="Secti
on 4.1.3"/>). </t>
<t pn="section-1-5"> Many applications that are intended to be
served by DetNet require the ability to synchronize the clocks in end systems
to a sub-microsecond accuracy. Some of the queue-control techniques defined
in <xref target="QueuingModels" format="default" sectionFormat="of" derivedConte
nt="Section 4.5"/> also require time synchronization among
network nodes. The means used to achieve time synchronization are not
addressed in this document. DetNet can accommodate various
time-synchronization techniques and profiles that are defined elsewhere to
address the needs of different market segments.
</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<name slugifiedName="name-terminology">Terminology</name>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.1
">
<name slugifiedName="name-terms-used-in-this-document">Terms Used in Thi
s Document</name>
<t pn="section-2.1-1">
The following terms are used in the context of DetNet in this document: The following terms are used in the context of DetNet in this document:
<list hangIndent="8" style="hanging"> </t>
<t hangText="allocation"><vspace blankLines="0"/> <dl newline="true" spacing="normal" indent="3" pn="section-2.1-2">
Resources are dedicated to support a DetNet flo <dt pn="section-2.1-2.1">allocation</dt>
w. Depending on an implementation, the resource may be reused by non-DetNet flow <dd pn="section-2.1-2.2">
s when it is not used by the DetNet flow. The dedication of resources
</t> to support a DetNet flow. Depending on an
<t hangText="App-flow"><vspace blankLines="0"/> implementation, the resource may be reused by
non-DetNet flows when it is not used by the DetNet
flow.
</dd>
<dt pn="section-2.1-2.3">App-flow</dt>
<dd pn="section-2.1-2.4">
The payload (data) carried over a DetNet service. The payload (data) carried over a DetNet service.
</t> </dd>
<t hangText="DetNet compound flow and DetNet member flo <dt pn="section-2.1-2.5">DetNet compound flow and DetNet member flow</
w"><vspace blankLines="0"/> dt>
A DetNet compound flow is a DetNet flow that has <dd pn="section-2.1-2.6"> A DetNet compound
been separated into flow is a DetNet flow that has been separated into
multiple duplicate DetNet member flows for servic multiple duplicate DetNet member flows for service
e protection at the DetNet service sub-layer. protection at the DetNet service sub-layer. Member
Member flows are merged back into a single DetNet flows are merged back into a single DetNet compound
compound flow such that there are no duplicate packets. flow such that there are no duplicate packets.
"Compound" and "member" are strictly "Compound" and "member" are strictly relative to
relative to each other, not absolutes; a DetNet c each other, not absolutes; a DetNet compound flow
ompound flow comprising comprising multiple DetNet member flows can, in
multiple DetNet member flows can, in turn, be a m turn, be a member of a higher-order compound.
ember of a higher-order compound. </dd>
</t> <dt pn="section-2.1-2.7">DetNet destination</dt>
<t hangText="DetNet destination"><vspace blankLines="0" <dd pn="section-2.1-2.8">
/>
An end system capable of terminating a DetNet flo w. An end system capable of terminating a DetNet flo w.
</t> </dd>
<t hangText="DetNet domain"><vspace blankLines="0"/> <dt pn="section-2.1-2.9">DetNet domain</dt>
The portion of a network that is DetNet aware. <dd pn="section-2.1-2.10">
It includes end The portion of a network that
systems and DetNet nodes. is DetNet aware. It includes end systems and DetNet
</t> nodes.
<t hangText="DetNet edge node"><vspace blankLines="0"/> </dd>
An instance of a DetNet relay node that acts as <dt pn="section-2.1-2.11">DetNet edge node</dt>
a source and/or <dd pn="section-2.1-2.12"> An instance
destination at the DetNet service sub-layer. Fo of a DetNet relay node that acts as a source and/or
r example, it can destination at the DetNet service sub-layer. For
include a DetNet service sub-layer proxy functi example, it can include a DetNet service sub-layer
on for DetNet service proxy function for DetNet service protection (e.g.,
protection (e.g., the addition or removal of pa the addition or removal of packet sequencing
cket sequencing information) information) for one or more end systems, it can start
for one or more end systems, or starts or termi or terminate resource allocation at the DetNet
nates resource allocation at forwarding sub-layer, or it can aggregate DetNet servic
the DetNet forwarding sub-layer, or aggregates es
DetNet services into new DetNet flows. into new DetNet flows. It is analogous to a Label
It is analogous to a Label Edge Router (LER) or Edge Router (LER) or a Provider Edge (PE) router.
a Provider Edge (PE) router. </dd>
</t> <dt pn="section-2.1-2.13">DetNet flow</dt>
<t hangText="DetNet flow"><vspace blankLines="0"/> <dd pn="section-2.1-2.14">
A DetNet flow is a sequence of packets which conf A sequence of packets that conforms uniquely
orm uniquely to a flow identifier and to which the DetNet serv
to a flow identifier, and to which the DetNet ser ice is to be
vice is to be
provided. It includes any DetNet headers added to support the provided. It includes any DetNet headers added to support the
DetNet service and forwarding sub-layers. DetNet service and forwarding sub-layers.
</t> </dd>
<t hangText="DetNet forwarding sub-layer"><vspace blank <dt pn="section-2.1-2.15">DetNet forwarding sub-layer</dt>
Lines="0"/> <dd pn="section-2.1-2.16">
DetNet functionality is divided into two sub-la DetNet functionality is divided into two sub-layers.
yers. One of One of
them is the DetNet forwarding sub-layer, which them is the DetNet forwarding sub-layer, which option
optionally ally
provides resource allocation for DetNet flows o ver paths provides resource allocation for DetNet flows o ver paths
provided by the underlying network. provided by the underlying network.
</t> </dd>
<t hangText="DetNet intermediate node"><vspace blankLin <dt pn="section-2.1-2.17">DetNet intermediate node</dt>
es="0"/> <dd pn="section-2.1-2.18">
A DetNet relay node or DetNet transit node. A DetNet relay node or DetNet transit node.
</t> </dd>
<t hangText="DetNet node"><vspace blankLines="0"/> <dt pn="section-2.1-2.19">DetNet node</dt>
A DetNet edge node, a DetNet relay node, or a <dd pn="section-2.1-2.20"> A
DetNet transit node. DetNet edge node, a DetNet relay
</t> node, or a DetNet transit node.
<t hangText="DetNet relay node"><vspace blankLines="0"/ </dd>
> <dt pn="section-2.1-2.21">DetNet relay node</dt>
A DetNet node including a service sub-layer funct <dd pn="section-2.1-2.22"> A DetNet
ion that interconnects different node that includes a service
DetNet forwarding sub-layer paths to provide serv sub-layer function that interconnects different
ice protection. A DetNet relay node DetNet forwarding sub-layer paths to provide service
participates in the DetNet service protection. A DetNet relay node participates in the
sub-layer. It typically incorporates DetNet forw DetNet service sub-layer. It typically incorporates
arding sub-layer functions as DetNet forwarding sub-layer functions as well, in
well, in which case it is collocated with a trans which case it is collocated with a transit node.
it node. </dd>
</t> <dt pn="section-2.1-2.23">DetNet service sub-layer</dt>
<t hangText="DetNet service sub-layer"><vspace blankLin <dd pn="section-2.1-2.24">
es="0"/> DetNet functionality is divided into two sub-layers. One of
DetNet functionality is divided into two sub-la them is the DetNet service sub-layer, at which a DetNet
yers. One of service (e.g., service protection) is provided.
them is the DetNet service sub-layer, at which </dd>
a DetNet service, <dt pn="section-2.1-2.25">DetNet service proxy</dt>
e.g., service protection is provided. <dd pn="section-2.1-2.26">
</t> A proxy that maps between App-flows and DetNet flows.
<t hangText="DetNet service proxy"><vspace blankLines=" </dd>
0"/> <dt pn="section-2.1-2.27">DetNet source</dt>
Maps between App-flows and DetNet flows. <dd pn="section-2.1-2.28">
</t>
<t hangText="DetNet source"><vspace blankLines="0"/>
An end system capable of originating a DetNet f low. An end system capable of originating a DetNet f low.
</t> </dd>
<t hangText="DetNet system"><vspace blankLines="0"/> <dt pn="section-2.1-2.29">DetNet system</dt>
A DetNet aware end system, transit node, or rel <dd pn="section-2.1-2.30">
ay node. A DetNet-aware end system, transit node, or rel
ay node.
"DetNet" may be omitted in some text. "DetNet" may be omitted in some text.
</t> </dd>
<t hangText="DetNet transit node"><vspace blankLines="0 <dt pn="section-2.1-2.31">DetNet transit node</dt>
"/> <dd pn="section-2.1-2.32">
A DetNet node operating at the DetNet forwardin A DetNet node, operating at the DetNet forwarding sub-
g sub-layer, that utilizes link layer layer,
and/or network layer switching across multiple that utilizes link-layer and/or network-layer
links and/or sub-networks to provide paths for switching across multiple links and/or sub-networks
DetNet service sub-layer functions. to provide paths for DetNet service sub-layer
Typically provides resource allocation over tho functions. It typically provides resource allocation
se paths. over those paths. An MPLS Label Switch Router (LSR) is
An MPLS LSR is an example of a DetNet transit n an example of a
ode. DetNet transit node.
</t> </dd>
<t hangText="DetNet-UNI"><vspace blankLines="0"/> <dt pn="section-2.1-2.33">DetNet-UNI</dt>
User-to-Network Interface with DetNet specific <dd pn="section-2.1-2.34">
functionalities. It is a packet-based reference point and may provide multiple f A User-to-Network Interface (UNI) with DetNet-specific
unctions like encapsulation, status, synchronization, etc. functionalities. It is a packet-based reference
</t> point and may provide multiple functions like
<t hangText="end system"><vspace blankLines="0"/> encapsulation, status, synchronization, etc.
Commonly called a "host" in IETF documents, and </dd>
an "end <dt pn="section-2.1-2.35">end system</dt>
station" is IEEE 802 documents. End systems of <dd pn="section-2.1-2.36">
interest to Commonly called a "host" in the RFC series and an
this document are either sources or destination "end station" in IEEE 802 standards. End systems of
s of DetNet flows. interest to this document are either sources or
And end system may or may not be DetNet forward destinations of DetNet flows, and they may or may
ing sub-layer aware or not be aware of DetNet forwarding sub-layers or
DetNet service sub-layer aware. DetNet service sub-layers.
</t> </dd>
<t hangText="link"><vspace blankLines="0"/> <dt pn="section-2.1-2.37">link</dt>
A connection between two DetNet nodes. It may <dd pn="section-2.1-2.38">
be composed of a A connection between two DetNet nodes. It may be
physical link composed of a physical link or a sub-network
or a sub-network technology that can provide ap technology that can provide appropriate traffic
propriate traffic delivery for DetNet flows.
delivery for DetNet </dd>
flows. <dt pn="section-2.1-2.39">Packet Elimination Function (PEF)</dt>
</t> <dd pn="section-2.1-2.40">
<t hangText="PEF"> A function that eliminates duplicate
A Packet Elimination Function (PEF) eliminates duplicate copi copies of packets to prevent excess packets flooding the
es of packets network or duplicate packets being sent out of the DetNet
to prevent excess packets flooding the network or domain. A PEF can be implemented by a DetNet edge node, a
duplicate packets being DetNet relay node, or an end system.
sent out of the DetNet domain. PEF can be impleme </dd>
nted by a DetNet edge node, a <dt pn="section-2.1-2.41">Packet Replication Function (PRF)</dt>
DetNet relay node, or an end system. <dd pn="section-2.1-2.42">
</t> A function that replicates DetNet flow
packets and forwards them to one or more next hops in the
<t hangText="PRF"> DetNet domain. The number of packet copies sent to the
A Packet Replication Function (PRF) replicates DetNet flow pa next hops is a parameter specific to the DetNet flow at the p
ckets oint
and forwards them to one or more next hops in the of replication. A PRF can be implemented by a DetNet edge
DetNet domain. node, a DetNet relay node, or an end system.
The number of packet copies sent to the next hops </dd>
is a DetNet flow <dt pn="section-2.1-2.43">PREOF</dt>
specific parameter at the point of replication. P <dd pn="section-2.1-2.44">
RF can be A collective name for Packet Replication, Elimination, and Or
implemented by a DetNet edge node, a DetNet relay dering Functions.
node, or an end system. </dd>
</t> <dt pn="section-2.1-2.45">Packet Ordering Function (POF)</dt>
<dd pn="section-2.1-2.46">
<t hangText="PREOF"> A function that reorders packets within
Collective name for Packet Replication, Elimination, and Orde a DetNet flow that are received out of order. This
ring Functions. function can be implemented by a DetNet edge node, a
</t> DetNet relay node, or an end system.
</dd>
<t hangText="POF"> <dt pn="section-2.1-2.47">reservation</dt>
A Packet Ordering Function (POF) re-orders packets within a D <dd pn="section-2.1-2.48">
etNet flow that are received out of order. The set of resources allocated between a source and
This function can be implemented by a DetNet edge node, a Det one or more destinations through DetNet nodes and
Net relay node, or an end system. subnets associated with a DetNet flow in order to provi
</t> de
the provisioned DetNet service.
<t hangText="reservation"><vspace blankLines="0"/> </dd>
The set of resources allocated between a source a </dl>
nd one or more destinations through DetNet nodes </section>
and subnets associated with a DetNet flow, to pro <section numbered="true" toc="include" removeInRFC="false" pn="section-2.2
vide the provisioned DetNet service. ">
</t> <name slugifiedName="name-dictionary-of-terms-used-by">Dictionary of Ter
</list> ms Used by TSN and DetNet</name>
</t> <t pn="section-2.2-1">
</section> This section serves as a dictionary for translating the
<section title="IEEE 802.1 TSN to DetNet dictionary">
<t>
This section also serves as a dictionary for translatin
g from the
terms used by the Time-Sensitive Networking (TSN) Task Group terms used by the Time-Sensitive Networking (TSN) Task Group
<xref target="IEEE802.1TSNTG"/> of the IEEE 802.1 WG t <xref target="IEEE802.1TSNTG" format="default" sectionF
o those of ormat="of" derivedContent="IEEE802.1TSNTG"/> of the IEEE 802.1 WG to those of
the DetNet WG. the Deterministic Networking (detnet) WG of the IETF.
<list hangIndent="8" style="hanging"> </t>
<t hangText="Listener"><vspace blankLines="0"/> <dl newline="true" spacing="normal" indent="3" pn="section-2.2-2">
The IEEE 802.1 term for a destination o <dt pn="section-2.2-2.1">Listener</dt>
f a DetNet flow. <dd pn="section-2.2-2.2">
</t> The term used by IEEE 802.1 for a desti
<t hangText="relay system"><vspace blankLines=" nation of a DetNet flow.
0"/> </dd>
The IEEE 802.1 term for a DetNet interm <dt pn="section-2.2-2.3">Relay system</dt>
ediate node. <dd pn="section-2.2-2.4">
</t> The term used by IEEE
<t hangText="Stream"><vspace blankLines="0"/> 802.1 for a DetNet intermediate node.
The IEEE 802.1 term for a DetNet flow. </dd>
</t> <dt pn="section-2.2-2.5">Stream</dt>
<t hangText="Talker"><vspace blankLines="0"/> <dd pn="section-2.2-2.6">
The IEEE 802.1 term for the source of a The term used by IEEE 802.1 for a DetNe
DetNet flow. t flow.
</t> </dd>
</list> <dt pn="section-2.2-2.7">Talker</dt>
</t> <dd pn="section-2.2-2.8">
</section> The term used by IEEE
</section> 802.1 for the source of a DetNet flow.
</dd>
<section anchor="ProvidingQoS" title="Providing the DetNet Quality of Ser </dl>
vice"> </section>
<section anchor="DefiningGoals" title="Primary goals defining the DetNet Q </section>
oS"> <section anchor="ProvidingQoS" numbered="true" toc="include" removeInRFC="fa
<t> lse" pn="section-3">
The DetNet Quality of Service can be expressed in terms o <name slugifiedName="name-providing-the-detnet-qualit">Providing the DetNe
f: t Quality of Service</name>
<list style="symbols"> <section anchor="DefiningGoals" numbered="true" toc="include" removeInRFC=
<t> "false" pn="section-3.1">
Minimum and maximum end-to-end latency from source to des <name slugifiedName="name-primary-goals-defining-the-">Primary Goals Def
tination; ining the DetNet QoS</name>
timely delivery, and bounded jitter (packet delay variation) derived <t pn="section-3.1-1">
from these constraints. The DetNet QoS can be expressed in terms of:
</t> </t>
<t> <ul spacing="normal" bare="false" empty="false" pn="section-3.1-2">
Packet loss ratio, under various assumptions as to the op <li pn="section-3.1-2.1">
erational Minimum and maximum end-to-end latency from source to
destination, timely delivery, and bounded jitter
(packet delay variation) derived from these
constraints.
</li>
<li pn="section-3.1-2.2">
Packet loss ratio under various assumptions as to the ope
rational
states of the nodes and links. states of the nodes and links.
</t><t> </li>
<li pn="section-3.1-2.3">
An upper bound on out-of-order packet delivery. It is wor th noting An upper bound on out-of-order packet delivery. It is wor th noting
that some DetNet applications are unable to tolerate any that some DetNet applications are unable to tolerate any
out-of-order delivery. out-of-order delivery.
</t> </li>
</list> </ul>
</t><t> <t pn="section-3.1-3">
It is a distinction of DetNet that it is concerned solely with It is a distinction of DetNet that it is concerned solely with
worst-case values for the end-to-end latency, jitter, and worst-case values for the end-to-end latency, jitter, and
misordering. Average, mean, or typical values are of litt le misordering. Average, mean, or typical values are of litt le
interest, because they do not affect the ability of a rea l-time interest, because they do not affect the ability of a rea l-time
system to perform its tasks. In general, a trivial priori ty-based system to perform its tasks. In general, a trivial priori ty-based
queuing scheme will give better average latency to a data flow than queuing scheme will give better average latency to a data flow than
DetNet; however, it may not be a suitable option for DetN et because DetNet; however, it may not be a suitable option for DetN et because
of its worst-case latency. of its worst-case latency.
</t><t> </t>
<t pn="section-3.1-4">
Three techniques are used by DetNet to provide these qual ities of service: Three techniques are used by DetNet to provide these qual ities of service:
<list style="symbols"> </t>
<t> <ul spacing="normal" bare="false" empty="false" pn="section-3.1-5">
Resource allocation (<xref target="Zero"/ <li pn="section-3.1-5.1">
>). Resource allocation (<xref target="Zero"
</t><t> format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>)
Service protection (<xref target="srvcpro </li>
t"/>). <li pn="section-3.1-5.2">
</t><t> Service protection (<xref target="srvcpro
Explicit routes (<xref target="pinned"/>) t" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>)
. </li>
</t> <li pn="section-3.1-5.3">
</list> Explicit routes (<xref target="pinned" fo
</t><t> rmat="default" sectionFormat="of" derivedContent="Section 3.2.3"/>)
</li>
</ul>
<t pn="section-3.1-6">
Resource allocation operates by assigning resources, e.g., buffer Resource allocation operates by assigning resources, e.g., buffer
space or link bandwidth, to a DetNet flow (or flow aggregate) along space or link bandwidth, to a DetNet flow (or flow aggregate) along
its path. Resource allocation greatly reduces, or even eliminates its path. Resource allocation greatly reduces, or even eliminates
entirely, packet loss due to output packet contention within the entirely, packet loss due to output packet contention within the
network, but it can only be supplied to a DetNet flow that is limite d network, but it can only be supplied to a DetNet flow that is limite d
at the source to a maximum packet size and transmission rate. at the source to a maximum packet size and transmission rate.
As DetNet flows are assumed to be rate-limited and DetNet is designed As DetNet flows are assumed to be rate limited and DetNet is designed
to provide sufficient allocated resources (including prov isioned to provide sufficient allocated resources (including prov isioned
capacity), the use of transport layer congestion control capacity), the use of transport-layer congestion control
<xref target="RFC2914"/> for App-flows is not required; h <xref target="RFC2914" format="default" sectionFormat="of
owever, " derivedContent="RFC2914"/> for App-flows is not required; however,
if resources are allocated appropriately, use of congesti on control if resources are allocated appropriately, use of congesti on control
should not impact transmission negatively. should not impact transmission negatively.
</t><t> </t>
Resource allocation addresses two of the DetNet QoS requirements: <t pn="section-3.1-7"> Resource allocation addresses two of the DetNet Q
latency and packet loss. Given that DetNet nodes have a finite oS requirements: latency
amount of buffer space, resource allocation necessarily results in and packet loss. Given that DetNet nodes have a finite amount of buffer space,
a maximum end-to-end latency. It also addresses contention related resource allocation necessarily results in a maximum end-to-end
packet loss. latency. Resource allocation also addresses contention-related packet loss.
</t><t> </t>
Other important contribution to packet loss are <t pn="section-3.1-8"> Other important contributions to packet loss are
random media errors and equipment failures. Service prot random media errors
ection is the name for the and equipment failures. Service protection is the name for the mechanisms
mechanisms used by DetNet to address these losses. The m used by DetNet to address these losses. The mechanisms employed are
echanisms employed are constrained by the need to meet the users' latency requirements. Packet
constrained by the requirement to meet the users' latency replication and elimination (<xref target="Seamless" format="default" sectionFor
requirements. mat="of" derivedContent="Section 3.2.2.2"/>) and packet encoding
Packet replication and elimination (<xref target="srvcpro (<xref target="PacketEncoding" format="default" sectionFormat="of" derivedConten
t"/>) and packet encoding t="Section 3.2.2.3"/>) are described in this document to provide
(<xref target="PacketEncoding"/>) are described in this document service protection, but other mechanisms may also be found. For instance,
to provide service protection; others may be found. For i packet encoding can be used to provide service protection against random media
nstance, packet encoding errors, while packet replication and elimination can be used to provide
can be used to provide service protection against random media error service protection against equipment failures. This mechanism distributes the
s, packet contents of DetNet flows over multiple paths in time and/or space, so that the
replication and elimination can be used to provide service protectio loss of some of the paths does need not cause the loss of any packets.
n against </t>
equipment failures. This mechanism <t pn="section-3.1-9"> The paths are typically (but not necessarily) exp
distributes the contents of DetNet flows licit routes so that
over multiple paths in time and/or space, so that the los they do not normally suffer temporary interruptions caused by the convergence
s of some of the paths does of routing or bridging protocols. </t>
need not cause the loss of any packets. <t pn="section-3.1-10"> These three techniques can be applied individual
</t><t> ly or applied together; it
The paths are typically (but not necessarily) explicit ro results that eight combinations, including none (no DetNet), are
utes, so that they do not normally possible. Some combinations, however, are of wider utility than others. This
suffer temporary interruptions caused by the convergence separation keeps the protocol stack coherent and maximizes interoperability
of routing or bridging protocols. with existing and developing standards in the IETF and other Standards
</t><t> Development Organizations. The following are examples of typical expected
These three techniques can be applied independently, givi combinations:
ng eight possible combinations, </t>
including none (no DetNet), although some combinations ar <ul spacing="normal" bare="false" empty="false" pn="section-3.1-11">
e of wider utility than others. <li pn="section-3.1-11.1">
This separation keeps the protocol stack coherent and max The combination of explicit routes and service protection is the techniqu
imizes interoperability with e
existing and developing standards in this (IETF) and othe employed by seamless redundancy mechanisms applied on a ring topology,
r e.g., as described in <xref target="IEC-62439-3" format="default" section
Standards Development Organizations. Some examples of ty Format="of" derivedContent="IEC-62439-3"/>. In this
pical expected combinations: example, explicit routes are achieved by limiting the physical
<list style="symbols"> topology of the network to a ring. Sequentialization, replication, and
<t> duplicate elimination are facilitated by packet tags added at the
Explicit routes plus service protection a front or the end of Ethernet frames. <xref target="RFC8227" format="defau
re exactly the techniques lt" sectionFormat="of" derivedContent="RFC8227"/> provides
employed by seamless redundancy mechanism another example in the context of MPLS. </li>
s applied on a ring topology <li pn="section-3.1-11.2"> Resource allocation
as described, e.g., in <xref target="IEC6 alone was originally offered by Audio Video Bridging as defined by IEEE 8
2439-3-2016"/>. In this example, 02.1 <xref target="IEEE802.1BA" format="default" sectionFormat="of" derivedConte
explicit routes are achieved by limiting nt="IEEE802.1BA"/>. As long as the network suffers no failures,
the physical topology of packet loss due to output packet contention can be eliminated through
the network to a ring. Sequentialization, the use of a reservation protocol (e.g., the Multiple Stream Registration
replication, and Protocol <xref target="IEEE802.1Q" format="default" sectionFormat="of" de
duplicate elimination are facilitated by rivedContent="IEEE802.1Q"/>), shapers in every bridge,
packet tags added at the and proper dimensioning. </li>
front or the end of Ethernet frames. <xre <li pn="section-3.1-11.3"> Using all three together gives
f target="RFC8227"/> provides maximum protection.
another example in the context of MPLS. </li>
</t><t> </ul>
Resource allocation alone was originally <t pn="section-3.1-12"> There are, of course, simpler methods available
offered by IEEE 802.1 Audio Video bridging (and employed today) to
<xref target="IEEE802.1BA"/>. As long as achieve levels of latency and packet loss that are satisfactory for many
the network suffers no failures, applications. Prioritization and over-provisioning is one such technique.
packet loss due to output packet contenti However, these methods generally work best in the absence of any significant
on can be eliminated through the use of a reservation protocol (e.g., Multiple S amount of noncritical traffic in the network (if, indeed, such traffic is
tream Registration Protocol <xref target="IEEE802.1Q-2018"/>), shapers in every supported at all). They may also work only if the critical traffic constitutes o
bridge, and proper dimensioning. nly a small portion of
</t><t> the network's theoretical capacity, if all systems are functioning properly,
Using all three together gives maximum pr or if actions by end systems that disrupt the network's
otection. operations are absent. </t>
</t> <t pn="section-3.1-13"> There are any number of methods in use, defined,
</list> or in progress for
</t><t> accomplishing each of the above techniques. It is expected that the DetNet
There are, of course, simpler methods available (and empl architecture defined in this document will assist various vendors, users, and/or
oyed, today) to achieve "vertical" Standards
levels of latency and packet loss that are satisfactory f Development Organizations (dedicated to a single industry) in making selections
or many applications. among the available means of implementing DetNet networks.
Prioritization and over-provisioning is one such techniqu </t>
e. However, these </section>
methods generally work best in the absence of any signifi <section anchor="Techniques" numbered="true" toc="include" removeInRFC="fa
cant amount of non-critical lse" pn="section-3.2">
traffic in the network (if, indeed, such traffic is suppo <name slugifiedName="name-mechanisms-to-achieve-detne">Mechanisms to Ach
rted at all), or work only if ieve DetNet QoS</name>
the critical traffic constitutes only a small portion of <section anchor="Zero" numbered="true" toc="include" removeInRFC="false"
the network's theoretical pn="section-3.2.1">
capacity, or work only if all systems are functioning pro <name slugifiedName="name-resource-allocation">Resource Allocation</na
perly, or in the absence of me>
actions by end systems that disrupt the network's operati <section anchor="ZeroL" numbered="true" toc="exclude" removeInRFC="fal
ons. se" pn="section-3.2.1.1">
</t><t> <name slugifiedName="name-eliminate-contention-loss">Eliminate Conte
There are any number of methods in use, defined, or in pr ntion Loss</name>
ogress for accomplishing each <t pn="section-3.2.1.1-1">
of the above techniques. It is expected that this DetNet The primary means by which DetNet achieves its QoS
Architecture will assist assurances is to reduce, or even completely eliminate,
various vendors, users, and/or "vertical" packet loss due to output packet contention within a
Standards Development Organizations (dedicated to a singl DetNet node as a cause of packet loss. This can be
e industry) to make selections achieved only by the provision of sufficient buffer
among the available means of implementing DetNet networks storage at each node through the network to ensure
. that no packets are dropped due to a lack of buffer
</t> storage. Note that App-flows are generally not
</section> expected to be responsive to implicit <xref target="RFC29
<section anchor="Techniques" title="Mechanisms to achieve DetNet QoS"> 14" format="default" sectionFormat="of" derivedContent="RFC2914"/> or explicit c
<section anchor="Zero" title="Resource allocation"> ongestion notification
<section anchor="ZeroL" title="Eliminate contention loss"> <xref target="RFC3168" format="default" sectionFormat="of
<t> " derivedContent="RFC3168"/>.
The primary means by which DetNet achieves its QoS assura
nces is to reduce, or even completely eliminate packet loss due to output packet
contention
within a DetNet node as a cause of packet loss.
This can be achieved only by the provision of
sufficient buffer storage at each node through the networ
k to ensure that no
packets are dropped due to a lack of buffer storage.
Note that App-flows are generally not expected to be res
ponsive to implicit <xref target="RFC2914"/> or explicit congestion notification
<xref target="RFC3168"/>.
</t><t> </t>
Ensuring adequate buffering requires, in turn, that the s <t pn="section-3.2.1.1-2"> Ensuring adequate buffering requires, in
ource, and every DetNet turn, that
node along the path to the destination (or nearly every n the source and every DetNet node along the path to the
ode, see destination (or nearly every node; see <xref target="Incomplete"
<xref target="Incomplete"/>) be careful to regulate its o format="default" sectionFormat="of" derivedContent="Section 4.3.3"/>) be careful
utput to not exceed the to regulate its output to
data rate for any DetNet flow, except for brief periods w not exceed the data rate for any DetNet flow, except for brief
hen making up for periods when making up for interfering traffic. Any packet
interfering traffic. Any packet sent ahead of its time p sent ahead of its time potentially adds to the number of
otentially adds to the buffers required by the next-hop DetNet node and may thus
number of buffers required by the next hop DetNet node an exceed the resources allocated for a particular DetNet
d may thus exceed the resources flow. Furthermore, rate limiting (e.g., using traffic policing)
allocated for a particular DetNet flow. Furthermore, rate and shaping functions (e.g., shaping as defined in <xref target="
limiting, e.g., using traffic RFC2475" format="default" sectionFormat="of" derivedContent="RFC2475"/>) at the
policing and shaping functions, e.g., <xref target="RFC24 ingress of the DetNet domain must be applied. This is needed
75"/>, at the ingress of the for meeting the requirements of DetNet flows as well as for
DetNet domain must be applied. This is needed for meeting protecting non-DetNet traffic from potentially misbehaving
the requirements of DetNet DetNet traffic sources. Note that large buffers have some
flows as well as for protecting non-DetNet traffic from p issues (see, e.g., <xref target="BUFFERBLOAT" format="default" se
otentially misbehaving DetNet ctionFormat="of" derivedContent="BUFFERBLOAT"/>). </t>
traffic sources. Note that large buffers have some issues <t pn="section-3.2.1.1-3"> The low-level mechanisms described in <xr
, see, e.g., <xref target="BUFFERBLOAT"/>. ef target="QueuingModels" format="default" sectionFormat="of" derivedContent="Se
</t><t> ction 4.5"/>
The low-level mechanisms described in <xref target="Queui provide the necessary regulation of transmissions by an end system or DetNet
ngModels"/> provide node to provide resource allocation. The allocation of the bandwidth and
the necessary buffers for a DetNet flow requires provisioning. A DetNet node may have other
regulation of transmissions by an end system or DetNet no resources requiring allocation and/or scheduling that might otherwise be
de to provide over-subscribed and trigger the rejection of a reservation.
resource allocation. The allocation of the bandwidth and </t>
buffers for a DetNet flow requires provisioning. </section>
A DetNet node may have other resources requiring allocati <section anchor="Jitterless" numbered="true" toc="exclude" removeInRFC
on and/or scheduling, ="false" pn="section-3.2.1.2">
that might otherwise be over-subscribed and trigger the r <name slugifiedName="name-jitter-reduction">Jitter Reduction</name>
ejection of a reservation. <t pn="section-3.2.1.2-1">
</t>
</section>
<section anchor="Jitterless" title="Jitter Reduction">
<t>
A core objective of DetNet is to enable the convergence of sensitive non- IP networks A core objective of DetNet is to enable the convergence of sensitive non- IP networks
onto a common network infrastructure. This requires the accurate emulatio n onto a common network infrastructure. This requires the accurate emulatio n
of currently deployed mission-specific networks, which of currently deployed mission-specific networks, which,
for example rely on point-to-point analog (e.g., 4-20mA modulation) and for example, rely on point-to-point analog (e.g., 4-20mA modulation) and
serial-digital cables (or buses) for highly reliable, synchronized and serial-digital cables (or buses) for highly reliable, synchronized, and
jitter-free communications. While the latency of analog transmissions is jitter-free communications. While the latency of analog transmissions is
basically the speed of light, legacy serial links are usually slow (in th e basically the speed of light, legacy serial links are usually slow (in th e
order of Kbps) compared to, say, Gigabit Ethernet, and some latency is us ually order of Kbps) compared to, say, Gigabit Ethernet, and some latency is us ually
acceptable. What is not acceptable is the introduction of excessive jitte r, acceptable. What is not acceptable is the introduction of excessive jitte r,
which may, for instance, affect the stability of control systems. which may, for instance, affect the stability of control systems.
</t> </t>
<t>Applications that are designed to operate on serial links usually do <t pn="section-3.2.1.2-2">Applications that are designed to operate
on serial links usually do
not provide services to recover the jitter, because jitter simply does no t not provide services to recover the jitter, because jitter simply does no t
exist there. DetNet flows are generally expected to be delivered in-order exist there. DetNet flows are generally expected to be delivered in order ,
and the precise time of reception influences the processes. In order to and the precise time of reception influences the processes. In order to
converge such existing applications, converge such existing applications,
there is a desire to emulate all properties of the serial cable, such there is a desire to emulate all properties of the serial cable, such
as clock transportation, perfect flow isolation and fixed latency. While minimal as clock transportation, perfect flow isolation, and fixed latency. While minimal
jitter (in the form of specifying minimum, as well as maximum, end-to-end latency) jitter (in the form of specifying minimum, as well as maximum, end-to-end latency)
is supported by DetNet, there are practical limitations on packet-based n etworks is supported by DetNet, there are practical limitations on packet-based n etworks
in this regard. In general, users in this regard. In general, users
are encouraged to use a combination of: are encouraged to use a combination of:
<list style="symbols"> </t>
<t> <ul spacing="normal" bare="false" empty="false" pn="section-3.2.1.2-
3">
<li pn="section-3.2.1.2-3.1">
Sub-microsecond time synchronization among all source an d destination Sub-microsecond time synchronization among all source an d destination
end systems, and end systems, and
</t><t> </li>
<li pn="section-3.2.1.2-3.2">
Time-of-execution fields in the application packets. Time-of-execution fields in the application packets.
</t> </li>
</list> </ul>
</t><t> <t pn="section-3.2.1.2-4">
Jitter reduction is provided by the mechanisms described in <xref ta Jitter reduction is provided by the mechanisms described in <xref ta
rget="QueuingModels"/> rget="QueuingModels" format="default" sectionFormat="of" derivedContent="Section
4.5"/>
that also provide resource allocation. that also provide resource allocation.
</t> </t>
</section> </section>
</section> </section>
<section anchor="srvcprot" numbered="true" toc="include" removeInRFC="fa
<section anchor="srvcprot" title="Service Protection"> lse" pn="section-3.2.2">
<t> <name slugifiedName="name-service-protection">Service Protection</name
Service protection aims to mitigate or eliminate packet loss due to >
equipment failures, including random media and/or memory faults. <t pn="section-3.2.2-1">
These types of Service protection aims to mitigate or eliminate packet loss due
packet loss can be greatly reduced by spreading the data over mul to equipment failures, including random media and/or memory
tiple faults. These types of packet loss can be greatly reduced by
disjoint forwarding paths. Various service protection methods are spreading the data over multiple disjoint forwarding
described in <xref target="RFC6372"/>, e.g., 1+1 linear protectio paths. Various service protection methods are described in <xref targ
n. et="RFC6372" format="default" sectionFormat="of" derivedContent="RFC6372"/>, e.g
This section describes the functional details of an additional me ., 1+1 linear protection. The functional
thod details of an additional method are described in <xref target="Seamle
in <xref target="Seamless"/>, which can be implemented as describ ss" format="default" sectionFormat="of" derivedContent="Section 3.2.2.2"/>, whic
ed in h can be implemented as described in
<xref target="PacketEncoding"/> or as specified in <xref target="PacketEncoding" format="default" sectionFormat="of" der
<xref target="I-D.ietf-detnet-dp-sol-mpls"/> in order to provide ivedContent="Section 3.2.2.3"/> or as specified in <xref target="I-D.ietf-detnet
1+n hitless -mpls" format="default" sectionFormat="of" derivedContent="DETNET-MPLS"/> in ord
protection. The appropriate service protection mechanism depends er to provide 1+n hitless
on the protection. The appropriate service protection mechanism depends
scenario and the requirements. on the scenario and the requirements.
</t> </t>
<section anchor="inorder" numbered="true" toc="exclude" removeInRFC="f
<section anchor="inorder" title="In-Order Delivery"> alse" pn="section-3.2.2.1">
<t> <name slugifiedName="name-in-order-delivery">In-Order Delivery</name
Out-of-order packet delivery can be a side effect of service protection. >
Packets delivered out-of-order impact the amount of buffering nee <t pn="section-3.2.2.1-1">
ded at Out-of-order packet delivery can be a side effect of service
the destination to properly process the received data. Such packe protection. Packets delivered out of order impact the amount of
ts buffering needed at the destination to properly process the received
also influence the jitter of a flow. The DetNet service includes data. Such packets also influence the jitter of a flow. The guarantees
maximum allowed misordering as a constraint. Zero misordering wou of a DetNet service include a maximum amount of misordering as a
ld be constraint. Zero misordering would be a valid service constraint to
a valid service constraint to reflect that the end system(s) of t reflect that the end system(s) of the flow cannot tolerate any
he out-of-order delivery. A DetNet Packet Ordering Function (POF)
flow cannot tolerate any out-of-order delivery. DetNet Packet Ord (<xref target="Seamless" format="default" sectionFormat="of" derivedCont
ering ent="Section 3.2.2.2"/>) can be used to provide in-order delivery.
Functionality (POF) (<xref target="Seamless"/>) can be used to pr </t>
ovide </section>
in-order delivery. <section anchor="Seamless" numbered="true" toc="exclude" removeInRFC="
</t> false" pn="section-3.2.2.2">
</section> <name slugifiedName="name-packet-replication-and-elim">Packet Replic
ation and Elimination</name>
<section anchor="Seamless" title="Packet Replication and Elimination"> <t pn="section-3.2.2.2-1">
<t>
This section describes a service protection method that sends copies This section describes a service protection method that sends copies
of the same packets over multiple paths. of the same packets over multiple paths. </t>
</t><t> <t pn="section-3.2.2.2-2"> The DetNet service
The DetNet service sub-layer includes the packet replication (PRF), sub-layer includes the PRF, PEF, and POF for use in DetNet edge,
the relay node, and end-system packet processing. These functions can be
packet elimination (PEF), and the packet ordering functionali enabled in a DetNet edge node, relay node, or end system. The
ty (POF) collective name for all three functions is Packet Replication,
for use in DetNet edge, relay node, and end system packet Elimination, and Ordering Functions (PREOF). The packet replication
processing. and elimination service protection method altogether involves four
These functions can be enabled in a DetNet edge node, rel capabilities:
ay </t>
node or end system. The collective name for all three fun <ul spacing="normal" bare="false" empty="false" pn="section-3.2.2.2-
ctions is 3">
Packet Replication, Elimination, and Ordering Functions ( <li pn="section-3.2.2.2-3.1">
PREOF). Sequencing information is provided to the
The packet replication and elimination service protection
method
altogether involves four capabilities:
<list style="symbols">
<t>
Providing sequencing information to the
packets of a DetNet compound flow. This may packets of a DetNet compound flow. This may
be done by adding a sequence number or time stamp be done by adding a sequence number or time
as part of DetNet, or may be stamp as part of DetNet, or it may be inherent
inherent in the packet, e.g., in a higher layer p in the packet, e.g., in a higher-layer
rotocol, or associated to other physical protocol or associated to other physical
properties such as the precise time (and radio ch properties such as the precise time (and radio
annel) of reception of the packet. channel) of reception of the packet. This is
This is typically done once, at or near the sourc typically done once, at or near the source.
e. </li>
</t><t> <li pn="section-3.2.2.2-3.2"> The PRF
The Packet Replication Function (PRF) replicates replicates these packets into multiple DetNet
these packets member flows and typically sends them along
into multiple DetNet member flows and typically s multiple different paths to the
ends them along destination(s), e.g., over the explicit routes
multiple different paths to the destination(s), e described in <xref target="pinned" format="defaul
.g., over the t" sectionFormat="of" derivedContent="Section 3.2.3"/>. The location
explicit routes of <xref target="pinned"/>. The l within a DetNet node and the mechanism used
ocation within for the PRF are left open for implementations.
a DetNet node, and the mechanism used for the PRF </li>
is left open <li pn="section-3.2.2.2-3.3"> The PEF
for implementations. eliminates duplicate packets of a DetNet flow
</t><t> based on the sequencing information and a
The Packet Elimination Function (PEF) eliminates history of received packets. The output of the
duplicate packets PEF is always a single packet. This may be
of a DetNet flow based on the sequencing informat done at any DetNet node along the path to save
ion and a history network resources further downstream, in
of received packets. The output of the PEF is alw particular if multiple replication points
ays a single packet. exist. But the most common case is to perform
This may be done at any DetNet node along the pat this operation at the very edge of the DetNet
h to save network network, preferably in or near the
resources further downstream, in particular if mu receiver. The location within a DetNet node
ltiple and the mechanism used for the PEF is left open
Replication points exist. But the most common cas for implementations. </li>
e is to <li pn="section-3.2.2.2-3.4"> The
perform this operation at the very edge of the De POF uses the sequencing
tNet network, information to reorder a DetNet flow's packets
preferably in or near the receiver. The location that are received out of order.
within a DetNet node, </li>
and mechanism used for the PEF is left open f </ul>
or implementations. <t pn="section-3.2.2.2-4"> The order in which a DetNet node applies
</t><t> PEF, POF, and
The Packet Ordering Function (POF) uses the sequencin PRF to a DetNet flow is left open for implementations.
g information </t>
to re-order a DetNet flow's packets that are rece <t pn="section-3.2.2.2-5"> Some service protection mechanisms rely o
ived out of order. n switching from one flow to
</t> another when a failure of a flow is detected. Contrarily, packet replication
</list> and elimination combines the DetNet member flows sent along multiple different
</t><t> paths and performs a packet-by-packet selection of which to discard, e.g.,
The order in which a DetNet node applies PEF, POF, and PRF to based on sequencing information.
a DetNet flow is </t>
left open for implementations. <t pn="section-3.2.2.2-6">In the simplest case, this amounts to 1) r
</t><t> eplicating each packet in a
Some service protection mechanisms rely on switching from one flow source that has two interfaces and 2) conveying them through the network along
to another when a failure of a flow is detected. Contrari separate (Shared Risk Link Group (SRLG) disjoint) paths to the similarly
ly, packet dual-homed destinations that 3) reorder the packets and 4) discard the
replication and elimination combines the DetNet member fl duplicates. This ensures that one path
ows sent remains, even if some DetNet intermediate node fails. The sequencing
along multiple different paths, and performs a packet-by- information can also be used for loss detection and for reordering. </t>
packet <t pn="section-3.2.2.2-7">
selection of which to discard, e.g., based on sequencing DetNet relay nodes in the network can provide replication and elimination
information. facilities at various points in the network so that multiple failures can be
</t><t> accommodated. </t>
In the simplest case, this amounts to replicating each pa <t pn="section-3.2.2.2-8"> This is shown in <xref target="FigSeamles
cket in a source that s" format="default" sectionFormat="of" derivedContent="Figure 1"/>, where the tw
has two interfaces, and conveying them through the networ o relay nodes
k, along separate each replicate (R) the DetNet flow on input, sending the DetNet member flows
(Shared Risk Link Group (SRLG) disjoint) paths, to the to both the other relay node and to the end system, and eliminate duplicates
similarly dual-homed destinations, that discard the extra (E) on the output interface to the right-hand end system. Any one link in the
s. This ensures that one network can fail, and the DetNet compound flow can still get through.
path remains, even if some DetNet intermediate node fails Furthermore, two links can fail, as long as they are in different segments of
. the network.
The sequencing information can also be used for loss dete </t>
ction and for re-ordering. <figure anchor="FigSeamless" align="left" suppress-title="false" pn=
</t><t> "figure-1">
DetNet relay nodes in the network can provide <name slugifiedName="name-packet-replication-and-elimi">Packet Rep
replication and elimination lication and Elimination</name>
facilities at various points in the network, so that mult <artwork align="left" name="" type="" alt="" pn="section-3.2.2.2-9
iple .1">
failures can be accommodated. &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; relay &gt; &gt; &gt; &
</t><t> gt; &gt; &gt; &gt; &gt;
This is shown in <xref target="FigSeamless"/>, where the &gt; /------------+ R node E +------------\ &gt;
two relay nodes &gt; / v + ^ \ &gt;
each replicate (R) the DetNet flow on input, sending the
DetNet member flows to both the other
relay node and to the end system, and eliminate duplicate
s (E) on the output
interface to the right-hand end system. Any one link in
the network can
fail, and the DetNet compound flow can still get through.
Furthermore, two links can
fail, as long as they are in different segments of the ne
twork.
</t>
<figure align="center" anchor="FigSeamless"
title="Packet replication and elimination">
<artwork align="left"><![CDATA[
> > > > > > > > > relay > > > > > > > >
> /------------+ R node E +------------\ >
> / v + ^ \ >
end R + v | ^ + E end end R + v | ^ + E end
system + v | ^ + system system + v | ^ + system
> \ v + ^ / > &gt; \ v + ^ / &gt;
> \------------+ R relay E +-----------/ > &gt; \------------+ R relay E +-----------/ &gt;
> > > > > > > > > node > > > > > > > > &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; node &gt; &gt; &gt; &
]]></artwork> gt; &gt; &gt; &gt; &gt;</artwork>
</figure> </figure>
<t> <t pn="section-3.2.2.2-10">Packet replication and elimination does n
Packet replication and elimination does not react to and ot react to and correct failures;
correct failures; it is it is entirely passive. Thus, intermittent failures, mistakenly created
entirely passive. Thus, intermittent failures, mistakenl packet filters, or misrouted data is handled just the same as the equipment
y created packet filters, failures that are handled by typical routing and bridging protocols. </t>
or misrouted data is handled just the same as the equipme <t pn="section-3.2.2.2-11">If member flows that take different-lengt
nt failures h paths through the network are
that are handled by typical routing and bridging protocol combined, a merge point may require extra buffering to equalize the delays
s. over the different paths. This equalization ensures that the resultant
</t><t> compound flow will not exceed its contracted bandwidth even after one of the
If member flows that take different-length paths paths is restored after a failure. The extra buffering can be also used to
through the network are combined, a merge provide in-order delivery.
point may require extra buffering to equalize the delays </t>
over the different paths. This </section>
equalization ensures that the resultant compound flow wil <section anchor="PacketEncoding" numbered="true" toc="exclude" removeI
l not exceed its nRFC="false" pn="section-3.2.2.3">
contracted bandwidth even after one or the other of the p <name slugifiedName="name-packet-encoding-for-service">Packet Encodi
aths is restored ng for Service Protection</name>
after a failure. The extra buffering can be also used to <t pn="section-3.2.2.3-1">
provide in-order delivery.
</t>
</section>
<section anchor="PacketEncoding" title="Packet encoding for service protec
tion">
<t>
There are methods for using multiple paths to provide service prot ection There are methods for using multiple paths to provide service prot ection
that involve encoding the information in a that involve encoding the information in a
packet belonging to a DetNet flow into multiple transmission units , packet belonging to a DetNet flow into multiple transmission units ,
combining information from multiple packets into any given transmi ssion unit. combining information from multiple packets into any given transmi ssion unit.
Such techniques, also known as "network coding", Such techniques, also known as "network coding",
can be used as a DetNet service protection technique. can be used as a DetNet service protection technique.
</t>
</section>
</section>
<section anchor="pinned" numbered="true" toc="include" removeInRFC="fals
e" pn="section-3.2.3">
<name slugifiedName="name-explicit-routes">Explicit Routes</name>
<t pn="section-3.2.3-1">
In networks controlled by typical dynamic control protocols such as IS-IS or
OSPF, a network topology event in one part of the network can impact, at least
briefly, the delivery of data in parts of the network remote from the failure
or recovery event. Even the use of redundant paths through a network, e.g., as
defined by <xref target="RFC6372" format="default" sectionFormat="of" derivedCon
tent="RFC6372"/>, does not eliminate the chances of packet
loss. Furthermore, out-of-order packet delivery can be a side effect of route
changes. </t>
<t pn="section-3.2.3-2"> Many real-time networks rely on physical ring
s of two-port
devices, with a relatively simple ring control protocol. This supports
redundant paths for service protection with a minimum of wiring. As an
additional benefit, ring topologies can often utilize different topology
management protocols from those used for a mesh network, with a consequent
reduction in the response time to topology changes. Of course, this comes at
some cost in terms of increased hop count, and thus latency, for the typical
path. </t>
<t pn="section-3.2.3-3"> In order to get the advantages of low hop cou
nt and still ensure against
even very brief losses of connectivity, DetNet employs explicit routes where
the path taken by a given DetNet flow does not change, at least not
immediately and likely not at all, in response to network topology events.
Service protection (see Sections <xref target="srvcprot" format="counter" sectio
nFormat="of" derivedContent="3.2.2"/>
and <xref target="PacketEncoding" format="counter" sectionFormat="of" derivedCon
tent="3.2.2.3"/>) over explicit routes
provides a high likelihood of continuous connectivity. Explicit routes can be
established in various ways, e.g., with RSVP-TE <xref target="RFC3209" format="d
efault" sectionFormat="of" derivedContent="RFC3209"/>, with
Segment Routing (SR) <xref target="RFC8402" format="default" sectionFormat="of"
derivedContent="RFC8402"/>, via a SDN approach <xref target="RFC8453" format="de
fault" sectionFormat="of" derivedContent="RFC8453"/>, with IS-IS <xref target="R
FC7813" format="default" sectionFormat="of" derivedContent="RFC7813"/>, etc. Ex
plicit routes
are typically used in MPLS TE (Traffic Engineering) Label Switched Paths
(LSPs). </t>
<t pn="section-3.2.3-4"> Out-of-order packet delivery can be a side ef
fect of distributing a single
flow over multiple paths, especially when there is a change from one path to
another when combining the flow. This is irrespective of the distribution
method used and also applies to service protection over explicit routes. As
described in <xref target="inorder" format="default" sectionFormat="of" derivedC
ontent="Section 3.2.2.1"/>, out-of-order packets influence the
jitter of a flow and impact the amount of buffering needed to process the
data; therefore, the guarantees of a DetNet service include a maximum amount
of misordering as a constraint. The use of explicit routes helps to provide in-o
rder delivery
because there is no immediate route change with the network topology, but the
changes are plannable as they are between the different explicit routes.
</t> </t>
</section>
</section> </section>
</section> <section anchor="MoreGoals" numbered="true" toc="include" removeInRFC="fal
se" pn="section-3.3">
<section anchor="pinned" title="Explicit routes"> <name slugifiedName="name-secondary-goals-for-detnet">Secondary Goals fo
<t> r DetNet</name>
In networks controlled by typical dynamic control protoco <t pn="section-3.3-1">
ls such as IS-IS or OSPF,
a network topology event in one part of the network
can impact, at least briefly, the delivery of data in par
ts of the network remote from the
failure or recovery event. Even the use of redundant path
s through a network, e.g.,
as defined by <xref target="RFC6372"/> do not eliminate t
he chances of packet loss. Furthermore,
out-of-order packet delivery can be a side effect of rout
e changes.
</t><t>
Many real-time networks rely on physical rings of two-por
t devices, with
a relatively simple ring control protocol. This supports
redundant paths for
service protection with a minimum
of wiring. As an additional benefit, ring topologies can
often
utilize different topology management protocols than thos
e used for a mesh network, with
a consequent reduction in the response time to topology c
hanges. Of course, this comes
at some cost in terms of increased hop count, and thus la
tency, for the typical path.
</t><t>
In order to get the advantages of low hop count and still
ensure against even very brief
losses
of connectivity, DetNet employs explicit routes, where th
e path taken by a given DetNet flow
does not change, at least immediately, and likely not at
all, in response to network
topology events. Service protection (<xref target="srvcp
rot"/> or
<xref target="PacketEncoding"/>)
over explicit routes provides a high likelihood of contin
uous connectivity.
Explicit routes can be established in various ways, e.g.,
with
RSVP-TE <xref target="RFC3209"/>, with Segment Routing (S
R)
<xref target="RFC8402"/>, via a Software
Defined Networking approach <xref target="RFC8453"/>, wit
h IS-IS
<xref target="RFC7813"/>, etc.
Explicit routes are typically used in MPLS TE LSPs.
</t><t>
Out-of-order packet delivery can be a side effect of dist
ributing a
single flow over multiple paths, especially when there is
a change
from one path to another when combining the flow. This is
irrespective of the distribution method used, and also ap
plies to
service protection over explicit routes. As described in
<xref target="inorder"/>, out-of-order packets influence
the
jitter of a flow and impact the amount of buffering neede
d to
process the data; therefore, DetNet service includes maxi
mum
allowed misordering as a constraint. The use of explicit
routes
helps to provide in-order delivery because there is no im
mediate
route change with the network topology, but the changes a
re plannable
as they are between the different explicit routes.
</t>
</section>
</section>
<section anchor="MoreGoals" title="Secondary goals for DetNet">
<t>
Many applications require DetNet to provide additional services, includi ng coexistence with Many applications require DetNet to provide additional services, includi ng coexistence with
other QoS mechanisms <xref target="Coexistence"/> and protection against other QoS mechanisms (<xref target="Coexistence" format="default" sectio
misbehaving transmitters nFormat="of" derivedContent="Section 3.3.1"/>) and protection against misbehavin
<xref target="FaultMitigation"/>. g transmitters
</t> (<xref target="FaultMitigation" format="default" sectionFormat="of" deri
<section anchor="Coexistence" title="Coexistence with normal traffic"> vedContent="Section 3.3.2"/>).
<t> </t>
A DetNet network supports the dedication of a high proportion of t <section anchor="Coexistence" numbered="true" toc="include" removeInRFC=
he "false" pn="section-3.3.1">
network bandwidth <name slugifiedName="name-coexistence-with-normal-tra">Coexistence wit
to DetNet flows. But, no matter how much is dedicated for DetNet h Normal Traffic</name>
flows, it is <t pn="section-3.3.1-1">
a goal of DetNet to coexist with existing Class of Service schemes A DetNet network supports the dedication of a high proportion of
(e.g., DiffServ). the network bandwidth to DetNet flows. But, no matter how much
It is also is dedicated for DetNet flows, it is a goal of DetNet to coexist
important that non-DetNet traffic not disrupt the DetNet flow, of with existing Class-of-Service schemes (e.g., DiffServ). It is
course (see also important that non-DetNet traffic not disrupt the DetNet
<xref target="FaultMitigation"/> and <xref target="SecurityConside flow, of course (see Sections <xref target="FaultMitigation" forma
rations"/>). t="counter" sectionFormat="of" derivedContent="3.3.2"/> and <xref target="Securi
For these reasons: tyConsiderations" format="counter" sectionFormat="of" derivedContent="5"/>). Fo
<list style="symbols"> r these reasons:
<t>
Bandwidth (transmission opportunities) not utilized by a D
etNet flow is available
to non-DetNet packets (though not to other DetNet flows).
</t><t>
DetNet flows can be shaped or scheduled, in order to ensur
e that the
highest-priority non-DetNet
packet is also ensured a worst-case latency.
</t><t>
When transmission opportunities for DetNet flows are sched
uled in detail, then
the algorithm constructing the schedule should leave suffi
cient opportunities for
non-DetNet packets to satisfy the needs of the users of th
e network. Detailed
scheduling can also permit the time-shared use of buffer r
esources by different
DetNet flows.
</t>
</list>
</t><t>
Starvation of non-DetNet traffic must be avoided, e.g., by traffic
policing and shaping functions (e.g., <xref target="RFC
2475"/>). Thus, the net
effect of the presence of DetNet flows in a network on
the
non-DetNet flows is primarily a reduction in the availa
ble bandwidth.
</t> </t>
</section> <ul spacing="normal" bare="false" empty="false" pn="section-3.3.1-2">
<section anchor="FaultMitigation" title="Fault Mitigation"> <li pn="section-3.3.1-2.1">Bandwidth (transmission opportunities) no
<t> t utilized by a DetNet flow is
Robust real-time systems require reducing the number of available to non-DetNet packets (though not to other DetNet flows). </li>
possible failures. Filters and policers should be used in a DetNet <li pn="section-3.3.1-2.2"> DetNet flows can be shaped or scheduled,
network to in order to ensure that the
detect if DetNet packets are received highest-priority non-DetNet packet is also ensured a worst-case latency. </li>
on the wrong interface, or at the wrong time, or in too great a vo <li pn="section-3.3.1-2.3"> When transmission opportunities for DetN
lume. et flows are scheduled in detail,
Furthermore, filters and policers can take the algorithm constructing the schedule should leave sufficient
actions to discard the offending packets or flows, or trigger opportunities for non-DetNet packets to satisfy the needs of the users of the
shutting down the offending flow or the offending interface. network. Detailed scheduling can also permit the time-shared use of buffer
</t><t> resources by different DetNet flows.
It is also essential that filters and service remarking be employe </li>
d at the network edge </ul>
to prevent non-DetNet <t pn="section-3.3.1-3"> Starvation of non-DetNet traffic must be avoi
packets from being mistaken for DetNet packets, and thus impinging ded, for example, by
on the resources traffic policing and shaping functions (e.g., <xref target="RFC2475" f
allocated to DetNet packets. In particular, sending DetNet traffic ormat="default" sectionFormat="of" derivedContent="RFC2475"/>). Thus, the net ef
into networks that have not been provisioned in advance fect of the presence of DetNet
to handle flows in a network on the non-DetNet flows is primarily a reduction
that DetNet traffic has to be treated as a fault. The in the available bandwidth.
use of </t>
egress traffic filters, or equivalent mechanisms, to pr </section>
event this <section anchor="FaultMitigation" numbered="true" toc="include" removeIn
from happening are strongly recommended at the edges of RFC="false" pn="section-3.3.2">
a DetNet <name slugifiedName="name-fault-mitigation">Fault Mitigation</name>
networks and DetNet supporting networks. In this conte <t pn="section-3.3.2-1">
xt, the Robust real-time systems require reducing the number of possible
term 'provisioned' has a broad meaning, e.g., provision failures. Filters and policers should be used in a DetNet
ing could be network to detect if DetNet packets are received on the wrong
performed via an administrative decision that the downs interface, at the wrong time, or in too great a volume.
tream network Furthermore, filters and policers can take actions to discard
has the available capacity to carry the DetNet traffic the offending packets or flows, or trigger shutting down the
that is being offending flow or the offending interface. </t>
sent into it. <t pn="section-3.3.2-2"> It is also
</t><t> essential that filters and service remarking be employed at the
network edge to prevent non-DetNet packets from being mistaken
for DetNet packets and thus impinging on the resources
allocated to DetNet packets. In particular, sending DetNet
traffic into networks that have not been provisioned in advance
to handle that DetNet traffic has to be treated as a fault. The
use of egress traffic filters, or equivalent mechanisms, to
prevent this from happening are strongly recommended at the
edges of DetNet networks and DetNet supporting networks. In
this context, the term 'provisioned' has a broad meaning, e.g.,
provisioning could be performed via an administrative decision
that the downstream network has the available capacity to carry
the DetNet traffic that is being sent into it. </t>
<t pn="section-3.3.2-3">
Note that the sending of App-flows that do not use tran Note that the sending of App-flows that do not use
sport layer transport-layer congestion control per <xref target="RF
congestion control per <xref target="RFC2914"/> into a C2914" format="default" sectionFormat="of" derivedContent="RFC2914"/> into a net
network that work that is not
is not provisioned to handle such DetNet traffic has to provisioned to handle such traffic has to be treated
be treated as a fault and prevented. PRF-generated DetNet
as a fault and prevented. PRF generated DetNet member f member flows also need to be treated as not using
lows also transport-layer congestion control even if the
need to be treated as not using transport layer congest original App-flow supports transport-layer
ion control congestion control because PREOF can remove
even if the original App-flow supports transport layer congestion indications at the PEF and thereby hide
congestion such indications (e.g., drops, ECN markings,
control because PREOF can remove congestion indications increased latency) from end systems.
at the PEF
and thereby hide such indications (e.g., drops, ECN mar
kings,
increased latency) from end systems.
</t><t>
The mechanisms to support these requirements are both data plane
and implementation specific. Data plane specific solut
ions will
be specified in the relevant data plane solution docume
nt. There
also exist techniques, at present and/or in various sta
ges of
standardization, that can support these fault mitigation tasks tha
t deliver a high probability that misbehaving
systems will have zero impact on well-behaved DetNet flows, except
of course, for
the receiving interface(s) immediately downstream of the misbehavi
ng device.
Examples of such techniques include traffic policing and shaping f
unctions (e.g.,
<xref target="RFC2475"/>) and separating flows into per-flow rate-
limited queues,
and potentially apply active queue management <xref tar
get="RFC7567"/>.
</t> </t>
<t pn="section-3.3.2-4"> The mechanisms to support these requirements
are both Data
Plane and implementation specific. Solutions that are data-plane
specific will be specified in the relevant data-plane solution
document. There also exist techniques, at present and/or in various
stages of standardization, that can support these fault-mitigation
tasks that deliver a high probability that misbehaving systems will
have zero impact on well-behaved DetNet flows with the exception, of
course, of the receiving interface(s) immediately downstream from
the misbehaving device. Examples of such techniques include traffic
policing and shaping functions (e.g., those described in <xref target=
"RFC2475" format="default" sectionFormat="of" derivedContent="RFC2475"/>),
separating flows into per-flow rate-limited queues, and potentially
applying active queue management <xref target="RFC7567" format="defaul
t" sectionFormat="of" derivedContent="RFC7567"/>.
</t>
</section>
</section> </section>
</section>
</section> </section>
<section anchor="arch" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="arch" title="DetNet Architecture"> "section-4">
<section anchor="Stacks" title="DetNet stack model"> <name slugifiedName="name-detnet-architecture">DetNet Architecture</name>
<t> <section anchor="Stacks" numbered="true" toc="include" removeInRFC="false"
DetNet functionality (<xref target="ProvidingQoS"/>) is impleme pn="section-4.1">
nted <name slugifiedName="name-detnet-stack-model">DetNet Stack Model</name>
<t pn="section-4.1-1">
DetNet functionality (<xref target="ProvidingQoS" format="defau
lt" sectionFormat="of" derivedContent="Section 3"/>) is implemented
in two adjacent sub-layers in the protocol stack: the DetNet se rvice in two adjacent sub-layers in the protocol stack: the DetNet se rvice
sub-layer and the DetNet forwarding sub-layer. The DetNet servi ce sub-layer sub-layer and the DetNet forwarding sub-layer. The DetNet servi ce sub-layer
provides DetNet service, e.g., service protection, to higher l ayers provides DetNet service, e.g., service protection, to higher l ayers
in the protocol stack and applications. The DetNet forwarding s ub-layer in the protocol stack and applications. The DetNet forwarding s ub-layer
supports DetNet service in the underlying network, e.g., by supports DetNet service in the underlying network, e.g., by
providing explicit routes and resource allocation to DetNet flo ws. providing explicit routes and resource allocation to DetNet flo ws.
</t> </t>
<section anchor="StackModel" title="Representative Protocol Stack Model" <section anchor="StackModel" numbered="true" toc="include" removeInRFC="
> false" pn="section-4.1.1">
<t> <name slugifiedName="name-representative-protocol-sta">Representative
<xref target="ProtStack1"/> illustrates a conceptual DetNet data Protocol Stack Model</name>
plane layering model. <t pn="section-4.1.1-1"><xref target="ProtStack1" format="default" sec
One may compare it to that in <xref target="IEEE802.1CB"/>, Anne tionFormat="of" derivedContent="Figure 2"/> illustrates a conceptual DetNet data
x C. -plane layering model.
</t> One may compare it to that in <xref target="IEEE802.1CB" format=
<figure align="center" anchor="ProtStack1" "default" sectionFormat="of" derivedContent="IEEE802.1CB"/>, Annex C.
title="DetNet data plane protocol stack"> </t>
<artwork align="center"><![CDATA[ <figure anchor="ProtStack1" align="left" suppress-title="false" pn="fi
gure-2">
<name slugifiedName="name-detnet-data-plane-protocol-">DetNet Data-P
lane Protocol Stack</name>
<artwork align="center" name="" type="" alt="" pn="section-4.1.1-2.1
">
| packets going | ^ packets coming ^ | packets going | ^ packets coming ^
v down the stack v | up the stack | v down the stack v | up the stack |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Source | | Destination | | Source | | Destination |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Service sub-layer: | | Service sub-layer: | | Service sub-layer: | | Service sub-layer: |
| Packet sequencing | | Duplicate elimination | | Packet sequencing | | Duplicate elimination |
| Flow replication | | Flow merging | | Flow replication | | Flow merging |
| Packet encoding | | Packet decoding | | Packet encoding | | Packet decoding |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Forwarding sub-layer: | | Forwarding sub-layer: | | Forwarding sub-layer: | | Forwarding sub-layer: |
| Resource allocation | | Resource allocation | | Resource allocation | | Resource allocation |
| Explicit routes | | Explicit routes | | Explicit routes | | Explicit routes |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| Lower layers | | Lower layers | | Lower layers | | Lower layers |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
v ^ v ^
\_________________________/ \_________________________/
]]></artwork> </artwork>
</figure> </figure>
<t> <t pn="section-4.1.1-3">
Not all sub-layers are required for any given application, or ev en for any Not all sub-layers are required for any given application, or ev en for any
given network. The functionality shown in <xref target="ProtStac given network. The functionality shown in <xref target="ProtStac
k1"/> is: k1" format="default" sectionFormat="of" derivedContent="Figure 2"/> is:
<list hangIndent="8" style="hanging"> </t>
<t hangText="Application"><vspace blankLines="0"/> <dl newline="true" spacing="normal" indent="3" pn="section-4.1.1-4">
<dt pn="section-4.1.1-4.1">Application</dt>
<dd pn="section-4.1.1-4.2">
Shown as "source" and "destination" in the diagram. Shown as "source" and "destination" in the diagram.
</t> </dd>
<t hangText="Packet sequencing"><vspace blankLines="0"/> <dt pn="section-4.1.1-4.3">Packet sequencing</dt>
As part of DetNet service protection, supplies the seque <dd pn="section-4.1.1-4.4">
nce number for As part of the DetNet service sub-layer, the packet
packet replication and elimination (<xref target="srvcpr sequencing function supplies the sequence number for
ot"/>), thus peers packet replication and elimination for DetNet service
with Duplicate elimination. This sub-layer is not neede protection (<xref target="Seamless" format="default" section
d if a higher layer protocol Format="of" derivedContent="Section 3.2.2.2"/>); thus, its peer is
is expected to perform any packet sequencing and duplica duplicate elimination. This sub-layer is not needed if a
te elimination higher-layer protocol is expected to perform any packet
required by the DetNet flow replication. sequencing and duplicate elimination required by the
</t> DetNet flow replication.
<t hangText="Duplicate elimination"><vspace blankLines="0"/> </dd>
As part of the DetNet service sub-layer, based on the se <dt pn="section-4.1.1-4.5">Duplicate elimination</dt>
quenced number <dd pn="section-4.1.1-4.6">
supplied by its peer, packet sequencing, As part of the DetNet service sub-layer, based on the se
Duplicate elimination discards any duplicate packets gen quence number
erated by DetNet supplied by its peer (packet sequencing),
duplicate elimination discards any duplicate packets gen
erated by DetNet
flow replication. It can operate on member flows, compo und flows, or both. flow replication. It can operate on member flows, compo und flows, or both.
The replication may also be inferred from other The replication may also be inferred from other
information such as the precise time of reception in a s cheduled network. information such as the precise time of reception in a s cheduled network.
The duplicate elimination sub-layer may also perform res equencing of packets The duplicate elimination sub-layer may also perform res equencing of packets
to restore packet order in a to restore packet order in a
flow that was disrupted by the loss of packets on one or another of flow that was disrupted by the loss of packets on one or another of
the multiple paths taken. the multiple paths taken.
</t> </dd>
<t hangText="Flow replication"><vspace blankLines="0"/> <dt pn="section-4.1.1-4.7">Flow replication</dt>
As part of DetNet service protection, packets that belon <dd pn="section-4.1.1-4.8"> As
g to a part of DetNet service protection, packets that belong to
DetNet compound flow are replicated into two or more Det a DetNet compound flow are replicated into two or more
Net member flows. DetNet member flows. This function is separate from
This function is separate from packet sequencing. Flow packet sequencing. Flow replication can be an explicit
replication replication and remarking of packets or can be performed
can be an explicit replication and remarking of packets, by, for example, techniques similar to ordinary multicast
or can be performed by, replication, albeit with resource allocation implications.
for example, techniques similar to ordinary multicast re Its peer is DetNet flow merging.
plication, albeit with </dd>
resource allocation implications. <dt pn="section-4.1.1-4.9">Flow merging</dt>
Peers with DetNet flow merging. <dd pn="section-4.1.1-4.10"> As
</t> part of the DetNet service sub-layer, the flow merging
<t hangText="Flow merging"><vspace blankLines="0"/> function combines DetNet member flows together for packets
As part of DetNet service protection, merges coming up the stack belonging to a specific DetNet
DetNet member flows together for packets coming up the s compound flow. DetNet flow merging, together with packet
tack belonging to a sequencing, duplicate elimination, and DetNet flow
specific DetNet compound flow. replication perform packet replication and elimination
Peers with DetNet flow replication. (<xref target="srvcprot" format="default" sectionFormat="of"
DetNet flow merging, together with packet sequencing, du derivedContent="Section 3.2.2"/>). Its peer is DetNet flow
plicate elimination, replication.
and DetNet flow replication perform </dd>
packet replication and elimination (<xref target="srvcpr <dt pn="section-4.1.1-4.11">Packet encoding</dt>
ot"/>). <dd pn="section-4.1.1-4.12"> As
</t> part of DetNet service protection, as an alternative to
<t hangText="Packet encoding"><vspace blankLines="0"/> packet sequencing and flow replication, packet encoding
As part of DetNet service protection, as an alternative combines the information in multiple DetNet packets,
to packet sequencing perhaps from different DetNet compound flows, and
and flow replication, packet encoding combines the infor transmits that information in packets on different DetNet
mation in member flows. Its peer is packet decoding.
multiple DetNet packets, perhaps from different DetNet c </dd>
ompound flows, and transmits that <dt pn="section-4.1.1-4.13">Packet decoding</dt>
information in packets on different DetNet member Flows. <dd pn="section-4.1.1-4.14"> As
Peers with Packet decoding. part of DetNet service protection, as an alternative to
</t> flow merging and duplicate elimination, packet decoding
<t hangText="Packet decoding"><vspace blankLines="0"/> takes packets from different DetNet member flows and
As part of DetNet service protection, as an alternative computes from those packets the original DetNet packets
to flow merging and from the compound flows input to packet encoding. Its
duplicate elimination, packet decoding takes packets fro peer is packet encoding.
m different DetNet member </dd>
flows, and computes from those packets the original DetN <dt pn="section-4.1.1-4.15">Resource allocation</dt>
et packets from the <dd pn="section-4.1.1-4.16">
compound flows input to packet encoding. Peers with Pac The DetNet forwarding sub-layer provides resource
ket encoding. allocation. See <xref target="QueuingModels" format="default
</t> " sectionFormat="of" derivedContent="Section 4.5"/>. The
<t hangText="Resource allocation"><vspace blankLines="0"/> actual queuing and shaping mechanisms are typically
The DetNet forwarding sub-layer provides resource alloca provided by the underlying subnet. These can be closely
tion. See <xref target="QueuingModels"/>. associated with the means of providing paths for DetNet
The actual queuing and shaping mechanisms are typically flows. The path and the resource allocation are conflated
provided by underlying subnet. in this figure.
These can be closely associated with the means of provid </dd>
ing paths <dt pn="section-4.1.1-4.17">Explicit routes</dt>
for DetNet flows. <dd pn="section-4.1.1-4.18">
The path and the resource allocation are conflated in th Explicit routes are arrangements of fixed paths operated at
is figure. the DetNet forwarding sub-layer that are determined in advance
</t> to avoid the impact of network convergence on DetNet flows.
<t hangText="Explicit routes"><vspace bla </dd>
nkLines="0"/> </dl>
The DetNet forwarding sub-layer provides mechanisms to e <t pn="section-4.1.1-5">
nsure that fixed paths are provided Operations, Administration, and Maintenance (OAM) leverages
for DetNet flows. These explicit paths avoid the impact in-band and out-of-band signaling that validates whether the
of network convergence. service is effectively obtained within QoS constraints. OAM is
</t> not shown in <xref target="ProtStack1" format="default" sectionForma
t="of" derivedContent="Figure 2"/>; it may reside in any
</list> number of the layers. OAM can involve specific tagging added in
</t> the packets for tracing implementation or network configuration
<t> errors; traceability enables finding whether a packet is a
Operations, Administration, and Maintenance (OAM) leverages in-band replica, which DetNet relay node performed the replication, and
and which segment was intended for the replica. Active and hybrid OAM
out-of-band signaling that validates whether the service methods require additional bandwidth to perform fault management
is effectively and performance monitoring of the DetNet domain. OAM may, for
obtained within QoS constraints. OAM is not shown in instance, generate special test probes or add OAM information into
<xref target="ProtStack1"/>; it may reside in any number the data packet.
of the layers. </t>
OAM can involve specific tagging added in the packets for <t pn="section-4.1.1-6">
tracing implementation The packet replication and elimination functions may be
or network configuration errors; traceability enables to performed either at the source and destination ends of a
find whether a DetNet compound flow or in a DetNet relay node.
packet is a replica, which DetNet relay node performed th </t>
e replication, and which
segment was intended for the replica. Active and hybrid O
AM methods require
additional bandwidth to perform fault management and perf
ormance monitoring
of the DetNet domain. OAM may, for instance, generate spe
cial test probes or
add OAM information into the data packet.
</t>
<t>
The packet sequencing and replication elimination functions at t
he
source and destination ends of a DetNet compound flow may be per
formed either
in the end system or in a DetNet relay node.
</t>
</section> </section>
<section title="DetNet Data Plane Overview" anchor="sec_dt_dp"> <section anchor="sec_dt_dp" numbered="true" toc="include" removeInRFC="f
<t> alse" pn="section-4.1.2">
A "Deterministic Network" will be composed of DetNet enabled end <name slugifiedName="name-detnet-data-plane-overview">DetNet Data-Plan
systems, DetNet edge nodes, and DetNet relay nodes, which collective e Overview</name>
ly deliver DetNet <t pn="section-4.1.2-1">
services. DetNet relay and edge nodes are interconnected via DetNet A "Deterministic Network" will be composed of DetNet-enabled end
transit nodes systems, DetNet edge nodes, and DetNet relay nodes, which
(e.g., LSRs) which support DetNet, but are not DetNet service collectively deliver DetNet services. DetNet relay and edge nodes
aware. All DetNet nodes are connected to are interconnected via DetNet transit nodes (e.g., LSRs), which
sub-networks, where a point-to-point link is also considered as a support DetNet but are not DetNet service aware. All DetNet nodes
simple sub-network. These are connected to sub-networks, where a point-to-point link is also
sub-networks will provide DetNet compatible service for support of D considered a simple sub-network. These sub-networks provide
etNet DetNet-compatible service for support of DetNet traffic. Examples
traffic. Examples of sub-network technologies include MPLS TE, IEEE of sub-network technologies include MPLS TE, TSN as defined by
802.1 TSN and IEEE 802.1, and OTN (Optical Transport Network). Of course,
OTN. Of course, multi-layer DetNet systems may also be possible, wh multilayer DetNet systems may also be possible, where one DetNet
ere appears as a sub-network and provides service to a higher-layer
one DetNet appears as a sub-network, and provides service to, a high DetNet system. A simple DetNet concept network is shown in <xref tar
er layer get="fig_detnet" format="default" sectionFormat="of" derivedContent="Figure 3"/>
DetNet system. A simple DetNet concept network is shown in <xref tar .
get="fig_detnet"/>.
Note that in this and following figures "Forwarding" and Note that in this and following figures, "Forwarding" and "Fwd" refer to the
"Fwd" refer to the DetNet DetNet forwarding sub-layer, and "Service" and "Svc" refer to the DetNet
forwarding sub-layer, "Service" and "Svc" refer to the De service sub-layer; both of these sub-layers are described in detail in <xref tar
tNet service sub-layer, get="StackModel" format="default" sectionFormat="of" derivedContent="Section 4.1
which are described in detail in <xref target="Stacks"/>. .1"/>.
</t> </t>
<figure anchor="fig_detnet" align="center" <figure anchor="fig_detnet" align="left" suppress-title="false" pn="fi
title="A Simple DetNet Enabled Network"> gure-3">
<artwork align="center"><![CDATA[ <name slugifiedName="name-a-simple-detnet-enabled-net">A Simple DetN
et-Enabled Network</name>
<artwork align="center" name="" type="" alt="" pn="section-4.1.2-2.1
">
TSN Edge Transit Relay DetNet TSN Edge Transit Relay DetNet
End System Node Node Node End System End System Node Node Node End System
+----------+ +.........+ +----------+ +----------+ +.........+ +----------+
| Appl. |<--:Svc Proxy:-- End to End Service --------&gt;| Appl. | | Appl. |<--:Svc Proxy:-- End-to-End Service --------&gt;| Appl. |
+----------+ +---------+ +---------+ +----------+ +----------+ +---------+ +---------+ +----------+
| TSN | |TSN| |Svc|<- DetNet flow --: Service :--&gt;| Service | | TSN | |TSN| |Svc|<- DetNet flow --: Service :--&gt;| Service |
+----------+ +---+ +---+ +--------+ +---------+ +----------+ +----------+ +---+ +---+ +--------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| |Forwarding| |Forwarding| |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +--.----.+ +-.-+ +-.-+ +---.------+ +-------.--+ +-.-+ +-.-+ +--.----.+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \ : Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +.......+ +-[ Sub ]-+ +........+ +-[ Sub- ]-+ +.......+ +-[ Sub- ]-+
[Network] [Network] [network] [network]
`-----' `-----' `-----' `-----'
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.1.2-3">
<t> DetNet Data Plane is divided into two sub-layers: the DetNet
DetNet data plane is divided into two sub-layers: the DetNet service sub-layer and the DetNet forwarding sub-layer. This helps
service sub-layer and the DetNet forwarding sub-layer. Th to explore and evaluate various combinations of the data-plane
is solutions available. Some of them are illustrated in <xref target="f
helps to explore and evaluate various combinations of the ig_adaptation" format="default" sectionFormat="of" derivedContent="Figure 4"/>.
data This separation of DetNet sub-layers,
plane solutions available. Some of them are illustrated i while helpful, should not be considered a formal requirement.
n For example, some technologies may violate these strict sub-layers
<xref target="fig_adaptation"/>. This separation of DetN and still be able to deliver a DetNet service.
et
sub-layers, while helpful, should not be considered as fo
rmal
requirement. For example, some technologies may violate
these
strict sub-layers and still be able to deliver a DetNet s
ervice.
</t> </t>
<figure anchor="fig_adaptation" align="left" suppress-title="false" pn
<figure anchor="fig_adaptation" align="center" ="figure-4">
title="DetNet adaptation to data plane"> <name slugifiedName="name-detnet-adaptation-to-data-p">DetNet Adapta
<artwork align="center"><![CDATA[ tion to Data Plane</name>
<artwork align="center" name="" type="" alt="" pn="section-4.1.2-4.1
">
. .
. .
+-----------------------------+ +-----------------------------+
| DetNet Service sub-layer | PW, UDP, GRE | DetNet Service sub-layer | PW, UDP, GRE
+-----------------------------+ +-----------------------------+
| DetNet Forwarding sub-layer | IPv6, IPv4, MPLS TE LSPs, MPLS SR | DetNet Forwarding sub-layer | IPv6, IPv4, MPLS TE LSPs, MPLS SR
+-----------------------------+ +-----------------------------+
. .
. .
]]></artwork> </artwork>
</figure> </figure>
<t> <t pn="section-4.1.2-5">
In some networking scenarios, the end system initially provides a De In some networking scenarios, the end system initially provides a
tNet DetNet flow encapsulation, which contains all information needed
flow encapsulation, which contains all information needed by DetNet by DetNet nodes (e.g., DetNet flow based on the Real-time Transport
nodes Protocol (RTP) <xref target="RFC3550" format="default" sectionFormat
(e.g., Real-time Transport Protocol (RTP) <xref target="RFC3550"/> b ="of" derivedContent="RFC3550"/> that is carried over a
ased native UDP/IP network or pseudowire (PW)). In other scenarios, the
DetNet flow carried over a native UDP/IP network or PseudoWire). In encapsulation formats might differ significantly.
other scenarios, the encapsulation formats might differ significantl
y.
</t> </t>
<t> <t pn="section-4.1.2-6">
There are many valid options to create a data plane solution for Det There are many valid options to create a data-plane solution for Det
Net Net
traffic by selecting a technology approach for the DetNet service su b-layer and traffic by selecting a technology approach for the DetNet service su b-layer and
also selecting a technology approach for the DetNet forwarding sub-l ayer. There are also selecting a technology approach for the DetNet forwarding sub-l ayer. There are
a large number of valid combinations. a large number of valid combinations.
</t> </t>
<t> <t pn="section-4.1.2-7">
One of the most fundamental differences between different potential One of the most fundamental differences between different
data plane options is the basic headers used by DetNet potential data-plane options is the basic headers used by DetNet
nodes. For example, the basic service can be delivered based on an nodes. For example, the basic service can be delivered based on
MPLS label an MPLS label or an IP header. This decision impacts the basic
or an IP header. This decision impacts the basic forwardi forwarding logic for the DetNet service sub-layer. Note that in
ng logic for the DetNet both cases, IP addresses are used to address DetNet nodes. The
service sub-layer. Note that in both cases, IP addresses selected DetNet forwarding sub-layer technology also needs to be
are used to address DetNet nodes. mapped to the subnet technology used to interconnect DetNet
The selected DetNet forwarding sub-layer technology also needs to nodes. For example, DetNet flows will need to be mapped to TSN
be mapped to the sub-net Streams.
technology used to interconnect DetNet nodes. For example
, DetNet flows will need to
be mapped to TSN Streams.
</t> </t>
</section> </section>
<section anchor="netref" title="Network reference model"> <section anchor="netref" numbered="true" toc="include" removeInRFC="fals
e" pn="section-4.1.3">
<t> <xref target="fig_DetNetservice"/> shows another view of the <name slugifiedName="name-network-reference-model">Network Reference M
DetNet service related reference points and main componen odel</name>
ts. <t pn="section-4.1.3-1"><xref target="fig_DetNetservice" format="defau
</t> lt" sectionFormat="of" derivedContent="Figure 5"/> shows another view of the
DetNet service-related reference points and main componen
<figure anchor="fig_DetNetservice" align="center" ts.
title="DetNet Service Reference Model (multi-domain)"> </t>
<artwork><![CDATA[ <figure anchor="fig_DetNetservice" align="left" suppress-title="false"
pn="figure-5">
<name slugifiedName="name-detnet-service-reference-mo">DetNet Servic
e Reference Model (Multidomain)</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1.3-2.1">
DetNet DetNet DetNet DetNet
end system end system End System End System
_ _ _ _
/ \ +----DetNet-UNI (U) / \ / \ +----DetNet-UNI (U) / \
/App\ | /App\ /App\ | /App\
/-----\ | /-----\ /-----\ | /-----\
| NIC | v ________ | NIC | | NIC | v ________ | NIC |
+--+--+ _____ / \ DetNet-UNI (U) --+ +--+--+ +--+--+ _____ / \ DetNet-UNI (U) --+ +--+--+
| / \__/ \ | | | / \__/ \ | |
| / +----+ +----+ \_____ | | | / +----+ +----+ \_____ | |
| / | | | | \_______ | | | / | | | | \_______ | |
+------U PE +----+ P +----+ \ _ v | +------U PE +----+ P +----+ \ _ v |
| | | | | | | ___/ \ | | | | | | | | ___/ \ |
| +--+-+ +----+ | +----+ | / \_ | | +--+-+ +----+ | +----+ | / \_ |
\ | | | | | / \ | \ | | | | | / \ |
\ | +----+ +--+-+ +--+PE |------ U-----+ \ | +----+ +--+-+ +--+PE |------ U-----+
\ | | | | | | | | | \_ _/ \ | | | | | | | | | \_ _/
\ +---+ P +----+ P +--+ +----+ | \____/ \ +---+ P +----+ P +--+ +----+ | \____/
\___ | | | | / \___ | | | | /
\ +----+__ +----+ DetNet-1 DetNet-2 \ +----+__ +----+ DetNet-1 DetNet-2
| \_____/ \___________/ | | \_____/ \___________/ |
| | | |
| | End-to-End service | | | | | | End-to-End Service | | | |
<-------------------------------------------------------------> &lt;-------------------------------------------------------------&gt;
| | DetNet service | | | | | | DetNet Service | | | |
| <------------------------------------------------> | | &lt;------------------------------------------------&gt; |
| | | | | | | | | | | |
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.1.3-3">DetNet User-to-Network Interfaces (DetNet-UNIs
<t>DetNet User Network Interfaces (DetNet-UNIs) ("U" in <xref target ) ("U" in <xref target="fig_DetNetservice" format="default" sectionFormat="of" d
="fig_DetNetservice"/>) are assumed in this document to be packet-based referenc erivedContent="Figure 5"/>) are assumed in this document to be
e points and provide connectivity over the packet network. A DetNet-UNI may prov packet-based reference points and provide connectivity over the
ide multiple functions, e.g., it may add networking technology specific encapsul packet network. A DetNet-UNI may provide multiple functions. For
ation to the DetNet flows if necessary; it may provide status of the availabilit example, it may:
y of the resources associated with a reservation; it may provide a synchronizati </t>
on service for the end system; it may carry enough signaling to place the reserv <ul spacing="normal" bare="false" empty="false" pn="section-4.1.3-4">
ation in a network without a controller, or if the controller only deals with th <li pn="section-4.1.3-4.1">add encapsulation specific to networking
e network but not the end systems. Internal reference points of end systems (bet technology to the DetNet flows if necessary,
ween the application and the NIC) are more challenging from control perspective </li>
and they may have extra requirements (e.g., in-order delivery is expected in end <li pn="section-4.1.3-4.2">provide status of the availability of the
system internal reference points, whereas it is considered optional over the De resources associated with a reservation,
tNet-UNI).</t> </li>
<li pn="section-4.1.3-4.3">provide a synchronization service for the
end system, or
</li>
<li pn="section-4.1.3-4.4">carry enough signaling to place the reser
vation in a network without a
controller or in a network where the controller only deals with the network
but not the end systems.
</li>
</ul>
<t pn="section-4.1.3-5">
Internal reference points of end systems (between the application
and the Network Interface Card (NIC)) are more challenging from the
control perspective, and they may have extra requirements (e.g.,
in-order delivery is expected in end system internal reference
points, whereas it is considered optional over the DetNet-UNI).</t>
</section> </section>
</section> </section>
<section anchor="netrefsys" title="DetNet systems"> <section anchor="netrefsys" numbered="true" toc="include" removeInRFC="fal
<section anchor="es" title="End system"> se" pn="section-4.2">
<t> <name slugifiedName="name-detnet-systems">DetNet Systems</name>
The traffic characteristics of an App-flow can be CBR (constant b <section anchor="es" numbered="true" toc="include" removeInRFC="false" p
it rate) or VBR (variable bit rate) and can have Layer-1 or Layer-2 or Layer-3 e n="section-4.2.1">
ncapsulation (e.g., TDM (time-division multiplexing), Ethernet, IP). These chara <name slugifiedName="name-end-system">End System</name>
cteristics are considered as input for resource reservation and might be simplif <t pn="section-4.2.1-1">
ied to ensure determinism during packet forwarding (e.g., making reservations fo The traffic characteristics of an App-flow can be CBR
r the peak rate of VBR traffic, etc.). (constant bit rate) or VBR (variable bit rate) and can have
</t> Layer 1, Layer 2, or Layer 3 encapsulation (e.g., TDM
(time-division multiplexing) Ethernet, IP). These
<t> characteristics are considered as input for resource
An end system may or may not be DetNet forwarding sub-layer aware reservation and might be simplified to ensure determinism
or DetNet service sub-layer aware. That is, an end system may or may not contai during packet forwarding (e.g., making reservations for the
n DetNet specific functionality. End systems with DetNet functionalities may hav peak rate of VBR traffic, etc.).
e the same or different forwarding sub-layer as the connected DetNet domain. Cat </t>
egorization of end systems are shown in <xref target="fig_endsys2"/>. <t pn="section-4.2.1-2">
</t> An end system may or may not be aware of the DetNet forwarding su
b-layer
<figure anchor="fig_endsys2" align="center" or DetNet service sub-layer. That is, an end
title="Categorization of end systems"> system may or may not contain DetNet-specific
<artwork><![CDATA[ functionality. End systems with DetNet functionalities may
have the same or different forwarding sub-layer as the
connected DetNet domain. Categorization of end systems are
shown in <xref target="fig_endsys2" format="default" sectionForma
t="of" derivedContent="Figure 6"/>.
</t>
<figure anchor="fig_endsys2" align="left" suppress-title="false" pn="f
igure-6">
<name slugifiedName="name-categorization-of-end-syste">Categorizatio
n of End Systems</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2.1-3.1">
End system End system
| |
| |
| DetNet aware ? | DetNet aware ?
/ \ / \
+------< &gt;------+ +------< &gt;------+
NO | \ / | YES NO | \ / | YES
| v | | v |
DetNet unaware | DetNet-unaware |
End system | End system |
| Service/Forwarding | Service/Forwarding
| sub-layer | sub-layer
/ \ aware ? / \ aware ?
+--------< &gt;-------------+ +--------< &gt;-------------+
f-aware | \ / | s-aware f-aware | \ / | s-aware
| v | | v |
| | both | | | both |
| | | | | |
DetNet f-aware | DetNet s-aware DetNet f-aware | DetNet s-aware
End system | End system End system | End system
v v
DetNet sf-aware DetNet sf-aware
End system End system
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.2.1-4">
<t> The following are some known use case examples for end systems:
Note some known use case examples for end systems: </t>
<list style="symbols"> <dl spacing="normal" newline="true" indent="3" pn="section-4.2.1-5">
<t> DetNet unaware: The classic case requiring service pr <dt pn="section-4.2.1-5.1">DetNet unaware</dt>
oxies.</t> <dd pn="section-4.2.1-5.2"> The classic case requiring service proxi
<t> DetNet f-aware: A DetNet forwarding sub-layer aware s es.</dd>
ystem. It knows about some TSN functions (e.g., reservation), but not about serv <dt pn="section-4.2.1-5.3">DetNet f-aware</dt>
ice protection. </t> <dd pn="section-4.2.1-5.4">A system that is aware of the DetNet forw
<t> DetNet s-aware: A DetNet service sub-layer aware syst arding
em. It supplies sequence numbers, but doesn't know about resource allocation. </ sub-layer. It knows about some TSN
t> functions (e.g., reservation) but not about service
<t> DetNet sf-aware: A full functioning DetNet end system protection. </dd>
, it has DetNet functionalities and usually the same forwarding paradigm as the <dt pn="section-4.2.1-5.5">DetNet s-aware</dt>
connected DetNet domain. It can be treated as an integral part of the DetNet dom <dd pn="section-4.2.1-5.6"> A system that is aware of the DetNet ser
ain. </t> vice
</list> sub-layer. It supplies sequence numbers but
</t> doesn't know about resource allocation. </dd>
</section> <dt pn="section-4.2.1-5.7">DetNet sf-aware</dt>
<section anchor="ertn" title="DetNet edge, relay, and transit nodes"> <dd pn="section-4.2.1-5.8">A fully functioning DetNet end
<t> system. It has DetNet functionalities and usually the
As shown in <xref target="fig_detnet"/>, DetNet edge nodes providing same forwarding paradigm as the connected DetNet
proxy domain. It can be treated as an integral part of the
service and DetNet relay nodes providing the DetNet service sub-laye DetNet domain. </dd>
r are </dl>
DetNet-aware, and DetNet transit nodes need only be aware of the Det </section>
Net <section anchor="ertn" numbered="true" toc="include" removeInRFC="false"
forwarding sub-layer. pn="section-4.2.2">
</t><t> <name slugifiedName="name-detnet-edge-relay-and-trans">DetNet Edge, Re
In general, if a DetNet flow passes through one or more DetNet-unawa lay, and Transit Nodes</name>
re <t pn="section-4.2.2-1">
network nodes between two DetNet nodes providing the DetNet forwardi As shown in <xref target="fig_detnet" format="default" sectionFormat
ng sub-layer ="of" derivedContent="Figure 3"/>, DetNet edge nodes
for that flow, there is a potential for disruption or failure of the providing proxy service and DetNet relay nodes providing the
DetNet QoS. A network administrator needs to ensure that the DetNet DetNet service sub-layer are DetNet aware, and DetNet transit
-unaware nodes need only be aware of the DetNet forwarding sub-layer.
network nodes are configured to minimize the chances of packet loss </t>
and <t pn="section-4.2.2-2"> In general, if a DetNet flow passes through o
delay, and provision enough extra buffer space in the DetNet transit ne or more
node DetNet-unaware network nodes between two DetNet nodes providing
following the DetNet-unaware network nodes to absorb the induced lat the DetNet forwarding sub-layer for that flow, there is a
ency potential for disruption or failure of the DetNet QoS. A network
variations. administrator needs to 1) ensure that the DetNet-unaware network
nodes are configured to minimize the chances of packet loss and
delay and 2) provision enough extra buffer space in the DetNet
transit node following the DetNet-unaware network nodes to absorb
the induced latency variations.
</t> </t>
</section> </section>
</section> </section>
<section anchor="DetNetFlows" title="DetNet flows"> <section anchor="DetNetFlows" numbered="true" toc="include" removeInRFC="f
alse" pn="section-4.3">
<section anchor="DetNetFlowsTypes" title="DetNet flow types"> <name slugifiedName="name-detnet-flows">DetNet Flows</name>
<t> <section anchor="DetNetFlowsTypes" numbered="true" toc="include" removeI
A DetNet flow can have different formats while its p nRFC="false" pn="section-4.3.1">
ackets are <name slugifiedName="name-detnet-flow-types">DetNet Flow Types</name>
forwarded between the peer end systems depending <t pn="section-4.3.1-1">
on the type A DetNet flow can have different formats while its packets are forwarded
of the end systems. Corresponding to the end sys between the peer end systems depending on the type of the end
tem types, systems. Corresponding to the end system types, the following possible
the following possible types / formats of a DetN types/formats of a DetNet flow are distinguished in this document. The
et flow are different flow types have different requirements to DetNet nodes.
distinguished in this document. The different fl </t>
ow types have <dl spacing="normal" newline="true" indent="3" pn="section-4.3.1-2">
different requirements to DetNet nodes. <dt pn="section-4.3.1-2.1">App-flow</dt>
<list style="symbols"> <dd pn="section-4.3.1-2.2">The payload (data) carried over a DetNet
<t> App-flow: the payload (data) carried over a DetNet flow flow between DetNet-unaware end systems. An App-flow does
between DetNet unaware end systems. An not contain any DetNet-related attributes and does not
app-flow does not imply any specific requirement on DetNet nodes.</dd>
contain any DetNet related attributes a <dt pn="section-4.3.1-2.3">DetNet-f-flow</dt>
nd does not imply any <dd pn="section-4.3.1-2.4">The specific format of a DetNet flow. It
specific requirement on DetNet nodes.</ only requires the resource allocation features provided by
t> the DetNet forwarding sub-layer. </dd>
<t> DetNet-f-flow: specific format of a DetNet flow. It only <dt pn="section-4.3.1-2.5">DetNet-s-flow</dt>
requires the resource allocation features provided by the DetNet forwarding sub <dd pn="section-4.3.1-2.6">The specific format of a DetNet flow. It
-layer. </t> only requires the service protection feature ensured by
<t> DetNet-s-flow: specific format of a DetNet flow. It onl the DetNet service sub-layer. </dd>
y requires the service protection feature ensured by the DetNet service sub-laye <dt pn="section-4.3.1-2.7"> DetNet-sf-flow</dt>
r. </t> <dd pn="section-4.3.1-2.8">The specific format of a DetNet
<t> DetNet-sf-flow: specific format of a DetNet flow. It re flow. It requires both the DetNet service sub-layer and
quires both DetNet service the DetNet forwarding sub-layer functions during
sub-layer and DetNet forwarding sub-layer functions du forwarding. </dd>
ring forwarding. </t> </dl>
</list> </section>
</t> <section anchor="FlowLimits" numbered="true" toc="include" removeInRFC="
</section> false" pn="section-4.3.2">
<name slugifiedName="name-source-transmission-behavio">Source Transmis
<section anchor="FlowLimits" title="Source transmission behavior"> sion Behavior</name>
<t> <t pn="section-4.3.2-1">
For the purposes of resource allocation, For the purposes of resource allocation,
DetNet flows can be synchronous or asynchronous. DetNet flows can be synchronous or asynchronous.
In synchronous DetNet flows, at least the DetNet nodes (and po ssibly In synchronous DetNet flows, at least the DetNet nodes (and po ssibly
the end systems) are closely time the end systems) are closely time
synchronized, typically to better than 1 microsecond. By tran smitting synchronized, typically to better than 1 microsecond. By tran smitting
packets from different DetNet flows or classes of DetNet flows at different times, packets from different DetNet flows or classes of DetNet flows at different times,
using repeating schedules synchronized among the DetNet nodes, resources using repeating schedules synchronized among the DetNet nodes, resources
such as buffers and link bandwidth can be shared over the time domain such as buffers and link bandwidth can be shared over the time domain
among different DetNet flows. There is a tradeoff among techn iques for among different DetNet flows. There is a trade-off among tech niques for
synchronous DetNet flows between the burden of fine-grained sc heduling and the synchronous DetNet flows between the burden of fine-grained sc heduling and the
benefit of reducing the required resources, especially buffer space. benefit of reducing the required resources, especially buffer space.
</t><t> </t>
<t pn="section-4.3.2-2">
In contrast, asynchronous DetNet flows are not coordinated wit h a fine-grained In contrast, asynchronous DetNet flows are not coordinated wit h a fine-grained
schedule, so relay and end systems must assume worst-case inte rference schedule, so relay and end systems must assume worst-case inte rference
among DetNet flows contending for buffer resources. among DetNet flows contending for buffer resources.
Asynchronous DetNet flows are characterized by: Asynchronous DetNet flows are characterized by:
<list style="symbols"> </t>
<t> <ul spacing="normal" bare="false" empty="false" pn="section-4.3.2-3">
<li pn="section-4.3.2-3.1">
A maximum packet size; A maximum packet size;
</t><t> </li>
<li pn="section-4.3.2-3.2">
An observation interval; and An observation interval; and
</t><t> </li>
<li pn="section-4.3.2-3.3">
A maximum number of transmissions during that observat ion interval. A maximum number of transmissions during that observat ion interval.
</t> </li>
</list> </ul>
</t><t> <t pn="section-4.3.2-4"> These parameters, together with knowledge of
These parameters, together with knowledge of the protocol stac the
k used (and thus the protocol stack used (and thus the size of the various headers
size of the various headers added to a packet), provide the ba added to a packet), provide the bandwidth that is needed for the
ndwidth that is needed for the DetNet flow. DetNet flow. </t>
</t><t> <t pn="section-4.3.2-5"> The source is required not to exceed these
The source is required not to exceed these limits in order to limits in order to obtain DetNet service. If the source
obtain DetNet service. If the source transmits less data than this limit allows, then the unused resour
transmits less data than this limit allows, the unused resourc ce,
e such as link such as link bandwidth, can be made available by the DetNet
bandwidth can be made available by the DetNet system to non-De system to non-DetNet packets as long as all guarantees are
tNet packets as long as all guarantees are fulfilled. However, fulfilled. However, making those resources available to DetNet
making those resources available to DetNet packets in other De packets in other DetNet flows would serve no purpose. Those
tNet flows would serve other DetNet flows have their own dedicated resources, on the
no purpose. Those other DetNet flows have their own dedicated assumption that all DetNet flows can use all of their resources
resources, on the over a long period of time.
assumption that all DetNet flows can use all of their resource
s over a long
period of time.
</t><t> </t>
There is no expectation in DetNet for App-flows to be responsi <t pn="section-4.3.2-6">
ve to congestion control <xref target="RFC2914"/> or explicit congestion notific There is no expectation in DetNet for App-flows to be responsive to
ation <xref target="RFC3168"/>. The assumption congestion control <xref target="RFC2914" format="default" sectionFormat="o
is that a DetNet flow, to be useful, must be delivered in its f" derivedContent="RFC2914"/> or explicit congestion
entirety. That notification <xref target="RFC3168" format="default" sectionFormat="of" der
is, while any useful application is written to expect a certai ivedContent="RFC3168"/>. The assumption is that a DetNet
n number of lost flow, to be useful, must be delivered in its entirety. That is, while
packets, the real-time applications of interest to DetNet dema any useful application is written to expect a certain number of lost
nd that the loss of packets, the real-time applications of interest to DetNet demand that the
data due to the network is a rare event. loss of data due to the network is a rare event. </t>
</t><t> <t pn="section-4.3.2-7"> Although DetNet strives to minimize the chang
Although DetNet strives to minimize the changes required of an es required of an
application to application to allow it to shift from a special-purpose digital network to an
allow it to shift from a special-purpose digital network to an Internet Protocol network, one fundamental shift in the behavior of network
Internet Protocol applications is impossible to avoid: the reservation of resources before the
network, one fundamental shift in application starts. In the first place, a network cannot deliver finite
the behavior of network applications is impossible to avoid: t latency and practically zero packet loss to an arbitrarily high offered load.
he reservation Secondly, achieving practically zero packet loss for DetNet flows means that
of resources before the application starts. DetNet nodes have to dedicate buffer resources to specific DetNet flows or to
In the first place, a network cannot deliver finite latency an classes of DetNet flows. The requirements of each reservation have to be
d practically zero translated into the parameters that control each DetNet system's queuing,
packet loss to an arbitrarily high offered load. Secondly, ac shaping, and scheduling functions, and they have to be delivered to the DetNet
hieving nodes and end
practically zero packet loss for DetNet flows systems. </t>
means that DetNet nodes have to dedicate buffer resources to s <t pn="section-4.3.2-8"> All nodes in a DetNet domain are expected to
pecific support the data behavior
DetNet flows or to classes of DetNet flows. The requirements required to deliver a particular DetNet service. If a node itself is not
of each reservation have to be DetNet service aware, the DetNet nodes that are adjacent to them must ensure
translated into the parameters that control each DetNet system that the node that is non-DetNet aware is provisioned to appropriately support
's the DetNet service. For example, a TSN node (as defined by IEEE 802.1) may be us
queuing, shaping, and scheduling functions and delivered to th ed to
e DetNet nodes and end systems. interconnect DetNet-aware nodes, and these DetNet nodes can map DetNet flows
</t><t> to 802.1 TSN flows. As another example, an MPLS-TE or MPLS-TP (Transport Profile
All nodes in a DetNet domain are expected to suppor ) domain may be used to
t the data interconnect DetNet-aware nodes, and these DetNet nodes can map DetNet flows
behavior required to deliver a particular DetNe to TE LSPs, which can provide the QoS requirements of the DetNet service.
t service. If </t>
a node itself is not DetNet service aware, the </section>
DetNet nodes <section anchor="Incomplete" numbered="true" toc="include" removeInRFC="
that are adjacent to such non-DetNet aware node false" pn="section-4.3.3">
s must ensure <name slugifiedName="name-incomplete-networks">Incomplete Networks</na
that the non-DetNet aware node is provisioned t me>
o appropriately <t pn="section-4.3.3-1">
support the DetNet service. For example, an IEE The presence in the network of intermediate nodes or subnets
E 802.1 TSN that are not fully capable of offering DetNet services
node may be used to interconnect DetNet aware n complicates the ability of the intermediate nodes and/or
odes, and these controller to allocate resources, as extra buffering must be
DetNet nodes can map DetNet flows to 802.1 TSN allocated at points downstream from the non-DetNet
flows. Another intermediate node for a DetNet flow. This extra buffering
example, an MPLS-TE or TP domain may be used to may increase latency and/or jitter.
interconnect </t>
DetNet aware nodes, and these DetNet nodes can </section>
map DetNet
flows to TE LSPs which can provide the QoS requ
irements of the
DetNet service.
</t>
</section>
<section anchor="Incomplete" title="Incomplete Networks">
<t>
The presence in the network of intermediate nodes or subnets t
hat are not fully capable of offering
DetNet services complicates the ability of the intermediate no
des and/or controller to
allocate resources,
as extra buffering must be allocated at points
downstream from the non-DetNet intermediate node
for a DetNet flow. This extra buffering may inc
rease latency and/or jitter.
</t>
</section>
</section> </section>
<section anchor="te" title="Traffic Engineering for DetNet"> <section anchor="te" numbered="true" toc="include" removeInRFC="false" pn=
<t> "section-4.4">
<xref target="TEAS">Traffic Engineering Architecture and Signaling (TEA <name slugifiedName="name-traffic-engineering-for-det">Traffic Engineeri
S) ng for DetNet</name>
</xref> defines traffic-engineering architectures for generic applicabi <t pn="section-4.4-1"><xref target="TEAS" format="default" sectionFormat
lity ="of" derivedContent="TEAS">Traffic Engineering Architecture and Signaling (TEAS
across packet and non-packet networks. )
</xref> defines traffic-engineering architectures for generic applicab
ility
across packet and nonpacket networks.
From a TEAS perspective, Traffic Engineering (TE) refers to techniques From a TEAS perspective, Traffic Engineering (TE) refers to techniques
that enable operators to control how specific traffic flows are treated that enable operators to control how specific traffic flows are treated
within their networks. within their networks.
</t> </t>
<t> <t pn="section-4.4-2">
Because if its very nature of establishing explicit optimized paths, Because of its very nature of establishing explicit optimized paths,
Deterministic Networking can be seen as a new, specialized branch of DetNet can be seen as a new, specialized branch of
Traffic Engineering, and inherits its architecture with a separation TE, and it inherits its architecture with a separation
into planes. into planes.
</t><t> </t>
The Deterministic Networking architecture is thus composed <t pn="section-4.4-3">
of three planes, a (User) Application Plane, a Controller Plane, and a The DetNet architecture is thus composed of three planes: a (User)
Network Plane, which echoes that of Figure 1 of Application Plane, a Controller Plane, and a Network Plane. This
<xref target="RFC7426"> Software-Defined Networking (SDN): echoes the composition of Figure 1 of <xref target="RFC7426" format="de
Layers and Architecture Terminology</xref>, and the Controllers fault" sectionFormat="of" derivedContent="RFC7426">"Software-Defined Networking
identified in <xref target="RFC8453"/> and <xref target="RFC7149 (SDN): Layers and
"/>. Architecture Terminology"</xref> and the controllers identified in
</t> <xref target="RFC8453" format="default" sectionFormat="of" derivedConte
nt="RFC8453"/> and <xref target="RFC7149" format="default" sectionFormat="of" de
<section anchor="appplane" title="The Application Plane"> rivedContent="RFC7149"/>.
<t> </t>
Per <xref target="RFC7426"/>, <section anchor="appplane" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-4.4.1">
<name slugifiedName="name-the-application-plane">The Application Plane
</name>
<t pn="section-4.4.1-1">
Per <xref target="RFC7426" format="default" sectionFormat="of" derivedC
ontent="RFC7426"/>,
the Application Plane includes both applications and services. In parti cular, the Application Plane includes both applications and services. In parti cular,
the Application Plane incorporates the User Agent, a specialized applic ation the Application Plane incorporates the User Agent, a specialized applic ation
that interacts with the end user / operator and performs requests for that interacts with the end user and operator and performs requests for
Deterministic Networking services via an abstract Flow Management Entit DetNet services via an abstract Flow Management Entity
y, (FME), which may or may not be collocated with (one of) the end systems
(FME) which may or may not be collocated with (one of) the end systems. .
</t> </t>
<t>At the Application Plane, a management interface enables the n <t pn="section-4.4.1-2">At the Application Plane, a management interfa
egotiation of flows between end ce enables
systems. An abstraction of the flow called a Traffic Spec the negotiation of flows between end systems. An abstraction
ification (TSpec) provides the of the flow called a Traffic Specification (TSpec) provides
representation. This abstraction is used to place a reser the representation. This abstraction is used to place a
vation over the (Northbound) Service reservation over the (Northbound) Service Interface and within
Interface and within the Application plane. the Application Plane. It is associated with an abstraction
It is associated with an abstraction of location, such as IP addresses of location, such as IP addresses and DNS names, to identify
and DNS the end systems and possibly specify DetNet nodes.
names, to identify the end systems and possibly specify D </t>
etNet nodes. </section>
</t> <section anchor="ctrlplane" numbered="true" toc="include" removeInRFC="f
</section> alse" pn="section-4.4.2">
<section anchor="ctrlplane" title="The Controller Plane"> <name slugifiedName="name-the-controller-plane">The Controller Plane</
<t> name>
The Controller Plane corresponds to the aggregation of the Control and <t pn="section-4.4.2-1">
Management Planes in <xref target="RFC7426"/>, though The Controller Plane corresponds to the aggregation of the Control
Common Control and Measurement Plane (CCAMP) <xref target="CCAMP"/> and Management Planes in <xref target="RFC7426" format="default" sectio
makes an additional distinction between management and measurement. nFormat="of" derivedContent="RFC7426"/>, though Common
When the logical separation of the Control, Measurement and other Control and Measurement Plane (CCAMP) (as defined by the CCAMP
Management entities is not relevant, the term Controller Plane is used Working Group <xref target="CCAMP" format="default" sectionFormat="of" d
for simplicity to represent them all, and the term Controller Plane Fun erivedContent="CCAMP"/>) makes an
ction (CPF) refers to additional distinction between management and measurement. When the
any device operating in that plane, whether is it a Path Computation logical separation of the Control, Measurement, and other Management
Element (PCE) <xref target="RFC4655"/>, or a Network Management entity entities is not relevant, the term "Controller Plane" is used for
(NME), or a distributed control plane. simplicity to represent them all, and the term "Controller Plane
The CPF is a core Function (CPF)" refers to any device operating in that plane, whether
element of a controller, in charge of computing Deterministic paths it is a Path Computation Element (PCE) <xref target="RFC4655" format="d
to be applied in the Network Plane. efault" sectionFormat="of" derivedContent="RFC4655"/>, a
</t> Network Management Entity (NME), or a distributed control protocol.
<t>
The CPF is a core element of a controller, in charge of computing
deterministic paths to be applied in the Network Plane.
</t>
<t pn="section-4.4.2-2">
A (Northbound) Service Interface enables applications in the Applicatio n A (Northbound) Service Interface enables applications in the Applicatio n
Plane to communicate with the entities in the Controller Plane as Plane to communicate with the entities in the Controller Plane as
illustrated in <xref target="NorthSouth"/>. illustrated in <xref target="NorthSouth" format="default" sectio
</t> nFormat="of" derivedContent="Figure 7"/>.
<t> </t>
One or more CPF(s) collaborate to implement the requests from the FME <t pn="section-4.4.2-3">
as Per-Flow Per-Hop Behaviors installed in the DetNet nod One or more CPFs collaborate to implement the requests from the FME
es for as per-flow, per-hop behaviors installed in the DetNet nodes for each
each individual flow. The CPFs individual flow. The CPFs place each flow along a deterministic
place each flow along a deterministic sequence of DetNet nodes so as arrangement of DetNet nodes so as to respect per-flow constraints such
to respect per-flow constraints such as security and as security and latency, and to optimize the overall result for metrics
latency, and optimize the overall result for metrics such such as an abstract aggregated cost. The deterministic arrangement can
as an typically be more complex than a direct arrangement and include
abstract aggregated cost. The deterministic sequence can typically be redundant paths with one or more packet replication and elimination
more complex than a direct sequence and include redundant paths, with points. Scaling to larger networks is discussed in <xref target="Scalin
one or more packet replication and elimination points. Scaling to large g" format="default" sectionFormat="of" derivedContent="Section 4.9"/>.
r </t>
networks is discussed in <xref target="Scaling"/>. </section>
</t> <section anchor="netplane" numbered="true" toc="include" removeInRFC="fa
</section> lse" pn="section-4.4.3">
<section anchor="netplane" title="The Network Plane"><t> <name slugifiedName="name-the-network-plane">The Network Plane</name>
The Network Plane represents the network devices and protocols as a <t pn="section-4.4.3-1">
whole, regardless of the Layer at which the network devices operate.
It includes Forwarding Plane (data plane), Application, and The Network Plane represents the network devices and protocols as a whole,
Operational Plane (e.g., OAM) aspects. regardless of the layer at which the network devices operate. It includes the
</t> Data Plane and Operational Plane (e.g., OAM) aspects.
<t> </t>
The network Plane comprises the Network Interface Cards (NIC) in the <t pn="section-4.4.3-2">The Network Plane comprises the Network Interf
end systems, which are typically IP hosts, ace Cards (NICs) in the
and DetNet nodes, which are typically IP routers and MPLS switches. end systems, which are typically IP hosts, and DetNet nodes, which
Network-to-Network Interfaces such as used for Traffic Engineering are typically IP routers and MPLS switches.
path reservation in <xref target="RFC5921"/>, </t>
as well as User-to-Network Interfaces (UNI) such as provided by <t pn="section-4.4.3-3">
the Local Management Interface (LMI) between network and end systems,
are both part of the Network Plane, both in the control plane and
the data plane.
</t>
<t>
A Southbound (Network) Interface enables the entities in the Controller A Southbound (Network) Interface enables the entities in the Controller
Plane to communicate with devices in the Network Plane as illustrated Plane to communicate with devices in the Network Plane as illustrated
in <xref target="NorthSouth"/>. This interface leverages and ext ends in <xref target="NorthSouth" format="default" sectionFormat="of" derivedContent="Figure 7"/>. This interface leverages and extends
TEAS to describe the physical topology and resources in the Netw ork TEAS to describe the physical topology and resources in the Netw ork
Plane. Plane.
</t> </t>
<figure align="center" anchor="NorthSouth" <figure anchor="NorthSouth" align="left" suppress-title="false" pn="fi
title="Northbound and Southbound interfaces"> gure-7">
<artwork align="left"><![CDATA[ <name slugifiedName="name-northbound-and-southbound-i">Northbound an
d Southbound Interfaces</name>
<artwork align="left" name="" type="" alt="" pn="section-4.4.3-4.1">
End End End End
System System System System
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
CPF CPF CPF CPF CPF CPF CPF CPF
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
DetNet DetNet DetNet DetNet DetNet DetNet DetNet DetNet
Node Node Node Node Node Node Node Node
NIC NIC NIC NIC
DetNet DetNet DetNet DetNet DetNet DetNet DetNet DetNet
Node Node Node Node Node Node Node Node
]]></artwork> </artwork>
</figure> </figure>
<t> <t pn="section-4.4.3-5">
The DetNet nodes (and possibly the end systems NIC) expos The DetNet nodes (and possibly the end systems' NICs) expose their capabilities
e their capabilities and physical and physical resources to the controller (the CPF) and update the CPFs with
resources to the controller (the CPF), and update the CPF their dynamic perception of the topology across the Southbound Interface. In
s with their dynamic perception of the return, the CPFs set the per-flow paths up, providing a Flow Characterization
topology, across the Southbound Interface. In return, the that is more tightly coupled to the DetNet node operation than a TSpec.
CPFs set the per-flow </t>
paths up, providing a Flow Characterization that is more <t pn="section-4.4.3-6"> At the Network Plane, DetNet nodes may exchan
tightly coupled to the DetNet node ge information regarding
Operation than a TSpec. the state of the paths, between adjacent DetNet nodes and possibly with the
</t><t> end systems, and forward packets within constraints associated to each flow,
At the Network plane, DetNet nodes may exchange informati or, when unable to do so, perform a last-resort operation such as drop or
on regarding the state of the paths, declassify. </t>
between adjacent DetNet nodes and possibly with the end s <t pn="section-4.4.3-7"> This document focuses on the Southbound inter
ystems, and forward packets within face and the
constraints associated to each flow, or, when unable to d operation of the Network Plane.
o so, perform a last resort </t>
operation such as drop or declassify. </section>
</t><t>
This document focuses on the Southbound interface and the
operation of the Network Plane.
</t>
</section> </section>
</section> <section anchor="QueuingModels" numbered="true" toc="include" removeInRFC=
<section anchor="QueuingModels" title="Queuing, Shaping, Scheduling, an "false" pn="section-4.5">
d Preemption"> <name slugifiedName="name-queuing-shaping-scheduling-">Queuing, Shaping,
<t> Scheduling, and Preemption</name>
DetNet achieves bounded delivery latency <t pn="section-4.5-1"> DetNet achieves bounded delivery latency by reser
by reserving bandwidth and buffer resources at each DetNet node ving bandwidth and buffer
along resources at each DetNet node along the path of the DetNet flow. The
the path of the DetNet flow. reservation itself is not sufficient, however. Implementors and users of a
The reservation itself is not sufficient, however. Implementor number of proprietary and standard real-time networks have found that
s and users of a standards for specific data-plane techniques are required to enable these
number of assurances to be made in a multivendor network. The fundamental reason is
proprietary and standard real-time networks have found that sta that latency variation in one DetNet system results in the need for extra
ndards for buffer space in the next-hop DetNet system(s), which in turn increases the
specific data plane techniques are required to enable these ass worst-case per-hop latency. </t>
urances to be <t pn="section-4.5-2"> Standard queuing and transmission-selection algor
made in a multi-vendor ithms allow TE
network. The fundamental reason is that latency variation in o (<xref target="te" format="default" sectionFormat="of" derivedContent="Section 4
ne DetNet system results .4"/>) to compute the latency contribution of each
in the need for extra buffer space in the next-hop DetNet syste DetNet node to the end-to-end latency, to compute the amount of buffer space
m(s), which in turn, required in each DetNet node for each incremental DetNet flow, and most
increases the worst-case per-hop latency. importantly, to translate from a flow specification to a set of values for the
</t><t> managed objects that control each relay or end system. For example, the IEEE
Standard queuing and transmission selection algorithms allow tr 802.1 WG has specified (and is specifying) a set of queuing, shaping, and
affic engineering scheduling algorithms that enable each DetNet node, and/or a central
<xref target="te"/> to compute the latency contribution controller, to compute these values. These algorithms include:
of each DetNet node to the end-to-end latency, to compute the a </t>
mount of buffer space <ul spacing="normal" bare="false" empty="false" pn="section-4.5-3">
required in each DetNet node for each incremental DetNet flow, <li pn="section-4.5-3.1">
and most importantly, to A credit-based shaper <xref target="IEEE802.1Qav" format="default" sectionForm
translate from a flow specification to a set of values for the at="of" derivedContent="IEEE802.1Qav"/> (incorporated to <xref target="IEEE802.1
managed objects that Q" format="default" sectionFormat="of" derivedContent="IEEE802.1Q"/>). </li>
control each relay or end system. For example, the IEEE 802.1 <li pn="section-4.5-3.2"> Time-gated queues governed by a rotating tim
WG has specified (and is e schedule based on
specifying) a set of queuing, shaping, and scheduling algorithm synchronized time <xref target="IEEE802.1Qbv" format="default" sectionFormat="of
s " derivedContent="IEEE802.1Qbv"/> (incorporated to <xref target="IEEE802.1Q" for
that enable each DetNet node, and/or a central controller, to mat="default" sectionFormat="of" derivedContent="IEEE802.1Q"/>).
compute these values. These algorithms include: </li>
<list style="symbols"> <li pn="section-4.5-3.3"> Synchronized double (or triple) buffers driv
<t> en by synchronized time ticks.
A credit-based shaper <xref target="IEEE802.1Qav"/> (su <xref target="IEEE802.1Qch" format="default" sectionFormat="of" derivedContent="
perseded by <xref target="IEEE802.1Q-2018"/>). IEEE802.1Qch"/> (incorporated to <xref target="IEEE802.1Q" format="default" sect
</t><t> ionFormat="of" derivedContent="IEEE802.1Q"/>). </li>
Time-gated queues governed by a rotating time schedule <li pn="section-4.5-3.4"> Preemption of an Ethernet packet in transmis
based on synchronized time sion by a packet with a more
<xref target="IEEE802.1Qbv"/> (superseded by <xref targ stringent latency requirement, followed by the resumption of the preempted
et="IEEE802.1Q-2018"/>). packet <xref target="IEEE802.1Qbu" format="default" sectionFormat="of" derivedCo
</t><t> ntent="IEEE802.1Qbu"/> (incorporated to <xref target="IEEE802.1Q" format="defaul
Synchronized double (or triple) buffers driven by synch t" sectionFormat="of" derivedContent="IEEE802.1Q"/>) <xref target="IEEE802.3br"
ronized time ticks. format="default" sectionFormat="of" derivedContent="IEEE802.3br"/> (incorporated
<xref target="IEEE802.1Qch"/> (superseded by <xref targ to <xref target="IEEE802.3" format="default" sectionFormat="of" derivedContent=
et="IEEE802.1Q-2018"/>). "IEEE802.3"/>).
</t><t> </li>
Pre-emption of an Ethernet packet in transmission by a </ul>
packet with a more stringent <t pn="section-4.5-4"> While these techniques are currently embedded in
latency requirement, followed by the resumption of the Ethernet <xref target="IEEE802.3" format="default" sectionFormat=
preempted packet "of" derivedContent="IEEE802.3"/> and bridging
<xref target="IEEE802.1Qbu"/> (superseded by <xref targ standards, we can note that they are all, except perhaps for
et="IEEE802.1Q-2018"/>), packet preemption, equally applicable to media other than
<xref target="IEEE802.3br"/> (superseded by <xref targe Ethernet and to routers as well as bridges. Other media may
t="IEEE802.3-2018"/>). have their own methods (see, e.g., <xref target="I-D.ietf-6tisch-
</t> architecture" format="default" sectionFormat="of" derivedContent="TSCH-ARCH"/> a
</list> nd <xref target="RFC7554" format="default" sectionFormat="of" derivedContent="RF
</t><t> C7554"/>).
While these techniques are currently embedded in Ethernet <xre Further techniques are defined by the IETF (e.g., <xref target="R
f target="IEEE802.3-2018"/> and bridging standards, FC8289" format="default" sectionFormat="of" derivedContent="RFC8289"/> and <xref
we can note that they are all, except perhaps for packet preemp target="RFC8033" format="default" sectionFormat="of" derivedContent="RFC8033"/>
tion, equally applicable ). DetNet may
to other media than Ethernet, and to routers as well as bridges include such definitions in the future or may define how
. Other media may have its these techniques can be used by DetNet nodes.
own methods, see, e.g., <xref target="I-D.ietf-6tisch-architect </t>
ure"/>, <xref target="RFC7554"/>. </section>
Further techniques are defined by the IETF, e.g., <xref target= <section anchor="ServInst" numbered="true" toc="include" removeInRFC="fals
"RFC8289"/> and <xref target="RFC8033"/>. e" pn="section-4.6">
DetNet may include such <name slugifiedName="name-service-instance">Service Instance</name>
definitions in the future, or may define how these techniques c <t pn="section-4.6-1"> A service instance represents all the functions r
an be used by DetNet nodes. equired
</t> on a DetNet node to allow the end-to-end service between the
</section> UNIs.
</t>
<section anchor="ServInst" title="Service instance"> <t pn="section-4.6-2"> The DetNet network general reference model is sho
<t> A Service instance represents all the functions required on a wn in <xref target="fig_DetNetrefmodel" format="default" sectionFormat="of" deri
DetNet node to allow the end-to-end service between the UNIs. vedContent="Figure 8"/> for a DetNet service scenario (i.e., between two
</t> DetNet-UNIs). In this figure, end systems ("A" and "B") are connected directly
to the edge nodes of an IP/MPLS network ("PE1" and "PE2"). End systems
<t> The DetNet network general reference model is shown in <xref participating in DetNet communication may require connectivity before setting
target="fig_DetNetrefmodel"/> for a DetNet service scenario (i.e., between two D up an App-flow that requires the DetNet service. Such a connectivity-related
etNet-UNIs). In this figure, end systems ("A" and "B") are connected directly to service instance and the one dedicated for DetNet service share the same
the edge nodes of an IP/MPLS network ("PE1" and "PE2"). End systems participati access. Packets belonging to a DetNet flow are selected by a filter configured
ng in DetNet communication may require connectivity before setting up an App-flo on the access ("F1" and "F2"). As a result, data-flow-specific access
w that requires the DetNet service. Such a connectivity related service instance ("access-A + F1" and "access-B + F2") is terminated in the flow-specific
and the one dedicated for DetNet service share the same access. Packets belongi service instance ("SI-1" and "SI-2"). A tunnel is used to provide connectivity
ng to a DetNet flow are selected by a filter configured on the access ("F1" and between the service instances.
"F2"). As a result, data flow specific access ("access-A + F1" and "access-B + F </t>
2") are terminated in the flow specific service instance ("SI-1" and "SI-2"). A <t pn="section-4.6-3"> The tunnel is exclusively used for the packets of
tunnel is used to provide connectivity between the service instances. the DetNet flow between "SI-1" and "SI-2". The service instances are configured
</t> to implement DetNet functions and a flow-specific DetNet forwarding. The servic
e instance and the tunnel may or may not be shared by multiple DetNet flows. Sha
<t> The tunnel is exclusively used for the packets of the DetNet ring the service instance by multiple DetNet flows requires properly populated f
flow between "SI-1" and "SI-2". The service instances are configured to implemen orwarding tables of the service instance.
t DetNet functions and a flow specific DetNet forwarding. The service instance a </t>
nd the tunnel may or may not be shared by multiple DetNet flows. Sharing the ser <figure anchor="fig_DetNetrefmodel" align="left" suppress-title="false"
vice instance by multiple DetNet flows requires properly populated forwarding ta pn="figure-8">
bles of the service instance. <name slugifiedName="name-detnet-network-general-refe">DetNet Network
</t> General Reference Model</name>
<artwork name="" type="" align="left" alt="" pn="section-4.6-4.1">
<figure anchor="fig_DetNetrefmodel" align="center"
title="DetNet network general reference model">
<artwork><![CDATA[
access-A access-B access-A access-B
<-----> <-------- tunnel ----------> <-----&gt; <-----&gt; &lt;-------- tunnel ----------&gt; &lt;-----&gt;
+---------+ ___ _ +---------+ +---------+ ___ _ +---------+
End system | +----+ | / \/ \_ | +----+ | End system End system | +----+ | / \/ \_ | +----+ | End system
"A" -------F1+ | | / \ | | +F2----- "B" "A" -------F1+ | | / \ | | +F2----- "B"
| | +========+ IP/MPLS +=======+ | | | | +========+ IP/MPLS +=======+ | |
| |SI-1| | \__ Net._/ | |SI-2| | | |SI-1| | \__ Net._/ | |SI-2| |
| +----+ | \____/ | +----+ | | +----+ | \____/ | +----+ |
|PE1 | | PE2| |PE1 | | PE2|
+---------+ +---------+ +---------+ +---------+</artwork>
</figure>
]]></artwork> <t pn="section-4.6-5"> The tunnel between the service instances may have
</figure> some special
characteristics. For example, in case of a DetNet L3 service, there are
<t> The tunnel between the service instances may have some specia differences in the usage of the PW for DetNet traffic compared to the network
l characteristics. For example, in case of a DetNet L3 service, there are differ model described in <xref target="RFC6658" format="default" sectionFormat="of" de
ences in the usage of the PW for DetNet traffic compared to the network model de rivedContent="RFC6658"/>. In the DetNet scenario, the PW is
scribed in <xref target="RFC6658"/>. In the DetNet scenario, the PW is likely to likely to be used exclusively by the DetNet flow, whereas <xref target="RFC6658"
be used exclusively by the DetNet flow, whereas <xref target="RFC6658"/> states format="default" sectionFormat="of" derivedContent="RFC6658"/> states:
: "The packet PW appears as a single point-to-point link to the client layer. N </t>
etwork-layer adjacency formation and maintenance between the client equipment wi <blockquote pn="section-4.6-6">
ll follow the normal practice needed to support the required relationship in the The packet PW appears as a single point-to-point link to the client
client layer ... This packet PseudoWire is used to transport all of the require layer. Network-layer adjacency formation and maintenance between the
d Layer-2 and Layer-3 protocols between LSR1 and LSR2". Further details are netw client equipments will follow the normal practice needed to support
ork technology specific and can be found in <xref target="I-D.ietf-detnet-dp-sol the required relationship in the client layer.
-mpls"/> and <xref target="I-D.ietf-detnet-dp-sol-ip"/>. </blockquote>
</t> <t pn="section-4.6-7">and</t>
<blockquote pn="section-4.6-8">
</section> This packet pseudowire is used to transport all of the required layer 2 and
<section anchor="FlowIDatTechBord" title="Flow identification at techno layer 3 protocols between LSR1 and LSR2.
logy borders"> </blockquote>
<t>This section discusses what needs to be done at technology border <t pn="section-4.6-9">
s including Further details are network technology specific and can be found in <xref target
Ethernet as one of the technologies. Flow identification for MPL ="I-D.ietf-detnet-data-plane-framework" format="default" sectionFormat="of" deri
S and IP data vedContent="DETNET-FRAMEWORK"/>.
planes are described in <xref target="I-D.ietf-detnet-dp-sol-mpl </t>
s"/> and </section>
<xref target="I-D.ietf-detnet-dp-sol-ip"/>, respectively. <section anchor="FlowIDatTechBord" numbered="true" toc="include" removeInR
</t> FC="false" pn="section-4.7">
<name slugifiedName="name-flow-identification-at-tech">Flow Identificati
<section anchor="Relayering" title="Exporting flow identification"> on at Technology Borders</name>
<t> <t pn="section-4.7-1">This section discusses what needs to be done at te
A DetNet node may need to map specific flows to lower layer flo chnology
ws (or Streams) in order to provide specific borders including Ethernet as one of the technologies. Flow
queuing and shaping services for specific flows. For example: identification for MPLS and IP Data Planes are described in <xref ta
<list style="symbols"> rget="I-D.ietf-detnet-mpls" format="default" sectionFormat="of" derivedContent="
<t> DETNET-MPLS"/> and <xref target="I-D.ietf-detnet-ip" format="default" sectionFor
mat="of" derivedContent="DETNET-IP"/>,
respectively.
</t>
<section anchor="Relayering" numbered="true" toc="include" removeInRFC="
false" pn="section-4.7.1">
<name slugifiedName="name-exporting-flow-identificati">Exporting Flow
Identification</name>
<t pn="section-4.7.1-1">
A DetNet node may need to map specific flows to lower-layer
flows (or Streams) in order to provide specific queuing and
shaping services for specific flows. For example:
</t>
<ul spacing="normal" bare="false" empty="false" pn="section-4.7.1-2">
<li pn="section-4.7.1-2.1">
A non-IP, strictly L2 source end system X may be sending multiple flows A non-IP, strictly L2 source end system X may be sending multiple flows
to the same L2 destination end system Y. Those f lows may include to the same L2 destination end system Y. Those f lows may include
DetNet flows with different QoS requirements, and may include non-DetNet DetNet flows with different QoS requirements and may include non-DetNet
flows. flows.
</t><t> </li>
<li pn="section-4.7.1-2.2">
A router may be sending any number of flows to an other router. A router may be sending any number of flows to an other router.
Again, those flows may include Again, those flows may include
DetNet flows with different QoS requirements, and may include non-DetNet DetNet flows with different QoS requirements and may include non-DetNet
flows. flows.
</t><t> </li>
<li pn="section-4.7.1-2.3">
Two routers may be separated by bridges. For the se bridges to perform Two routers may be separated by bridges. For the se bridges to perform
any required per-flow queuing and shaping, they m ust be able to identify any required per-flow queuing and shaping, they m ust be able to identify
the individual flows. the individual flows.
</t><t> </li>
<li pn="section-4.7.1-2.4">
A Label Edge Router (LER) may have a Label Switch ed A Label Edge Router (LER) may have a Label Switch ed
Path (LSP) set up for handling traffic Path (LSP) set up for handling traffic
destined for a particular IP address carrying onl y non-DetNet flows. If destined for a particular IP address carrying onl y non-DetNet flows. If
a DetNet flow to that same address is requested, a separate LSP may be a DetNet flow to that same address is requested, a separate LSP may be
needed, in order that all of the Label Switch Rou needed in order for all of the Label Switch Route
ters (LSRs) along the rs (LSRs) along the
path to the destination give that flow special qu path to the destination to give that flow special
euing and shaping. queuing and shaping.
</t> </li>
</list> </ul>
</t><t> <t pn="section-4.7.1-3"> The need for a lower-layer node to be aware o
The need for a lower-layer node to be aware of individual highe f
r-layer individual higher-layer flows is not unique to DetNet. But,
flows is not unique to DetNet. But, given the endless complexi given the endless complexity of layering and relayering over
ty of layering tunnels that is available to network designers, DetNet needs
and relayering over tunnels that is available to network design to provide a model for flow identification that is better than
ers, DetNet packet inspection. That is not to say that packet inspection
needs to provide a model for flow identification that is to Layer 4 or Layer 5 addresses will not be used or the
better than packet inspection. That is not to say that packet capability standardized; however, there are alternatives. </t>
inspection <t pn="section-4.7.1-4">
to Layer-4 or Layer-5 addresses A DetNet relay node can connect DetNet flows on different
will not be used, or the capability standardized; but, there ar paths using different flow identification methods. For
e alternatives. example:
</t><t> </t>
A DetNet relay node can connect DetNet flows on different paths <ul spacing="normal" bare="false" empty="false" pn="section-4.7.1-5">
using different <li pn="section-4.7.1-5.1">
flow identification methods. For example:
<list style="symbols">
<t>
A single unicast DetNet flow passing from router A thro ugh a bridged network A single unicast DetNet flow passing from router A thro ugh a bridged network
to router B may be assigned a TSN Stream identifier tha t is to router B may be assigned a TSN Stream identifier tha t is
unique within that bridged network. The bridges can th en identify the unique within that bridged network. The bridges can th en identify the
flow without accessing higher-layer headers. Of course , the receiving router flow without accessing higher-layer headers. Of course , the receiving router
must recognize and accept that TSN Stream. must recognize and accept that TSN Stream.
</t><t> </li>
<li pn="section-4.7.1-5.2">
A DetNet flow passing from LSR A to LSR B may be assign ed a different A DetNet flow passing from LSR A to LSR B may be assign ed a different
label than that used for other flows to the same IP des tination. label than that used for other flows to the same IP des tination.
</t> </li>
</list> </ul>
</t><t> <t pn="section-4.7.1-6">
In any of the above cases, it is possible that an existing DetN et flow can In any of the above cases, it is possible that an existing DetN et flow can
be an aggregate carrying multiple other DetNet flows. (Not to be an aggregate carrying multiple other DetNet flows (not to be
be confused confused
with DetNet compound vs. member flows.) Of course, this requir with DetNet compound vs. member flows). Of course, this requir
es that the es that the
aggregate DetNet flow be provisioned properly to carry the aggr egated flows. aggregate DetNet flow be provisioned properly to carry the aggr egated flows.
</t><t> </t>
<t pn="section-4.7.1-7">
Thus, rather than packet inspection, there is the option to exp ort Thus, rather than packet inspection, there is the option to exp ort
higher-layer information to the lower layer. The requirement t o support higher-layer information to the lower layer. The requirement t o support
one or the other method for flow identification (or both) is a one or the other method for flow identification (or both) is a
complexity that is part of DetNet control models. complexity that is part of DetNet control models.
</t> </t>
</section> </section>
<section anchor="FlowAttrMapping" numbered="true" toc="include" removeIn
<section anchor="FlowAttrMapping" title="Flow attribute mapping between RFC="false" pn="section-4.7.2">
layers"> <name slugifiedName="name-flow-attribute-mapping-betw">Flow Attribute
<t>Forwarding of packets of DetNet flows over multiple technology Mapping between Layers</name>
domains may require that lower layers are aware of specific flows of higher lay <t pn="section-4.7.2-1">Forwarding of packets of DetNet flows over mul
ers. Such an "exporting of flow identification" is needed each time when the for tiple
warding paradigm is changed on the forwarding path (e.g., two LSRs are interconn technology domains may require that lower layers are aware of
ected by a L2 bridged domain, etc.). The three representative forwarding methods specific flows of higher layers. Such an "exporting of flow
considered for deterministic networking are: identification" is needed each time when the forwarding
<list style="symbols"> paradigm is changed on the forwarding path (e.g., two LSRs are
<t>IP routing</t> interconnected by an L2 bridged domain, etc.). The three
<t>MPLS label switching</t> representative forwarding methods considered for DetNet
<t>Ethernet bridging</t> are:
</list> </t>
A packet with corresponding Flow-IDs is illustrated in <xref targ <ul spacing="normal" bare="false" empty="false" pn="section-4.7.2-2">
et="fig_FlowIDStack"/>, <li pn="section-4.7.2-2.1">IP routing</li>
<li pn="section-4.7.2-2.2">MPLS label switching</li>
<li pn="section-4.7.2-2.3">Ethernet bridging</li>
</ul>
<t pn="section-4.7.2-3">
A packet with corresponding Flow-IDs is illustrated in <xref targ
et="fig_FlowIDStack" format="default" sectionFormat="of" derivedContent="Figure
9"/>,
which also indicates where each Flow-ID can be added or removed. which also indicates where each Flow-ID can be added or removed.
</t> </t>
<figure anchor="fig_FlowIDStack" align="left" suppress-title="false" p
<figure anchor="fig_FlowIDStack" align="center" n="figure-9">
title="Packet with multiple Flow-IDs"> <name slugifiedName="name-packet-with-multiple-flow-i">Packet with M
<artwork><![CDATA[ ultiple Flow-IDs</name>
<artwork name="" type="" align="left" alt="" pn="section-4.7.2-4.1">
add/remove add/remove add/remove add/remove
Eth Flow-ID IP Flow-ID Eth Flow-ID IP Flow-ID
| | | |
v v v v
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| | | | | | | | | |
| Eth | MPLS | IP | Application data | | Eth | MPLS | IP | Application data |
| | | | | | | | | |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
^ ^
| |
add/remove add/remove
MPLS Flow-ID MPLS Flow-ID
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.7.2-5"> The additional (domain-specific) Flow-ID can
<t> The additional (domain specific) Flow-ID can be be:
<list style="symbols"> </t>
<t>created by a domain specific function or </t> <ul spacing="normal" bare="false" empty="false" pn="section-4.7.2-6">
<t>derived from the Flow-ID added to the App-flow. </t> <li pn="section-4.7.2-6.1">created by a domain-specific function or
</list> </li>
<li pn="section-4.7.2-6.2">derived from the Flow-ID added to the App
-flow. </li>
</ul>
<t pn="section-4.7.2-7">
The Flow-ID must be unique inside a given domain. Note that the F low-ID added to the App-flow is still present in the packet, but some nodes may lack the function to recognize it; that's why the additional Flow-ID is added. The Flow-ID must be unique inside a given domain. Note that the F low-ID added to the App-flow is still present in the packet, but some nodes may lack the function to recognize it; that's why the additional Flow-ID is added.
</t> </t>
</section> </section>
<section anchor="FlowIDMapEx" numbered="true" toc="include" removeInRFC=
<section anchor="FlowIDMapEx" title="Flow-ID mapping examples"> "false" pn="section-4.7.3">
<t> IP nodes and MPLS nodes are assumed to be configured to push <name slugifiedName="name-flow-id-mapping-examples">Flow-ID Mapping Ex
such an additional (domain specific) Flow-ID when sending traffic to an Ethernet amples</name>
switch (as shown in the examples below). <t pn="section-4.7.3-1"> IP nodes and MPLS nodes are assumed to be con
</t> figured to push such an additional (domain-specific) Flow-ID when sending traffi
c to an Ethernet switch (as shown in the examples below).
<t> <xref target="fig_ippushflowid"/> shows a scenario where an I </t>
P end system ("IP-A") is connected via two Ethernet switches ("ETH-n") to an IP <t pn="section-4.7.3-2"><xref target="fig_ippushflowid" format="defaul
router ("IP-1"). t" sectionFormat="of" derivedContent="Figure 10"/> shows a scenario where an IP
</t> end system ("IP-A") is connected via two Ethernet switches ("ETH-n") to an IP ro
uter ("IP-1").
<figure anchor="fig_ippushflowid" align="center" </t>
title="IP nodes interconnected by an Ethernet domain"> <figure anchor="fig_ippushflowid" align="left" suppress-title="false"
<artwork><![CDATA[ pn="figure-10">
<name slugifiedName="name-ip-nodes-interconnected-by-">IP Nodes Inte
rconnected by an Ethernet Domain</name>
<artwork name="" type="" align="left" alt="" pn="section-4.7.3-3.1">
IP domain IP domain
<----------------------------------------------- &lt;-----------------------------------------------
+======+ +======+ +======+ +======+
|L3-ID | |L3-ID | |L3-ID | |L3-ID |
+======+ /\ +-----+ +======+ +======+ /\ +-----+ +======+
/ \ Forward as | | / \ Forward as | |
/IP-A\ per ETH-ID |IP-1 | Recognize /IP-A\ per ETH-ID |IP-1 | Recognize
Push ------> +-+----+ | +---+-+ &lt;----- ETH-ID Push ------> +-+----+ | +---+-+ &lt;----- ETH-ID
ETH-ID | +----+-----+ | ETH-ID | +----+-----+ |
| v v | | v v |
| +-----+ +-----+ | | +-----+ +-----+ |
+------+ | | +---------+ +------+ | | +---------+
+......+ |ETH-1+----+ETH-2| +======+ +......+ |ETH-1+----+ETH-2| +======+
.L3-ID . +-----+ +-----+ |L3-ID | .L3-ID . +-----+ +-----+ |L3-ID |
+======+ +......+ +======+ +======+ +......+ +======+
|ETH-ID| .L3-ID . |ETH-ID| |ETH-ID| .L3-ID . |ETH-ID|
+======+ +======+ +------+ +======+ +======+ +------+
|ETH-ID| |ETH-ID|
+======+ +======+
Ethernet domain Ethernet domain
<----------------> &lt;----------------&gt;
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.7.3-4"> End system "IP-A" uses the original App-flow-
<t> End system "IP-A" uses the original App-flow specific ID ("L3 specific ID
-ID"), but as it is connected to an Ethernet domain it has to push an Ethernet-d ("L3-ID"), but as it is connected to an Ethernet
omain specific flow-ID ("ETH-ID") before sending the packet to "ETH-1" node. Eth domain, it has to push an Ethernet-domain-specific
ernet switch "ETH-1" can recognize the data flow based on the "ETH-ID" and it do Flow-ID ("ETH-ID") before sending the packet to
es forwarding toward "ETH-2". "ETH-2" switches the packet toward the IP router. "ETH-1". Ethernet switch "ETH-1" can recognize the data flow
"IP-1" must be configured to receive the Ethernet Flow-ID specific multicast flo based on the "ETH-ID", and it does forwarding toward
w, but (as it is an L3 node) it decodes the data flow ID based on the "L3-ID" fi "ETH-2". "ETH-2" switches the packet toward the IP
elds of the received packet. router. "IP-1" must be configured to receive the Ethernet
</t> Flow-ID-specific multicast
flow, but (as it is an L3
<t> <xref target="fig_mplspushflowid"/> shows a scenario where MP node) it decodes the data flow ID based on the "L3-ID" fields
LS domain nodes ("PE-n" and "P-m") are connected via two Ethernet switches ("ETH of the received packet.
-n"). </t>
</t> <t pn="section-4.7.3-5"><xref target="fig_mplspushflowid" format="defa
ult" sectionFormat="of" derivedContent="Figure 11"/> shows a scenario where MPLS
<figure anchor="fig_mplspushflowid" align="center" domain nodes ("PE-n" and "P-m") are connected via two Ethernet switches ("ETH-n
title="MPLS nodes interconnected by an Ethernet domain"> ").
<artwork><![CDATA[ </t>
<figure anchor="fig_mplspushflowid" align="left" suppress-title="false
" pn="figure-11">
<name slugifiedName="name-mpls-nodes-interconnected-b">MPLS Nodes In
terconnected by an Ethernet Domain</name>
<artwork name="" type="" align="left" alt="" pn="section-4.7.3-6.1">
MPLS domain MPLS domain
<-----------------------------------------------&gt; <-----------------------------------------------&gt;
+=======+ +=======+ +=======+ +=======+
|MPLS-ID| |MPLS-ID| |MPLS-ID| |MPLS-ID|
+=======+ +-----+ +-----+ +=======+ +-----+ +=======+ +-----+ +-----+ +=======+ +-----+
| | Forward as | | | | | | Forward as | | | |
|PE-1 | per ETH-ID | P-2 +-----------+ PE-2| |PE-1 | per ETH-ID | P-2 +-----------+ PE-2|
Push -----> +-+---+ | +---+-+ +-----+ Push -----&gt; +-+---+ | +---+-+ +-----+
ETH-ID | +-----+----+ | \ Recognize ETH-ID | +-----+----+ | \ Recognize
| v v | +-- ETH-ID | v v | +-- ETH-ID
| +-----+ +-----+ | | +-----+ +-----+ |
+---+ | | +----+ +---+ | | +----+
+.......+ |ETH-1+----+ETH-2| +=======+ +.......+ |ETH-1+----+ETH-2| +=======+
.MPLS-ID. +-----+ +-----+ |MPLS-ID| .MPLS-ID. +-----+ +-----+ |MPLS-ID|
+=======+ +=======+ +=======+ +=======+
|ETH-ID | +.......+ |ETH-ID | |ETH-ID | +.......+ |ETH-ID |
+=======+ .MPLS-ID. +-------+ +=======+ .MPLS-ID. +-------+
+=======+ +=======+
|ETH-ID | |ETH-ID |
+=======+ +=======+
Ethernet domain Ethernet domain
<----------------> &lt;----------------&gt;
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.7.3-7"> "PE-1" uses the MPLS-specific ID ("MPLS-ID"),
<t> "PE-1" uses the MPLS specific ID ("MPLS-ID"), but as it is co but as it
nnected to an Ethernet domain it has to push an Ethernet-domain specific flow-ID is connected to an Ethernet domain, it has to push an
("ETH-ID") before sending the packet to "ETH-1". Ethernet switch "ETH-1" can re Ethernet-domain-specific Flow-ID
cognize the data flow based on the "ETH-ID" and it does forwarding toward "ETH-2 ("ETH-ID") before sending the
". "ETH-2" switches the packet toward the MPLS node ("P-2"). "P-2" must be confi packet to "ETH-1". Ethernet switch "ETH-1" can recognize the
gured to receive the Ethernet Flow-ID specific multicast flow, but (as it is an data flow based on the "ETH-ID", and it does forwarding toward
MPLS node) it decodes the data flow ID based on the "MPLS-ID" fields of the rece "ETH-2". "ETH-2" switches the packet toward the MPLS node
ived packet. ("P-2"). "P-2" must be configured to receive the Ethernet
</t> Flow-ID-specific multicast flow, but (as it is an MPLS node)
<t>One can appreciate from the above example that, when the means used f it decodes the data flow ID based on the "MPLS-ID" fields of
or DetNet flow identification the received packet.
</t>
<t pn="section-4.7.3-8">One can appreciate from the above example that
, when the means used for DetNet flow identification
is altered or exported, the means for encoding the sequence number i nformation must similarly is altered or exported, the means for encoding the sequence number i nformation must similarly
be altered or exported. be altered or exported.
</t> </t>
</section>
</section> </section>
</section> <section anchor="Advertising" numbered="true" toc="include" removeInRFC="f
<section anchor="Advertising" title="Advertising resources, capabilitie alse" pn="section-4.8">
s and adjacencies"> <name slugifiedName="name-advertising-resources-capab">Advertising Resou
<t> rces, Capabilities, and Adjacencies</name>
<t pn="section-4.8-1">
Provisioning of DetNet requires knowledge about: Provisioning of DetNet requires knowledge about:
<list style="symbols"><t> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-4.8-2">
<li pn="section-4.8-2.1">
Details of the DetNet system's capabilities that are requ ired in order to Details of the DetNet system's capabilities that are requ ired in order to
accurately allocate that DetNet system's resources, as we ll as other DetNet systems' accurately allocate that DetNet system's resources, as we ll as other DetNet systems'
resources. This includes, for example, which specific qu euing and resources. This includes, for example, which specific qu euing and
shaping algorithms are implemented (<xref target="Queuing Models"/>), shaping algorithms are implemented (<xref target="Queuing Models" format="default" sectionFormat="of" derivedContent="Section 4.5"/>),
the number of buffers dedicated for DetNet allocation, an d the worst-case the number of buffers dedicated for DetNet allocation, an d the worst-case
forwarding delay and misordering. forwarding delay and misordering.
</t><t> </li>
<li pn="section-4.8-2.2">
The actual state of a DetNet node's DetNet resources. The actual state of a DetNet node's DetNet resources.
</t><t> </li>
The identity of the DetNet system's neighbors, and the ch <li pn="section-4.8-2.3">
aracteristics of the The identity of the DetNet system's neighbors and the cha
racteristics of the
link(s) between the DetNet systems, including the latency of link(s) between the DetNet systems, including the latency of
the links (in nanoseconds). the links (in nanoseconds).
</t> </li>
</list> </ul>
</t> </section>
</section> <section anchor="Scaling" numbered="true" toc="include" removeInRFC="false
" pn="section-4.9">
<section anchor="Scaling" title="Scaling to larger networks"> <name slugifiedName="name-scaling-to-larger-networks">Scaling to Larger
<t> Networks</name>
<t pn="section-4.9-1">
Reservations for individual DetNet flows require considerable s tate information in Reservations for individual DetNet flows require considerable s tate information in
each DetNet node, especially when adequate fault mitigation each DetNet node, especially when adequate fault mitigation
(<xref target="FaultMitigation"/>) is required. The DetNet dat a plane, in order to (<xref target="FaultMitigation" format="default" sectionFormat= "of" derivedContent="Section 3.3.2"/>) is required. The DetNet Data Plane, in o rder to
support larger numbers of DetNet flows, must support the aggreg ation of DetNet flows. support larger numbers of DetNet flows, must support the aggreg ation of DetNet flows.
Such aggregated flows can be viewed by the DetNet nodes' data p lane Such aggregated flows can be viewed by the DetNet nodes' Data P lane
largely as individual DetNet flows. Without such aggregation, the per-relay largely as individual DetNet flows. Without such aggregation, the per-relay
system may limit the scale of DetNet networks. Example techniqu es that may be used system may limit the scale of DetNet networks. Example techniqu es that may be used
include MPLS hierarchy and IP DiffServ Code Points (DSCPs). include MPLS hierarchy and IP DiffServ Code Points (DSCPs).
</t> </t>
</section> </section>
<section anchor="Compatibility" title="Compatibility with Layer-2"> <section anchor="Compatibility" numbered="true" toc="include" removeInRFC=
<t> "false" pn="section-4.10">
Standards providing similar <name slugifiedName="name-compatibility-with-layer-2">Compatibility with
capabilities for bridged networks (only) have been and are bein Layer 2</name>
g generated in the <t pn="section-4.10-1">
IEEE 802 LAN/MAN Standards Committee. The present architecture Standards providing similar capabilities for bridged networks (only) have
describes an abstract model that can be applicable both at Laye been and are being generated in the IEEE 802 LAN/MAN Standards Committee.
r-2 The present architecture describes an abstract model that can be applicable
and Layer-3, and over links not defined by IEEE 802. both at Layer 2 and Layer 3, and over links not defined by IEEE 802. </t>
</t><t> <t pn="section-4.10-2"> DetNet-enabled end systems and DetNet nodes can
DetNet enabled end systems and DetNet nodes can be interc be interconnected by
onnected by sub-networks, i.e., Layer 2 technologies. These sub-networks will provide
sub-networks, i.e., Layer-2 technologies. DetNet compatible service for support of DetNet traffic. Examples of
These sub-networks will sub-network technologies include MPLS TE, TSN as defined by IEEE 802.1, and a po
provide DetNet compatible service for support of DetNet t int-to-point OTN
raffic. link. Of course, multilayer DetNet systems may be possible too, where one
Examples of sub-network technologies include MPLS TE, 802 DetNet appears as a sub-network and provides service to a higher-layer DetNet
.1 TSN, and a point-to-point OTN link. system.
Of course, multi-layer DetNet systems may be possible too </t>
, where one </section>
DetNet appears as a sub-network, and provides service to,
a higher layer
DetNet system.
</t>
</section>
</section> </section>
<section anchor="SecurityConsiderations" numbered="true" toc="include" remov
<section anchor="SecurityConsiderations" title="Security Considerations"> eInRFC="false" pn="section-5">
<name slugifiedName="name-security-considerations">Security Considerations
<t> </name>
Security considerations for DetNet are described in detail in <t pn="section-5-1">
<xref target="I-D.ietf-detnet-security"/>. This section conside Security considerations for DetNet are described in detail
rs in <xref target="I-D.ietf-detnet-security" format="default" sec
exclusively security considerations which are specific to the D tionFormat="of" derivedContent="DETNET-SECURITY"/>. This section considers
etNet exclusively security considerations that are specific to the
architecture. DetNet architecture. </t>
</t><t> <t pn="section-5-2"> Security aspects that are
Security aspects which are unique to DetNet are those whose aim unique to DetNet are those whose aim is to provide the
is to specific QoS aspects of DetNet, which are
provide the specific quality of service aspects of DetNet, whic primarily to deliver data flows with extremely low packet
h are loss rates and bounded end-to-end delivery latency. A DetNet
primarily to deliver data flows with extremely low packet loss may be implemented using MPLS and/or IP (including both v4
rates and v6) technologies and thus inherits the security
and bounded end-to-end delivery latency. A DetNet may be implem properties of those technologies at both the Data Plane and
ented the Controller Plane. </t>
using MPLS and/or IP (including both v4 and v6) technologies, a <t pn="section-5-3"> Security considerations for
nd DetNet are constrained (compared to, for example, the open
thus inherits the security properties of those technologies at Internet) because DetNet is defined to operate only within a
both single administrative domain (see <xref target="introduction" f
the data plane and the control plane. ormat="default" sectionFormat="of" derivedContent="Section 1"/>). The primary
</t><t> considerations are to secure the request and control of
Security considerations for DetNet are constrained (compared to DetNet resources, maintain confidentiality of data
, for traversing the DetNet, and provide the availability of the
example, the open Internet) because DetNet is defined to operat DetNet QoS. </t>
e only <t pn="section-5-4"> To secure the request
within a single administrative domain (see Section 1). The prim and control of DetNet resources, authentication and
ary authorization can be used for each device connected to a
considerations are to secure the request and control of DetNet DetNet domain, most importantly to network controller
resources, maintain confidentiality of data traversing the DetN devices. Control of a DetNet network may be centralized or
et, distributed (within a single administrative domain). In the
and provide the availability of the DetNet quality of service. case of centralized control, precedent for security
</t><t> considerations as defined for Abstraction and Control of
To secure the request and control of DetNet resources, authenti Traffic Engineered Networks (ACTN) can be found in <xref target
cation ="RFC8453" sectionFormat="of" section="9" format="default" derivedLink="https://
and authorization can be used for each device connected to a rfc-editor.org/rfc/rfc8453#section-9" derivedContent="RFC8453"/>. In the case of
DetNet domain, most importantly to network controller devices. distributed
Control control protocols, DetNet security is expected to be
of a DetNet network may be centralized or distributed (within a provided by the security properties of the protocols in
single use. In any case, the result is that manipulation of
administrative domain). In the case of centralized control, pre administratively configurable parameters is limited to
cedent authorized entities. </t>
for security considerations as defined for Abstraction and Cont <t pn="section-5-5"> To maintain confidentiality of
rol of data traversing the DetNet, application flows can be
Traffic Engineered Networks (ACTN) can be found in protected through whatever means is provided by the
<xref target="RFC8453"/>, Section 9. In the case of distributed underlying technology. For example, encryption may be used,
control protocols, DetNet security is expected to be provided b such as that provided by IPsec <xref target="RFC4301" format="d
y the efault" sectionFormat="of" derivedContent="RFC4301"/>, for
security properties of the protocols in use. In any case, the r IP flows and by MACSec <xref target="IEEE802.1AE" format="defau
esult lt" sectionFormat="of" derivedContent="IEEE802.1AE"/> for
is that manipulation of administratively configurable parameter Ethernet (Layer 2) flows. </t>
s is <t pn="section-5-6"> DetNet flows are
limited to authorized entities. identified on a per-flow basis, which may provide attackers
</t><t> with additional information about the data flows (when
To maintain confidentiality of data traversing the DetNet, compared to networks that do not include per-flow
application flows can be protected through whatever means is identification). This is an inherent property of DetNet
provided by the underlying technology. For example, encryption that has security implications that should be considered
may be when determining if DetNet is a suitable technology for any
used, such as that provided by IPSec <xref target="RFC4301"/> f given use case. </t>
or IP <t pn="section-5-7"> To provide uninterrupted
flows and by MACSec <xref target="IEEE802.1AE-2018"/> for Ether availability of the DetNet QoS, provisions
net can be made against DoS attacks and delay attacks. To
(Layer-2) flows. protect against DoS attacks, excess traffic due to malicious
</t><t> or malfunctioning devices can be prevented or mitigated, for
DetNet flows are identified on a per-flow basis, which may provide example, through the use of traffic admission control
attackers with additional information about the data flows (when applied at the input of a DetNet domain as described in
compared to networks that do not include per-flow identification). <xref target="Zero" format="default" sectionFormat="of" derived
This is an inherent property of DetNet which has security Content="Section 3.2.1"/> and through the fault-mitigation
implications that should be considered when determining if DetNet is methods described in <xref target="FaultMitigation" format="def
a suitable technology for any given use case. ault" sectionFormat="of" derivedContent="Section 3.3.2"/>. To
</t><t> prevent DetNet packets from being delayed by an entity
To provide uninterrupted availability of the DetNet quality of external to a DetNet domain, DetNet technology definition
service, provisions can be made against DOS attacks and delay can allow for the mitigation of man-in-the-middle attacks,
attacks. To protect against DOS attacks, excess traffic due to for example, through use of authentication and authorization
malicious or malfunctioning devices can be prevented or mitigat of devices within the DetNet domain. </t>
ed, <t pn="section-5-8"> Because DetNet
for example through the use of traffic admission control applie mechanisms or applications that rely on DetNet can make
d at heavy use of methods that require precise time
the input of a DetNet domain, as described in <xref target="Zer synchronization, the accuracy, availability, and integrity
o"/>, of time synchronization is of critical importance. Extensive
and through the fault mitigation methods described in discussion of this topic can be found in <xref target="RFC7384"
<xref target="FaultMitigation"/>. To prevent DetNet packets fro format="default" sectionFormat="of" derivedContent="RFC7384"/>. </t>
m <t pn="section-5-9"> DetNet use cases are known to
being delayed by an entity external to a DetNet domain, DetNet have widely divergent security requirements. The intent of
technology definition can allow for the mitigation of this section is to provide a baseline for security
Man-In-The-Middle attacks, for example through use of considerations that are common to all DetNet designs and
authentication and authorization of devices within the DetNet d implementations, without burdening individual designs with
omain. specifics of security infrastructure that may not be
</t><t> germane to the given use case. Designers and implementors of
Because DetNet mechanisms or applications that rely on DetNet can DetNet systems are expected to take use-case-specific considera
make heavy use of methods that require precise time synchroniza tions
tion, into account in their DetNet designs
the accuracy, availability, and integrity of time synchronizati and implementations.
on is </t>
of critical importance. Extensive discussion of this topic can </section>
be <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
found in <xref target="RFC7384"/>. <name slugifiedName="name-privacy-considerations">Privacy Considerations</
</t><t> name>
DetNet use cases are known to have widely divergent security <t pn="section-6-1">
requirements. The intent of this section is to provide a baseli DetNet provides a QoS, and the generic
ne for
security considerations which are common to all DetNet designs
and
implementations, without burdening individual designs with spec
ifics
of security infrastructure which may not be germane to the give
n use
case. Designers and implementers of DetNet systems are expected
to
take use case specific considerations into account in their Det
Net
designs and implementations.
</t>
</section>
<section title="Privacy Considerations">
<t>
DetNet provides a Quality of Service (QoS), and the generic
considerations for such mechanisms apply. In particular, such mar kings considerations for such mechanisms apply. In particular, such mar kings
allow for an attacker to correlate flows or to select particular types allow for an attacker to correlate flows or to select particular types
of flow for more detailed inspection. of flow for more detailed inspection.
</t><t> </t>
<t pn="section-6-2">
However, the requirement for every (or almost every) node along t he path of However, the requirement for every (or almost every) node along t he path of
a DetNet flow to identify DetNet flows may present an additional attack a DetNet flow to identify DetNet flows may present an additional attack
surface for privacy, should the DetNet paradigm be found useful i n broader surface for privacy should the DetNet paradigm be found useful in broader
environments. environments.
</t> </t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
<section title="IANA Considerations"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>This document does not require an action from IANA. <t pn="section-7-1">This document has no IANA actions.
</t> </t>
</section> </section>
<section title="Acknowledgements">
<t>The authors wish to thank Lou Berger, David Black, Stewart Bryant,
Rodney Cummings, Ethan Grossman, Craig Gunther, Marcel Kiessling,
Rudy Klecka, Jouni Korhonen, Erik Nordmark, Shitanshu Shah,
Wilfried Steiner, George Swallow, Michael Johas Teener, Pat Thaler,
Thomas Watteyne, Patrick Wetterwald, Karl Weber, Anca Zamfir,
for their various contributions to this work.
</t>
</section>
</middle> </middle>
<back> <back>
<references title='Informative References'> <displayreference target="I-D.ietf-detnet-security" to="DETNET-SECURITY"/>
<displayreference target="I-D.ietf-detnet-ip" to="DETNET-IP"/>
<?rfc include='reference.I-D.ietf-6tisch-architecture'?> <displayreference target="I-D.ietf-detnet-data-plane-framework" to="DETNET-F
<?rfc include='reference.I-D.ietf-detnet-problem-statement'?> RAMEWORK"/>
<?rfc include='reference.I-D.ietf-detnet-use-cases'?> <displayreference target="I-D.ietf-detnet-mpls" to="DETNET-MPLS"/>
<?rfc include='reference.I-D.ietf-detnet-dp-sol-mpls'?> <displayreference target="I-D.ietf-6tisch-architecture" to="TSCH-ARCH"/>
<?rfc include='reference.I-D.ietf-detnet-dp-sol-ip'?> <references pn="section-8">
<?rfc include='reference.I-D.ietf-detnet-security'?> <name slugifiedName="name-informative-references">Informative References</
<?rfc include='reference.RFC.2205'?> name>
<?rfc include='reference.RFC.2475'?> <reference anchor="BUFFERBLOAT" quoteTitle="true" target="https://doi.org/
<?rfc include='reference.RFC.2914'?> 10.1145/2063176.2063196" derivedAnchor="BUFFERBLOAT">
<?rfc include='reference.RFC.3168'?> <front>
<?rfc include='reference.RFC.3209'?> <title>Bufferbloat: Dark Buffers in the Internet</title>
<?rfc include='reference.RFC.3550'?> <seriesInfo name="DOI" value="10.1145/2063176.2063196"/>
<?rfc include='reference.RFC.4301'?> <seriesInfo name="Communications of the ACM," value="Volume 55, Issue
<?rfc include='reference.RFC.4655'?> 1"/>
<?rfc include='reference.RFC.5921'?> <author initials="J." surname="Gettys" fullname="Jim Gettys">
<?rfc include='reference.RFC.6372'?> <organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.6658'?> </author>
<?rfc include='reference.RFC.7149'?> <author initials="K." surname="Nichols" fullname="Kathleen Nichols">
<?rfc include='reference.RFC.7384'?> <organization showOnFrontPage="true"/>
<?rfc include='reference.RFC.7426'?> </author>
<?rfc include='reference.RFC.7554'?> <date month="January" year="2012"/>
<?rfc include='reference.RFC.7567'?> </front>
<?rfc include='reference.RFC.7813'?> </reference>
<?rfc include='reference.RFC.8033'?> <reference anchor="CCAMP" target="https://datatracker.ietf.org/wg/ccamp/ch
<?rfc include='reference.RFC.8227'?> arter/" quoteTitle="true" derivedAnchor="CCAMP">
<?rfc include='reference.RFC.8289'?> <front>
<?rfc include='reference.RFC.8402'?> <title>Common Control and Measurement Plane (ccamp)</title>
<?rfc include='reference.RFC.8453'?> <author>
<organization showOnFrontPage="true">IETF</organization>
<reference anchor="IEC62439-3-2016" </author>
target="https://webstore.iec.ch/publication/24447"> <date/>
<front> </front>
<title>IEC 62439-3:2016 Industrial communication networks - Hig </reference>
h <reference anchor="I-D.ietf-detnet-data-plane-framework" quoteTitle="true"
target="https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-02"
derivedAnchor="DETNET-FRAMEWORK">
<front>
<title>DetNet Data Plane Framework</title>
<author initials="B" surname="Varga" fullname="Balazs Varga">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Farkas" fullname="Janos Farkas">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Berger" fullname="Lou Berger">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Fedyk" fullname="Don Fedyk">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Malis" fullname="Andrew Malis">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Bryant" fullname="Stewart Bryant">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization showOnFrontPage="true"/>
</author>
<date month="September" day="13" year="2019"/>
<abstract>
<t>This document provides an overall framework for the Deterministic
Networking data plane. It covers concepts and considerations that are generall
y common to any Deterministic Networking data plane specification.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-data-plane-fr
amework-02"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-iet
f-detnet-data-plane-framework-02.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-detnet-ip" quoteTitle="true" target="https://t
ools.ietf.org/html/draft-ietf-detnet-ip-01" derivedAnchor="DETNET-IP">
<front>
<title>DetNet Data Plane: IP</title>
<author initials="B" surname="Varga" fullname="Balazs Varga">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Farkas" fullname="Janos Farkas">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Berger" fullname="Lou Berger">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Fedyk" fullname="Don Fedyk">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Malis" fullname="Andrew Malis">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Bryant" fullname="Stewart Bryant">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization showOnFrontPage="true"/>
</author>
<date month="July" day="1" year="2019"/>
<abstract>
<t>This document specifies the Deterministic Networking data plane w
hen operating in an IP packet switched network.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-ip-01"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-iet
f-detnet-ip-01.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-detnet-mpls" quoteTitle="true" target="https:/
/tools.ietf.org/html/draft-ietf-detnet-mpls-01" derivedAnchor="DETNET-MPLS">
<front>
<title>DetNet Data Plane: MPLS</title>
<author initials="B" surname="Varga" fullname="Balazs Varga">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Farkas" fullname="Janos Farkas">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Berger" fullname="Lou Berger">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Fedyk" fullname="Don Fedyk">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Malis" fullname="Andrew Malis">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Bryant" fullname="Stewart Bryant">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization showOnFrontPage="true"/>
</author>
<date month="July" day="1" year="2019"/>
<abstract>
<t>This document specifies the Deterministic Networking data plane w
hen operating over an MPLS Packet Switched Networks.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-mpls-01"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-iet
f-detnet-mpls-01.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-detnet-security" quoteTitle="true" target="htt
ps://tools.ietf.org/html/draft-ietf-detnet-security-05" derivedAnchor="DETNET-SE
CURITY">
<front>
<title>Deterministic Networking (DetNet) Security Considerations</titl
e>
<author initials="T" surname="Mizrahi" fullname="Tal Mizrahi">
<organization showOnFrontPage="true"/>
</author>
<author initials="E" surname="Grossman" fullname="Ethan Grossman">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Hacker" fullname="Andrew Hacker">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Das" fullname="Subir Das">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Dowdell" fullname="John Dowdell">
<organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Austad" fullname="Henrik Austad">
<organization showOnFrontPage="true"/>
</author>
<author initials="K" surname="Stanton" fullname="Kevin Stanton">
<organization showOnFrontPage="true"/>
</author>
<author initials="N" surname="Finn" fullname="Norman Finn">
<organization showOnFrontPage="true"/>
</author>
<date month="August" day="29" year="2019"/>
<abstract>
<t>A deterministic network is one that can carry data flows for real
- time applications with extremely low data loss rates and bounded latency. Det
erministic networks have been successfully deployed in real-time operational tec
hnology (OT) applications for some years (for example [ARINC664P7]). However, s
uch networks are typically isolated from external access, and thus the security
threat from external attackers is low. IETF Deterministic Networking (DetNet) s
pecifies a set of technologies that enable creation of deterministic networks on
IP-based networks of potentially wide area (on the scale of a corporate network
) potentially bringing the OT network into contact with Information Technology (
IT) traffic and security threats that lie outside of a tightly controlled and bo
unded area (such as the internals of an aircraft). These DetNet technologies ha
ve not previously been deployed together on a wide area IP-based network, and th
us can present security considerations that may be new to IP- based wide area ne
twork designers. This draft, intended for use by DetNet network designers, prov
ides insight into these security considerations. In addition, this draft collec
ts all security- related statements from the various DetNet drafts (Architecture
, Use Cases, etc) into a single location Section 8.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-security-05"/
>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-iet
f-detnet-security-05.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="IEC-62439-3" target="https://webstore.iec.ch/publicatio
n/24447" quoteTitle="true" derivedAnchor="IEC-62439-3">
<front>
<title>Industrial communication networks - High
availability automation networks - Part 3: Parallel Redundan cy availability automation networks - Part 3: Parallel Redundan cy
Protocol (PRP) and High-availability Seamless Redundancy (HS R) Protocol (PRP) and High-availability Seamless Redundancy (HS R)
</title> </title>
<author> <seriesInfo name="TC 65 /" value="SC 65C"/>
<organization>International Electrotechnical Commission ( <seriesInfo name="IEC" value="62439-3:2016"/>
IEC) <author>
TC 65/SC 65C - Industrial networks</organization> <organization showOnFrontPage="true">IEC</organization>
</author> </author>
<date year="2016" /> <date month="March" year="2016"/>
</front> </front>
</reference>
<reference anchor="IEEE802.1AE-2018"
target="https://ieeexplore.ieee.org/document/8585421">
<front>
<title>IEEE Std 802.1AE-2018 MAC Security (MACsec)</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date year="2018" />
</front>
</reference>
<reference anchor="IEEE802.1CB"
target="https://ieeexplore.ieee.org/document/8091139/">
<front>
<title>IEEE Std 802.1CB-2017 Frame Replication and Elimination
for Reliability</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date year="2017" />
</front>
</reference>
<reference anchor="IEEE802.1Q-2018"
target="https://ieeexplore.ieee.org/document/8403927">
<front>
<title>IEEE Std 802.1Q-2018 Bridges and Bridged Networks</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date year="2018" />
</front>
</reference> </reference>
<reference anchor="IEEE802.1AE" target="https://ieeexplore.ieee.org/docume
<reference anchor="IEEE802.1Qav" nt/8585421" quoteTitle="true" derivedAnchor="IEEE802.1AE">
target="https://ieeexplore.ieee.org/document/5375704/"> <front>
<front> <title>IEEE Standard for Local and metropolitan area
<title>IEEE Std 802.1Qav-2009 Bridges and Bridged Networks - Amend networks-Media Access Control (MAC) Security</title>
ment 12: <seriesInfo name="IEEE" value="802.1AE-2018"/>
Forwarding and Queuing Enhancements for Time-Sensitive <author>
Streams</title> <organization showOnFrontPage="true">IEEE</organization>
<author> </author>
<organization>IEEE Standards Association</organ </front>
ization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="IEEE802.1Qbu"
target="https://ieeexplore.ieee.org/document/7553415/">
<front>
<title>IEEE Std 802.1Qbu-2016 Bridges and Bridged Networks - Amend
ment 26: Frame Preemption</title>
<author>
<organization>IEEE Standards Association</organ
ization>
</author>
<date year="2016" />
</front>
</reference>
<reference anchor="IEEE802.1Qbv"
target="https://ieeexplore.ieee.org/document/7572858/">
<front>
<title>IEEE Std 802.1Qbv-2015 Bridges and Bridged Networks - Amend
ment 25: Enhancements for Scheduled Traffic</title>
<author>
<organization>IEEE Standards Association</organ
ization>
</author>
<date year="2015" />
</front>
</reference>
<reference anchor="IEEE802.1BA"
target="https://ieeexplore.ieee.org/document/6032690/">
<front>
<title>IEEE Std 802.1BA-2011 Audio Video Bridging (AVB) Systems
</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date year="2011" />
</front>
</reference>
<reference anchor="IEEE802.1Qch"
target="https://ieeexplore.ieee.org/document/7961303/">
<front>
<title>IEEE Std 802.1Qch-2017 Bridges and Bridged Netwo
rks - Amendment 29: Cyclic Queuing and Forwarding</title>
<author>
<organization>IEEE Standards Association</organ
ization>
</author>
<date year="2017" />
</front>
</reference>
<reference anchor="IEEE802.3-2018"
target="https://ieeexplore.ieee.org/document/8457469">
<front>
<title>IEEE Std 802.3-2018 Standard for Ethernet</title
>
<author>
<organization>IEEE Standards Association</organ
ization>
</author>
<date year="2018" />
</front>
</reference>
<reference anchor="IEEE802.3br"
target="http://ieeexplore.ieee.org/document/7900321/">
<front>
<title>IEEE Std 802.3br-2016 Standard for Ethernet Amen
dment 5:
Specification and Management Parameters for Interspersing Expr
ess Traffic</title>
<author>
<organization>IEEE Standards Association</organ
ization>
</author>
<date year="2016" />
</front>
</reference>
<reference anchor="IEEE802.1TSNTG" target="http://www.ieee802.org/1/tsn
">
<front>
<title>IEEE 802.1 Time-Sensitive Networking Task Group</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date></date>
</front>
</reference>
<reference anchor="TEAS" target="https://datatracker.ietf.org/doc/charter-
ietf-teas/">
<front>
<title>Traffic Engineering Architecture and Signaling Working Group<
/title>
<author>
<organization>IETF</organization>
</author>
<date></date>
</front>
</reference> </reference>
<reference anchor="IEEE802.1BA" target="https://ieeexplore.ieee.org/docume
<reference anchor="CCAMP" target="https://datatracker.ietf.org/doc/char nt/6032690" quoteTitle="true" derivedAnchor="IEEE802.1BA">
ter-ietf-ccamp/"> <front>
<front> <title>IEEE Standard for Local and metropolitan area
<title>Common Control and Measurement Plane Working Group</title> networks--Audio Video Bridging (AVB) Systems</title>
<author> <seriesInfo name="IEEE" value="802.1BA-2011"/>
<organization>IETF</organization> <author>
</author> <organization showOnFrontPage="true">IEEE</organization>
<date></date> </author>
</front> </front>
</reference> </reference>
<reference anchor="IEEE802.1CB" target="https://ieeexplore.ieee.org/docume
<reference anchor="BUFFERBLOAT"> nt/8091139" quoteTitle="true" derivedAnchor="IEEE802.1CB">
<front> <front>
<title>Bufferbloat: Dark Buffers in the Internet</title> <title>IEEE Standard for Local and metropolitan area
networks--Frame Replication and Elimination for Reliability</ti
<author fullname="J. Gettys" initials="J." surname="Gettys"></author> tle>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8091139"/>
<author fullname="K. Nichols" initials="K." surname="Nichols"></author <seriesInfo name="IEEE" value="802.1CB-2017"/>
> <author>
<organization showOnFrontPage="true">IEEE</organization>
<date month="January" year="2012" /> </author>
<date/>
</front> </front>
<format octets="Communications of the ACM, Volume 55 Issue 1, Pages 57-6
5 " target="https://dl.acm.org/citation.cfm?id=2063176.2063196" type="PDF" />
</reference> </reference>
<reference anchor="IEEE802.1Q" target="https://ieeexplore.ieee.org/documen
</references> t/8403927" quoteTitle="true" derivedAnchor="IEEE802.1Q">
<front>
<title>IEEE Standard for Local and Metropolitan Area
Network--Bridges and Bridged Networks</title>
<seriesInfo name="IEEE" value="802.1Q-2018"/>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
</front>
</reference>
<reference anchor="IEEE802.1Qav" target="https://ieeexplore.ieee.org/docum
ent/5375704" quoteTitle="true" derivedAnchor="IEEE802.1Qav">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks -
Virtual Bridged Local Area Networks Amendment 12: Forwarding and
Queuing Enhancements for Time-Sensitive Streams</title>
<seriesInfo name="IEEE" value="802.1Qav-2009"/>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
</front>
</reference>
<reference anchor="IEEE802.1Qbu" target="https://ieeexplore.ieee.org/docum
ent/7553415" quoteTitle="true" derivedAnchor="IEEE802.1Qbu">
<front>
<title>IEEE Standard for Local and metropolitan area networks --
Bridges and Bridged Networks -- Amendment 26: Frame Preemption</tit
le>
<seriesInfo name="IEEE" value="802.1Qbu-2016"/>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
</front>
</reference>
<reference anchor="IEEE802.1Qbv" target="https://ieeexplore.ieee.org/docum
ent/7440741" quoteTitle="true" derivedAnchor="IEEE802.1Qbv">
<front>
<title>IEEE Standard for Local and metropolitan area networks --
Bridges and Bridged Networks - Amendment 25: Enhancements for
Scheduled Traffic</title>
<seriesInfo name="IEEE" value="802.1Qbv-2015"/>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
</front>
</reference>
<reference anchor="IEEE802.1Qch" target="https://ieeexplore.ieee.org/docum
ent/7961303" quoteTitle="true" derivedAnchor="IEEE802.1Qch">
<front>
<title>IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks--Amendment
29: Cyclic Queuing and Forwarding</title>
<seriesInfo name="IEEE" value="802.1Qch-2017"/>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
</front>
</reference>
<reference anchor="IEEE802.1TSNTG" target="https://1.ieee802.org/tsn/" quo
teTitle="true" derivedAnchor="IEEE802.1TSNTG">
<front>
<title>Time-Sensitive Networking (TSN) Task Group</title>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
</front>
</reference>
<reference anchor="IEEE802.3" target="https://ieeexplore.ieee.org/document
/8457469" quoteTitle="true" derivedAnchor="IEEE802.3">
<front>
<title>IEEE Standard for Ethernet</title>
<seriesInfo name="IEEE" value="802.3-2018"/>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
</front>
</reference>
<reference anchor="IEEE802.3br" target="https://ieeexplore.ieee.org/docume
nt/7900321" quoteTitle="true" derivedAnchor="IEEE802.3br">
<front>
<title>IEEE Standard for Ethernet Amendment 5:
Specification and Management Parameters for
Interspersing Express Traffic</title>
<seriesInfo name="IEEE" value="802.3br"/>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
</front>
</reference>
<reference anchor="RFC2205" target="https://www.rfc-editor.org/info/rfc220
5" quoteTitle="true" derivedAnchor="RFC2205">
<front>
<title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Sp
ecification</title>
<author initials="R." surname="Braden" fullname="R. Braden" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Zhang" fullname="L. Zhang">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Berson" fullname="S. Berson">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Herzog" fullname="S. Herzog">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Jamin" fullname="S. Jamin">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="September"/>
<abstract>
<t>This memo describes version 1 of RSVP, a resource reservation set
up protocol designed for an integrated services Internet. RSVP provides receive
r-initiated setup of resource reservations for multicast or unicast data flows,
with good scaling and robustness properties. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2205"/>
<seriesInfo name="DOI" value="10.17487/RFC2205"/>
</reference>
<reference anchor="RFC2475" target="https://www.rfc-editor.org/info/rfc247
5" quoteTitle="true" derivedAnchor="RFC2475">
<front>
<title>An Architecture for Differentiated Services</title>
<author initials="S." surname="Blake" fullname="S. Blake">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Black" fullname="D. Black">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Carlson" fullname="M. Carlson">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Davies" fullname="E. Davies">
<organization showOnFrontPage="true"/>
</author>
<author initials="Z." surname="Wang" fullname="Z. Wang">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Weiss" fullname="W. Weiss">
<organization showOnFrontPage="true"/>
</author>
<date year="1998" month="December"/>
<abstract>
<t>This document defines an architecture for implementing scalable s
ervice differentiation in the Internet. This memo provides information for the
Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2475"/>
<seriesInfo name="DOI" value="10.17487/RFC2475"/>
</reference>
<reference anchor="RFC2914" target="https://www.rfc-editor.org/info/rfc291
4" quoteTitle="true" derivedAnchor="RFC2914">
<front>
<title>Congestion Control Principles</title>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization showOnFrontPage="true"/>
</author>
<date year="2000" month="September"/>
<abstract>
<t>The goal of this document is to explain the need for congestion c
ontrol in the Internet, and to discuss what constitutes correct congestion contr
ol. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="41"/>
<seriesInfo name="RFC" value="2914"/>
<seriesInfo name="DOI" value="10.17487/RFC2914"/>
</reference>
<reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc316
8" quoteTitle="true" derivedAnchor="RFC3168">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP</t
itle>
<author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan
">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Black" fullname="D. Black">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="September"/>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congestion
Notification) to TCP and IP, including ECN's use of two bits in the IP header.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>
<reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc320
9" quoteTitle="true" derivedAnchor="RFC3209">
<front>
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
<author initials="D." surname="Awduche" fullname="D. Awduche">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Berger" fullname="L. Berger">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Gan" fullname="D. Gan">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="December"/>
<abstract>
<t>This document describes the use of RSVP (Resource Reservation Pro
tocol), including all the necessary extensions, to establish label-switched path
s (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP
is completely identified by the label applied at the ingress node of the path, t
hese paths may be treated as tunnels. A key application of LSP tunnels is traff
ic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3209"/>
<seriesInfo name="DOI" value="10.17487/RFC3209"/>
</reference>
<reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc355
0" quoteTitle="true" derivedAnchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Frederick" fullname="R. Frederick">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="July"/>
<abstract>
<t>This memorandum describes RTP, the real-time transport protocol.
RTP provides end-to-end network transport functions suitable for applications t
ransmitting real-time data, such as audio, video or simulation data, over multic
ast or unicast network services. RTP does not address resource reservation and
does not guarantee quality-of- service for real-time services. The data transpo
rt is augmented by a control protocol (RTCP) to allow monitoring of the data del
ivery in a manner scalable to large multicast networks, and to provide minimal c
ontrol and identification functionality. RTP and RTCP are designed to be indepe
ndent of the underlying transport and network layers. The protocol supports the
use of RTP-level translators and mixers. Most of the text in this memorandum is
identical to RFC 1889 which it obsoletes. There are no changes in the packet f
ormats on the wire, only changes to the rules and algorithms governing how the p
rotocol is used. The biggest change is an enhancement to the scalable timer algo
rithm for calculating when to send RTCP packets in order to minimize transmissio
n in excess of the intended rate when many participants join a session simultane
ously. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc430
1" quoteTitle="true" derivedAnchor="RFC4301">
<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Seo" fullname="K. Seo">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="December"/>
<abstract>
<t>This document describes an updated version of the "Security Archi
tecture for IP", which is designed to provide security services for traffic at t
he IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4301"/>
<seriesInfo name="DOI" value="10.17487/RFC4301"/>
</reference>
<reference anchor="RFC4655" target="https://www.rfc-editor.org/info/rfc465
5" quoteTitle="true" derivedAnchor="RFC4655">
<front>
<title>A Path Computation Element (PCE)-Based Architecture</title>
<author initials="A." surname="Farrel" fullname="A. Farrel">
<organization showOnFrontPage="true"/>
</author>
<author initials="J.-P." surname="Vasseur" fullname="J.-P. Vasseur">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Ash" fullname="J. Ash">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="August"/>
<abstract>
<t>Constraint-based path computation is a fundamental building block
for traffic engineering systems such as Multiprotocol Label Switching (MPLS) an
d Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation
in large, multi-domain, multi-region, or multi-layer networks is complex and may
require special computational components and cooperation between the different
network domains.</t>
<t>This document specifies the architecture for a Path Computation E
lement (PCE)-based model to address this problem space. This document does not
attempt to provide a detailed description of all the architectural components, b
ut rather it describes a set of building blocks for the PCE architecture from wh
ich solutions may be constructed. This memo provides information for the Intern
et community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4655"/>
<seriesInfo name="DOI" value="10.17487/RFC4655"/>
</reference>
<reference anchor="RFC6372" target="https://www.rfc-editor.org/info/rfc637
2" quoteTitle="true" derivedAnchor="RFC6372">
<front>
<title>MPLS Transport Profile (MPLS-TP) Survivability Framework</title
>
<author initials="N." surname="Sprecher" fullname="N. Sprecher" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Farrel" fullname="A. Farrel" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="September"/>
<abstract>
<t>Network survivability is the ability of a network to recover traf
fic delivery following failure or degradation of network resources. Survivabili
ty is critical for the delivery of guaranteed network services, such as those su
bject to strict Service Level Agreements (SLAs) that place maximum bounds on the
length of time that services may be degraded or unavailable.</t>
<t>The Transport Profile of Multiprotocol Label Switching (MPLS-TP)
is a packet-based transport technology based on the MPLS data plane that reuses
many aspects of the MPLS management and control planes.</t>
<t>This document comprises a framework for the provision of survivab
ility in an MPLS-TP network; it describes recovery elements, types, methods, and
topological considerations. To enable data-plane recovery, survivability may b
e supported by the control plane, management plane, and by Operations, Administr
ation, and Maintenance (OAM) functions. This document describes mechanisms for r
ecovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudo
wire recovery in MPLS-TP networks is beyond the scope of this document.</t>
<t>This document is a product of a joint Internet Engineering Task F
orce (IETF) / International Telecommunication Union Telecommunication Standardiz
ation Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF
MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the
capabilities and functionalities of a packet-based transport network as defined
by the ITU-T. </t>
<t>This document is not an Internet Standards Track specification; i
t is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6372"/>
<seriesInfo name="DOI" value="10.17487/RFC6372"/>
</reference>
<reference anchor="RFC6658" target="https://www.rfc-editor.org/info/rfc665
8" quoteTitle="true" derivedAnchor="RFC6658">
<front>
<title>Packet Pseudowire Encapsulation over an MPLS PSN</title>
<author initials="S." surname="Bryant" fullname="S. Bryant" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Martini" fullname="L. Martini">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Malis" fullname="A. Malis">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="July"/>
<abstract>
<t>This document describes a pseudowire mechanism that is used to tr
ansport a packet service over an MPLS PSN in the case where the client Label Swi
tching Router (LSR) and the server Provider Edge equipments are co-resident in t
he same equipment. This pseudowire mechanism may be used to carry all of the re
quired layer 2 and layer 3 protocols between the pair of client LSRs. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6658"/>
<seriesInfo name="DOI" value="10.17487/RFC6658"/>
</reference>
<reference anchor="RFC7149" target="https://www.rfc-editor.org/info/rfc714
9" quoteTitle="true" derivedAnchor="RFC7149">
<front>
<title>Software-Defined Networking: A Perspective from within a Servic
e Provider Environment</title>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Jacquenet" fullname="C. Jacquenet">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="March"/>
<abstract>
<t>Software-Defined Networking (SDN) has been one of the major buzz
words of the networking industry for the past couple of years. And yet, no clea
r definition of what SDN actually covers has been broadly admitted so far. This
document aims to clarify the SDN landscape by providing a perspective on requir
ements, issues, and other considerations about SDN, as seen from within a servic
e provider environment.</t>
<t>It is not meant to endlessly discuss what SDN truly means but rat
her to suggest a functional taxonomy of the techniques that can be used under an
SDN umbrella and to elaborate on the various pending issues the combined activa
tion of such techniques inevitably raises. As such, a definition of SDN is only
mentioned for the sake of clarification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7149"/>
<seriesInfo name="DOI" value="10.17487/RFC7149"/>
</reference>
<reference anchor="RFC7384" target="https://www.rfc-editor.org/info/rfc738
4" quoteTitle="true" derivedAnchor="RFC7384">
<front>
<title>Security Requirements of Time Protocols in Packet Switched Netw
orks</title>
<author initials="T." surname="Mizrahi" fullname="T. Mizrahi">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="October"/>
<abstract>
<t>As time and frequency distribution protocols are becoming increas
ingly common and widely deployed, concern about their exposure to various securi
ty threats is increasing. This document defines a set of security requirements
for time protocols, focusing on the Precision Time Protocol (PTP) and the Networ
k Time Protocol (NTP). This document also discusses the security impacts of time
protocol practices, the performance implications of external security practices
on time protocols, and the dependencies between other security services and tim
e synchronization.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7384"/>
<seriesInfo name="DOI" value="10.17487/RFC7384"/>
</reference>
<reference anchor="RFC7426" target="https://www.rfc-editor.org/info/rfc742
6" quoteTitle="true" derivedAnchor="RFC7426">
<front>
<title>Software-Defined Networking (SDN): Layers and Architecture Term
inology</title>
<author initials="E." surname="Haleplidis" fullname="E. Haleplidis" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Pentikousis" fullname="K. Pentikousis"
role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Denazis" fullname="S. Denazis">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hadi Salim" fullname="J. Hadi Salim">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Meyer" fullname="D. Meyer">
<organization showOnFrontPage="true"/>
</author>
<author initials="O." surname="Koufopavlou" fullname="O. Koufopavlou">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="January"/>
<abstract>
<t>Software-Defined Networking (SDN) refers to a new approach for ne
twork programmability, that is, the capacity to initialize, control, change, and
manage network behavior dynamically via open interfaces. SDN emphasizes the ro
le of software in running networks through the introduction of an abstraction fo
r the data forwarding plane and, by doing so, separates it from the control plan
e. This separation allows faster innovation cycles at both planes as experience
has already shown. However, there is increasing confusion as to what exactly S
DN is, what the layer structure is in an SDN architecture, and how layers interf
ace with each other. This document, a product of the IRTF Software-Defined Netw
orking Research Group (SDNRG), addresses these questions and provides a concise
reference for the SDN research community based on relevant peer-reviewed literat
ure, the RFC series, and relevant documents by other standards organizations.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="7426"/>
<seriesInfo name="DOI" value="10.17487/RFC7426"/>
</reference>
<reference anchor="RFC7554" target="https://www.rfc-editor.org/info/rfc755
4" quoteTitle="true" derivedAnchor="RFC7554">
<front>
<title>Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement</title>
<author initials="T." surname="Watteyne" fullname="T. Watteyne" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Palattella" fullname="M. Palattella">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Grieco" fullname="L. Grieco">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="May"/>
<abstract>
<t>This document describes the environment, problem statement, and g
oals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MA
C) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LL
Ns). The set of goals enumerated in this document form an initial set only.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7554"/>
<seriesInfo name="DOI" value="10.17487/RFC7554"/>
</reference>
<reference anchor="RFC7567" target="https://www.rfc-editor.org/info/rfc756
7" quoteTitle="true" derivedAnchor="RFC7567">
<front>
<title>IETF Recommendations Regarding Active Queue Management</title>
<author initials="F." surname="Baker" fullname="F. Baker" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="July"/>
<abstract>
<t>This memo presents recommendations to the Internet community conc
erning measures to improve and preserve Internet performance. It presents a str
ong recommendation for testing, standardization, and widespread deployment of ac
tive queue management (AQM) in network devices to improve the performance of tod
ay's Internet. It also urges a concerted effort of research, measurement, and u
ltimate deployment of AQM mechanisms to protect the Internet from flows that are
not sufficiently responsive to congestion notification.</t>
<t>Based on 15 years of experience and new research, this document r
eplaces the recommendations of RFC 2309.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="197"/>
<seriesInfo name="RFC" value="7567"/>
<seriesInfo name="DOI" value="10.17487/RFC7567"/>
</reference>
<reference anchor="RFC7813" target="https://www.rfc-editor.org/info/rfc781
3" quoteTitle="true" derivedAnchor="RFC7813">
<front>
<title>IS-IS Path Control and Reservation</title>
<author initials="J." surname="Farkas" fullname="J. Farkas" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Bragg" fullname="N. Bragg">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Unbehagen" fullname="P. Unbehagen">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Parsons" fullname="G. Parsons">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Ashwood-Smith" fullname="P. Ashwood-Smi
th">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bowers" fullname="C. Bowers">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="June"/>
<abstract>
<t>IEEE 802.1Qca Path Control and Reservation (PCR) specifies explic
it path control via IS-IS in Layer 2 networks in order to move beyond the shorte
st path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-
IS PCR provides capabilities for the establishment and control of explicit forwa
rding trees in a Layer 2 network domain. This document specifies the sub-TLVs f
or IS-IS PCR.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7813"/>
<seriesInfo name="DOI" value="10.17487/RFC7813"/>
</reference>
<reference anchor="RFC8033" target="https://www.rfc-editor.org/info/rfc803
3" quoteTitle="true" derivedAnchor="RFC8033">
<front>
<title>Proportional Integral Controller Enhanced (PIE): A Lightweight
Control Scheme to Address the Bufferbloat Problem</title>
<author initials="R." surname="Pan" fullname="R. Pan">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Natarajan" fullname="P. Natarajan">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Baker" fullname="F. Baker">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="White" fullname="G. White">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="February"/>
<abstract>
<t>Bufferbloat is a phenomenon in which excess buffers in the networ
k cause high latency and latency variation. As more and more interactive applic
ations (e.g., voice over IP, real-time video streaming, and financial transactio
ns) run in the Internet, high latency and latency variation degrade application
performance. There is a pressing need to design intelligent queue management sc
hemes that can control latency and latency variation, and hence provide desirabl
e quality of service to users.</t>
<t>This document presents a lightweight active queue management desi
gn called "PIE" (Proportional Integral controller Enhanced) that can effectively
control the average queuing latency to a target value. Simulation results, theo
retical analysis, and Linux testbed results have shown that PIE can ensure low l
atency and achieve high link utilization under various congestion situations. T
he design does not require per-packet timestamps, so it incurs very little overh
ead and is simple enough to implement in both hardware and software.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8033"/>
<seriesInfo name="DOI" value="10.17487/RFC8033"/>
</reference>
<reference anchor="RFC8227" target="https://www.rfc-editor.org/info/rfc822
7" quoteTitle="true" derivedAnchor="RFC8227">
<front>
<title>MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topolo
gy</title>
<author initials="W." surname="Cheng" fullname="W. Cheng">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Wang" fullname="L. Wang">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Li" fullname="H. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="van Helvoort" fullname="H. van Helvoort
">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Dong" fullname="J. Dong">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="August"/>
<abstract>
<t>This document describes requirements, architecture, and solutions
for MPLS-TP Shared-Ring Protection (MSRP) in a ring topology for point- to-poin
t (P2P) services. The MSRP mechanism is described to meet the ring protection r
equirements as described in RFC 5654. This document defines the Ring Protection
Switching (RPS) protocol that is used to coordinate the protection behavior of
the nodes on an MPLS ring.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8227"/>
<seriesInfo name="DOI" value="10.17487/RFC8227"/>
</reference>
<reference anchor="RFC8289" target="https://www.rfc-editor.org/info/rfc828
9" quoteTitle="true" derivedAnchor="RFC8289">
<front>
<title>Controlled Delay Active Queue Management</title>
<author initials="K." surname="Nichols" fullname="K. Nichols">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="McGregor" fullname="A. McGregor" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Iyengar" fullname="J. Iyengar" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="January"/>
<abstract>
<t>This document describes CoDel (Controlled Delay) -- a general fra
mework that controls bufferbloat-generated excess delay in modern networking env
ironments. CoDel consists of an estimator, a setpoint, and a control loop. It
requires no configuration in normal Internet deployments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8289"/>
<seriesInfo name="DOI" value="10.17487/RFC8289"/>
</reference>
<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc840
2" quoteTitle="true" derivedAnchor="RFC8402">
<front>
<title>Segment Routing Architecture</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Litkowski" fullname="S. Litkowski">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="July"/>
<abstract>
<t>Segment Routing (SR) leverages the source routing paradigm. A no
de steers a packet through an ordered list of instructions, called "segments".
A segment can represent any instruction, topological or service based. A segmen
t can have a semantic local to an SR node or global within an SR domain. SR pro
vides a mechanism that allows a flow to be restricted to a specific topological
path, while maintaining per-flow state only at the ingress node(s) to the SR dom
ain.</t>
<t>SR can be directly applied to the MPLS architecture with no chang
e to the forwarding plane. A segment is encoded as an MPLS label. An ordered l
ist of segments is encoded as a stack of labels. The segment to process is on t
he top of the stack. Upon completion of a segment, the related label is popped
from the stack.</t>
<t>SR can be applied to the IPv6 architecture, with a new type of ro
uting header. A segment is encoded as an IPv6 address. An ordered list of segm
ents is encoded as an ordered list of IPv6 addresses in the routing header. The
active segment is indicated by the Destination Address (DA) of the packet. The
next active segment is indicated by a pointer in the new routing header.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8402"/>
<seriesInfo name="DOI" value="10.17487/RFC8402"/>
</reference>
<reference anchor="RFC8453" target="https://www.rfc-editor.org/info/rfc845
3" quoteTitle="true" derivedAnchor="RFC8453">
<front>
<title>Framework for Abstraction and Control of TE Networks (ACTN)</ti
tle>
<author initials="D." surname="Ceccarelli" fullname="D. Ceccarelli" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t>Traffic Engineered (TE) networks have a variety of mechanisms to
facilitate the separation of the data plane and control plane. They also have a
range of management and provisioning protocols to configure and activate networ
k resources. These mechanisms represent key technologies for enabling flexible
and dynamic networking. The term "Traffic Engineered network" refers to a netwo
rk that uses any connection-oriented technology under the control of a distribut
ed or centralized control plane to support dynamic provisioning of end-to- end c
onnectivity.</t>
<t>Abstraction of network resources is a technique that can be appli
ed to a single network domain or across multiple domains to create a single virt
ualized network that is under the control of a network operator or the customer
of the operator that actually owns the network resources.</t>
<t>This document provides a framework for Abstraction and Control of
TE Networks (ACTN) to support virtual network services and connectivity service
s.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8453"/>
<seriesInfo name="DOI" value="10.17487/RFC8453"/>
</reference>
<reference anchor="RFC8557" target="https://www.rfc-editor.org/info/rfc855
7" quoteTitle="true" derivedAnchor="RFC8557">
<front>
<title>Deterministic Networking Problem Statement</title>
<author initials="N." surname="Finn" fullname="N. Finn">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="May"/>
<abstract>
<t>This paper documents the needs in various industries to establish
multi-hop paths for characterized flows with deterministic properties.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8557"/>
<seriesInfo name="DOI" value="10.17487/RFC8557"/>
</reference>
<reference anchor="RFC8578" target="https://www.rfc-editor.org/info/rfc857
8" quoteTitle="true" derivedAnchor="RFC8578">
<front>
<title>Deterministic Networking Use Cases</title>
<author initials="E." surname="Grossman" fullname="E. Grossman" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="May"/>
<abstract>
<t>This document presents use cases for diverse industries that have
in common a need for "deterministic flows". "Deterministic" in this context me
ans that such flows provide guaranteed bandwidth, bounded latency, and other pro
perties germane to the transport of time-sensitive data. These use cases differ
notably in their network topologies and specific desired behavior, providing as
a group broad industry context for Deterministic Networking (DetNet). For each
use case, this document will identify the use case, identify representative sol
utions used today, and describe potential improvements that DetNet can enable.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="8578"/>
<seriesInfo name="DOI" value="10.17487/RFC8578"/>
</reference>
<reference anchor="TEAS" target="https://datatracker.ietf.org/doc/charter-
ietf-teas/" quoteTitle="true" derivedAnchor="TEAS">
<front>
<title>Traffic Engineering Architecture and Signaling (teas)</title>
<author>
<organization showOnFrontPage="true">IETF</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="I-D.ietf-6tisch-architecture" quoteTitle="true" target=
"https://tools.ietf.org/html/draft-ietf-6tisch-architecture-26" derivedAnchor="T
SCH-ARCH">
<front>
<title>An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4</t
itle>
<author initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization showOnFrontPage="true"/>
</author>
<date month="August" day="27" year="2019"/>
<abstract>
<t>This document describes a network architecture that provides low-
latency, low-jitter and high-reliability packet delivery. It combines a high-s
peed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel h
opping (TSCH) to meet the requirements of LowPower wireless deterministic applic
ations.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-architecture-
26"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-iet
f-6tisch-architecture-26.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
</references>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t pn="section-appendix.a-1">The authors wish to thank Lou Berger, David B
lack, Stewart
Bryant, Rodney Cummings, Ethan Grossman, Craig Gunther, Marcel
Kiessling, Rudy Klecka, Jouni Korhonen, Erik Nordmark, Shitanshu
Shah, Wilfried Steiner, George Swallow, Michael Johas Teener, Pat
Thaler, Thomas Watteyne, Patrick Wetterwald, Karl Weber, and Anca
Zamfir for their various contributions to this work.
</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="N" surname="Finn" fullname="Norman Finn">
<organization showOnFrontPage="true">Huawei</organization>
<address>
<postal>
<street>3101 Rio Way</street>
<city>Spring Valley</city>
<region>California</region>
<code>91977</code>
<country>United States of America</country>
</postal>
<phone>+1 925 980 6430</phone>
<email>nfinn@nfinnconsulting.com</email>
</address>
</author>
<author initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization abbrev="Cisco" showOnFrontPage="true">
Cisco Systems
</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street>
<street>
Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>France</country>
</postal>
<phone>+33 4 97 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author fullname="Balázs Varga" initials="B." surname="Varga">
<organization showOnFrontPage="true">Ericsson</organization>
<address>
<postal>
<street>Magyar tudosok korutja 11</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1117</code>
</postal>
<email>balazs.a.varga@ericsson.com</email>
</address>
</author>
<author fullname="János Farkas" initials="J." surname="Farkas">
<organization showOnFrontPage="true">Ericsson</organization>
<address>
<postal>
<street>Magyar tudosok korutja 11</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1117</code>
</postal>
<email>janos.farkas@ericsson.com</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 133 change blocks. 
2308 lines changed or deleted 3516 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/