rfc9912.original.xml   rfc9912.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" docN
<!-- Compiles with XML2RFC v3 https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc-dev ame="draft-ietf-raw-architecture-30" number="9912" consensus="true" ipr="trust20
.cgi --> 0902" updates="" tocInclude="true" obsoletes="" submissionType="IETF" xml:lang="
en" sortRefs="true" symRefs="true" prepTime="2026-04-09T13:52:03" indexInclude="
<?rfc toc="yes"?> true" scripts="Common,Latin" tocDepth="3">
<?rfc tocompact="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-raw-architecture-30" r
<?rfc tocdepth="3"?> el="prev"/>
<?rfc tocindent="yes"?> <link href="https://dx.doi.org/10.17487/rfc9912" rel="alternate"/>
<?rfc symrefs="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
etf-raw-architecture-30"
ipr="trust200902" obsoletes="" submissionType="IETF"
xml:lang="en" version="3">
<front> <front>
<title abbrev="RAW Architecture">Reliable and Available Wireless <title abbrev="RAW Architecture">Reliable and Available Wireless (RAW) Archi
Architecture</title> tecture</title>
<seriesInfo name="RFC" value="9912" stream="IETF"/>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="edito
'> r">
<organization abbrev=''>Without Affiliation</organization> <organization showOnFrontPage="true">Independent</organization>
<address> <address>
<postal> <postal>
<city>Roquefort-les-Pins</city> <city>Roquefort-les-Pins</city>
<code>06330</code> <code>06330</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>pascal.thubert@gmail.com</email> <email>pascal.thubert@gmail.com</email>
</address> </address>
</author> </author>
<date month="04" year="2026"/>
<date/> <area>RTG</area>
<area>Routing Area</area> <workgroup>detnet</workgroup>
<workgroup>DetNet</workgroup> <keyword>DetNet</keyword>
<keyword>Draft</keyword> <abstract pn="section-abstract">
<abstract> <t indent="0" pn="section-abstract-1">
<t>
Reliable and Available Wireless (RAW) extends the reliability and Reliable and Available Wireless (RAW) extends the reliability and
availability of DetNet to networks composed of any combination of wired an d availability of Deterministic Networking (DetNet) to networks composed of any combination of wired and
wireless segments. wireless segments.
The RAW Architecture leverages and extends RFC 8655, the The RAW architecture leverages and extends RFC 8655 ("Deterministic
Deterministic Networking Architecture, to adapt to challenges that Networking Architecture") to adapt to challenges that prominently affect
affect prominently the wireless medium, notably intermittent transmission the wireless medium, notably intermittent transmission loss.
loss.
This document defines a network control loop that optimizes the use of This document defines a network control loop that optimizes the use of
constrained bandwidth and energy while assuring the expected constrained bandwidth and energy while ensuring the expected
DetNet services. DetNet services.
The loop involves a new Point of Local Repair (PLR) function in The loop involves a new Point of Local Repair (PLR) function in
the DetNet Service sub-layer that dynamically selects the DetNet the DetNet Service sub-layer that dynamically selects the DetNet
path(s) for packets to route around local connectivity degradation. path(s) for packets to route around local connectivity degradation.
</t> </t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This document is not an Internet Standards Track specification; it i
s
published for informational purposes.
</t>
<t indent="0" 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). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
</t>
<t indent="0" 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/rfc9912" brackets="non
e"/>.
</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 indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" 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" brackets="none
"/>) in effect on 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 Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-the-raw-proble
m">The RAW Problem</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-terminology">Terminology</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><
xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ab
breviations">Abbreviations</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-link-and-direction">Li
nk and Direction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.2.2">
<li pn="section-toc.1-1.3.2.2.2.1">
<t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derived
Content="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-flapping">
Flapping</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derived
Content="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-uplink">Up
link</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.3">
<t indent="0" pn="section-toc.1-1.3.2.2.2.3.1"><xref derived
Content="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-downlink">
Downlink</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.4">
<t indent="0" pn="section-toc.1-1.3.2.2.2.4.1"><xref derived
Content="3.2.4" format="counter" sectionFormat="of" target="section-3.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-downstream
">Downstream</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.5">
<t indent="0" pn="section-toc.1-1.3.2.2.2.5.1"><xref derived
Content="3.2.5" format="counter" sectionFormat="of" target="section-3.2.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-upstream">
Upstream</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-path-and-recovery-grap
hs">Path and Recovery Graphs</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.3.2">
<li pn="section-toc.1-1.3.2.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derived
Content="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-path">Path
</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.3.2.2.1"><xref derived
Content="3.3.2" format="counter" sectionFormat="of" target="section-3.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-recovery-g
raph">Recovery Graph</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.2.3.1"><xref derived
Content="3.3.3" format="counter" sectionFormat="of" target="section-3.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-forward-an
d-crossing">Forward and Crossing</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3.2.4">
<t indent="0" pn="section-toc.1-1.3.2.3.2.4.1"><xref derived
Content="3.3.4" format="counter" sectionFormat="of" target="section-3.3.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-protection
-path">Protection Path</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3.2.5">
<t indent="0" pn="section-toc.1-1.3.2.3.2.5.1"><xref derived
Content="3.3.5" format="counter" sectionFormat="of" target="section-3.3.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-segment">S
egment</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3.2.4">
<t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent=
"3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-deterministic-networki
ng">Deterministic Networking</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.4.2">
<li pn="section-toc.1-1.3.2.4.2.1">
<t indent="0" pn="section-toc.1-1.3.2.4.2.1.1"><xref derived
Content="3.4.1" format="counter" sectionFormat="of" target="section-3.4.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-the-detnet
-planes">The DetNet Planes</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4.2.2">
<t indent="0" pn="section-toc.1-1.3.2.4.2.2.1"><xref derived
Content="3.4.2" format="counter" sectionFormat="of" target="section-3.4.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-flow">Flow
</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4.2.3">
<t indent="0" pn="section-toc.1-1.3.2.4.2.3.1"><xref derived
Content="3.4.3" format="counter" sectionFormat="of" target="section-3.4.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-residence-
time">Residence Time</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4.2.4">
<t indent="0" pn="section-toc.1-1.3.2.4.2.4.1"><xref derived
Content="3.4.4" format="counter" sectionFormat="of" target="section-3.4.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-l3-determi
nistic-flow-ident">L3 Deterministic Flow Identifier </xref></t>
</li>
<li pn="section-toc.1-1.3.2.4.2.5">
<t indent="0" pn="section-toc.1-1.3.2.4.2.5.1"><xref derived
Content="3.4.5" format="counter" sectionFormat="of" target="section-3.4.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-time-sensi
tive-networking">Time-Sensitive Networking</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4.2.6">
<t indent="0" pn="section-toc.1-1.3.2.4.2.6.1"><xref derived
Content="3.4.6" format="counter" sectionFormat="of" target="section-3.4.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-lower-laye
r-api">Lower-Layer API</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3.2.5">
<t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent=
"3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-reliability-and-availa
bilit">Reliability and Availability</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.5.2">
<li pn="section-toc.1-1.3.2.5.2.1">
<t indent="0" pn="section-toc.1-1.3.2.5.2.1.1"><xref derived
Content="3.5.1" format="counter" sectionFormat="of" target="section-3.5.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-service-le
vel-agreement">Service Level Agreement</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5.2.2">
<t indent="0" pn="section-toc.1-1.3.2.5.2.2.1"><xref derived
Content="3.5.2" format="counter" sectionFormat="of" target="section-3.5.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-service-le
vel-objective">Service Level Objective</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5.2.3">
<t indent="0" pn="section-toc.1-1.3.2.5.2.3.1"><xref derived
Content="3.5.3" format="counter" sectionFormat="of" target="section-3.5.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-service-le
vel-indicator">Service Level Indicator</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5.2.4">
<t indent="0" pn="section-toc.1-1.3.2.5.2.4.1"><xref derived
Content="3.5.4" format="counter" sectionFormat="of" target="section-3.5.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-precision-
availability-metr">Precision Availability Metrics</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5.2.5">
<t indent="0" pn="section-toc.1-1.3.2.5.2.5.1"><xref derived
Content="3.5.5" format="counter" sectionFormat="of" target="section-3.5.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-reliabilit
y">Reliability</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5.2.6">
<t indent="0" pn="section-toc.1-1.3.2.5.2.6.1"><xref derived
Content="3.5.6" format="counter" sectionFormat="of" target="section-3.5.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-availabili
ty">Availability</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-reliable-and-available-wire">Relia
ble and Available Wireless</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-high-availability-engi
neeri">High Availability Engineering Principles</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.1.2">
<li pn="section-toc.1-1.4.2.1.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derived
Content="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-eliminatio
n-of-single-point">Elimination of Single Points of Failure</xref></t>
</li>
<li pn="section-toc.1-1.4.2.1.2.2">
<t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derived
Content="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-reliable-c
rossover">Reliable Crossover</xref></t>
</li>
<li pn="section-toc.1-1.4.2.1.2.3">
<t indent="0" pn="section-toc.1-1.4.2.1.2.3.1"><xref derived
Content="4.1.3" format="counter" sectionFormat="of" target="section-4.1.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-prompt-not
ification-of-fail">Prompt Notification of Failures</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-applying-reliability-c
oncep">Applying Reliability Concepts to Networking</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-wireless-effects-affec
ting-">Wireless Effects Affecting Reliability</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-the-raw-conceptual-model">The RAW
Conceptual Model</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-raw-planes">The RA
W Planes</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-raw-versus-upper-and-l
ower-">RAW Versus Upper and Lower Layers</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-raw-and-detnet">RAW an
d DetNet</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-the-raw-control-loop">The RAW Cont
rol Loop</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-routing-timescale-vers
us-fo">Routing Timescale Versus Forwarding Timescale</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ooda-loop">OODA Loop</
xref></t>
</li>
<li pn="section-toc.1-1.6.2.3">
<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
"6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-observe-raw-oam">Obser
ve: RAW OAM </xref></t>
</li>
<li pn="section-toc.1-1.6.2.4">
<t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent=
"6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-orient-the-raw-extende
d-det">Orient: The RAW-Extended DetNet Operational Plane</xref></t>
</li>
<li pn="section-toc.1-1.6.2.5">
<t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent=
"6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-decide-the-point-of-lo
cal-r">Decide: The Point of Local Repair</xref></t>
</li>
<li pn="section-toc.1-1.6.2.6">
<t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent=
"6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-act-detnet-path-select
ion-a">Act: DetNet Path Selection and Reliability Functions</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-collocated-denial-of-s
ervic">Collocated Denial-of-Service Attacks</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-layer-2-encryption">La
yer 2 Encryption</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
"7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-forced-access">Forced
Access</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
f></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-address">Author's Addre
ss</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<section numbered="true" toc="default"> <name slugifiedName="name-introduction">Introduction</name>
<name>Introduction</name> <t indent="0" pn="section-1-1">
Deterministic Networking (DetNet) aims to provide bounded latency and elimina
<t> te
Deterministic Networking aims at providing bounded latency and eliminating congestion loss, even when coexisting with best-effort traffic.
congestion loss, even when co-existing with best-effort traffic.
It provides the ability to carry It provides the ability to carry
specified unicast or multicast data flows for real-time applications specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end with extremely low packet loss rates and ensures maximum end-to-end
delivery latency. A description of the general background and delivery latency. A description of the general background and
concepts of DetNet can be found in [RFC8655]. concepts of DetNet can be found in <xref target="RFC8655" format="default" se ctionFormat="of" derivedContent="DetNet-ARCH"/>.
</t> </t>
<t> <t indent="0" pn="section-1-2">
DetNet and the related IEEE 802.1 DetNet and the related IEEE 802.1
Time-Sensitive networking (TSN) <xref target="TSN"/> initially focused on wir ed Time-Sensitive Networking (TSN) <xref target="TSN" format="default" sectionFo rmat="of" derivedContent="TSN"/> initially focused on wired
infrastructure, which provides a more stable communication channel infrastructure, which provides a more stable communication channel
than wireless networks. than wireless networks.
Wireless networks operate on a shared medium where uncontrolled interference, Wireless networks operate on a shared medium where uncontrolled interference,
including the self-induced multipath fading, may cause intermittent transmiss ion losses. including self-induced multipath fading, may cause intermittent transmission losses.
Fixed and mobile obstacles and reflectors may block or alter the signal, Fixed and mobile obstacles and reflectors may block or alter the signal,
causing transient and unpredictable variations of the throughput and packet causing transient and unpredictable variations of the throughput and Packet
delivery ratio (PDR) of a wireless link. This adds new dimensions to the Delivery Ratio (PDR) of a wireless link. This adds new dimensions to the
statistical effects that affect the quality and reliability of the link. statistical effects that affect the quality and reliability of the link.
</t> </t>
<t> <t indent="0" pn="section-1-3">
Nevertheless, deterministic capabilities are required in a number of wireless Nevertheless, deterministic capabilities are required in a number of
use cases as well <xref target="I-D.ietf-raw-use-cases"/>. With scheduled wireless use cases as well <xref target="RFC9450" format="default" sectionFor
radios such as Time Slotted Channel Hopping (TSCH) and Orthogonal Frequency mat="of" derivedContent="RAW-USE-CASES"/>. With scheduled radios
Division Multiple Access (OFDMA) (see <xref target="I-D.ietf-raw-technologies such as Time-Slotted Channel Hopping (TSCH) and Orthogonal
"/> for more on both of these and other technologies as well) Frequency-Division Multiple Access (OFDMA) being developed
being developed to provide determinism over wireless links at the lower to provide determinism over wireless links at the lower layers, providing
layers, providing DetNet capabilities has become possible. DetNet capabilities has become possible. See <xref target="RFC9913" format="d
</t> efault" sectionFormat="of" derivedContent="RAW-TECHNOS"/>
<t> for more on TSCH, OFDMA, and other technologies.
</t>
<t indent="0" pn="section-1-4">
Reliable and Available Wireless (RAW) takes up the challenge of providing Reliable and Available Wireless (RAW) takes up the challenge of providing
highly available and reliable end-to-end performances in a DetNet network tha highly available and reliable end-to-end performances in a DetNet network
t may include that may include wireless segments. To achieve this, RAW leverages all
wireless segments. To achieve this, RAW leverages all the possible transmissi possible transmission diversity and redundancy to ensure packet delivery,
on while optimizing the use of the shared spectrum to preserve bandwidth and
diversity and redundancy to assure packet delivery, while optimizing the use save energy. To that effect, RAW defines protection paths that can be activa
of the shared spectrum to preserve bandwidth and save energy. ted
To that effect, RAW defines Protection Paths can be activated dynamically up dynamically upon failures and a control loop that dynamically controls the
on failures and a control loop that dynamically controls the activation and deac activation and deactivation of the feasible protection paths to react
tivation of the feasible Protection Paths to react quickly to intermittent losse quickly to intermittent losses.
s. </t>
</t> <t indent="0" pn="section-1-5">
The intent of RAW is to meet Service Level Objectives (SLOs) in terms of P
<t> DR, maximum contiguous losses, or latency boundaries for DetNet flows over mixes
of wired and wireless networks, including wireless access and meshes (see <xref
The intent of RAW is to meet Service Level Objectives (SLO) in terms of pack target="problem" format="default" sectionFormat="of" derivedContent="Section 2"
et delivery ratio (PDR), maximum contiguous losses or latency boundaries for Det /> for more on the RAW problem).
Net flows over mixes of wired and wireless networks, including wireless access a
nd meshes (see <xref target="problem"/> for more on the RAW problem).
This document introduces and/or leverages terminology (see <xref target="term This document introduces and/or leverages terminology (see <xref target="term
s"/>), principles (see <xref target="raw"/>), and concepts such as protection p s" format="default" sectionFormat="of" derivedContent="Section 3"/>), principles
ath and recovery graph, to put together a conceptual model for RAW (see <xref ta (see <xref target="raw" format="default" sectionFormat="of" derivedContent="Sec
rget="model"/>), and, based on that model, elaborate on an tion 4"/>), and concepts such as protection paths and recovery graphs to put tog
in-network optimization control loop (see <xref target="control"/>). ether a conceptual model for RAW (see <xref target="model" format="default" sect
ionFormat="of" derivedContent="Section 5"/>). Based on that model, this document
elaborates on an in-network optimization control loop (see <xref target="contro
l" format="default" sectionFormat="of" derivedContent="Section 6"/>).
</t> </t>
</section> </section>
<!-- Introduction --> <section anchor="problem" numbered="true" toc="include" removeInRFC="false"
<!-- 000000000000000000000 --> pn="section-2">
<name slugifiedName="name-the-raw-problem">The RAW Problem</name>
<section anchor="problem" numbered="true" toc="default"> <t indent="0" pn="section-2-1">
<name>The RAW problem</name> While the generic "Deterministic Networking Problem Statement" <xref target="
<t> RFC8557" format="default" sectionFormat="of" derivedContent="RFC8557"/> applies
While the generic <xref target="RFC8557">"Deterministic Networking to both wired and wireless media, the "Deterministic Networking Architecture" <x
Problem Statement"</xref> applies to both the wired and the wireless media, ref target="RFC8655" format="default" sectionFormat="of" derivedContent="DetNet-
the <xref target="RFC8655">"Deterministic Networking Architecture" ARCH"/> must be extended to address less consistent
</xref> must be extended to address less consistent
transmissions, energy conservation, and shared spectrum efficiency. transmissions, energy conservation, and shared spectrum efficiency.
</t> </t>
<t> <t indent="0" pn="section-2-2">
Operating at Layer 3, RAW does not change the wireless technology at the
Operating at Layer-3, RAW does not change the wireless technology at the lowe lower layers. On the other hand, it can further increase diversity in the
r layers. OTOH, it can further increase diversity in the spatial, spatial, time, code, and frequency domains by enabling multiple link-layer
time, code, and frequency domains by enabling multiple link-layer wired and wired and wireless technologies in parallel or sequentially, for a higher
wireless technologies in parallel or sequentially, for a higher resilience resilience and a wider applicability. RAW can also provide homogeneous
and a wider applicability. RAW can also provide homogeneous services to services to critical applications beyond the boundaries of a single
critical applications beyond the boundaries of a single subnetwork, e.g., subnetwork, e.g., using diverse radio access technologies to optimize the
using diverse radio access technologies to optimize the
end-to-end application experience. end-to-end application experience.
</t> </t>
<t> <t indent="0" pn="section-2-3">
RAW extends the DetNet services by providing elements that are specialized RAW extends the DetNet services by providing elements that are specialized
for transporting IP flows over deterministic radio technologies such as for transporting IP flows over deterministic radio technologies such as
listed in <xref target="I-D.ietf-raw-technologies"/>. those listed in <xref target="RFC9913" format="default" sectionFormat="of" de
Conceptually, RAW is agnostic to the lower layer, though the rivedContent="RAW-TECHNOS"/>. Conceptually, RAW is agnostic to
capability to control latency is assumed to assure the DetNet services that R the lower layer, though the capability to control latency is assumed to
AW extends. ensure the DetNet services that RAW extends. How the lower layers are
How the lower layers are operated to do so, and, e.g., whether a radio networ operated to do so (and whether a radio network is single hop or
k is single-hop or meshed, are opaque to the IP layer and not part of the RAW ab meshed, for example) are opaque to the IP layer and not part of the RAW abstr
straction. action.
Nevertheless, cross-layer optimizations may take place to ensure proper Nevertheless, cross-layer optimizations may take place to ensure proper
link awareness (think, link quality) and packet handling (think, scheduling). link awareness (such as link quality) and packet handling (such as
scheduling).
</t> </t>
<t> <t indent="0" pn="section-2-4">
The RAW Architecture extends the DetNet Network Plane, to accommodate one or The RAW architecture extends the DetNet Network Plane to accommodate one or
multiple hops of homogeneous or heterogeneous wired and wireless technologies . multiple hops of homogeneous or heterogeneous wired and wireless technologies .
RAW adds reactivity to the DetNet Forwarding sub-layer to compensate the dyna mics RAW adds reactivity to the DetNet forwarding sub-layer to compensate the dyna mics
for the radio links in terms of lossiness and bandwidth. This may apply, for for the radio links in terms of lossiness and bandwidth. This may apply, for
instance, to mesh networks as illustrated in <xref target ="FigCPF"/>, or instance, to mesh networks as illustrated in <xref target="FigCPF" format="de
diverse radio access networks as illustrated in <xref target ="Figranp2"/>. fault" sectionFormat="of" derivedContent="Figure 4"/> or
diverse radio access networks as illustrated in <xref target="Figranp2" forma
t="default" sectionFormat="of" derivedContent="Figure 10"/>.
</t> </t>
<t indent="0" pn="section-2-5">
<t>
As opposed to wired links, the availability and performance of an individual As opposed to wired links, the availability and performance of an individual
wireless link cannot be trusted over the long term; it varies with wireless link cannot be trusted over the long term; it varies with
transient service discontinuity, and any path that includes wireless transient service discontinuity, and any path that includes wireless
hops is bound to face short periods of high loss. On the other hand, being hops is bound to face short periods of high loss. On the other hand, being
broadcast in nature, the wireless medium provides capabilities that are broadcast in nature, the wireless medium provides capabilities that are
atypical on modern wired links and that the RAW Architecture can leverage atypical on modern wired links and that the RAW architecture can leverage
opportunistically to improve the end-to-end reliability over a collection of opportunistically to improve the end-to-end reliability over a collection of
paths. paths.
</t> </t>
<t> <t indent="0" pn="section-2-6">
Those capabilities include: Those capabilities include:
</t> </t>
<dl> <dl indent="3" newline="false" spacing="normal" pn="section-2-7">
<dt>Promiscuous Overhearing:</dt><dd> Some wired and wireless <dt pn="section-2-7.1">Promiscuous overhearing:</dt>
<dd pn="section-2-7.2"> Some wired and wireless
technologies allow for multiple lower-layer attached nodes to receive technologies allow for multiple lower-layer attached nodes to receive
the same packet sent by another node. This differs from a the same packet sent by another node. This differs from a
lower-layer network that is physically point-to-point like a wire. lower-layer network that is physically point-to-point, like a wire.
With overhearing, more than one With overhearing, more than one
node in the forward direction of the packet may hear or overhear a node in the forward direction of the packet may hear or overhear a
transmission, and the reception by one may compensate the loss by another. transmission, and the reception by one may compensate the loss by another.
The concept of path can be revisited in favor of multipoint to multipoint The concept of path can be revisited in favor of multipoint-to-multipoint
progress in the forward direction and statistical chances of successful progress in the forward direction and statistical chances of successful
reception of any of the transmissions by any of the receivers. reception of any of the transmissions by any of the receivers.
</dd> </dd>
<dt>L2-aware routing:</dt><dd> As the quality and speed of a link varies <dt pn="section-2-7.3">L2-aware routing:</dt>
<dd pn="section-2-7.4">
<t indent="0" pn="section-2-7.4.1">As the quality and speed of a link
varies
over time, the concept of metric must also be revisited. Shortest-path cost loses over time, the concept of metric must also be revisited. Shortest-path cost loses
its absolute value, and hop count turns into a bad idea as the link budget its absolute value, and hop count turns into a bad idea as the link budget
drops with the physical distance. Routing over radio requires both 1) a new drops with the physical distance. Routing over radio requires both:</t>
and more <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-
dynamic sense of link metrics, with new protocols such as DLEP and L2-trigge 2-7.4.2">
r to <li pn="section-2-7.4.2.1" derivedCounter="1.">a new and more dynamic sens
keep L3 up to date with the link quality and availability, and 2) an e of link metrics, with new protocols
approach to multipath routing, where multiple link metrics are such as the Dynamic Link Exchange Protocol (DLEP) and Layer 2 (L2) trigger
considered since simple shortest-path cost loses its meaning with s to keep Layer 3 (L3) up to date with the link quality
the instability of the metrics. and availability, and</li>
</dd> <li pn="section-2-7.4.2.2" derivedCounter="2.">an approach to multip
<dt>Redundant transmissions:</dt><dd>Though feasible on any technology, proa ath routing, where multiple link metrics are
ctive considered since simple shortest-path cost loses its meaning with the
(forward) and reactive (ack-based) error correction are typical to the wirel instability of the metrics.</li>
ess </ol>
media. Bounded latency can still be obtained on a wireless link while </dd>
<dt pn="section-2-7.5">Redundant transmissions:</dt>
<dd pn="section-2-7.6">Though feasible on any technology,
proactive (forward) and reactive (acknowledgment-based) error correction is
typical for wireless media. Bounded latency can still be obtained on a wirel
ess link while
operating those technologies, provided that link latency used in operating those technologies, provided that link latency used in
path selection allows for the extra transmission, or that the introduced del ay is path selection allows for the extra transmission or the introduced delay is
compensated along the path. In the case of coded fragments and retries, it compensated along the path. In the case of coded fragments and retries, it
makes sense to vary all the possible physical properties of the makes sense to vary all the possible physical properties of the
transmission to reduce the chances that the same effect causes the loss of transmission to reduce the chances that the same effect causes the loss of
both original and redundant transmissions. both original and redundant transmissions.
</dd> </dd>
<dt>Relay Coordination and constructive interference:</dt><dd>Though it can <dt pn="section-2-7.7">Relay coordination and constructive interference:
be difficult to achieve at high speed, a fine time synchronization and a </dt>
precise sense of phase allows the energy from multiple coordinated senders <dd pn="section-2-7.8">Though it
to add up at the receiver and actually improve the signal quality, can be difficult to achieve at high speed, a fine time synchronization and
a precise sense of phase allows the energy from multiple coordinated
senders to add up at the receiver and actually improve the signal quality,
compensating for either distance or physical objects in the Fresnel zone compensating for either distance or physical objects in the Fresnel zone
that would reduce the link budget. From a DetNet perspective, this that would reduce the link budget. From a DetNet perspective, this may trans
may translate taking into account how transmission from one node may late to taking into account
interfere with the transmission of another node attached to the same how transmission from one node may interfere with the transmission
wireless sub-layer network. of another node attached to the same wireless sub-layer network.</dd>
</dd>
</dl> </dl>
<t> <t indent="0" pn="section-2-8">
RAW and DetNet enable application flows that require a special treatment alo ng paths that can provide that treatment. RAW and DetNet enable application flows that require a special treatment alo ng paths that can provide that treatment.
This may be seen as a form of Path Aware Networking and may be subject to This may be seen as a form of Path Aware networking and may be subject to
impediments documented in <xref target="RFC9049"/>. impediments documented in <xref target="RFC9049" format="default" sectionFor
mat="of" derivedContent="RFC9049"/>.
</t> </t>
<t> <t indent="0" pn="section-2-9">
The mechanisms used to establish a path is not unique to, or necessarily The mechanism used to establish a path is not unique to, or
impacted by, RAW. It is expected to be the product of the DetNet necessarily impacted by, RAW. The mechanism is expected to be the product of
Controller Plane <xref the DetNet Controller Plane <xref target="RFC9938" format="default" sectionFo
target="I-D.ietf-detnet-controller-plane-framework"/>, and may use rmat="of" derivedContent="DetNet-PLANE"/>; it may use a Path
a Path computation Element (PCE) <xref target="RFC4655"/> or the Computation Element (PCE) <xref target="RFC4655" format="default" sectionForm
DetNet Yang Data Model <xref target="RFC9633"/>, or may be at="of" derivedContent="RFC4655"/> or the DetNet YANG data model
computed in a distributed fashion ala <xref target="RFC9633" format="default" sectionFormat="of" derivedContent="RF
Resource ReSerVation Protocol (RSVP) <xref target="RFC2205"/>. C9633"/>, or it may be computed in a distributed fashion as per the
Either way, the assumption is that it is slow relative to Resource ReSerVation Protocol (RSVP) <xref target="RFC2205" format="default"
local forwarding operations along the path. sectionFormat="of" derivedContent="RFC2205"/>.
To react fast enough to transient changes in the radio transmissions, RAW lev Either way, the assumption is that it is slow relative
erages DetNet Network Plane enhancements to to local forwarding operations along the path. To react fast enough to
optimize the use of the paths and match the quality of the transmissions over transient changes in the radio transmissions, RAW leverages DetNet Network
time. Plane enhancements to optimize the use of the paths and match the quality
</t> of the transmissions over time.
<t> </t>
As opposed to wired <t indent="0" pn="section-2-10">
networks, the action of installing a path over a set of wireless links As opposed to wired networks, the action of installing a path over a set of
may be very slow relative to the speed at which the radio conditions vary, wireless links may be very slow relative to the speed at which the radio
and it makes sense in the wireless case to provide redundant forwarding conditions vary; thus, in the wireless case, it makes sense to provide
solutions along a alternate paths (see <xref target="pt"/>) and to leave it redundant forwarding solutions along alternate paths (see <xref target="pt" f
to the Network Plane to select which of those forwarding solutions are to be ormat="default" sectionFormat="of" derivedContent="Section 3.3"/>) and to leave
used for a given packet based on the current conditions. it to the Network Plane to select which of
The RAW Network Plane operations happen within the scope of a recovery graph those forwarding solutions are to be used for a given packet based on the
(see <xref target="trk"/>) that is pre-established and installed current conditions. The RAW Network Plane operations happen within the
by means outside of the scope of RAW. scope of a recovery graph (see <xref target="trk" format="default" sectionFor
mat="of" derivedContent="Section 3.3.2"/>) that is
pre-established and installed by means outside of the scope of RAW.
A recovery graph may be strict or loose depending on whether A recovery graph may be strict or loose depending on whether
each or just a subset of the hops are observed and controlled by RAW. each hop or just a subset of the hops is observed and controlled by RAW.
</t> </t>
<t> <t indent="0" pn="section-2-11">
RAW distinguishes the longer time-scale at which routes are computed from the RAW distinguishes the longer timescale at which routes are computed from
shorter time-scale where forwarding decisions are made (see <xref target= "ti the shorter timescale where forwarding decisions are made (see <xref target="
mescale"/>). timescale" format="default" sectionFormat="of" derivedContent="Section 6.1"/>).
The RAW Network Plane operations happen at a time-scale that sits timewise be The RAW Network Plane operations happen at a
tween the timescale that sits timewise between the routing and the forwarding
routing and the forwarding time-scales. Their goal is to select dynamically, timescales. Within the resources delineated by a recovery graph, their
within the resources delineated by a recovery graph, the protection path(s) that goal is to dynamically select the protection path(s) that the upcoming
the upcoming packets of a DetNet flow shall follow. As they influence the path packets of a DetNet flow shall follow. As they influence the path for the
for entire or portion of flows, the RAW Network Plane operations may affect the entirety of the flows or a portion of them, the RAW Network Plane operations
metrics used in their rerouting decision, which could potentially lead to oscill may
ations; such effects must be avoided or dampened. affect the metrics used in their rerouting decisions, which could
potentially lead to oscillations; such effects must be avoided or dampened.
</t> </t>
</section>
</section> <!-- The RAW problem --> <section anchor="terms" numbered="true" toc="include" removeInRFC="false" pn
="section-3">
<section anchor="terms" numbered="true" toc="default"> <name slugifiedName="name-terminology">Terminology</name>
<name>Terminology</name> <t indent="0" pn="section-3-1">RAW reuses terminology defined for DetNet i
n "Deterministic Networking
<t>RAW reuses terminology defined for DetNet in the <xref target="RFC8655"> Architecture" <xref target="RFC8655" format="default" sectionFormat="of" der
"Deterministic Networking Architecture"</xref>, e.g., PREOF for Packet ivedContent="DetNet-ARCH"/>, e.g., "PREOF" to stand for "Packet
Replication, Elimination and Ordering Functions. RAW inherits and augments Replication, Elimination, and Ordering Functions". RAW inherits and
the IETF art of Protection as seen in DetNet and Traffic Engineering. augments IETF recovery mechanisms such as the ones provided in DetNet
</t> <xref target="RFC8655" format="default" sectionFormat="of" derivedContent="D
<t>RAW reuses terminology defined for Operations, Administration, and Mainte etNet-ARCH"/> and in Traffic Engineering, e.g., <xref target="RFC4090" format="d
nance (OAM) protocols efault" sectionFormat="of" derivedContent="RFC4090"/>.
in Section 1.1 of the <xref target="RFC9551"> "Framework of OAM for DetNet" < </t>
/xref> and <t indent="0" pn="section-3-2">RAW also reuses terminology defined for Ope
<xref target="RFC7799">"Active and Passive Metrics and Methods (with Hybrid T rations, Administration, and
ypes In-Between)" </xref>. Maintenance (OAM) protocols in Section <xref target="RFC9551" sectionFormat=
"bare" section="1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rf
<!-- c9551#section-1.1" derivedContent="DetNet-OAM"/> of "Framework of Operations, Ad
<xref target="I-D.ietf-opsawg-oam-characterization">"Guidelines for Character ministration, and Maintenance
izing OAM"</xref> (OAM) for Deterministic Networking (DetNet)" <xref target="RFC9551" format="
provides additional semantics of the terms Active, Passive, Hybrid, and In-Pa default" sectionFormat="of" derivedContent="DetNet-OAM"/> and in "Active and Pas
cket OAM that are consistent with sive
<xref target="RFC7799"/>. It also warns about potential inconsistencies in t Metrics and Methods (with Hybrid Types In-Between)" <xref target="RFC7799" f
he way the terms "in-band" and "out-of-band" are used across the IETF; the DetNe ormat="default" sectionFormat="of" derivedContent="RFC7799"/>.
t reference for those terms is <xref target="RFC9551"/>. </t>
<t indent="0" pn="section-3-3">
--> RAW also reuses terminology defined for MPLS in <xref target="RFC4427" forma
</t> t="default" sectionFormat="of" derivedContent="RFC4427"/>, such as the term "rec
<t> overy" to cover both protection
RAW also reuses terminology defined for MPLS in <xref target= and restoration for a number of recovery types. That document defines a
"RFC4427" format="default"/> such as the term recovery as covering number of concepts, such as the recovery domain, that are used in RAW
both Protection and Restoration, a number of recovery types. mechanisms and defines the new term "recovery graph". A recovery graph
That document defines a number of concepts such as recovery domain that are associates a topological graph with usage metadata that represents how the
used in the RAW mechanisms, and defines the new term recovery graph. paths are built and used within the recovery graph. The recovery graph
A recovery graph associates a topological graph with usage metadata that provides excess bandwidth for the intended traffic over alternate
represents how the paths are built and used within the recovery graph. potential paths, and the use of that bandwidth is optimized dynamically.
The recovery graph provides excess bandwidth for the intended traffic over a </t>
lternate potential paths, and <t indent="0" pn="section-3-4">
the use of that bandwidth is optimized dynamically. The concept of a recovery graph is agnostic to
</t> the underlying technology and applies, but is not limited to, any full or
<t>
RAW also reuses terminology defined for RSVP-TE in <xref target=
"RFC4090" format="default"/> such as the Point of Local Repair (PLR).
The concept of backup path is generalized with protection path, which is the
term mostly found in recent standards and used in this document.
</t>
<t>
RAW also reuses terminology defined for 6TiSCH in <xref target=
"RFC9030" format="default"/> and equates the 6TiSCH concept of a Track with
that of a recovery graph.
</t>
<t>
The concept of recovery graph is agnostic to
the underlying technology and applies but is not limited to any full or
partial wireless mesh. partial wireless mesh.
RAW specifies strict and loose recovery graphs depending on whether the path is fully RAW specifies strict and loose recovery graphs depending on whether the path is fully
controlled by RAW or traverses an opaque network where RAW cannot observe controlled by RAW or traverses an opaque network where RAW cannot observe
and control the individual hops. and control the individual hops.
</t> </t>
<t> <t indent="0" pn="section-3-5">
RAW uses the following terminology and acronyms: RAW also reuses terminology defined for RSVP-TE in <xref target="RFC4090" fo
</t> rmat="default" sectionFormat="of" derivedContent="RFC4090"/>, such as the "Point
of Local Repair (PLR)".
<section><name>Acronyms</name> The concept of a backup path is generalized with protection path, which is t
<section><name>ARQ</name> he
<t> term mostly found in recent standards and used in this document.
Automatic Repeat Request, a well-known mechanism, enabling an acknowledged </t>
transmission with retries to mitigate errors and loss. ARQ may be <t indent="0" pn="section-3-6">
implemented at various layers in a network. ARQ is typically implemented at RAW also reuses terminology defined for 6TiSCH in <xref target="RFC9030" for
Layer-2, per hop and not end-to-end in wireless networks. ARQ improves mat="default" sectionFormat="of" derivedContent="6TiSCH-ARCH"/> and equates the
delivery on lossy wireless. Additionally, ARQ retransmission may be further 6TiSCH concept of a Track with that of
limited by a bounded time to meet end-to-end packet latency constraints. a recovery graph.
Additional details and considerations for ARQ are detailed in </t>
<xref target="RFC3366"/>. <section numbered="true" removeInRFC="false" toc="include" pn="section-3.1
</t> ">
</section> <name slugifiedName="name-abbreviations">Abbreviations</name>
<t indent="0" pn="section-3.1-1">RAW uses the following abbreviations.</
<section><name>FEC</name> t>
<t> <dl newline="true" indent="3" spacing="normal" pn="section-3.1-2">
Forward Error Correction, adding redundant data to protect against a partial <dt pn="section-3.1-2.1">ARQ</dt>
loss without retries. <dd pn="section-3.1-2.2">
</t> Automatic Repeat Request. A well-known mechanism that enables an
</section> acknowledged transmission with retries to mitigate errors and loss. ARQ
may be implemented at various layers in a network. ARQ is typically
<section><name>HARQ</name> implemented per hop (not end to end) at Layer 2 in wireless
<t> networks. ARQ improves delivery on lossy wireless. Additionally, ARQ
Hybrid ARQ, combining FEC and ARQ. retransmission may be further limited by a bounded time to meet
</t> end-to-end packet latency constraints. Additional details and
</section> considerations for ARQ are detailed in <xref target="RFC3366" format="def
ault" sectionFormat="of" derivedContent="RFC3366"/>.
<section><name>ETX</name> </dd>
<t> <dt pn="section-3.1-2.3">FEC</dt>
Expected Transmission Count: a statistical metric that represents the expect <dd pn="section-3.1-2.4">
ed total number of packet transmissions (including retransmissions) required to Forward Error Correction. Adding redundant data to protect against a part
successfully deliver a packet along a path, used by 6TiSCH <xref target="RFC6551 ial
"/>. loss without retries.
</t> </dd>
</section> <dt pn="section-3.1-2.5">HARQ</dt>
<section><name>ISM</name> <dd pn="section-3.1-2.6">
<t> Hybrid ARQ. A combination of FEC and ARQ.
</dd>
The industrial, scientific, and medical (ISM) radio band refers to a group o <dt pn="section-3.1-2.7">ETX</dt>
f radio bands or parts of the radio spectrum (e.g., 2.4 GHz and 5 GHz) that are <dd pn="section-3.1-2.8">
internationally reserved for the use of radio frequency (RF) energy intended for Expected Transmission Count. A statistical metric that represents the
scientific, medical, and industrial requirements, e.g., by microwaves, depth ra expected total number of packet transmissions (including retransmissions)
dars, and medical diathermy machines. Cordless phones, Bluetooth and LoWPAN devi required to successfully deliver a packet along a path, used by 6TiSCH
ces, near-field communication (NFC) devices, garage door openers, baby monitors, <xref target="RFC6551" format="default" sectionFormat="of" derivedContent
and Wi-Fi networks may all use the ISM frequencies, although these low-power tr ="RFC6551"/>.
ansmitters are not considered to be ISM devices. In general, communications equi </dd>
pment operating in ISM bands must tolerate any interference generated by ISM app <dt pn="section-3.1-2.9">ISM</dt>
lications, and users have no regulatory protection from ISM device operation in <dd pn="section-3.1-2.10">
these bands. Industrial, Scientific, and Medical. Refers to a group of radio bands
or parts of the radio spectrum (e.g., 2.4 GHz and 5 GHz) that are
</t> internationally reserved for the use of radio frequency (RF) energy
</section> intended for industrial, scientific, and medical requirements (e.g.,
by microwaves, depth radars, and medical diathermy machines). Cordless
<section><name>PER and PDR</name> phones, Bluetooth and Low-Power Wireless Personal Area Network
<t> (LoWPAN) devices, near-field communication (NFC) devices, garage door
openers, baby monitors, and Wi-Fi networks may all use the ISM
The Packet Error Rate (PER) is defined as the ratio of the number of packets frequencies, although these low-power transmitters are not considered
received in error to the total number of transmitted packets. A packet is consi to be ISM devices. In general, communications equipment operating in
dered to be in error if even a single bit within the packet is received incorrec ISM bands must tolerate any interference generated by ISM
tly. In contrast, the Packet Delivery Ratio (PDR) indicates the ratio of the num applications, and users have no regulatory protection from ISM device
ber successful delivery of data packets to the total number of transmitted pack operation in these bands.
ets from the sender to the receiver. </dd>
</t> <dt pn="section-3.1-2.11">PER</dt>
</section> <dd pn="section-3.1-2.12">
Packet Error Rate. The ratio of the number of packets received in
<section><name>RSSI</name> error to the total number of transmitted packets. A packet is
<t> considered to be in error if even a single bit within the packet is
Received Signal Strength Indication (a.k.a. Energy Detection Level): a measu received incorrectly.
re of incoherent (raw) RF power in a channel. The RF power can come from any sou </dd>
rce: other transmitters using the same technology, other radio technology using <dt pn="section-3.1-2.13">PDR</dt>
the same band, or background radiation. For a single-hop, RSSI may be used for L <dd pn="section-3.1-2.14">
QI. Packet Delivery Ratio (PDR). The ratio of the number of successfully
</t> delivered data packets to the total number of packets transmitted from
</section> the sender to the receiver.
</dd>
<section><name>LQI</name> <dt pn="section-3.1-2.15">RSSI</dt>
<t> <dd pn="section-3.1-2.16">
Received Signal Strength Indication. Also known as "Energy Detection
The link quality indicator (LQI) is an indication of the quality of the data Level". A measure of the incoherent (raw) RF power in a channel. The
packets received by the receiver. RF power can come from any source: other transmitters using the same
It is typically derived from packet error statistics, the exact method depen technology, other radio technology using the same band, or background
ding on the network stack being used. radiation. For a single hop, RSSI may be used for LQI.
LQI values may be exposed to the controller plane for each individual hop or </dd>
cumulated along segments. <dt pn="section-3.1-2.17">LQI</dt>
Outgoing LQI values can be calculated from coherent (demodulated) PER, RSSI <dd pn="section-3.1-2.18">
and incoming LQI values. Link Quality Indicator. An indication of the quality of the data packets
</t> received by the receiver.
</section> It is typically derived from packet error statistics, with the exact meth
od depending on the network stack being used.
<section><name>OAM</name> LQI values may be exposed to the Controller Plane for each individual hop
<t> or cumulated along segments.
OAM stands for Operations, Administration, and Maintenance, and Outgoing LQI values can be calculated from coherent (demodulated) PER, RS
covers the processes, activities, tools, and standards involved SI, and incoming LQI values.
with operating, administering, managing, and maintaining any </dd>
system. This document uses the terms Operations, Administration, <dt pn="section-3.1-2.19">OAM</dt>
and Maintenance, in conformance with the <xref target="RFC6291"> <dd pn="section-3.1-2.20">
'Guidelines for the Use of the "OAM" Acronym in the IETF'</xref> Operations, Administration, and Maintenance. Covers the processes,
and the system observed by the RAW OAM is the recovery graph. activities, tools, and standards involved with operating, administering,
managing, and maintaining any system. This document uses the term
</t> in conformance with "Guidelines for the Use of the 'OAM' Acronym in the I
</section> ETF" <xref target="RFC6291" format="default" sectionFormat="of" derivedContent="
<section><name>OODA</name> RFC6291"/>, and the system observed by the RAW OAM is the
<t> recovery graph.
OODA (Observe, Orient, Decide, Act) is a generic formalism to represent the </dd>
operational steps in a Control Loop. In the context of RAW, OODA is applied <dt pn="section-3.1-2.21">OODA</dt>
to network <dd pn="section-3.1-2.22">
control and convergence, more in <xref target="ooda"/>. Observe, Orient, Decide, Act. A generic formalism to represent the
operational steps in a control loop. In the context of RAW, OODA is
</t> applied to network control and convergence; see <xref target="ooda" forma
</section> t="default" sectionFormat="of" derivedContent="Section 6.2"/>
for more.
<section><name>SNR</name> </dd>
<t> <dt pn="section-3.1-2.23">SNR</dt>
Signal-Noise Ratio (a.k.a. S/N): a measure used in science and engineering t <dd pn="section-3.1-2.24">
hat compares the level of a desired signal to the level of background noise. SNR Signal-to-Noise Ratio. Also known as "S/N Ratio". A measure used in
is defined as the ratio of signal power to noise power, often expressed in deci science and engineering that compares the level of a desired signal to
bels. the level of background noise. SNR is defined as the ratio of signal
</t> power to noise power, often expressed in decibels.
</section> </dd>
</dl>
</section><!--Acronyms--> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3.2
<section><name>Link and Direction</name> ">
<name slugifiedName="name-link-and-direction">Link and Direction</name>
<section><name>Flapping</name> <t indent="0" pn="section-3.2-1">This document uses the following terms
<t> relating to links and direction in the context of RAW.</t>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3
.2.1">
<name slugifiedName="name-flapping">Flapping</name>
<t indent="0" pn="section-3.2.1-1">
In the context of RAW, a link flaps when the reliability of the wireless In the context of RAW, a link flaps when the reliability of the wireless
connectivity drops abruptly for a short period of time, typically of a connectivity drops abruptly for a short period of time, typically a
subsecond to seconds duration. duration of a subsecond to seconds.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3
<section><name>Uplink</name> .2.2">
<t> <name slugifiedName="name-uplink">Uplink</name>
Connection from end-devices to data communication equipment. In the <t indent="0" pn="section-3.2.2-1">
context of wireless, uplink refers to the connection between a station An uplink is the connection from end devices to data communication equipment
(STA) and a controller (AP) or a User Equipment (UE) to a Base Station (BS) . In the
such as a 3GPP 5G gNodeB (gNb). context of wireless, uplink refers to the connection between a station
</t> (STA) and a controller (AP) or a User Equipment (UE) and a Base Station (BS)
</section> such as a 3GPP 5G gNodeB (gNB).
</t>
<section><name>Downlink</name> </section>
<t> <section numbered="true" removeInRFC="false" toc="include" pn="section-3
The reverse direction from uplink. .2.3">
</t> <name slugifiedName="name-downlink">Downlink</name>
</section> <t indent="0" pn="section-3.2.3-1">
A downlink is the reverse direction from uplink.
<section><name>Downstream</name> </t>
<t> </section>
Following the direction of the flow data path along a recovery graph. <section numbered="true" removeInRFC="false" toc="include" pn="section-3
</t> .2.4">
</section> <name slugifiedName="name-downstream">Downstream</name>
<t indent="0" pn="section-3.2.4-1">
<section><name>Upstream</name> Downstream refers to the following the direction of the flow data path along
<t> a recovery graph.
Against the direction of the flow data path along a recovery graph. </t>
</t> </section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-3
.2.5">
</section><!-- Link and Direction --> <name slugifiedName="name-upstream">Upstream</name>
<t indent="0" pn="section-3.2.5-1">
<section anchor="pt"><name>Path and Recovery Graphs</name> Upstream refers to going against the direction of the flow data path along a
<section><name>Path</name> recovery graph.
</t>
<t> </section>
Quoting section 1.1.3 of <xref target="RFC1122"/>: </section>
</t> <section anchor="pt" numbered="true" removeInRFC="false" toc="include" pn=
<blockquote> "section-3.3">
<name slugifiedName="name-path-and-recovery-graphs">Path and Recovery Gr
aphs</name>
<t indent="0" pn="section-3.3-1">This document uses the following terms
relating to paths and recovery
graphs in the context of RAW.</t>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3
.3.1">
<name slugifiedName="name-path">Path</name>
<t indent="0" pn="section-3.3.1-1">
<xref target="RFC1122" section="1.3.3" format="default" sectionFormat="of" d
erivedLink="https://rfc-editor.org/rfc/rfc1122#section-1.3.3" derivedContent="IN
T-ARCH"/> provides a definition of path:
</t>
<blockquote pn="section-3.3.1-2">
At a given moment, all the IP datagrams from a particular source host to a At a given moment, all the IP datagrams from a particular source host to a
particular destination host typically traverse the same sequence of particular destination host will typically traverse the same sequence of
gateways. We use the term "path" for this sequence. Note that a path is gateways. We use the term "path" for this sequence. Note that a path is
unidirectional; it is not unusual to have different paths in the two uni-directional; it is not unusual to have different paths in the two
directions between a given host pair. directions between a given host pair.
</blockquote> </blockquote>
<t> <t indent="0" pn="section-3.3.1-3">
Section 2 of <xref target="RFC9473"/> points to a <xref target="RFC9473" section="2" format="default" sectionFormat="of" deriv
edLink="https://rfc-editor.org/rfc/rfc9473#section-2" derivedContent="RFC9473"/>
points to a
longer, more modern definition of path, which begins as follows: longer, more modern definition of path, which begins as follows:
</t> </t>
<blockquote> <blockquote pn="section-3.3.1-4">
<t> <t indent="0" pn="section-3.3.1-4.1">
A sequence of adjacent path elements over which a packet can A sequence of adjacent path elements over which a packet can
be transmitted, starting and ending with a node. be transmitted, starting and ending with a node.
</t><t> </t>
Paths are unidirectional and time-dependent, i.e., there can be a <t indent="0" pn="section-3.3.1-4.2">
variety of paths from one node to another, and the path over which Paths are unidirectional and time dependent, i.e., there can be a
packets are transmitted may change. A path definition can be variety of paths from one node to another, and the path over which
fixed (i.e., the exact sequence of path elements remains the packets are transmitted may change. A path definition can be strict
same) or mutable (i.e., the start and end node remain the same, but (i.e., the exact sequence of path elements remains the same) or loose
the path elements between them may vary over time). (i.e., the start and end node remain the same, but the path elements
</t><t> between them may vary over time).
</t>
<t indent="0" pn="section-3.3.1-4.3">
The representation of a path and its properties may depend on the The representation of a path and its properties may depend on the
entity considering the path. On the one hand, the representation entity considering the path. On the one hand, the representation
may differ due to entities having partial visibility of path may differ due to entities having partial visibility of path
elements comprising a path or their visibility changing over time. elements comprising a path or their visibility changing over time.
</t> </t>
</blockquote> </blockquote>
<t> <t indent="0" pn="section-3.3.1-5">
It follows that the general acceptance of a path is a linear sequence of It follows that the general acceptance of a path is a linear sequence of
links and nodes, as opposed to a multi-dimensional graph, defined by the links and nodes, as opposed to a multi-dimensional graph, defined by the
experience of the packet that went from a node A to a node B. experience of the packet that went from a node A to a node B.
In the context of this document, a path is observed by following one copy In the context of this document, a path is observed by following one copy
or one fragment of a packet that conserves its uniqueness and integrity. or one fragment of a packet that conserves its uniqueness and integrity.
For instance, if C replicates to E and F and D eliminates duplicates, For instance, if C replicates to E and F and if D eliminates duplicates,
a packet from A to B can experience 2 paths, A->C->E->D->B and a packet from A to B can experience two paths: A-&gt;C-&gt;E-&gt;D-&gt;B and
A->C->F->D->B. Those paths are called protection paths. Protection A-&gt;C-&gt;F-&gt;D-&gt;B. Those paths are called protection paths. Protecti
paths may be fully non-congruent, and alternatively may intersect at on
paths may be fully non-congruent; alternatively, they may intersect at
replication or elimination points. replication or elimination points.
</t> </t>
<t> With DetNet and RAW, <t indent="0" pn="section-3.3.1-6"> With DetNet and RAW,
a packet may be duplicated, fragmented, and network-coded, and the various a packet may be duplicated, fragmented, and network coded, and the various
byproducts may travel different paths that are not necessarily end-to-end byproducts may travel different paths that are not necessarily end to end
between A and B; we refer to that complex scenario as a DetNet path. between A and B. We refer to this complex scenario as a DetNet path.
As such, the DetNet path extends the above description of a path, As such, the DetNet path extends the above description of a path,
but it still matches the experience of a packet that traverses the network. but it still matches the experience of a packet that traverses the network.
</t> </t>
<t> <t indent="0" pn="section-3.3.1-7">
With RAW, the path experienced by a packet is subject to change from one pac ket to the next, With RAW, the path experienced by a packet is subject to change from one pac ket to the next,
but all the possible experiences are all contained within a finite set. but all the possible experiences are all contained within a finite set.
Therefore, we introduce below the term of a recovery graph that coalesces Therefore, we introduce the term "recovery graph" (see the next section) tha t coalesces
that set and covers the overall topology where the possible DetNet paths are that set and covers the overall topology where the possible DetNet paths are
all contained. As such, the recovery graph coalesces all the possible paths all contained. As such, the recovery graph coalesces all the possible paths
a flow a flow
may experience, each with its own statistical probability to be used. may experience, each with its own statistical probability to be used.
</t> </t>
</section> </section>
<section anchor="trk"><name>Recovery Graph</name> <section anchor="trk" numbered="true" removeInRFC="false" toc="include"
pn="section-3.3.2">
<t>A networking graph that can be followed to transport packets with <name slugifiedName="name-recovery-graph">Recovery Graph</name>
equivalent treatment, associated with usage metadata; as opposed to the <t indent="0" pn="section-3.3.2-1">A recovery graph is a networking gr
definition of a path above, a recovery graph represents not an actual but a aph that can be followed to
potential, it is not necessarily a linear sequence like a simple path, and transport packets with equivalent treatment and is associated with usage
is not metadata. In contrast to the definition of a path above, a recovery graph
necessarily fully traversed (flooded) by all packets of a flow like a DetNet represents a potential path, not an actual one. Also, a recovery graph is
Path. Still, and as a simplification, the casual reader may consider that a not necessarily a linear sequence like a simple path and is not
recovery graph is very much like a DetNet path, aggregating multiple paths t necessarily fully traversed (flooded) by all packets of a flow like a
hat may DetNet path. Still, and as a simplification, the casual reader may
overlap, fork and rejoin, for instance to enable a protection service by the consider that a recovery graph is very much like a DetNet path,
PREOF operations. aggregating multiple paths that may overlap or fork and then rejoin, for
</t> instance, to enable a protection service by the PREOF operations.
<figure anchor="Figtrk"> </t>
<name>Example IoT Recovery Graph to an IoT Gateway with 1+1 Redundancy <figure anchor="Figtrk" align="left" suppress-title="false" pn="figure
</name> -1">
<artwork align="center" name="" type="" alt=""> <name slugifiedName="name-example-iot-recovery-graph-">Example IoT R
<![CDATA[ ecovery Graph to an IoT Gateway with 1+1 Redundancy</name>
<artwork align="center" name="" type="" alt="" pn="section-3.3.2-2.1
">
_________ _________
| | | |
| IoT G/W | | IoT G/W |
|_________| |_________|
EGRESS <&lt;=== Elimination at Egress EGRESS <&lt;=== Elimination at Egress
| | | |
---+--------+--+--------+-------- ---+--------+--+--------+--------
| Backbone | | Backbone |
__|__ __|__ __|__ __|__
| | Backbone | | Backbone | | Backbone | | Backbone
|__ __| Router |__ __| Router |__ __| Router |__ __| Router
| # | | # |
# \ # / <-- protection path # \ # / &lt;-- protection path
# # #-------# # # #-------#
\ # / # ( Low-power ) \ # / # ( Low-power )
# # \ / # ( Lossy Network) # # \ / # ( Lossy Network)
\ / \ /
# INGRESS <<=== Replication at recovery graph Ingress # INGRESS <&lt;=== Replication at recovery graph ingress
| |
# <-- source device # &lt;-- source device
#: Low-power device
#: Low-power device </artwork>
</figure>
]]> <t indent="0" pn="section-3.3.2-3">
</artwork> Refining further, a recovery graph is defined as the coalescence of all the
</figure> feasible DetNet paths that a packet with an assigned flow may be forwarded
along. A packet that is assigned to the recovery graph experiences one of
<t> the feasible DetNet paths based on the current selection by the PLR at the
Refining further, a recovery graph is defined as the coalescence of the coll time the packet traverses the network.
ection </t>
of all the feasible DetNet Paths that a packet for which a flow is assigned <t indent="0" pn="section-3.3.2-4">
to the Refining even further, the feasible DetNet paths within the recovery graph m
recovery graph may be forwarded along. ay or may
A packet that is assigned to the recovery graph experiences one of the feasi not be computed in advance; instead, they may be decided upon the detection
ble of a change from
DetNet Paths based on the current selection by the PLR at the time the
packet traverses the network.
</t>
<t>
Refining even further, the feasible DetNet Paths within the recovery graph m
ay or may
not be computed in advance, but decided upon the detection of a change from
a clean slate. a clean slate.
Furthermore, the PLR decision may be distributed, which yields a large Furthermore, the PLR decision may be distributed, which yields a large
combination of possible and dependent decisions, with no node in the network combination of possible and dependent decisions, with no node in the network
capable of reporting which is the current DetNet Path within the recovery gr capable of reporting which is the current DetNet path within the recovery gr
aph. aph.
</t> </t>
<t> <t indent="0" pn="section-3.3.2-5">
In DetNet <xref target="RFC8655"/> terms, a recovery graph has the following In DetNet <xref target="RFC8655" format="default" sectionFormat="of" derived
Content="DetNet-ARCH"/> terms, a recovery graph has the following
properties: properties:
</t> </t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section
<li> -3.3.2-6">
A recovery graph is a Layer-3 abstraction built upon IP links between router <li pn="section-3.3.2-6.1">
s. A recovery graph is a Layer 3 abstraction built upon IP links between router
s.
A router may form multiple IP links over a single radio interface. A router may form multiple IP links over a single radio interface.
</li><li> </li>
A recovery graph has one Ingress and one Egress node, which operate as DetNe <li pn="section-3.3.2-6.2">
t Edge A recovery graph has one ingress and one egress node, which operate as DetNe
t edge
nodes. nodes.
</li><li>
The graph of a recovery graph is reversible, meaning that packets can be rou
ted against
the flow of data packets, e.g., to carry OAM measurements or control
messages back to the Ingress.
</li><li>
The vertices of that graph are DetNet Relay Nodes that operate at the
DetNet Service sub-layer and provide the PREOF functions.
</li><li>
The topological edges of the graph are strict sequences of DetNet Transit
nodes that operate at the DetNet Forwarding sub-layer.
</li> </li>
</ul> <li pn="section-3.3.2-6.3">
A recovery graph is reversible, meaning that packets
<t> can be routed against the flow of data packets, e.g., to carry OAM
<xref target='TRK'/> illustrates the generic concept of a recovery graph, measurements or control messages back to the ingress.
between an Ingress Node and an Egress Node. </li>
<li pn="section-3.3.2-6.4">
The recovery graph is composed of forward protection paths and forward or cr The vertices of a recovery graph are DetNet relay nodes that operate at
ossing the DetNet Service sub-layer and provide the PREOF functions.
Segments (see the definition for those terms in the next sections). </li>
The recovery graph contains at least 2 protection paths as a main path and a <li pn="section-3.3.2-6.5">
backup path. The topological edges of a recovery graph are strict sequences of DetNet
</t> transit nodes that operate at the DetNet forwarding sub-layer.
<figure anchor='TRK'><name>A Recovery Graph and its Components</name> </li>
<artwork align="center"><![CDATA[ </ul>
<t indent="0" pn="section-3.3.2-7">
------------------- forward direction ----------------------> <xref target="TRK" format="default" sectionFormat="of" derivedContent="Figur
e 2"/> illustrates the generic concept of a recovery graph,
a ==> b ==> C -=- F ==> G ==> h T1 I: Ingress between an ingress node and an egress node.
/ \ / | \ / E: Egress
I o n E -=- T2 T1, T2, T3:
\ / \ | / \ External
p ==> q ==> R -=- T ==> U ==> v T3 Targets
Uppercase: DetNet Relay Nodes
Lowercase: DetNet Transit nodes
I ==> a ==> b ==> C : A forward Segment to targets F and o
C ==> o ==> T: A forward Segment to target T (and/or U)
G | n | U : A crossing Segment to targets G or U
I -> F -> E : A forward Protection Path to targets T1, T2, and T3
I, a, b, C, F, G, h, E : a path to T1, T2, and/or T3 The recovery graph is composed of forward protection paths, forward segments
I, p, q, R, o, F, G, h, E : segment-crossing protection path , and crossing
segments (see the definitions of those terms in the next sections).
The recovery graph contains at least two protection paths: a main path and a
backup path.
</t>
<figure anchor="TRK" align="left" suppress-title="false" pn="figure-2"
>
<name slugifiedName="name-a-recovery-graph-and-its-co">A Recovery Gr
aph and Its Components</name>
<artwork align="center" pn="section-3.3.2-8.1">
------------------- forward direction ----------------------&gt;
]]></artwork> a ==&gt; b ==&gt; C -=- F ==&gt; G ==&gt; h T1
</figure> / \ / | \ /
I o n E -=- T2
\ / \ | / \
p ==&gt; q ==&gt; R -=- T ==&gt; U ==&gt; v T3
</section> I: Ingress
<section><name>Forward and Crossing</name> E: Egress
<t> T1, T2, T3: external targets
Forward refers to progress towards the recovery graph Egress. Forward links Uppercase: DetNet relay nodes
are Lowercase: DetNet transit nodes
</artwork>
</figure>
<t indent="0" pn="section-3.3.2-9">Of note:</t>
<dl newline="false" spacing="normal" indent="3" pn="section-3.3.2-10">
<dt pn="section-3.3.2-10.1">I ==&gt; a ==&gt; b ==&gt; C:</dt>
<dd pn="section-3.3.2-10.2">A forward segment to targets F and o</dd
>
<dt pn="section-3.3.2-10.3">C ==&gt; o ==&gt; T:</dt>
<dd pn="section-3.3.2-10.4">A forward segment to target T (and/or U)
</dd>
<dt pn="section-3.3.2-10.5">G | n | U:</dt>
<dd pn="section-3.3.2-10.6">A crossing segment to targets G or U</dd
>
<dt pn="section-3.3.2-10.7">I -&gt; F -&gt; E:</dt>
<dd pn="section-3.3.2-10.8">A forward protection path to targets T1,
T2, and T3</dd>
<dt pn="section-3.3.2-10.9">I, a, b, C, F, G, h, E:</dt>
<dd pn="section-3.3.2-10.10">A path to T1, T2, and/or T3</dd>
<dt pn="section-3.3.2-10.11">I, p, q, R, o, F, G, h, E:</dt>
<dd pn="section-3.3.2-10.12">A segment-crossing protection path</dd>
</dl>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3
.3.3">
<name slugifiedName="name-forward-and-crossing">Forward and Crossing</
name>
<t indent="0" pn="section-3.3.3-1">
Forward refers to progress towards the egress of the recovery graph. Forward
links are
directional, and packets that are forwarded along the recovery graph can onl y be directional, and packets that are forwarded along the recovery graph can onl y be
transmitted along the link direction. Crossing links are bidirectional, transmitted along the link direction. Crossing links are bidirectional,
meaning that they can be used in both directions, though a given packet may meaning that they can be used in both directions, though a given packet may
use the link in one direction only. A Segment can be forward, in which use the link in one direction only. A segment can be forward, in which
case it is composed of forward links only, or crossing, in which case it is composed of forward links only, or it can be crossing, in which
case it is composed of crossing links only. A Protection Path is always forw case it is composed of crossing links only. A protection path is always forw
ard, ard,
meaning that it is composed of forward links and Segments. meaning that it is composed of forward links and segments.
</t> </t>
</section> </section>
<section><name>Protection Path</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-3
<t> .3.4">
An end-to-end forward path between the Ingress and Egress Nodes of a <name slugifiedName="name-protection-path">Protection Path</name>
<t indent="0" pn="section-3.3.4-1">
A protection path is an end-to-end forward path between the ingress and egre
ss nodes of a
recovery graph. A protection path in a recovery graph is expressed as a stri ct sequence recovery graph. A protection path in a recovery graph is expressed as a stri ct sequence
of DetNet Relay Nodes or as a loose sequence of DetNet Relay Nodes that are of DetNet relay nodes or as a loose sequence of DetNet relay nodes that are
joined by recovery graph Segments. Background information on the joined by segments in the recovery graph. Background information on the
concepts related to protection paths can be found in <xref concepts related to protection paths can be found in <xref target="RFC4427"
target="RFC4427"/> and <xref target="RFC6378"/> format="default" sectionFormat="of" derivedContent="RFC4427"/> and <xref target=
</t> "RFC6378" format="default" sectionFormat="of" derivedContent="RFC6378"/>.
</section> </t>
<section><name>Segment</name> </section>
<t> <section numbered="true" removeInRFC="false" toc="include" pn="section-3
A strict sequence of DetNet Transit nodes between 2 DetNet Relay Nodes; a .3.5">
Segment of a recovery graph is composed topologically of two vertices of the <name slugifiedName="name-segment">Segment</name>
<t indent="0" pn="section-3.3.5-1">
A segment is a strict sequence of DetNet transit nodes between two DetNet re
lay nodes; a
segment of a recovery graph is composed topologically of two vertices of the
recovery graph and one edge of the recovery graph between those vertices. recovery graph and one edge of the recovery graph between those vertices.
</t> </t>
</section> </section>
</section>
</section><!--Path and recovery graphs--> <section numbered="true" removeInRFC="false" toc="include" pn="section-3.4
">
<section><name>Deterministic Networking</name> <name slugifiedName="name-deterministic-networking">Deterministic Networ
<t>This document reuses the terminology in section 2 of king</name>
<xref target="RFC8557"/> and section 4.1.2 of <xref target="RFC8655"/> <t indent="0" pn="section-3.4-1">This document reuses the terminology in
for deterministic networking and deterministic networks. <xref target="RFC8557" section="2" format="default" sectionFormat="of" deriv
</t> edLink="https://rfc-editor.org/rfc/rfc8557#section-2" derivedContent="RFC8557"/>
and <xref target="RFC8655" section="4.1.2" format="default" sectionFormat="of"
<section><name>The DetNet Planes</name> derivedLink="https://rfc-editor.org/rfc/rfc8655#section-4.1.2" derivedContent="D
<t> etNet-ARCH"/>
<xref target="RFC8655"/> defines three planes: the Application (User) Plane, for deterministic networking and deterministic networks. This document also
the Controller Plane, uses the following terms.
</t>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3
.4.1">
<name slugifiedName="name-the-detnet-planes">The DetNet Planes</name>
<t indent="0" pn="section-3.4.1-1">
<xref target="RFC8655" format="default" sectionFormat="of" derivedContent="De
tNet-ARCH"/> defines three planes: the Application (User) Plane, the Controller
Plane,
and the Network Plane. and the Network Plane.
The DetNet Network Plane is composed of a Data Plane (packet forwarding) and an The DetNet Network Plane is composed of a Data Plane (packet forwarding) and an
Operational Plane where OAM operations take place. Operational Plane where OAM operations take place.
In the Network Plane, the DetNet Service sub-layer In the Network Plane, the DetNet Service sub-layer
focuses on flow protection (e.g., using redundancy) and can be fully operated focuses on flow protection (e.g., using redundancy) and can be fully operated
at Layer-3, while the DetNet forwarding sub-layer establishes the paths, at Layer 3, while the DetNet forwarding sub-layer establishes the paths,
associates the flows to the paths, and ensures the availability of the associates the flows to the paths, ensures the availability of the
necessary resources, leverages Layer-2 functionalities for timely delivery necessary resources, and leverages Layer 2 functionalities for timely deliver
to the next DetNet system, more in <xref target='problem'/>. y
</t> to the next DetNet system. For more information, see <xref target="problem" f
</section> ormat="default" sectionFormat="of" derivedContent="Section 2"/>.
</t>
<section><name>Flow</name> </section>
<t> <section numbered="true" removeInRFC="false" toc="include" pn="section-3
A collection of consecutive IP packets defined by the upper layers and .4.2">
signaled by the same 5 or 6-tuple (see section 5.1 of <name slugifiedName="name-flow">Flow</name>
<xref target="RFC8939"/>). Packets of the same flow must be placed <t indent="0" pn="section-3.4.2-1">
on the same recovery graph to receive an equivalent treatment from Ingress t A flow is a collection of consecutive IP packets defined by the upper layers
o Egress and
signaled by the same 5-tuple or 6-tuple (see
<xref target="RFC8939" section="5.1" format="default" sectionFormat="of" der
ivedLink="https://rfc-editor.org/rfc/rfc8939#section-5.1" derivedContent="RFC893
9"/>). Packets of the same flow must be placed
on the same recovery graph to receive an equivalent treatment from ingress t
o egress
within the recovery graph. Multiple flows may be transported along the same recovery graph. within the recovery graph. Multiple flows may be transported along the same recovery graph.
The DetNet Path that is selected for the flow may change over time under the The DetNet path that is selected for the flow may change over time under the
control of the PLR. control of the PLR.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3
<section><name>Residence Time</name> .4.3">
<t> <name slugifiedName="name-residence-time">Residence Time</name>
<t indent="0" pn="section-3.4.3-1">
A residence time (RT) is defined as the time interval between when the recep tion A residence time (RT) is defined as the time interval between when the recep tion
of a packet starts and the transmission of the packet begins. In the of a packet starts and the transmission of the packet begins. In the
context of RAW, RT is useful for a transit node, not ingress or egress. context of RAW, RT is useful for a transit nodes, not ingress or egress nodes
</t> .
</section> </t>
</section>
<section><name>L3 Deterministic Flow Identifier </name> <section numbered="true" removeInRFC="false" toc="include" pn="section-3
<t> .4.4">
See section 3.3 of <xref target="RFC8938"/>. The classic IP 5-tuple that <name slugifiedName="name-l3-deterministic-flow-ident">L3 Deterministi
identifies a flow comprises the source IP, destination IP, source port, c Flow Identifier </name>
destination port, and <t indent="0" pn="section-3.4.4-1">
the upper layer protocol (ULP). DetNet uses a 6-tuple where the extra field The classic IP 5-tuple that identifies a flow comprises the source IP,
is the DSCP field in the packet. The IPv6 flow label is not used for that destination IP, source port, destination port, and the Upper-Layer
purpose. Protocol (ULP). DetNet uses a 6-tuple where the extra field is the
</t> Differentiated Services Code Point (DSCP) field in the packet (see <xref ta
</section> rget="RFC8938" section="3.3" format="default" sectionFormat="of" derivedLink="ht
tps://rfc-editor.org/rfc/rfc8938#section-3.3" derivedContent="DetNet-DP"/>). The
<section><name>TSN</name> IPv6 flow label is not used for
<t> that purpose.
TSN stands for Time-Sensitive Networking and denotes the efforts at IEEE </t>
802 for deterministic networking, originally for use on Ethernet. Wireless </section>
TSN (WTSN) denotes extensions of the TSN work on wireless media such as <section numbered="true" removeInRFC="false" toc="include" pn="section-3
the selected RAW technologies <xref target="I-D.ietf-raw-technologies"/>. .4.5">
</t> <name slugifiedName="name-time-sensitive-networking">Time-Sensitive Ne
</section> tworking</name>
<t indent="0" pn="section-3.4.5-1">
<section><name>Lower-Layer API</name> Time-Sensitive Networking (TSN) denotes the IEEE 802 efforts regarding
<t> deterministic networking, originally for use on
In addition, RAW includes the concept of a lower-layer API (LL Ethernet. See <xref target="TSN" format="default" sectionFormat="of" derivedC
API), that provides an interface between the ontent="TSN"/>. Wireless TSN (WTSN) denotes extensions of the TSN work on
lower layer (e.g., wireless) technology and the DetNet layers. The LL API is wireless media, e.g., the RAW technologies described in <xref target="RFC9913
" format="default" sectionFormat="of" derivedContent="RAW-TECHNOS"/>.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3
.4.6">
<name slugifiedName="name-lower-layer-api">Lower-Layer API</name>
<t indent="0" pn="section-3.4.6-1">
RAW includes the concept of a lower-layer API (LL
API) that provides an interface between the
lower-layer (e.g., wireless) technology and the DetNet layers. The LL API is
technology dependent as what the lower layers expose towards the DetNet laye rs may vary. technology dependent as what the lower layers expose towards the DetNet laye rs may vary.
Furthermore, the different RAW technologies are equipped with different Furthermore, different RAW technologies are equipped with
reliability features, e.g., short range broadcast, Multiple-User, different reliability features (e.g., short-range broadcast,
Multiple-Input, and Multiple-Output (MUMIMO), PHY rate and Multiple User - Multiple Input Multiple Output (MU-MIMO), physical layer (PH
other Modulation Coding Scheme (MCS) adaptation, coding and retransmissions m Y) rate
ethods, constructive and other Modulation Coding Scheme (MCS) adaptation, coding and
interference and overhearing, see <xref target="I-D.ietf-raw-technologies"/> retransmissions methods, and constructive interference and overhearing;
for details. see <xref target="RFC9913" format="default" sectionFormat="of" derivedContent
="RAW-TECHNOS"/> for more details).
The LL API enables interactions between the The LL API enables interactions between the
reliability functions provided by the lower layer and the reliability functions provided by the lower layer and the
reliability functions provided by DetNet. That is, the LL API makes reliability functions provided by DetNet. That is, the LL API makes
cross-layer optimization possible for the reliability functions of cross-layer optimization possible for the reliability functions of
different layers depending on the actual exposure provided via the LL API different layers depending on the actual exposure provided via the LL API
by the given RAW technology. by the given RAW technology.
The <xref target="RFC8175"> Dynamic Link Exchange Protocol (DLEP) </xref> is The <xref format="title" target="RFC8175" sectionFormat="of" derivedContent="
an Dynamic Link Exchange Protocol (DLEP)"/> <xref target="RFC8175" format="default"
example protocol that can be used to implement the LL API. sectionFormat="of" derivedContent="DLEP"/> is an
</t> example of a protocol that can be used to implement the LL API.
</t>
</section> </section>
</section><!--Deterministic Networking --> </section>
<section><name>Reliability and Availability</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-3.5
<t> ">
In the context of the RAW work, Reliability and Availability are defined as <name slugifiedName="name-reliability-and-availabilit">Reliability and A
follows: vailability</name>
</t> <t indent="0" pn="section-3.5-1">In the context of the RAW work, reliabi
lity and availability are
<section><name>Service Level Agreement</name> defined as follows, along with the following other terms.</t>
<t> <section numbered="true" removeInRFC="false" toc="include" pn="section-3
In the context of RAW, an SLA (service level agreement) is a contract .5.1">
between a provider (the network) and a client, the application flow, <name slugifiedName="name-service-level-agreement">Service Level Agree
defining measurable metrics such as latency boundaries, consecutive losses, ment</name>
and packet delivery ratio (PDR). <t indent="0" pn="section-3.5.1-1">
</t> In the context of RAW, a Service Level Agreement (SLA) is a contract
</section> between a provider (the network) and a client (the application flow) that def
<section><name>Service Level Objective</name> ines
<t> measurable metrics such as latency boundaries, consecutive
A service level objective (SLO) is one term in the SLA, for which specific losses, and Packet Delivery Ratio (PDR).
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3
.5.2">
<name slugifiedName="name-service-level-objective">Service Level Objec
tive</name>
<t indent="0" pn="section-3.5.2-1">
A Service Level Objective (SLO) is one term in the SLA, for which specific
network setting and operations are implemented. For instance, a dynamic network setting and operations are implemented. For instance, a dynamic
tuning of the packet redundancy addresses an SLO of consecutive losses in tuning of packet redundancy addresses an SLO of consecutive losses in
a row by augmenting the chances of delivery of a packet that follows a loss. a row by augmenting the chances of delivery of a packet that follows a loss.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3
<section><name>Service Level Indicator</name> .5.3">
<t> <name slugifiedName="name-service-level-indicator">Service Level Indic
A service level indicator (SLI) measures the compliance of an SLO to the ator</name>
terms of the contract. It can be for instance, the statistics of individual <t indent="0" pn="section-3.5.3-1">
losses and losses in a row as time series. A Service Level Indicator (SLI) measures the compliance of an SLO to the
</t> terms of the contract. For instance, it can be the statistics of
</section> individual losses or losses in a row during a certain amount of time.
</t>
<section><name> Precision Availability Metrics</name> </section>
<t> <section numbered="true" removeInRFC="false" toc="include" pn="section-3
Precision Availability Metrics (PAMs) <xref target="RFC9544"/> aim .5.4">
at capturing service levels for a flow, specifically the degree to which <name slugifiedName="name-precision-availability-metr">Precision Avail
ability Metrics</name>
<t indent="0" pn="section-3.5.4-1">
Precision Availability Metrics (PAMs) <xref target="RFC9544" format="default
" sectionFormat="of" derivedContent="RFC9544"/> aim
to capture service levels for a flow, specifically the degree to which
the flow complies with the SLOs that are in effect. the flow complies with the SLOs that are in effect.
</t> </t>
</section> </section>
<section><name>Reliability</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-3
<t> .5.5">
Reliability is a measure of the probability that an item (e.g., system, <name slugifiedName="name-reliability">Reliability</name>
<t indent="0" pn="section-3.5.5-1">
Reliability is a measure of the probability that an item (e.g., system or
network) will perform its intended function with no failure for a stated network) will perform its intended function with no failure for a stated
period of time (or a stated number of demands or load) under stated environme ntal period of time (or for a stated number of demands or load) under stated envir onmental
conditions. In other words, reliability is the probability that an item conditions. In other words, reliability is the probability that an item
will be in an uptime state (i.e., fully operational or ready to perform) will be in an uptime state (i.e., fully operational or ready to perform)
for a stated mission, e.g., to provide an SLA. See more in for a stated mission (e.g., to provide an SLA). See more in
<xref target="NASA1"/>. <xref target="NASA1" format="default" sectionFormat="of" derivedContent="NASA
</t> 1"/>.
</section> </t>
</section>
<section><name>Availability</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-3
<t> .5.6">
Availability is the probability of an item’s (e.g., a network’s) mission <name slugifiedName="name-availability">Availability</name>
readiness (e.g., to provide an SLA), an uptime state with the likelihood <t indent="0" pn="section-3.5.6-1">
of a recoverable downtime state. Availability is expressed as Availability is the probability of an item's (e.g., a network's)
mission readiness (e.g., to provide an SLA).
Availability is expressed as
(uptime)/(uptime+downtime). Note that it is availability that addresses (uptime)/(uptime+downtime). Note that it is availability that addresses
downtime (including time for maintenance, repair, and replacement activities) downtime (including time for maintenance, repair, and replacement activities)
and not reliability. See more in <xref target="NASA2"/>. and not reliability. See more in <xref target="NASA2" format="default" sectio
</t> nFormat="of" derivedContent="NASA2"/>.
</t>
</section>
</section>
</section> </section>
<section anchor="raw" numbered="true" toc="include" removeInRFC="false" pn="
</section><!--Reliability and Availability--> section-4">
<name slugifiedName="name-reliable-and-available-wire">Reliable and Availa
</section><!-- Terminology --> ble Wireless</name>
<!-- 1111111111111111 --> <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1
<section anchor="raw" numbered="true" toc="default"> ">
<name>Reliable and Available Wireless</name> <name slugifiedName="name-high-availability-engineeri">High Availability
Engineering Principles</name>
<!-- 2222222222222222 --> <t indent="0" pn="section-4.1-1">
<section numbered="true" toc="default"> The reliability criteria of a critical system pervade its elements,
<name>High Availability Engineering Principles</name> and if the system comprises a data network, then the data network is also
<t>
The reliability criteria of a critical system pervade through its elements,
and if the system comprises a data network and then the data network is also
subject to the inherited reliability and availability criteria. subject to the inherited reliability and availability criteria.
It is only natural to consider the art of high availability engineering and It is only natural to consider the art of high availability engineering and
apply it to wireless communications in the context of RAW. apply it to wireless communications in the context of RAW.
</t> </t>
<t indent="0" pn="section-4.1-2">
<t>
There are three principles (pillars) of high availability engineering: There are three principles (pillars) of high availability engineering:
</t> </t>
<ol spacing="compact"> <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4.
<li>elimination of each single point of failure</li> 1-3">
<li>reliable crossover</li> <li pn="section-4.1-3.1" derivedCounter="1.">elimination of each single poi
<li>prompt detection of failures as they occur</li> nt of failure</li>
</ol> <li pn="section-4.1-3.2" derivedCounter="2.">reliable crossover</li>
<t> <li pn="section-4.1-3.3" derivedCounter="3.">prompt detection of failu
res as they occur</li>
</ol>
<t indent="0" pn="section-4.1-4">
These principles are common to all high availability systems, not just ones These principles are common to all high availability systems, not just ones
with Internet technology at the center. Examples of both non-Internet and with Internet technology at the center. Both non-Internet and
Internet are included. Internet examples are included.
</t> </t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4
<!-- 333333333333333333333 --> .1.1">
<name slugifiedName="name-elimination-of-single-point">Elimination of
<section numbered="true" toc="default"> Single Points of Failure</name>
<name>Elimination of Single Points of Failure</name> <t indent="0" pn="section-4.1.1-1">
<t>
Physical and logical components in a system happen to fail, either as the Physical and logical components in a system happen to fail, either as the
effect of wear and tear, when used beyond acceptable limits, or due to a effect of wear and tear, when used beyond acceptable limits, or due to a
software bug. software bug.
It is necessary to decouple component failure from system failure to avoid It is necessary to decouple component failure from system failure to avoid
the latter. the latter.
This allows failed components to be restored while the rest of the system This allows failed components to be restored while the rest of the system
continues to function. continues to function.
</t> </t>
<t> <t indent="0" pn="section-4.1.1-2">
IP Routers leverage routing protocols to reroute to alternate routes in case IP routers leverage routing protocols to reroute to alternate routes in case
of a failure. When links are cabled through the same conduit, they form a of a failure. When links are cabled through the same conduit, they form a
shared risk link group (SRLG), and share the same fate if the conduit is Shared Risk Link Group (SRLG) and share the same fate if the conduit is
cut, making the reroute operation ineffective. cut, making the reroute operation ineffective.
The same effect can happen with virtual links that end up in a same The same effect can happen with virtual links that end up in the same
physical transport through the intricacies of nested encapsulation. physical transport through the intricacies of nested encapsulation.
In a same fashion, an interferer or an obstacle may affect multiple In the same fashion, an interferer or an obstacle may affect multiple
wireless transmissions at the same time, even between different sets of peer s. wireless transmissions at the same time, even between different sets of peer s.
</t> </t>
<t> <t indent="0" pn="section-4.1.1-3">
Intermediate network Nodes such as routers, switches and APs, wire bundles, Intermediate network nodes (such as routers, switches and APs, wire bundles,
and the air medium itself can become single points of failure. For High and the air medium itself) can become single points of failure. Thus, for hi
Availability, it is thus required to use physically link-disjoint and Node-d gh
isjoint availability, the use of physically link-disjoint and node-disjoint
paths; in the wireless space, it is also required to use the highest paths is required; in the wireless space, the use of the highest
possible degree of diversity (time, space, code, frequency, channel width) possible degree of diversity (time, space, code, frequency, and channel widt
in the transmissions over the air to combat the additional causes of h)
in the transmissions over the air is also required to combat the additional
causes of
transmission loss. transmission loss.
</t> </t>
<t> <t indent="0" pn="section-4.1.1-4">
From an economics standpoint, executing this principle properly generally From an economics standpoint, executing this principle properly generally
increases capital expense because of the redundant equipment. In a increases capital expense because of the redundant equipment. In a
constrained network where the waste of energy and bandwidth should be constrained network where the waste of energy and bandwidth should be
minimized, an excessive use of redundant links must be avoided; for RAW this minimized, an excessive use of redundant links must be avoided; for RAW, thi s
means that the extra bandwidth must be used wisely and efficiently. means that the extra bandwidth must be used wisely and efficiently.
</t> </t>
</section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-4
<!--Elimination of Single Points of Failure--> .1.2">
<name slugifiedName="name-reliable-crossover">Reliable Crossover</name
<!-- 333333333333333333333 --> >
<t indent="0" pn="section-4.1.2-1">
<section numbered="true" toc="default"> Backup equipment has limited value unless it can be reliably
<name>Reliable Crossover</name> switched into use within the downtime parameters.
IP routers execute reliable crossover continuously because
<t> the routers use any alternate routes that are available <xref target="RFC079
Having backup equipment has a limited value unless it can be reliably 1" format="default" sectionFormat="of" derivedContent="RFC0791"/>. This is due t
switched into use within the down-time parameters. o the stateless nature of IP datagrams and the
IP Routers execute reliable crossover continuously because
the routers use any alternate routes that are available <xref target=
"RFC0791"/>. This is due to the stateless nature of IP datagrams and the
dissociation of the datagrams from the forwarding routes they take. dissociation of the datagrams from the forwarding routes they take.
The <xref target="RFC5714">"IP Fast Reroute Framework"</xref> analyzes "IP Fast Reroute Framework" <xref target="RFC5714" format="default" sectionF
mechanisms for fast failure detection and path repair for IP Fast-Reroute (F ormat="of" derivedContent="FRR"/> analyzes
RR), mechanisms for fast failure detection and path repair for IP Fast Reroute (F
RR)
and discusses the case of multiple failures and SRLG. Examples of FRR and discusses the case of multiple failures and SRLG. Examples of FRR
techniques include Remote Loop-Free Alternate <xref target="RFC7490"/> and techniques include Remote Loop-Free Alternate <xref target="RFC7490" format=
backup label-switched path (LSP) tunnels for the local repair of LSP tunnels "default" sectionFormat="of" derivedContent="RLFA-FRR"/> and
using RSVP-TE <xref target="RFC4090"/>. backup Label Switched Path (LSP) tunnels for the local repair of LSP tunnels
</t> using RSVP-TE <xref target="RFC4090" format="default" sectionFormat="of" der
<t> ivedContent="RFC4090"/>.
</t>
<t indent="0" pn="section-4.1.2-2">
Deterministic flows, on the contrary, are attached to specific paths where Deterministic flows, on the contrary, are attached to specific paths where
dedicated resources are reserved for each flow. Therefore, each DetNet path dedicated resources are reserved for each flow. Therefore, each DetNet path
must inherently provide sufficient redundancy to provide the assured SLOs must inherently provide sufficient redundancy to provide the assured SLOs
at all times. at all times.
The DetNet PREOF typically leverages 1+1 redundancy whereby a packet is sent The DetNet PREOF typically leverages 1+1 redundancy whereby a packet is sent
twice, over non-congruent paths. This avoids the gap during the fast reroute twice, over non-congruent paths. This avoids the gap during the FRR
operation, but doubles the traffic in the network. operation but doubles the traffic in the network.
</t> </t>
<t> <t indent="0" pn="section-4.1.2-3">
In the case of RAW, the expectation is that multiple transient faults may In the case of RAW, the expectation is that multiple transient faults may
happen in overlapping time windows, in which case the 1+1 redundancy with happen in overlapping time windows, in which case the 1+1 redundancy with
delayed reestablishment of the second path does not provide the required delayed reestablishment of the second path does not provide the required
guarantees. guarantees.
The Data Plane must be configured with a sufficient degree of The Data Plane must be configured with a sufficient degree of
redundancy to select an alternate redundant path immediately upon a fault, redundancy to select an alternate redundant path immediately upon a fault,
without the need for a slow intervention from the Controller Plane. without the need for a slow intervention from the Controller Plane.
</t> </t>
</section> </section>
<!--Reliable Crossover--> <section numbered="true" toc="include" removeInRFC="false" pn="section-4
.1.3">
<!-- 333333333333333333333 --> <name slugifiedName="name-prompt-notification-of-fail">Prompt Notifica
tion of Failures</name>
<section numbered="true" toc="default"> <t indent="0" pn="section-4.1.3-1">
<name>Prompt Notification of Failures</name>
<t>
The execution of the two above principles is likely to render a system where The execution of the two above principles is likely to render a system where
the end user rarely sees a failure. But a failure that occurs must still be the end user rarely sees a failure. However, a failure that occurs must stil
detected in order to direct maintenance. l be detected in order to direct maintenance.
</t> </t>
<t> <t indent="0" pn="section-4.1.3-2">
There are many reasons for system monitoring (FCAPS for fault, configuration There are many reasons for system monitoring (Fault, Configuration, Accounti
, ng, Performance, and Security (FCAPS) is a handy mental checklist), but fault
accounting, performance, security is a handy mental checklist) but fault monitoring is a sufficient reason.
monitoring is sufficient reason. </t>
<t indent="0" pn="section-4.1.3-3">
</t> "Overview and Principles of Internet Traffic Engineering" <xref target="RFC9
<t> 522" format="default" sectionFormat="of" derivedContent="TE"/> discusses
<xref target="RFC9522"> the importance of measurement for network protection and provides an
"Overview and Principles of Internet Traffic Engineering"</xref> discusses
the importance of measurement for network protection, and provides an
abstract method for network survivability with the analysis of a traffic abstract method for network survivability with the analysis of a traffic
matrix as observed via a network management YANG data model, probing techniqu es, matrix as observed via a network management YANG data model, probing techniqu es,
file transfers, IGP link state advertisements, and more. file transfers, IGP link state advertisements, and more.
</t> </t>
<t indent="0" pn="section-4.1.3-4">
<t>
Those measurements are needed in the context of RAW to inform the controller Those measurements are needed in the context of RAW to inform the controller
and make the long-term reactive decision to rebuild a recovery graph based o n and make the long-term reactive decision to rebuild a recovery graph based o n
statistical and aggregated information. RAW itself operates in the DetNet statistical and aggregated information. RAW itself operates in the DetNet
Network Network
Plane at a faster time-scale with live information on speed, state, etc. Plane at a faster timescale with live information on speed, state, etc.
This live information can be obtained directly from the lower layer, e.g., This live information can be obtained directly from the lower layer (e.g.,
using L2 triggers, read from a protocol such as DLEP, using L2 triggers), read from a protocol such as DLEP,
or transported over multiple hops using OAM and reverse OAM, or transported over multiple hops using OAM and reverse OAM,
as illustrated in <xref target="Figlearn"/>. as illustrated in <xref target="Figlearn" format="default" sectionFormat="of
</t> " derivedContent="Figure 11"/>.
</t>
</section> </section>
<!--Prompt Notification of Failures--> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.2
</section> ">
<!--Reliability Engineering--> <name slugifiedName="name-applying-reliability-concep">Applying Reliabil
<!-- 22222222222222222222 --> ity Concepts to Networking</name>
<t indent="0" pn="section-4.2-1">
<section numbered="true" toc="default"> The terms "reliability" and "availability" are defined for use in RAW in
<name>Applying Reliability Concepts to Networking</name> <xref target="terms" format="default" sectionFormat="of" derivedContent="Sec
<t> tion 3"/>, and the reader is invited to read
The terms Reliability and Availability are defined for use in RAW in <xref target="NASA1" format="default" sectionFormat="of" derivedContent="NAS
<xref target="terms"/> and the reader is invited to read A1"/> and <xref target="NASA2" format="default" sectionFormat="of" derivedConten
<xref target="NASA1"/> and <xref target="NASA2"/> t="NASA2"/>
for more details on the general definition of Reliability. for more details on the general definition of reliability.
Practically speaking, a number of nines is often used to indicate the Practically speaking, a number of nines is often used to indicate the
reliability of a data link, e.g., 5 nines indicate a reliability of a data link (e.g., 5 nines indicate a
Packet Delivery Ratio (PDR) of 99.999%. Packet Delivery Ratio (PDR) of 99.999%).
</t> </t>
<t> <t indent="0" pn="section-4.2-2">
This number is typical in a wired This number is typical in a wired
environment where the loss is due to a random event such as a solar particle environment where the loss is due to a random event such as a solar particle
that affects the transmission of a particular packet, but does not affect th that affects the transmission of a particular packet but does not affect the
e previous packet, the next packet, or packets transmitted on other links. Not
previous or next packet, nor packets transmitted on other links. Note that t e that the
he
QoS requirements in RAW may include a bounded latency, and a packet that QoS requirements in RAW may include a bounded latency, and a packet that
arrives too late is a fault and not considered as delivered. arrives too late is a fault and not considered as delivered.
</t> </t>
<t> <t indent="0" pn="section-4.2-3">
For a periodic networking pattern such as an automation control loop, this For a periodic networking pattern such as an automation control loop, this
number is proportional to the Mean Time Between Failures (MTBF). number is proportional to the Mean Time Between Failures (MTBF).
When a single fault can have dramatic consequences, the MTBF expresses the When a single fault can have dramatic consequences, the MTBF expresses the
chances that the unwanted fault event occurs. In data networks, chances that the unwanted fault event occurs. In data networks,
this is rarely the case. Packet loss cannot be fully avoided and the this is rarely the case. Packet loss cannot be fully avoided, and the
systems are built to resist some loss, e.g., using redundancy with Retries systems are built to resist some loss. This can be done by using redundancy
(as in HARQ), Packet Replication and Elimination (PRE) FEC, Network Coding ( with retries
e.g., using (as in HARQ), Packet Replication and Elimination (PRE) FEC, and Network Codi
FEC with SCHC <xref target="RFC8724"/> fragments), or, in a typical control ng (e.g., using
loop, by linear interpolation from the previous measurements. FEC with Static Context Header Compression (SCHC) <xref target="RFC8724" for
</t> mat="default" sectionFormat="of" derivedContent="RFC8724"/> fragments). Also, in
<t> a typical control
But the linear interpolation method cannot resist multiple consecutive loop, linear interpolation from the previous measurements can be used.
losses, and a high MTBF is desired as a guarantee that this does not happen, </t>
in other words that the number of losses-in-a-row can be bounded. In that ca <t indent="0" pn="section-4.2-4">
se, what is However, the linear interpolation method cannot resist multiple consecutive
really desired is a Maximum Consecutive Loss (MCL). (See also section losses, and a high MTBF is desired as a guarantee that the number of losses
5.9.5 in <xref target="RFC8175"/>.) in a row is bounded. In this case, what is really desired is a Maximum
If the number of losses in a row passes the MCL, the control loop has to Consecutive Loss (MCL). If the number of losses in a row passes the MCL, the
abort and the system, e.g., the production line, may need to enter an control loop has to abort, and the system (e.g., the production line) may
emergency stop condition. need to enter an emergency stop condition.
</t> </t>
<t> <t indent="0" pn="section-4.2-5">
Engineers that build automated processes may use the network reliability Engineers that build automated processes may use the network
expressed in nines as an MTBF as a proxy to indicate an MCL, e.g., as reliability expressed in nines as the MTBF and as a proxy to indicate an
described in section 7.4 of the <xref target="RFC8578">"Deterministic MCL, e.g., as described in Section <xref target="RFC8578" sectionFormat="bare
Networking Use Cases"</xref>. " section="7.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8578
</t> #section-7.4" derivedContent="RFC8578"/> of "Deterministic
</section> Networking Use Cases" <xref target="RFC8578" format="default" sectionFormat="
<!--Applying Reliability concepts to Networking--> of" derivedContent="RFC8578"/>.
<!-- 22222222222222222222 --> </t>
</section>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3
<name>Wireless Effects Affecting Reliability</name> ">
<t> <name slugifiedName="name-wireless-effects-affecting-">Wireless Effects
Affecting Reliability</name>
<t indent="0" pn="section-4.3-1">
In contrast with wired networks, errors in transmission are the predominant In contrast with wired networks, errors in transmission are the predominant
source of packet loss in wireless networks. source of packet loss in wireless networks.
</t> </t>
<t> <t indent="0" pn="section-4.3-2">
The root cause for the loss may be of multiple origins, calling for The root cause for the loss may be of multiple origins, calling for
the use of different forms of diversity: the use of different forms of diversity:
</t> </t>
<dl> <dl indent="3" newline="false" spacing="normal" pn="section-4.3-3">
<dt>Multipath Fading:</dt> <dt pn="section-4.3-3.1">Multipath fading:</dt>
<dd> <dd pn="section-4.3-3.2">
<t>A destructive interference by a reflection of the original signal. <t indent="0" pn="section-4.3-3.2.1">A destructive interference by a
</t> reflection of the original signal.
<t>A radio signal may be received directly </t>
<t indent="0" pn="section-4.3-3.2.2">A radio signal may be received
directly
(line-of-sight) and/or as a reflection on a physical structure (echo). (line-of-sight) and/or as a reflection on a physical structure (echo).
The reflections take a longer path and are delayed by the extra distance The reflections take a longer path and are delayed by the extra distance
divided by the speed of light in the medium. Depending on the frequency, the divided by the speed of light in the medium. Depending on the frequency, the
echo lands with a different phase which may add up to (constructive echo lands with a different phase, which may either add up to (constructive
interference) or cancel (destructive interference) the direct signal. interference) or cancel (destructive interference) the direct signal.
</t> </t>
<t> <t indent="0" pn="section-4.3-3.2.3">
The affected frequencies depend on the relative position of the sender, the The affected frequencies depend on the relative position of the sender, the
receiver, and all the reflecting objects in the environment. receiver, and all the reflecting objects in the environment.
A given hop suffers from multipath fading for multiple packets in a A given hop suffers from multipath fading for multiple packets in a
row till a physical movement changes the reflection patterns. row until a physical movement changes the reflection patterns.
</t> </t>
</dd> </dd>
<dt>Co-channel Interference:</dt> <dt pn="section-4.3-3.3">Co-channel interference:</dt>
<dd> <dd pn="section-4.3-3.4">
<t> <t indent="0" pn="section-4.3-3.4.1">
Energy in the spectrum used for the transmission confuses the receiver. Energy in the spectrum used for the transmission confuses the receiver.
</t> </t>
<t> <t indent="0" pn="section-4.3-3.4.2">
The wireless medium itself is a Shared Risk Link Group (SRLG) for nearby The wireless medium itself is a Shared Risk Link Group (SRLG) for nearby
users of the same spectrum, as an interference may affect multiple co-channe l users of the same spectrum, as an interference may affect multiple co-channe l
transmissions between different peers within the interference domain of the transmissions between different peers within the interference domain of the
interferer, possibly even when they use different technologies. interferer, possibly even when they use different technologies.
</t> </t>
</dd> </dd>
<dt>Obstacle in Fresnel Zone:</dt> <dt pn="section-4.3-3.5">Obstacle in Fresnel zone:</dt>
<dd> <dd pn="section-4.3-3.6">
<t indent="0" pn="section-4.3-3.6.1">
<t>
The Fresnel zone is an elliptical region of space between and around the tra nsmit The Fresnel zone is an elliptical region of space between and around the tra nsmit
and receive antennas in a point-to-point wireless communication. and receive antennas in a point-to-point wireless communication.
The optimal transmission happens when it is free of obstacles. The optimal transmission happens when it is free of obstacles.
</t> </t>
</dd> </dd>
</dl> </dl>
<t> <t indent="0" pn="section-4.3-4">
In an environment that is rich in metallic structures and mobile objects, a In an environment that is rich in metallic structures and mobile objects, a
single radio link provides a fuzzy service, meaning that it cannot be single radio link provides a fuzzy service, meaning that it cannot be
trusted to transport the traffic reliably over a long period of time. trusted to transport the traffic reliably over a long period of time.
</t> </t>
<t> <t indent="0" pn="section-4.3-5">
Transmission losses are typically not independent, and their nature and Transmission losses are typically not independent, and their nature and
duration are unpredictable; as long as a physical object (e.g., a metallic duration are unpredictable; as long as a physical object (e.g., a metallic
trolley between peers) that affects the transmission is not removed, or as trolley between peers) that affects the transmission is not removed, or as
long as the interferer (e.g., a radar in the ISM band) keeps transmitting, a continuous long as the interferer (e.g., a radar in the ISM band) keeps transmitting, a continuous
stream of packets are affected. stream of packets are affected.
</t> </t>
<t> <t indent="0" pn="section-4.3-6">
The key technique to combat those unpredictable losses is diversity. The key technique to combat those unpredictable losses is diversity.
Different forms of diversity are necessary to combat different causes of Different forms of diversity are necessary to combat different causes of
loss and the use of diversity must be maximized to optimize the PDR. loss, and the use of diversity must be maximized to optimize the PDR.
</t> </t>
<t> <t indent="0" pn="section-4.3-7">
A single packet may be sent at different times (time diversity) over diverse A single packet may be sent at different times (time diversity) over
paths (spatial diversity) that rely on diverse radio channels (frequency diverse paths (spatial diversity) that rely on diverse radio channels
diversity) and diverse PHY technologies, e.g., narrowband vs. spread (frequency diversity) leveraging diverse PHY technologies (e.g.,
spectrum, or diverse codes. narrowband versus spread spectrum or diverse codes). Using time
Using time diversity defeats short-term interferences; diversity defeats short-term interferences; spatial diversity combats
spatial diversity combats very local causes of interference such as multipat very local causes of interference such as multipath fading; narrowband
h fading; and spread spectrum are relatively innocuous to one another and can be
narrowband and spread spectrum are relatively innocuous to one another and used for diversity in the presence of the other.
can be used for diversity in the presence of the other. </t>
</t> </section>
</section> </section>
<!--Reliability in the Context of RAW--> <section anchor="model" numbered="true" toc="include" removeInRFC="false" pn
="section-5">
</section> <!-- Reliable and Available Wireless --> <name slugifiedName="name-the-raw-conceptual-model">The RAW Conceptual Mod
el</name>
<!-- 000000000000000000000 --> <t indent="0" pn="section-5-1">
RAW extends the conceptual model described in Section <xref target="RFC8655"
<section anchor="model" numbered="true" toc="default"> sectionFormat="bare" section="4" format="default" derivedLink="https://rfc-edit
<name>The RAW Conceptual Model</name> or.org/rfc/rfc8655#section-4" derivedContent="DetNet-ARCH"/> of "Deterministic
<t> Networking Architecture" <xref target="RFC8655" format="default" sectionForm
RAW extends the conceptual model described in section 4 of the DetNet at="of" derivedContent="DetNet-ARCH"/> with the PLR at the
Architecture <xref target="RFC8655"/> with the PLR at the Service sub-layer, Service sub-layer, as illustrated in <xref target="FigLayers" format="defaul
as illustrated in <xref target='FigLayers'/>. The PLR t" sectionFormat="of" derivedContent="Figure 3"/>. The PLR
(see <xref target='PLRpce'/>) is a point of local reaction to (see <xref target="PLRpce" format="default" sectionFormat="of" derivedConten
provide additional agility against transmission loss. The PLR can act, e.g., t="Section 6.5"/>) provides additional agility against
based on indications from the lower layer or based on OAM. transmission loss. For example, the PLR can act based on indications from
</t> the lower layer or based on OAM.
</t>
<figure anchor="FigLayers"> <figure anchor="FigLayers" align="left" suppress-title="false" pn="figure-
<name>Extended DetNet Data-Plane Protocol Stack</name> 3">
<artwork align="left" name="" type="" alt=""> <name slugifiedName="name-extended-detnet-data-plane-">Extended DetNet D
ata Plane Protocol Stack</name>
<artwork align="left" name="" type="" alt="" pn="section-5-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 |
| Point of Local Repair | | | | Point of Local Repair | | |
skipping to change at line 1129 skipping to change at line 1318
| Point of Local Repair | | | | Point of Local Repair | | |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| 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>
<section anchor="plane" numbered="true" toc="include" removeInRFC="false"
<section anchor="plane" numbered="true" toc="default"> pn="section-5.1">
<name>The RAW Planes</name> <name slugifiedName="name-the-raw-planes">The RAW Planes</name>
<t> <t indent="0" pn="section-5.1-1">
The RAW Nodes are DetNet Relay Nodes that operate in the RAW Network Plane an The RAW nodes are DetNet relay nodes that operate in the RAW Network Plane an
d d
are capable of additional diversity mechanisms and measurement functions are capable of additional diversity mechanisms and measurement functions
related to the radio interface. related to the radio interface.
RAW leverages an Operational Plane orientation function (that typically opera RAW leverages an Operational Plane orientation function (that typically opera
tes inside the Ingress tes inside the ingress
Edge Nodes) to dynamically adapt the path of the packets and optimizes the edge nodes) to dynamically adapt the path of the packets and optimize the
resource usage. resource usage.
</t><t> </t>
<t indent="0" pn="section-5.1-2">
In the case of centralized routing operations, the RAW Controller Plane Funct ion (CPF) interacts In the case of centralized routing operations, the RAW Controller Plane Funct ion (CPF) interacts
with RAW Nodes over a Southbound API. It consumes data and information from with RAW nodes over a Southbound API. It consumes data and information from
the network and generates knowledge and wisdom to help steer the traffic opti mally inside a recovery graph. the network and generates knowledge and wisdom to help steer the traffic opti mally inside a recovery graph.
</t> </t>
<figure anchor="FigCPF"> <figure anchor="FigCPF" align="left" suppress-title="false" pn="figure-4
<name>RAW Nodes (Centralized Routing Case)</name> ">
<artwork align="center" name="" type="" alt=""> <name slugifiedName="name-raw-nodes-centralized-routi">RAW Nodes (Cent
ralized Routing Case)</name>
<artwork align="center" name="" type="" alt="" pn="section-5.1-3.1">
DetNet Routing DetNet Routing
CPF CPF CPF CPF CPF CPF CPF CPF
Southbound API Southbound API
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
___ RAW ___ RAW ___ RAW ___ RAW __ ___ RAW ___ RAW ___ RAW ___ RAW __
/ Node Node Node Node \ / Node Node Node Node \
Ingress __/ / \ / \ \____Egress Ingress __/ / \ / \ \____Egress
End __ / \ / .- -- . \ ___ End End __ / \ / .- -- . \ ___ End
Node \ / \ / .-( ). \ / Node Node \ / \ / .-( ). \ / Node
\_ RAW ___ RAW ___(Non-RAW Nodes)__ RAW _/ \_ RAW ___ RAW ___(Non-RAW Nodes)__ RAW _/
Node Node (___.______.____) Node Node Node (___.______.____) Node
</artwork> </artwork>
</figure> </figure>
<t> <t indent="0" pn="section-5.1-4">
When a new flow is defined, the routing function uses its current knowledge o f When a new flow is defined, the routing function uses its current knowledge o f
the network to build a new recovery graph between an Ingress End System and a the network to build a new recovery graph between an ingress End System and a
n Egress n egress
End System for that flow; it indicates to the RAW Nodes where the PREOF and/o End System for that flow; it indicates to the RAW nodes where the PREOF and/o
r radio r radio
diversity and reliability operations may be actioned in the Network Plane. diversity and reliability operations may be actioned in the Network Plane.
</t> </t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-5
<li> .1-5">
<li pn="section-5.1-5.1">
The recovery graph may be strict, meaning that the The recovery graph may be strict, meaning that the
DetNet forwarding sub-layer operations are enforced end-to-end DetNet forwarding sub-layer operations are enforced end to end.
</li><li> </li>
<li pn="section-5.1-5.2">
The recovery graph may be expressed loosely to enable traversing a non-RAW s ubnetwork The recovery graph may be expressed loosely to enable traversing a non-RAW s ubnetwork
as in <xref target='FigDN3'/>. as in <xref target="FigDN3" format="default" sectionFormat="of" derivedConte nt="Figure 7"/>.
In that case, RAW cannot leverage end-to-end DetNet and cannot provide In that case, RAW cannot leverage end-to-end DetNet and cannot provide
latency guarantees. latency guarantees.
</li> </li>
</ul> </ul>
<t> <t indent="0" pn="section-5.1-6">
The information that the orientation function reports to the routing functio The information that the orientation function reports to the routing
n function may be time aggregated (e.g., statistical), to match the
includes may be a time-aggregated, e.g., statistical fashion, to match the lo longer-term operation of the routing function. Example information includes
nger-term link-layer metrics such as link bandwidth (the medium speed depends
operation of the routing function. dynamically on the mode of the PHY layer), number of flows (bandwidth that
Example information includes Link-Layer metrics such as Link can be reserved for a flow depends on the number and size of flows sharing
bandwidth (the medium speed depends dynamically on the mode of the physical the spectrum), and the average and mean squared deviation of availability
(PHY) layer), number of and reliability metrics (such as PDR) over long periods of time. It may
flows (bandwidth that can be reserved for a flow depends on the number and also report an aggregated Expected Transmission Count (ETX) or a variation
size of flows sharing the spectrum) and average and mean squared deviation of it. </t>
of availability and reliability metrics, such as Packet Delivery Ratio (PDR) <t indent="0" pn="section-5.1-7"> Based on those metrics, the routing fu
over long periods of time. It may also report an aggregated expected nction installs the
transmission count (ETX), or a variation of it. recovery graph with enough redundant forwarding solutions to ensure that
</t><t> the Network Plane can reliably deliver the packets within an SLA associated
Based on those metrics, the routing function installs the recovery graph wit with the flows that it transports. The SLA defines end-to-end reliability
h enough and availability requirements, in which reliability may be expressed as a
redundant forwarding solutions to ensure that the Network Plane can reliably successful delivery in order and within a bounded delay of at least one
deliver the packets within an SLA associated with the copy of a packet. </t>
flows that it transports. <t indent="0" pn="section-5.1-8"> Depending on the use case and the SLA,
The SLA defines end-to-end reliability and availability requirements, in whi the
ch recovery graph may comprise non-RAW segments, either interleaved inside the
reliability may be expressed as a successful delivery in-order and within a recovery graph (e.g., over tunnels) or all the way to the egress End node
bounded delay of at least one copy of a packet. (e.g., a server in the local wired domain). RAW observes the lower-layer
</t><t> links between RAW nodes (typically radio links) and the end-to-end
Depending on the use case and the SLA, the recovery graph may comprise non-R network-layer operation to decide at all times which of the diversity
AW schemes is actioned by which RAW nodes. </t>
segments, either interleaved inside the recovery graph (e.g. over tunnels), <t indent="0" pn="section-5.1-9"> Once a recovery graph is
or all the way to the Egress End Node (e.g., a server in the local wired established, per-segment and end-to-end reliability and availability
domain). RAW observes the statistics are periodically reported to the routing function to ensure that
Lower-Layer Links between RAW nodes (typically, radio links) and the the SLA can be met; if not, then the recovery graph is recomputed.
end-to-end Network Layer operation to decide at all times which of the </t>
diversity schemes is actioned by which RAW Nodes. </section>
</t><t> <section anchor="layers" numbered="true" toc="include" removeInRFC="false"
Once a recovery graph is established, per-segment and end-to-end reliability pn="section-5.2">
and availability statistics are periodically reported to the routing function <name slugifiedName="name-raw-versus-upper-and-lower-">RAW Versus Upper
to ensure and Lower Layers</name>
that the SLA can be met or if not, then have the recovery graph recomputed. <t indent="0" pn="section-5.2-1">RAW builds on DetNet-provided features
</t> such as scheduling and shaping.
</section> <!--The RAW Network Plane -->
<section anchor="layers" numbered="true" toc="default">
<name>RAW vs. Upper and Lower Layers</name>
<t>RAW builds on DetNet-provided features such as scheduling and shaping.
In particular, RAW inherits the DetNet guarantees on end-to-end latency, In particular, RAW inherits the DetNet guarantees on end-to-end latency,
which can be tuned to ensure that DetNet and RAW reliability mechanisms have which can be tuned to ensure that DetNet and RAW reliability mechanisms have
no side effect on upper layers, e.g., on transport-layer packet recovery. no side effect on upper layers, e.g., on transport-layer packet recovery.
RAW operations include possible rerouting, which in turn may affect RAW operations include possible rerouting, which in turn may affect
the ordering of a burst of packets. RAW also inherits PREOF from DetNet, the ordering of a burst of packets. RAW also inherits PREOF from DetNet,
which can be used to reorder packets before delivery to the upper layers. which can be used to reorder packets before delivery to the upper layers.
As a result, DetNet in general and RAW in particular offer a smoother As a result, DetNet in general and RAW in particular offer a smoother
transport experience for the upper layers than the Internet at large transport experience for the upper layers than the Internet at large,
with ultra-low jitter and loss. with ultra-low jitter and loss.
</t> </t>
<t> <t indent="0" pn="section-5.2-2">
RAW improves the reliability of transmissions and the availability of the RAW improves the reliability of transmissions and the availability of the
communication resources, and should be seen as a dynamic optimization of the communication resources and should be seen as a dynamic optimization of
use of the use of redundancy to maintain reliability and availability metrics
redundancy to maintain it within certain boundaries. within certain boundaries. For instance, ARQ (which provides one-hop
For instance, ARQ, which provides 1-hop reliability through acknowledgements reliability through acknowledgements and retries) and FEC codes (such as
and retries, turbo codes which reduce the PER) are typically operated at Layer 2 and
and FEC codes such as turbo codes which reduce the PER, are typically operat Layer 1, respectively. In both cases, redundant transmissions improve
ed at Layer-2 and Layer-1 respectively. the one-hop reliability at the expense of energy and latency, which are
In both cases, redundant transmissions improve the 1-hop reliability at the the resources that RAW must control. In order to achieve its goals, RAW
expense of energy and latency, which are the resources that RAW must control. may leverage the lower-layer operations by abstracting the concept and
In order to achieve its goals, RAW may leverage the lower-layer operations providing hints to the lower layers on the desired outcome (e.g., in
by abstracting the concept and providing hints to the lower layers terms of reliability and timeliness), as opposed to performing the actual
on the desired outcome, e.g., in terms of reliability and timeliness, operations at Layer 3.
as opposed to performing the actual operations at Layer-3. </t>
</t> <t indent="0" pn="section-5.2-3">
Guarantees such as bounded latency depend on the upper layers (transport or
<t> application) to provide the payload in volumes and at times that match the
Guarantees such as bounded latency depend on the upper layers (Transport or contract with the DetNet sub-layers and the layers below. An excess of
Application) to provide the payload in volumes and at times that match the incoming traffic at the DetNet ingress may result in dropping or
contract with the DetNet sub-layers and the layers below. Excess of queueing of packets and can entail loss, latency, or jitter; this violates t
incoming traffic at the DetNet Ingress may result in dropping or he guarantees that are provided inside the DetNet Network.
queueing of packets, and can entail loss, latency, or jitter, and </t>
therefore, violate the guarantees that are provided inside the DetNet Networ <t indent="0" pn="section-5.2-4">
k.
</t>
<t>
When the traffic from upper layers matches the expectation of the lower When the traffic from upper layers matches the expectation of the lower
layers, RAW still depends on DetNet mechanisms and the layers, RAW still depends on DetNet mechanisms and the
lower layers to provide the timing and lower layers to provide the timing and
physical resource guarantees that are needed to match the traffic SLA. physical resource guarantees that are needed to match the traffic SLA.
When the availability of the physical resource varies, RAW acts on the When the availability of the physical resource varies, RAW acts on the
distribution of the traffic to leverage alternates within a finite set of distribution of the traffic to leverage alternates within a finite set of
potential resources. potential resources.
</t> </t>
<t> <t indent="0" pn="section-5.2-5">
The Operational Plane elements (Routing and OAM control) may gather The Operational Plane elements (routing and OAM control) may gather
aggregated information from lower layers about e.g., link quality, aggregated information from lower layers (e.g., information about link quali
either via measurement or communication with the lower layer. ty),
via measurement or communication with the lower layer.
This information may be obtained from inside the device using This information may be obtained from inside the device using
specialized APIs (e.g., L2 triggers), via monitoring and measurement protoc specialized APIs (e.g., L2 triggers) via monitoring and measurement protocol
ols such as BFD s such as Bidirectional Forwarding Detection (BFD)
<xref target="RFC5880"/> and STAMP <xref target="RFC8762"/>, respectively, o <xref target="RFC5880" format="default" sectionFormat="of" derivedContent="R
r via a control protocol exchange with the FC5880"/> and Simple Two-way Active Measurement Protocol (STAMP) <xref target="R
lower layer via, e.g., DLEP <xref target="RFC8175"/>. It may then be FC8762" format="default" sectionFormat="of" derivedContent="RFC8762"/>, respecti
processed and exported through OAM messaging or via a YANG data model, vely, or via a control protocol exchange with the
lower layer (e.g., DLEP <xref target="RFC8175" format="default" sectionForma
t="of" derivedContent="DLEP"/>). It may then be
processed and exported through OAM messaging or via a YANG data model
and exposed to the Controller Plane. and exposed to the Controller Plane.
</t> </t>
</section>
</section> <!--The RAW Network Plane --> <section anchor="DetNet" numbered="true" toc="include" removeInRFC="false"
pn="section-5.3">
<section anchor="DetNet" numbered="true" toc="default"> <name slugifiedName="name-raw-and-detnet">RAW and DetNet</name>
<name>RAW and DetNet</name> <t indent="0" pn="section-5.3-1">
<t> RAW leverages the DetNet forwarding sub-layer and requires the support of
RAW leverages the DetNet Forwarding sub-layer and requires the support of OAM in DetNet transit nodes (see Figure 3 of <xref target="RFC8655" format="de
OAM in DetNet Transit Nodes (see Figure 3 of <xref target="RFC8655"/>) for the fault" sectionFormat="of" derivedContent="DetNet-ARCH"/>) for the
dynamic acquisition of link capacity and state to maintain a strict RAW dynamic acquisition of link capacity and state to maintain a strict RAW
service, end-to-end, over a DetNet Network. In turn, DetNet and thus RAW service end to end over a DetNet Network. In turn, DetNet and thus RAW
may benefit from / leverage functionality such as provided by TSN at the may benefit from or leverage functionality such as that provided by TSN at the
lower layers. lower layers.
</t> </t>
<t> <t indent="0" pn="section-5.3-2">
RAW extends DetNet to improve the RAW extends DetNet to improve the
protection against link errors such as transient flapping that are far more protection against link errors such as transient flapping that are far more
common in wireless links. Nevertheless, the RAW methods are for the most part common in wireless links. Nevertheless, for the most part, the RAW methods are
applicable to wired links as well, e.g., when energy savings are desirable and applicable to wired links as well, e.g., when energy savings are desirable and
the available path diversity exceeds 1+1 linear redundancy. the available path diversity exceeds 1+1 linear redundancy.
</t> </t>
<t> <t indent="0" pn="section-5.3-3">
RAW adds sub-layer functions that operate in the DetNet Operational Plane, whi ch is part of the Network Plane. RAW adds sub-layer functions that operate in the DetNet Operational Plane, whi ch is part of the Network Plane.
The RAW orientation function may run only in the DetNet Edge Nodes (Ingress Ed The RAW orientation function may run only in the DetNet edge nodes (ingress ed
ge ge
Node or End System), or it also run in DetNet Relay Nodes node or End System), or it can also run in DetNet relay nodes
when the RAW operations are distributed along the recovery graph. when the RAW operations are distributed along the recovery graph.
The RAW Service sub-layer includes the PLR, which decides the DetNet Path for The RAW Service sub-layer includes the PLR, which decides the DetNet path for
the the
future packets of a flow along the DetNet Path, Maintenance End Points (MEPs) future packets of a flow along the DetNet path, Maintenance End Points (MEPs)
on edge nodes, and Maintenance Intermediate Points (MIPs) within. The MEPs on edge nodes, and Maintenance Intermediate Points (MIPs) within. The MEPs
trigger, and learn from, OAM observations, and feed the PLR for its trigger, and learn from, OAM observations and feed the PLR for its
next decision. next decision.
</t> </t>
<t> <t indent="0" pn="section-5.3-4">
As illustrated in <xref target='FigDN'/>, RAW extends the DetNet Stack (see As illustrated in <xref target="FigDN" format="default" sectionFormat="of" der
Figure 4 of <xref target="RFC8655"/> and <xref target='FigLayers'/>) with ivedContent="Figure 5"/>, RAW extends the DetNet Stack (see
Figure 4 of <xref target="RFC8655" format="default" sectionFormat="of" derived
Content="DetNet-ARCH"/> and <xref target="FigLayers" format="default" sectionFor
mat="of" derivedContent="Figure 3"/>) with
additional functionality at the DetNet Service sub-layer for the actuation of PREOF based on the PLR decision. additional functionality at the DetNet Service sub-layer for the actuation of PREOF based on the PLR decision.
DetNet operates at Layer-3, leveraging abstractions of the DetNet operates at Layer 3, leveraging abstractions of the
lower layers and APIs that control those abstractions. For instance, lower layers and APIs that control those abstractions. For instance,
DetNet already leverages lower layers for time-sensitive operations such as DetNet already leverages lower layers for time-sensitive operations such as
time synchronization and traffic shapers. As the performances of the time synchronization and traffic shapers. As the performances of the
radio layers are subject to rapid changes, RAW needs more dynamic gauges radio layers are subject to rapid changes, RAW needs more dynamic gauges
and knobs. To that effect, the LL API provides an and knobs. To that effect, the LL API provides an
abstraction to the DetNet layer that can be used to push reliability abstraction to the DetNet layer that can be used to push reliability
and timing hints like suggest X retries (min, max) within a time window, or and timing hints, like suggesting X retries (min, max) within a time window or
send unicast (one next hop) or multicast (for overhearing). sending unicast (one next hop) or multicast (for overhearing).
In the other direction up the stack, the RAW PLR needs hints about the radio c onditions such as L2 triggers (e.g., RSSI, LQI, or ETX) over all the wireless ho ps. In the other direction up the stack, the RAW PLR needs hints about the radio c onditions such as L2 triggers (e.g., RSSI, LQI, or ETX) over all the wireless ho ps.
</t> </t>
<t> <t indent="0" pn="section-5.3-5">
RAW uses various OAM functionalities at the different layers. For instance, RAW uses various OAM functionalities at the different layers. For instance,
the OAM function in the DetNet Service sub-layer may perform Active the OAM function in the DetNet Service sub-layer may perform Active
and/or Hybrid OAM to estimate the link and path availability, end-to-end and/or Hybrid OAM to estimate the link and path availability, either end to en
or limited to a Segment. The RAW d
functions may be present in the Service sub-layer in DetNet Edge and Relay Nod or limited to a segment. The RAW
es. functions may be present in the Service sub-layer in DetNet edge and relay nod
es.
</t> </t>
<figure anchor="FigDN" align="left" suppress-title="false" pn="figure-5"
<figure anchor="FigDN"> >
<name>RAW function placement (Centralized Routing Case)</name> <name slugifiedName="name-raw-function-placement-cent">RAW Function Pl
<artwork align="left" name="" type="" alt=""> acement (Centralized Routing Case)</name>
<artwork align="left" name="" type="" alt="" pn="section-5.3-6.1">
+-----------------+ +-------------------+ +-----------------+ +-------------------+
| Routing | | OAM Control | | Routing | | OAM Control |
+-----------------+ +-------------------+ +-----------------+ +-------------------+
Controller Plane Controller Plane
+-+-+-+-+-+-+-+-+ Southbound Interface -+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Southbound Interface -+-+-+-+-+-+-+-+-+-+-+-+
Network Plane Network Plane
| |
Operational Plane . Data Plane Operational Plane . Data Plane
| |
+-----------------+ . +-----------------+ .
| Orientation | | | Orientation | |
+-----------------+ . +-----------------+ .
| |
+-----------------+ +-------------------+ . +-----------------+ +-------------------+ .
| Point of | | OAM Maintenance | | | Point of Local | | OAM Maintenance | |
| local Repair | | End Point (MEP) | . | Repair (PLR) | | End Point (MEP) | .
+-----------------+ +-------------------+ | +-----------------+ +-------------------+ |
. .
| |
</artwork>
</artwork> </figure>
</figure> <t indent="0" pn="section-5.3-7">There are two main proposed models to d
<t> There are two main proposed models to deploy RAW and DetNet. In the first eploy RAW and DetNet: strict (<xref target="FigDN2" format="default" sectionForm
model (strict) (illustrated in <xref target="FigDN2"/>), RAW operates over a at="of" derivedContent="Figure 6"/>) and loose (<xref target="FigDN3" format="de
continuous DetNet Service end-to-end between the Ingress and the Egress Edge fault" sectionFormat="of" derivedContent="Figure 7"/>). In the
Nodes or End Systems. strict model, illustrated in <xref target="FigDN2" format="default" sectionFor
mat="of" derivedContent="Figure 6"/>, RAW operates over a
continuous DetNet service end to end between the ingress and the egress edge
nodes or End Systems.
</t> </t>
<t> <t indent="0" pn="section-5.3-8">
sIn the second model (loose), RAW may traverse a section of the network that In the loose model, illustrated in <xref target="FigDN3" format="default" sec
is not serviced by DetNet. RAW / OAM may observe the end-to-end traffic and make tionFormat="of" derivedContent="Figure 7"/>, RAW may traverse a section of the n
the best of the available resources, but it may not expect the DetNet guarantee etwork that
s over all paths. For instance, is not serviced by DetNet. RAW OAM may observe the end-to-end traffic and
the packets between two wireless entities may be relayed over a wired make the best of the available resources, but it may not expect the DetNet
infrastructure, in which case RAW observes and controls the transmission guarantees over all paths. For instance, the packets between two wireless
over the wireless first and last hops, as well as end-to-end metrics such as entities may be relayed over a wired infrastructure, in which case RAW
latency, jitter, and delivery ratio. This operation is loose since the observes and controls the transmission over the wireless first and last
structure and properties of the wired infrastructure are ignored, and may be hops, as well as end-to-end metrics such as latency, jitter, and delivery
either controlled by other means such as DetNet/TSN, or neglected in the ratio. This operation is loose since the structure and properties of the
face of the wireless hops. wired infrastructure are ignored and may be either controlled by other
means such as DetNet/TSN or neglected in the face of the wireless hops.
</t> </t>
<t> <t indent="0" pn="section-5.3-9">
A minimal Forwarding sub-layer service is provided at all DetNet Nodes A minimal forwarding sub-layer service is provided at all DetNet nodes
to ensure that the OAM information flows. DetNet Relay Nodes may or may not su to ensure that the OAM information flows. DetNet relay nodes may or may not su
pport pport
RAW services, whereas the DetNet Edge Nodes are required to support RAW in any RAW services, whereas the DetNet edge nodes are required to support RAW in any
case. case.
DetNet guarantees, such as bounded latency, are provided end-to-end. DetNet guarantees, such as bounded latency, are provided end to end.
RAW extends the DetNet Service sub-layer to optimize the use of resources. RAW extends the DetNet Service sub-layer to optimize the use of resources.
</t> </t>
<figure anchor="FigDN2" align="left" suppress-title="false" pn="figure-6
<figure anchor="FigDN2"> ">
<name>(Strict) RAW over DetNet</name> <name slugifiedName="name-raw-over-detnet-strict-mode">RAW over DetNet
<artwork align="left" name="" type="" alt=""> (Strict Model)</name>
<artwork align="left" name="" type="" alt="" pn="section-5.3-10.1">
--------------------Flow Direction----------------------------------&gt;
+---------+ +---------+
| RAW | | RAW |
| Control | | Control |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| RAW + | | RAW + | | RAW + | | RAW + | | RAW + | | RAW + |
| DetNet | | DetNet | | DetNet | | DetNet | | DetNet | | DetNet |
| Service | | Service | | Service | | Service | | Service | | Service |
+---------+---------------------------+---------+--------+---------+ +---------+---------------------------+---------+--------+---------+
| DetNet | | DetNet |
| Forwarding | | Forwarding |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Ingress Transit Relay Egress Ingress Transit Relay Egress
Edge ... Nodes ... Nodes ... Edge Edge ... Nodes ... Nodes ... Edge
Node Node Node Node
&lt;------------------End-to-End DetNet Service-----------------------> &lt;------------------End-to-End DetNet Service-----------------------&gt;
</artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-5.3-11">In the loose model (illustrated in <xr
<t> In the second model (loose), illustrated in <xref target="FigDN3"/>, RAW ef target="FigDN3" format="default" sectionFormat="of" derivedContent="Figure 7"
operates over a partial DetNet Service where typically only the Ingress and />), RAW
the Egress End Systems support RAW. The DetNet Domain may extend beyond the operates over a partial DetNet service where typically only the ingress and
Ingress Node, or there may be a DetNet domain starting at an Ingress the egress End Systems support RAW. The DetNet domain may extend beyond the
Edge Node at the first hop after the End System. ingress node, or there may be a DetNet domain starting at an ingress
edge node at the first hop after the End System.
</t> </t>
<t> <t indent="0" pn="section-5.3-12">
In the loose model, RAW cannot observe the hops in the network, and the path In the loose model, RAW cannot observe the hops in the network, and the path
beyond the first hop is opaque; RAW can still observe the end-to-end beyond the first hop is opaque; RAW can still observe the end-to-end
behavior and use Layer-3 measurements to decide whether to replicate a packet behavior and use Layer 3 measurements to decide whether to replicate a packet
and select the first-hop interface(s). and select the first-hop interface(s).
</t> </t>
<figure anchor="FigDN3"> <figure anchor="FigDN3" align="left" suppress-title="false" pn="figure-7
<name>Loose RAW</name> ">
<artwork align="left" name="" type="" alt=""> <name slugifiedName="name-raw-over-detnet-loose-model">RAW over DetNet
(Loose Model)</name>
<artwork align="left" name="" type="" alt="" pn="section-5.3-13.1">
--------------------Flow Direction----------------------------------&gt;
+---------+ +---------+
| RAW | | RAW |
| Control | | Control |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| RAW + | | DetNet | | RAW + | | RAW + | | DetNet | | RAW + |
| DetNet | | Only | | DetNet | | DetNet | | Only | | DetNet |
| Service | | Service | | Service | | Service | | Service | | Service |
+---------+----------------------+---+ +---+---------+ +---------+----------------------+---+ +---+---------+
| DetNet |_______________| DetNet | | DetNet |_______________| DetNet |
| Forwarding _______________ Forwarding | | Forwarding _______________ Forwarding |
+------------------------------------+ +-------------+ +------------------------------------+ +-------------+
Ingress Transit Relay Tunnel Egress Ingress Transit Relay Tunnel Egress
End ... Nodes ... Nodes ... ... End End ... Nodes ... Nodes ... ... End
System System System System
&lt;---------------Partitioned DetNet Service-------------------------> &lt;---------------Partitioned DetNet Service-------------------------&gt;
</artwork> </artwork>
</figure> </figure>
</section>
</section> <!-- RAW and DetNet --> </section>
<section anchor="control" numbered="true" toc="include" removeInRFC="false"
<!-- 1111111111111 --> pn="section-6">
<name slugifiedName="name-the-raw-control-loop">The RAW Control Loop</name
</section> <!-- The RAW Conceptual Model --> >
<section anchor="control" numbered="true" toc="default"> <t indent="0" pn="section-6-1">
<name>The RAW Control Loop</name> The RAW architecture is based on an abstract OODA
loop that controls the operation of a recovery graph. The generic
<t> concept involves the following:
The RAW Architecture is based on an abstract OODA Loop that controls the oper
ation of a Recovery Graph.
The generic concept involves:
</t> </t>
<ol> <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-6-2"
<li> Operational Plane measurement protocols for OAM to observe (like the >
first O in OODA) some or all hops along a recovery graph as well as <li pn="section-6-2.1" derivedCounter="1.">Operational Plane measurement p
the end-to-end packet delivery. rotocols allow OAM to observe (like
the first "O" in "OODA") some or all hops along a recovery graph as
well as the end-to-end packet delivery.
</li> </li>
<li> <li pn="section-6-2.2" derivedCounter="2.">
The DetNet Controller Plane establish primary and protection paths The DetNet Controller Plane establishes primary and protection paths for
for use by the RAW Network Plane. use by the RAW Network Plane. The orientation function reports data and
The orientation function reports information such as link statistics to be used by the routing function
data and information such as link statistics to be used to compute, install, and maintain the recovery graphs. The routing
by the routing function to compute, install, and maintain the function may also generate intelligence such as a trained model for link
recovery graphs. The routing function may also generate intelligence such quality prediction, which in turn can be used by the orientation
as a trained model function (like the second "O" in "OODA") to influence the path selection
for link quality prediction, which in turn can be used by the orientation by the PLR within the RAW OODA loop.
function (like the second O in OODA) to influence the Path selection by the PLR
within the RAW OODA loop.
</li> </li>
<li> A PLR operates at the DetNet Service <li pn="section-6-2.3" derivedCounter="3.">A PLR operates at the DetNet
sub-layer and hosts the decision function (like the D in OODA) of which Det Service sub-layer and hosts the
Net Paths to use decision function (like the "D" in "OODA"). The decision function determi
for the future packets that are routed within the recovery graph. nes
which DetNet paths will be
used for future packets that are routed within the recovery
graph.
</li> </li>
<li> Service protection actions that are actuated or triggered over the LL <li pn="section-6-2.4" derivedCounter="4.">Service protection actions ar
API by the PLR to increase the reliability of the end-to-end transmissions. e actuated or triggered over the LL API
The RAW architecture also covers in-situ signaling that is embedded within by the PLR to increase the reliability of the end-to-end
live user traffic <xref target="RFC9378"/>, e.g., via OAM, when the decision is transmissions. The RAW architecture also covers in-situ signaling that
acted (like the A in OODA) upon by a node that is downstream in the recover is embedded within live user traffic <xref target="RFC9378" format="defaul
y graph from the PLR. t" sectionFormat="of" derivedContent="RFC9378"/> (e.g., via
OAM) when the decision is acted (like the "A" in "OODA") upon by a node
that is downstream in the recovery graph from the PLR.
</li> </li>
</ol> </ol>
<t> The overall OODA Loop optimizes the use of redundancy to achieve the <t indent="0" pn="section-6-3">The overall OODA loop optimizes the use of redundancy to achieve the
required reliability and availability SLO(s) while required reliability and availability SLO(s) while
minimizing the use of constrained resources such as spectrum and battery. minimizing the use of constrained resources such as spectrum and battery.
</t> </t>
<section anchor="timescale" numbered="true" toc="include" removeInRFC="fal
<section anchor="timescale" numbered="true" toc="default"> se" pn="section-6.1">
<name>Routing Time-Scale vs. Forwarding Time-Scale</name> <name slugifiedName="name-routing-timescale-versus-fo">Routing Timescale
<t> Versus Forwarding Timescale</name>
With DetNet, the Controller Plane Function handles the routing <t indent="0" pn="section-6.1-1">
computation and maintenance. With RAW, the routing operation is With DetNet, the Controller Plane Function (CPF) handles the routing computat
segregated from the RAW Control Loop, so it may reside in the Controller Plan ion
e and maintenance. With RAW, the routing operation is segregated from the RAW
whereas the control loop itself happens in the Network Plane. To achieve RAW control loop, so it may reside in the Controller Plane, whereas the control
capabilities, the routing operation is extended to generate the information requ loop itself happens in the Network Plane. To achieve RAW capabilities, the
ired by the orientation function in the loop. routing operation is extended to generate the information required by the
The routing function may, e.g., propose DetNet Paths to be used as a reflex orientation function in the loop. For example, the routing function may prop
action in response to network events, or provide an aggregated history that ose
the orientation function can use to make a decision. DetNet paths to be used as a reflex action in response to network events
</t> or provide an aggregated history that the orientation function can use to
<t> make a decision.
In a wireless mesh, the path to a routing function located in the controller </t>
plane can be expensive and <t indent="0" pn="section-6.1-2">
In a wireless mesh, the path to a routing function located in the Controller
Plane can be expensive and
slow, possibly going across the whole mesh and back. slow, possibly going across the whole mesh and back.
Reaching to the Controller Plane can also be slow in regards to the speed Reaching the Controller Plane can also be slow in regard to the speed
of events that affect the forwarding operation in the Network Plane at the ra dio layer. of events that affect the forwarding operation in the Network Plane at the ra dio layer.
Note that a distributed routing protocol may also take time and Note that a distributed routing protocol may also take time and
consume excessive wireless resources to reconverge to a new optimized state. consume excessive wireless resources to reconverge to a new optimized state.
</t><t> </t>
As a result, the DetNet routing function is not expected to be aware of and t <t indent="0" pn="section-6.1-3">
o react to As a result, the DetNet routing function is not expected to be aware of and r
eact to
very transient changes. The abstraction of a link at the routing level is very transient changes. The abstraction of a link at the routing level is
expected to use statistical metrics that aggregate the behavior of a link expected to use statistical metrics that aggregate the behavior of a link
over long periods of time, and represent its properties as shades of gray as over long periods of time and represent its properties as shades of gray as
opposed to numerical values such as a link quality indicator, or a Boolean opposed to numerical values such as a link quality indicator or a Boolean
value for either up or down. value for either up or down.
</t><t> </t>
<t indent="0" pn="section-6.1-4">
The interaction between the network nodes and the routing function is handled The interaction between the network nodes and the routing function is
by the orientation function, which handled by the orientation function, which reports to the routing function
builds reports to the routing function and and sends control information in a digested form back to the RAW node to be
sends control information in a digested form back to the RAW node, to be used used inside a forwarding control loop for traffic steering.
inside a forwarding control loop for
traffic steering.
</t><t> </t>
<xref target="Figcontrol"/> illustrates a Network Plane recovery graph <t indent="0" pn="section-6.1-5">
<xref target="Figcontrol" format="default" sectionFormat="of" derivedContent=
"Figure 8"/> illustrates a Network Plane recovery graph
with links P-Q and N-E flapping, possibly in a transient fashion with links P-Q and N-E flapping, possibly in a transient fashion
due to a short-term interferences, and possibly for a longer time, e.g., due to short-term interferences and possibly for a longer time (e.g.,
due to obstacles between the sender and the receiver or hardware failures. due to obstacles between the sender and the receiver or hardware failures).
In order to maintain a received redundancy around a value of, say, 2, In order to maintain a received redundancy around a value of 2 (for instance)
RAW may leverage a higher ARQ on these hops if the overall latency permits th ,
e extra delay, RAW may leverage a higher ARQ on these hops if the overall latency permits th
e extra delay
or enable alternate paths between ingress I and egress E. or enable alternate paths between ingress I and egress E.
For instance, RAW may enable protection path I ==> F ==> N ==> Q ==> M ==> R ==&gt; E For instance, RAW may enable protection path I ==> F ==&gt; N ==&gt; Q ==& gt; M ==&gt; R ==&gt; E
that routes around both issues and provides some degree of spatial diversity that routes around both issues and provides some degree of spatial diversity
with protection path I ==> A ==> B ==> C ==> D ==> E. with protection path I ==&gt; A ==&gt; B ==&gt; C ==&gt; D ==&gt; E.
</t>
</t> <figure anchor="Figcontrol" align="left" suppress-title="false" pn="figu
re-8">
<figure anchor="Figcontrol"> <name slugifiedName="name-timescales">Timescales</name>
<name>Time-Scales</name> <artwork align="center" name="" type="" alt="" pn="section-6.1-6.1">
<artwork align="center" name="" type="" alt="">
<![CDATA[
+----------------+ +----------------+
| DetNet | | DetNet |
| Routing | | Routing |
+----------------+ +----------------+
^ ^
| |
Slow Slow
| Controller Plane | Controller Plane
_-._-._-._-._-._-. | ._-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-. | ._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-. | _-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-._-. | _-._-._-._-._-._-._-._-._-._-._-._-
skipping to change at line 1562 skipping to change at line 1740
| |
__...--- | ----.._. __...--- | ----.._.
.( | )-._ .( | )-._
( v ). ( v ).
( A--------B---C----D ) ( A--------B---C----D )
_ - / \ / \ --._ _ - / \ / \ --._
( I---F--------N--***-- E - ( I---F--------N--***-- E -
-_ \ / / ) -_ \ / / )
( P--***---Q----M---R . ( P--***---Q----M---R .
_ )- ._ _ )- ._
- <------ Fast -------&gt; ) - <------ Fast -------&gt; )
( -._ .- ( -._ .-
(_.___.._____________.____.._ __-____) (_.___.._____________.____.._ __-____)
*** = flapping at this time *** = flapping at this time
]]> </artwork>
</artwork> </figure>
</figure> <t indent="0" pn="section-6.1-7">
<t>
In the case of wireless, the changes that affect the forwarding decision can In the case of wireless, the changes that affect the forwarding decision can
happen frequently and often for short durations, e.g., a mobile object moves happen frequently and often for short durations. An example of this is a mobi
between a transmitter and a receiver, and cancels the line of sight le object that moves
transmission for a few seconds, or, a radar measures the depth of a pool usin between a transmitter and a receiver and cancels the line-of-sight
g the ISM band, and transmission for a few seconds. Another example is radar that measures the de
pth of a pool using the ISM band and
interferes on a particular channel for a split second. interferes on a particular channel for a split second.
</t> </t>
<t> <t indent="0" pn="section-6.1-8">
There is thus a desire to separate the long-term computation of the route and Thus, there is a desire to separate the long-term computation of the route an
d
the short-term forwarding decision. In that model, the routing operation the short-term forwarding decision. In that model, the routing operation
computes a recovery graph that enables multiple Unequal Cost Multi-Path computes a recovery graph that enables multiple Unequal-Cost Multipath
(UCMP) forwarding solutions along so-called protection paths, and leaves (UCMP) forwarding solutions along so-called protection paths and leaves
it to the Network Plane to make it to the Network Plane to make
the short-term decision of which of these possibilities should be used for wh the short-term decision of which of these possibilities should be used for wh
ich upcoming packets / flows. ich upcoming packets and flows.
</t> </t>
<t> <t indent="0" pn="section-6.1-9">
In the context of Traffic Engineering (TE), an alternate path can be used In the context of Traffic Engineering (TE), an alternate path can be used
upon the detection of a failure in the main path, e.g., using OAM in upon the detection of a failure in the main path, e.g., using OAM in
Multiprotocol Label Switching - Transport Profile (MPLS-TP) or BFD Multiprotocol Label Switching - Transport Profile (MPLS-TP) or BFD
over a collection of Software-Defined Wide Area Network (SD-WAN) tunnels. over a collection of Software-Defined Wide Area Network (SD-WAN) tunnels.
</t> </t>
<t> <t indent="0" pn="section-6.1-10">
RAW formalizes a forwarding time-scale that may be order(s) of magnitude shor RAW formalizes a forwarding timescale that may be order(s) of magnitude short
ter er
than the Controller Plane routing time-scale, and separates the protocols than the Controller Plane routing timescale and separates the protocols
and metrics that are used at both scales. and metrics that are used at both scales.
Routing can operate on long-term statistics such as delivery Routing can operate on long-term statistics such as delivery
ratio over minutes to hours, but as a first approximation can ignore the caus ratio over minutes to hours, but as a first approximation, it can ignore the
e of transient losses. cause of transient losses.
On the other hand, the RAW forwarding decision is made at the scale of a burs On the other hand, the RAW forwarding decision is made at the scale of a burs
t of packets, t of packets
and uses information that must be pertinent at the present time for the curre nt transmission(s). and uses information that must be pertinent at the present time for the curre nt transmission(s).
</t> </t>
</section>
</section > <section anchor="ooda" numbered="true" toc="include" removeInRFC="false" p
<!--Routing time-scale vs. Forwarding time-scale--> n="section-6.2">
<name slugifiedName="name-ooda-loop">OODA Loop</name>
<section anchor="ooda" numbered="true" toc="default"> <t indent="0" pn="section-6.2-1">
<name>OODA Loop</name> The RAW architecture applies the generic OODA model to continuously optimize
<t> the
The RAW Architecture applies the generic OODA model to continuously optimize
the
spectrum and energy used to forward packets within a recovery graph, instanti ating the spectrum and energy used to forward packets within a recovery graph, instanti ating the
OODA steps as follows: OODA steps as follows:
</t> </t>
<dl> <dl indent="3" newline="false" spacing="normal" pn="section-6.2-2">
<dt>Observe:</dt><dd> Network Plane measurements, including protocols for <dt pn="section-6.2-2.1">Observe:</dt>
OAM, to Observe the local state of the links and some or all hops along a <dd pn="section-6.2-2.2"> Network Plane measurements, including protoc
recovery graph as well as ols for
the end-to-end packet delivery (see more in <xref target = "aom"/>). OAM, observe the local state of the links and some or all hops along a rec
overy graph as well as
the end-to-end packet delivery (see more in <xref target="aom" format="def
ault" sectionFormat="of" derivedContent="Section 6.3"/>).
Information can also be provided by lower-layer Information can also be provided by lower-layer
interfaces such as DLEP; interfaces such as DLEP.
</dd> </dd>
<dt>Orient:</dt><dd> <dt pn="section-6.2-2.3">Orient:</dt>
The orientation function, which reports data and information such as the l <dd pn="section-6.2-2.4">
ink The orientation function reports data and information such as the link
statistics, and leverages offline-computed wisdom and knowledge to Orient statistics and leverages offline-computed wisdom and knowledge to orient
the PLR for its forwarding decision (see more in <xref target = "pce" />); the PLR for its forwarding decision (see more in <xref target="pce" format
="default" sectionFormat="of" derivedContent="Section 6.4"/>).
</dd> </dd>
<dt>Decide:</dt><dd> A local PLR that decides which DetNet Path to use <dt pn="section-6.2-2.5">Decide:</dt>
for the future packet(s) that are routed along the recovery graph <dd pn="section-6.2-2.6">A local PLR decides which DetNet path to use
(see more in <xref target = "PLRpce" />); for future packet(s) that are routed along the recovery graph
(see more in <xref target="PLRpce" format="default" sectionFormat="of" de
rivedContent="Section 6.5"/>).
</dd> </dd>
<dt>Act:</dt><dd> PREOF Data Plane <dt pn="section-6.2-2.7">Act:</dt>
actions are controlled by the PLR over the LL API to increase the <dd pn="section-6.2-2.8">PREOF Data Plane actions are controlled by th
reliability of the end-to-end transmission. The RAW architecture also e PLR over
covers in-situ signaling when the decision is Acted by a node that is the LL API to increase the reliability of the end-to-end
down the recovery graph from the PLR (see more in transmission. The RAW architecture also covers in-situ signaling when
<xref target = "reliability" />). the decision is acted by a node that is down the recovery graph from the
PLR (see more in <xref target="reliability" format="default" sectionFormat
="of" derivedContent="Section 6.6"/>).
</dd> </dd>
</dl> </dl>
<figure anchor="oodaloop"> <figure anchor="oodaloop" align="left" suppress-title="false" pn="figure
<name>The RAW OODA Loop</name> -9">
<artwork align="center" name="" type="" alt=""> <name slugifiedName="name-the-raw-ooda-loop">The RAW OODA Loop</name>
<![CDATA[ <artwork align="center" name="" type="" alt="" pn="section-6.2-3.1">
+-------&gt; Orientation ---------+
+-------> Orientation ---------+
| reflex actions | | reflex actions |
| pre-trained model | | pre-trained model |
| | | |
...................................... ......................................
| | | |
| Service sub-layer | | Service sub-layer |
| v | v
Observe (OAM) Decide (PLR) Observe (OAM) Decide (PLR)
^ | ^ |
| | | |
| | | |
+------- Act (LL API) <--------+ +------- Act (LL API) &lt;--------+
]]></artwork> </artwork>
</figure> </figure>
<t> The overall OODA Loop optimizes the use of redundancy to achieve the <t indent="0" pn="section-6.2-4"> The overall OODA loop optimizes the us
e of redundancy to achieve the
required reliability and availability Service Level Agreement (SLA) while required reliability and availability Service Level Agreement (SLA) while
minimizing the use of constrained resources such as spectrum and battery. minimizing the use of constrained resources such as spectrum and battery.
</t> </t>
</section>
</section > <!-- A OODA Loop --> <section anchor="aom" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="aom" numbered="true" toc="default"> ="section-6.3">
<name>Observe: The RAW OAM </name><t> <name slugifiedName="name-observe-raw-oam">Observe: RAW OAM </name>
RAW In-situ OAM operation in the Network Plane may observe either a full <t indent="0" pn="section-6.3-1">
recovery graph or the DetNet Path that is being used at this time. As packet The RAW in-situ OAM operation in the Network Plane may observe either a full
s may be load recovery graph or the DetNet path that is being used at this time. As packet
balanced, replicated, eliminated, and / or fragmented for Network Coding s may be load
FEC, the RAW In-situ operation needs to be balanced, replicated, eliminated, and/or fragmented for Network Coding
FEC, the RAW in-situ operation needs to be
able to signal which operation occurred to an individual packet. able to signal which operation occurred to an individual packet.
</t> </t>
<t> <t indent="0" pn="section-6.3-2">
Active RAW OAM may Active RAW OAM may
be needed to observe the unused segments and evaluate the desirability of be needed to observe the unused segments and evaluate the desirability of
a rerouting decision. a rerouting decision.
</t> </t>
<t> <t indent="0" pn="section-6.3-3">
Finally, the RAW Service sub-layer Assurance may observe the individual PREO Finally, the RAW Service sub-layer Service Assurance may observe the individ
F ual PREOF
operation of a DetNet Relay Node to ensure that it is conforming; this might operation of a DetNet relay node to ensure that it is conforming; this might
require injecting an OAM packet at an upstream point inside the recovery gra ph and require injecting an OAM packet at an upstream point inside the recovery gra ph and
extracting that packet at another point downstream before it reaches the extracting that packet at another point downstream before it reaches the
egress. egress.
</t><t> </t>
<t indent="0" pn="section-6.3-4">
This observation feeds the RAW This observation feeds the RAW
PLR that makes the decision on which path is used at which RAW PLR that makes the decision on which path is used at which RAW
Node, for one packet or a small continuous series of packets. node, for one packet or a small continuous series of packets.
</t> </t>
<t> <t indent="0" pn="section-6.3-5">
In the case of End-to-End Protection in a Wireless Mesh, the recovery In the case of end-to-end protection in a wireless mesh, the recovery
graph is strict and congruent with the path so all links are observed. graph is strict and congruent with the path so all links are observed.
</t> </t>
<t> <t indent="0" pn="section-6.3-6">
Conversely, in the case of Radio Access Protection, illustrated in Conversely, in the case of Radio Access Protection, illustrated in
<xref target="Figranp2"/>, the recovery graph is Loose and only the first <xref target="Figranp2" format="default" sectionFormat="of" derivedContent="F igure 10"/>, the recovery graph is loose and only the first
hop is observed; the rest of the path is abstracted and considered hop is observed; the rest of the path is abstracted and considered
infinitely reliable. The loss of a packet is attributed to the first-hop infinitely reliable. The loss of a packet is attributed to the first-hop
Radio Access Network (RAN), even if a particular loss effectively happens Radio Access Network (RAN), even if a particular loss effectively happens
farther down the path. In that case, RAW enables technology diversity farther down the path. In that case, RAW enables technology diversity
(e.g., Wi-Fi and 5G), which in turn improves the diversity in spectrum usage. (e.g., Wi-Fi and 5G), which in turn improves the diversity in spectrum usage.
</t> </t>
<figure anchor="Figranp2"> <figure anchor="Figranp2" align="left" suppress-title="false" pn="figure
<name>Observed Links in Radio Access Protection</name> -10">
<artwork align="center" name="" type="" alt=""> <name slugifiedName="name-observed-links-in-radio-acc">Observed Links
<![CDATA[ in Radio Access Protection</name>
<artwork align="center" name="" type="" alt="" pn="section-6.3-7.1">
Opaque to OAM Opaque to OAM
<----------------------------> &lt;----------------------------&gt;
.- .. - .. .- .. - ..
RAN 1 --------( ).__ RAN 1 --------( ).__
+-------+ / ( ). +------+ +-------+ / ( ). +------+
|Ingress|- __________Tunnel_______________|Egress| |Ingress|- __________Tunnel_______________|Egress|
| End |------ RAN 2 --_______________________________ End | | End |------ RAN 2 --_______________________________ End |
|System |- ( ) |System| |System |- ( ) |System|
+-------+ \ ( ). +------+ +-------+ \ ( ). +------+
RAN n ----( ) RAN n ----( )
(_______...___.__...____....__..) (_______...___.__...____....__..)
<-------L2------&gt; <-------L2------&gt;
Observed by OAM Observed by OAM
<----------------------L3-----------------------> &lt;----------------------L3-----------------------&gt;
]]></artwork>
</figure>
<t>
The Links that are not observed by OAM are opaque to it, meaning that the
OAM information is carried across and possibly echoed as data, but there is
no information captured in intermediate nodes. In the example above, the
Tunnel underlay is opaque and not controlled by RAW; still the RAW OAM measu
res the
end-to-end latency and delivery ratio for packets sent via RAN 1, RAN 2, and
RAN 3, and determines whether a packet should be sent over either or a
collection of those access links.
</t>
</section>
<!-- Observe: The RAW OAM -->
<section anchor="pce" numbered="true" toc="default">
<name>Orient: The RAW-extended DetNet Operational Plane</name>
<t> </artwork>
RAW separates the long time-scale at which a recovery graph is computed and i </figure>
nstalled, <t indent="0" pn="section-6.3-8">
from the short time-scale at which the forwarding decision is taken for one The links that are not observed by OAM are opaque to it, meaning that the
or for a few packets (see <xref target="timescale"/>) that experience the OAM information is carried across and possibly echoed as data, but there
is no information captured in intermediate nodes. In the example above,
the tunnel underlay is opaque and not controlled by RAW; still, RAW OAM
measures the end-to-end latency and delivery ratio for packets sent via
RAN 1, RAN 2, and RAN 3, and determines whether a packet should be sent
over either access link or a collection of those access links.
</t>
</section>
<section anchor="pce" numbered="true" toc="include" removeInRFC="false" pn
="section-6.4">
<name slugifiedName="name-orient-the-raw-extended-det">Orient: The RAW-E
xtended DetNet Operational Plane</name>
<t indent="0" pn="section-6.4-1">
RAW separates the long timescale at which a recovery graph is computed and in
stalled
from the short timescale at which the forwarding decision is taken for one
or a few packets (see <xref target="timescale" format="default" sectionFormat
="of" derivedContent="Section 6.1"/>) that experience the
same path until the network conditions evolve and another path is selected same path until the network conditions evolve and another path is selected
within the same recovery graph. within the same recovery graph.
</t> </t>
<t> <t indent="0" pn="section-6.4-2">
The recovery graph computation is out of scope, but RAW expects that the CPF The recovery graph computation is out of scope, but RAW expects that the CPF
that installs the recovery graph also provides related knowledge that installs the recovery graph also provides related knowledge
in the form of metadata about the links, segments, and possible DetNet Paths. in the form of metadata about the links, segments, and possible DetNet paths.
That metadata can be a pre-digested statistical model, and may include That metadata can be a pre-digested statistical model and may include
prediction of future flaps and packet loss, as well as recommended actions prediction of future flaps and packet loss, as well as recommended actions
when that happens. when that happens.
</t> </t>
<t> <t indent="0" pn="section-6.4-3">
The metadata may include: The metadata may include:
</t> </t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6
<li> .4-4">
A set of Pre-Determined DetNet Paths that are prepared to match <li pn="section-6.4-4.1">
expected link-degradation profiles, so the DetNet Relay Nodes can take reflex A set of pre-determined DetNet paths that are prepared to match
rerouting actions when expected link-degradation profiles, so the DetNet relay nodes can take reflex
facing a degradation that matches one such profile; rerouting actions when
facing a degradation that matches one such profile; and
</li> </li>
<li> <li pn="section-6.4-4.2">
Link-Quality Statistics history and pre-trained models, e.g., to predict the Link-quality statistics history and pre-trained models (e.g., to predict the
short-term variation of quality of the links in a recovery graph. short-term variation of quality of the links in a recovery graph).
</li> </li>
</ul> </ul>
<t> <t indent="0" pn="section-6.4-5">
The recovery graph is installed with measurable objectives that are computed The recovery graph is installed with measurable objectives that are computed
by the CPF to achieve the RAW SLA. The objectives can be expressed as any of the by the CPF to achieve the RAW SLA. The objectives can be expressed as any of the
maximum number of packets lost in a row, bounded latency, maximal jitter, maximum number of packets lost in a row, bounded latency, maximal jitter,
maximum number of interleaved out-of-order packets, maximum number of interleaved out-of-order packets,
average number of copies received at the elimination point, and maximal average number of copies received at the elimination point, and maximal
delay between the first and the last received copy of the same packet. delay between the first and the last received copy of the same packet.
</t> </t>
</section> </section>
<!-- Orient: The Path Computation Engine --> <section anchor="PLRpce" numbered="true" toc="include" removeInRFC="false"
pn="section-6.5">
<section anchor="PLRpce" numbered="true" toc="default"> <name slugifiedName="name-decide-the-point-of-local-r">Decide: The Point
<name>Decide: The Point of Local Repair</name> of Local Repair</name>
<t> <t indent="0" pn="section-6.5-1">
The RAW OODA Loop operates at the path selection time-scale to provide The RAW OODA loop operates at the path selection timescale to provide
agility vs. the brute-force approach of flooding the whole recovery graph. agility versus the brute-force approach of flooding the whole recovery
The OODA Loop controls, within the redundant solutions that are proposed graph. Within the redundant solutions that are proposed by the routing
by the routing function, which is used for each packet to provide a Reliable function, the OODA loop controls what is used for each packet and provides
and a reliable and available service while minimizing the waste of constrained
Available service while minimizing the waste of constrained resources. resources. </t>
</t><t> <t indent="0" pn="section-6.5-2"> To that effect, RAW defines the Point
To that effect, RAW defines the Point of Local Repair (PLR), which performs of Local Repair
rapid local adjustments of the forwarding tables within the path diversity th (PLR), which performs rapid local adjustments of the forwarding tables
at is within the path diversity that is available in that in the recovery
available in that in the recovery graph. The PLR enables exploitation of graph. The PLR enables exploitation of the richer forwarding capabilities
the richer forwarding capabilities at a faster time-scale over a portion of at a faster timescale over a portion of the recovery graph, in either a
the recovery graph, in either a loose or a strict fashion. loose or a strict fashion.
</t> </t>
<t> <t indent="0" pn="section-6.5-3">
The PLR operates on metrics that evolve faster, but that need to be The PLR operates on metrics that evolve quickly and need to be
advertised at a fast rate but only locally, within the recovery graph, and r advertised at a fast rate (but only locally, within the recovery graph), and
eacts on the PLR reacts to
the metric updates by changing the DetNet path in use for the affected the metric updates by changing the DetNet path in use for the affected
flows. flows.
</t> </t>
<t> <t indent="0" pn="section-6.5-4">
The rapid changes in the forwarding decisions are made and contained within The rapid changes in the forwarding decisions are made and contained within
the scope of a recovery graph and the actions of the PLR are not signaled ou tside the scope of a recovery graph, and the actions of the PLR are not signaled o utside
the recovery graph. This is as opposed to the routing function that must obs erve the recovery graph. This is as opposed to the routing function that must obs erve
the whole network and optimize all the recovery graphs globally, which can o nly be the whole network and optimize all the recovery graphs globally, which can o nly be
done at a slow pace and using long-term statistical metrics, as presented in done at a slow pace and with long-term statistical metrics, as presented in
<xref target="PCEPLRtable"/>. <xref target="PCEPLRtable" format="default" sectionFormat="of" derivedConten
</t> t="Table 1"/>.
</t>
<table anchor="PCEPLRtable"><name>Centralized Decision vs. PLR</name> <table anchor="PCEPLRtable" align="center" pn="table-1">
<thead> <name slugifiedName="name-centralized-decision-versus">Centralized Dec
<tr> ision Versus PLR</name>
<th> </th> <thead>
<th align='center'> Controller Plane </th> <tr>
<th align='center'> PLR </th> <th align="left" colspan="1" rowspan="1"/>
</tr> <th align="left" colspan="1" rowspan="1">Controller Plane</th>
<th align="left" colspan="1" rowspan="1">PLR</th>
</thead><tbody> </tr>
</thead>
<tr><td>Communication <tbody>
</td> <tr>
<td align='center'>Slow, distributed</td> <th align="left" colspan="1" rowspan="1">Communication</th>
<td align='center'>Fast, local</td> <td align="left" colspan="1" rowspan="1">Slow, distributed</td>
</tr> <td align="left" colspan="1" rowspan="1">Fast, local</td>
</tr>
<tr><td>Time-Scale (order)</td> <tr>
<td align='center'>Path computation + round trip, milliseconds to s <th align="left" colspan="1" rowspan="1">Timescale (order)</th>
econds</td> <td align="left" colspan="1" rowspan="1">Path computation + round
<td align='center'>Lookup + protection switch, micro to millisecond trip, milliseconds to seconds</td>
s</td> <td align="left" colspan="1" rowspan="1">Lookup + protection switc
</tr> h, micro to milliseconds</td>
</tr>
<tr><td>Network Size</td> <tr>
<td align='center'>Large, many recovery graphs to optimize globally <th align="left" colspan="1" rowspan="1">Network Size</th>
</td> <td align="left" colspan="1" rowspan="1">Large, many recovery grap
<td align='center'>Small, limited set of protection paths</td> hs to optimize globally</td>
</tr> <td align="left" colspan="1" rowspan="1">Small, limited set of pro
tection paths</td>
<tr><td>Considered Metrics</td> </tr>
<td align='center'>Averaged, statistical, shade of grey</td> <tr>
<td align='center'>Instantaneous values / boolean condition</td> <th align="left" colspan="1" rowspan="1">Considered Metrics</th>
</tr> <td align="left" colspan="1" rowspan="1">Averaged, statistical, sh
ade of grey</td>
</tbody> <td align="left" colspan="1" rowspan="1">Instantaneous values / bo
</table> olean condition</td>
<t> </tr>
The PLR sits in the DetNet Forwarding sub-layer of Edge and Relay Nodes. </tbody>
</table>
<t indent="0" pn="section-6.5-6">
The PLR sits in the DetNet forwarding sub-layer of edge and relay nodes.
The PLR operates on the packet flow, learning the recovery graph and The PLR operates on the packet flow, learning the recovery graph and
path-selection information from the packet, possibly making a local decision and path-selection information from the packet and possibly making a local decis ion and
retagging the packet to indicate so. On the other hand, the PLR interacts retagging the packet to indicate so. On the other hand, the PLR interacts
with the lower layers (through triggers and DLEP) and with its peers with the lower layers (through triggers and DLEP) and with its peers
(through OAM) to obtain up-to-date information about its links and (through OAM) to obtain up-to-date information about its links and
the quality of the overall recovery graph, respectively, as illustrated in the quality of the overall recovery graph, respectively, as illustrated in
<xref target="Figlearn"/>. <xref target="Figlearn" format="default" sectionFormat="of" derivedContent="
</t> Figure 11"/>.
</t>
<figure anchor="Figlearn"> <figure anchor="Figlearn" align="left" suppress-title="false" pn="figure
<name>PLR Conceptual Interfaces</name> -11">
<artwork align="center" name="" type="" alt=""><![CDATA[ <name slugifiedName="name-plr-conceptual-interfaces">PLR Conceptual In
terfaces</name>
<artwork align="center" name="" type="" alt="" pn="section-6.5-7.1">
| |
packet | going Packet | going
down the | stack down the | stack
+==========v==========+=====================+===================+ +==========v==========+=====================+===================+
|(In-situ OAM + iCTRL)| (L2 Triggers, DLEP) | (Hybrid OAM) | |(In-situ OAM + iCTRL)| (L2 triggers, DLEP) | (Hybrid OAM) |
+==========v==========+=====================+===================+ +==========v==========+=====================+===================+
| Learn from | | Learn from | | Learn from | | Learn from |
| packet tagging > Maintain &lt; end-to-end | | packet tagging > Maintain &lt; end-to-end |
+----------v----------+ Forwarding | OAM packets | +----------v----------+ Forwarding | OAM packets |
| Forwarding decision < State +---------^---------| | Forwarding decision &lt; State +---------^---------|
+----------v----------+ | Enrich or | +----------v----------+ | Enrich or |
+ Retag Packet | Learn abstracted > Regenerate | + Retag packet | Learn abstracted &gt; regenerate |
| and Forward | metrics about Links | OAM packets | | and forward | metrics about links | OAM packets |
+..........v..........+..........^..........+........^.v........+ +..........v..........+..........^..........+........^.v........+
| Lower layers | | Lower layers |
+..........v.....................^...................^.v........+ +..........v.....................^...................^.v........+
frame | sent Frame | L2 Ack Active | | OAM Frame | sent Frame | L2 ack Active | | OAM
over | wireless In | In and | | out over | wireless in | in and | | out
v | | v v | | v
]]></artwork>
</figure>
</section>
<!--PCE vs. PLR-->
<!-- 11111111111111111 --> </artwork>
<section anchor="reliability" numbered="true" toc="default"> </figure>
<name>Act: DetNet Path Selection and Reliability Functions</name> </section>
<t> <section anchor="reliability" numbered="true" toc="include" removeInRFC="f
The main action by the PLR is the swapping of the DetNet Path within the alse" pn="section-6.6">
<name slugifiedName="name-act-detnet-path-selection-a">Act: DetNet Path
Selection and Reliability Functions</name>
<t indent="0" pn="section-6.6-1">
The main action by the PLR is the swapping of the DetNet path within the
recovery graph for the future packets. recovery graph for the future packets.
The candidate DetNet Paths represent different energy and spectrum profiles, The candidate DetNet paths represent different energy and spectrum profiles
and provide protection against different failures. and provide protection against different failures.
</t> </t>
<t>The LL API enriches the DetNet protection services (PREOF) <t indent="0" pn="section-6.6-2">The LL API enriches the DetNet protecti
with potential possibility to interact with lower-layer one-hop reliability on services (PREOF) with the
functions that are more typical to wireless than wired, including ARQ, FEC, possibility to interact with lower-layer, one-hop reliability functions
and other techniques such as overhearing and constructive interferences. that are more typical with wireless links than with wired ones, including
Because RAW may be leveraged on wired links, ARQ, FEC, and other techniques such as overhearing and constructive
e.g., to save power, it is not expected that all lower layers support all interferences. Because RAW may be leveraged on wired links (e.g., to save
those capabilities. power), it is not expected that all lower layers support all those
</t> capabilities.
<t> </t>
<t indent="0" pn="section-6.6-3">
RAW provides hints to the lower-layer services on the desired outcome, and RAW provides hints to the lower-layer services on the desired outcome, and
the lower layer acts on those hints to provide the best approximation of the lower layer acts on those hints to provide the best approximation of
that outcome, e.g., a level of reliability for one-hop transmission within that outcome, e.g., a level of reliability for one-hop transmission within
a bounded budget of time and/or energy. Thus, the LL API makes possible a bounded budget of time and/or energy. Thus, the LL API makes possible
cross-layer optimization for reliability depending on the actual cross-layer optimization for reliability depending on the actual
abstraction provided. That is, some reliability functions are controlled abstraction provided. That is, some reliability functions are controlled
from Layer-3 using an abstract interface, while they are really operated at from Layer 3 using an abstract interface, while they are really operated at
the lower layers. the lower layers.
</t> </t>
<t> <t indent="0" pn="section-6.6-4">
The RAW Path Selection can be implemented in both centralized and The RAW path selection can be implemented in both centralized and
distributed approaches. distributed approaches.
In the centralized approach, the PLR may obtain a set of pre-computed DetNet In the centralized approach, the PLR may obtain a set of pre-computed DetNet
paths matching a set of expected failures, and apply the appropriate DetNet paths matching a set of expected failures and apply the appropriate DetNet
paths for the current state of the wireless links. paths for the current state of the wireless links.
In the distributed approach, the signaling in the packet may be more In the distributed approach, the signaling in the packet may be more
abstract than an explicit Path, and the PLR decision might be revised along abstract than an explicit path, and the PLR decision might be revised along
the selected DetNet Path based on a better knowledge of the rest of the way. the selected DetNet path based on a better knowledge of the rest of the way.
</t> </t>
<t> <t indent="0" pn="section-6.6-5">
The dynamic DetNet Path selection in RAW avoids the waste of critical The dynamic DetNet path selection in RAW avoids the waste of critical
resources such as spectrum and energy while providing for the resources such as spectrum and energy while providing for the
assured SLA, e.g., by rerouting and/or adding redundancy only when a assured SLA, e.g., by rerouting and/or adding redundancy only when a
loss spike is observed. loss spike is observed.
</t> </t>
</section>
</section> <!-- Act: The reliability Functions--> </section>
<section anchor="SecurityConsiderations" numbered="true" toc="include" remov
</section> eInRFC="false" pn="section-7">
<!-- The RAW Control Loop --> <name slugifiedName="name-security-considerations">Security Considerations
</name>
<!-- 000000000000000000000 --> <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1
">
<section anchor="SecurityConsiderations" numbered="true" toc="default"> <name slugifiedName="name-collocated-denial-of-servic">Collocated Denial
<name>Security Considerations</name> -of-Service Attacks</name>
<t indent="0" pn="section-7.1-1">
<section numbered="true" toc="default">
<name>Collocated Denial of Service Attacks</name>
<t>
RAW leverages diversity (e.g., spatial and time diversity, RAW leverages diversity (e.g., spatial and time diversity,
coding diversity, and frequency diversity), possibly using coding diversity, and frequency diversity), possibly using
heterogeneous wired and wireless networking technologies over different phys ical paths, heterogeneous wired and wireless networking technologies over different phys ical paths,
to increase the reliability and availability in the face of unpredictable to increase reliability and availability in the face of unpredictable
conditions. While this is not done specifically to defeat an attacker, the conditions. While this is not done specifically to defeat an attacker, the
amount of diversity used in RAW defeats possible attacks that would amount of diversity used in RAW defeats possible attacks that would
impact a particular technology or a specific path. impact a particular technology or a specific path.
</t> </t>
<t indent="0" pn="section-7.1-2">
<t>
Physical actions by a collocated attacker such as a radio interference Physical actions by a collocated attacker such as a radio interference
may still lower the reliability of an end-to-end RAW transmission by blocki ng one segment or one may still lower the reliability of an end-to-end RAW transmission by blocki ng one segment or one
possible path. But if an alternate path with diverse frequency, location, an d/or technology, is possible path. However, if an alternate path with diverse frequency, locatio n, and/or technology is
available, then RAW adapts by rerouting the impacted traffic over the prefer red alternates, available, then RAW adapts by rerouting the impacted traffic over the prefer red alternates,
which defeats the attack after a limited period of lower reliability. which defeats the attack after a limited period of lower reliability.
Then again, the security benefit is a side-effect of an action that is taken Then again, the security benefit is a side effect of an action that is taken
regardless of whether the source of the regardless of whether or not the source of the
issue is voluntary (an attack) or not. issue is voluntary (an attack).
</t> </t>
</section><!-- Collocated Denial of Service Attacks --> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7.2
<section numbered="true" toc="default"> ">
<name>Layer-2 encryption</name> <name slugifiedName="name-layer-2-encryption">Layer 2 Encryption</name>
<t> <t indent="0" pn="section-7.2-1">
Radio networks typically encrypt at the MAC layer to protect the Radio networks typically encrypt at the Media Access Control (MAC) layer to
transmission. If the encryption is per-pair of peers, then certain protect the
transmission. If the encryption is per pair of peers, then certain
RAW operations like promiscuous overhearing become impractical. RAW operations like promiscuous overhearing become impractical.
</t> </t>
</section>
</section><!-- Layer-2 encryption --> <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3
<section numbered="true" toc="default"> ">
<name>Forced Access</name> <name slugifiedName="name-forced-access">Forced Access</name>
<t> <t indent="0" pn="section-7.3-1">
A RAW policy may typically select the cheapest collection of links that A RAW policy typically selects the cheapest collection of links that
matches the requested SLA, e.g., use free Wi-Fi vs. paid 3GPP access. By matches the requested SLA, e.g., use free Wi-Fi versus paid 3GPP access. By
defeating the cheap connectivity (e.g., PHY-layer interference) the attacker defeating the cheap connectivity (e.g., PHY-layer interference) the
can force an End System to use the paid access and increase the cost of the attacker can force an End System to use the paid access and increase the
transmission for the user. cost of the transmission for the user.
</t> </t>
<t> <t indent="0" pn="section-7.3-2">
Similar attacks may also be used to deplete resources in lower-power Similar attacks may also be used to deplete resources in lower-power
nodes by forcing additional transmissions for FEC and ARQ, and attack nodes by forcing additional transmissions for FEC and ARQ, and attack
metrics such as battery life of the nodes. By affecting the transmissions metrics such as battery life of the nodes. By affecting the transmissions
and the associated routing metrics in one area, an attacker may force and the associated routing metrics in one area, an attacker may force
the traffic and cause congestion along a remote path, thus reducing the traffic and cause congestion along a remote path, thus reducing
the overall throughput of the network. the overall throughput of the network.
</t> </t>
</section><!-- Forced Access --> </section>
<!-- 111111111111111111111 -->
</section>
<!--Security Considerations-->
<!-- 000000000000000000000 -->
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.
</t>
</section> </section>
<!--IANA Considerations--> <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
<!-- 000000000000000000000 --> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-8-1">This document has no IANA actions.</t>
<section numbered="true" toc="default">
<name>Contributors</name>
<t>The editor wishes to thank the following individuals
for their contributions to the text and ideas exposed in this document:
</t>
<dl>
<dt>Lou Berger:</dt><dd>LabN Consulting, L.L.C, lberger@labn.net</dd>
<!--dt>Janos Farkas:</dt><dd>Erisson, Janos.Farkas@ericsson.com</dd-->
<dt>Xavi Vilajosana:</dt><dd>Wireless Networks Research Lab, Universitat Obe
rta de Catalunya, xvilajosana@gmail.com</dd>
<dt>Geogios Papadopolous:</dt><dd>IMT Atlantique , georgios.papadopoulos@i
mt-atlantique.fr</dd>
<dt>Remous-Aris Koutsiamanis:</dt><dd>IMT Atlantique, remous-aris.koutsiaman
is@imt-atlantique.fr </dd>
<dt>Rex Buddenberg:</dt><dd>retired, buddenbergr@gmail.com</dd>
<dt>Greg Mirsky:</dt><dd>Ericsson, gregimirsky@gmail.com</dd>
</dl>
</section> </section>
<!--ConTributors-->
<!-- 000000000000000000000 -->
<section><name>Acknowledgments</name>
<t>This architecture could never have been completed without the support and
recommendations from the DetNet Chairs Janos Farkas and Lou Berger, and
Dave Black, the DetNet Tech Advisor.
Many thanks to all of you.
</t>
<t>The authors wish to thank Ketan Talaulikar, as well as Balazs Varga, Dave
Cavalcanti, Don Fedyk,
Nicolas Montavont, and Fabrice Theoleyre for their in-depth reviews during
the development of this document.
</t>
<t>The authors wish to thank Acee Lindem, Eva Schooler, Rich Salz, Wesley Edd
y, Behcet Sarikaya, Brian Haberman,
Gorry Fairhurst, Eric Vyncke, Erik Kline, Roman Danyliw, and Dave Thaler, for
their reviews and comments during the IETF Last Call / IESG review cycle.
</t>
<t>
Special thanks for Mohamed Boucadair, Giuseppe Fioccola, and Benoit Claise,
for their help dealing with OAM technologies.
</t>
</section>
<!-- Acknowledgments -->
<!-- 000000000000000000000 -->
</middle> </middle>
<back> <back>
<displayreference target="RFC9913" to="RAW-TECHNOS"/>
<displayreference target="I-D.ietf-raw-technologies" to="RAW-TECHNOS"/> <displayreference target="RFC9450" to="RAW-USE-CASES"/>
<displayreference target="I-D.ietf-raw-use-cases" to="RAW-USE-CASES"/> <displayreference target="RFC1122" to="INT-ARCH"/>
<displayreference target="RFC9522" to="TE"/>
<displayreference target="RFC1122" to="INT-ARCHI"/> <displayreference target="RFC8175" to="DLEP"/>
<displayreference target="RFC9522" to="TE"/> <displayreference target="RFC7490" to="RLFA-FRR"/>
<displayreference target="RFC8175" to="DLEP"/> <displayreference target="RFC5714" to="FRR"/>
<displayreference target="RFC7490" to="RLFA-FRR"/> <displayreference target="RFC8938" to="DetNet-DP"/>
<displayreference target="RFC5714" to="FRR"/> <displayreference target="RFC8655" to="DetNet-ARCH"/>
<displayreference target="RFC8938" to="DetNet-DP"/> <displayreference target="RFC9030" to="6TiSCH-ARCH"/>
<!--displayreference target="RFC9016" to="DetNet-Flow"/--> <displayreference target="RFC9551" to="DetNet-OAM"/>
<displayreference target="RFC8655" to="DetNet-ARCHI"/> <displayreference target="RFC9938" to="DetNet-PLANE"/>
<displayreference target="RFC9030" to="6TiSCH-ARCHI"/> <references pn="section-9">
<displayreference target="RFC9551" to="DetNet-OAM"/> <name slugifiedName="name-references">References</name>
<references pn="section-9.1">
<references> <name slugifiedName="name-normative-references">Normative References</na
<name>References</name> me>
<references> <reference anchor="RFC8655" target="https://www.rfc-editor.org/info/rfc8
<name>Normative References</name> 655" quoteTitle="true" derivedAnchor="DetNet-ARCH">
<front>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D <title>Deterministic Networking Architecture</title>
.ietf-raw-technologies.xml"/> <author fullname="N. Finn" initials="N." surname="Finn"/>
<!-- Reliable and Available Wireless Technologies --> <author fullname="P. Thubert" initials="P." surname="Thubert"/>
<author fullname="B. Varga" initials="B." surname="Varga"/>
<reference anchor="TSN" target="https://1.ieee802.org/tsn/"> <author fullname="J. Farkas" initials="J." surname="Farkas"/>
<front> <date month="October" year="2019"/>
<title>Time-Sensitive Networking (TSN)</title> <abstract>
<author> <t indent="0">This document provides the overall architecture for
<organization>IEEE</organization> Deterministic Networking (DetNet), which provides a capability to carry specifie
</author> d unicast or multicast data flows for real-time applications with extremely low
<date/> data loss rates and bounded latency within a network domain. Techniques used inc
</front> lude 1) reserving data-plane resources for individual (or aggregated) DetNet flo
</reference> ws in some or all of the intermediate nodes along the path of the flow, 2) provi
ding explicit routes for DetNet flows that do not immediately change with the ne
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC. twork topology, and 3) distributing data from DetNet flow packets over time and/
9030.xml"/> or space to ensure delivery of each packet's data in spite of the loss of a path
<!-- 6TiSCH Architecture --> . DetNet operates at the IP layer and delivers service over lower-layer technolo
gies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC. </t>
4427.xml"/> </abstract>
<!-- Internet Architecture --> </front>
<seriesInfo name="RFC" value="8655"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <seriesInfo name="DOI" value="10.17487/RFC8655"/>
.6291.xml"/> </reference>
<!-- Guidelines for the Use of the "OAM" Acronym in the IETF --> <reference anchor="RFC9551" target="https://www.rfc-editor.org/info/rfc9
551" quoteTitle="true" derivedAnchor="DetNet-OAM">
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <front>
.7799.xml"/> <title>Framework of Operations, Administration, and Maintenance (OAM
<!-- Active and Passive Metrics and Methods for OAM --> ) for Deterministic Networking (DetNet)</title>
<author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <author fullname="F. Theoleyre" initials="F." surname="Theoleyre"/>
.8557.xml"/> <author fullname="G. Papadopoulos" initials="G." surname="Papadopoul
<!-- DetNet problem statement --> os"/>
<author fullname="CJ. Bernardos" initials="CJ." surname="Bernardos"/
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC >
.8655.xml"/> <author fullname="B. Varga" initials="B." surname="Varga"/>
<!-- Deterministic Networking Architecture --> <author fullname="J. Farkas" initials="J." surname="Farkas"/>
<date month="March" year="2024"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <abstract>
.9551.xml"/> <t indent="0">Deterministic Networking (DetNet), as defined in RFC
8655, aims to provide bounded end-to-end latency on top of the network infrastr
ucture, comprising both Layer 2 bridged and Layer 3 routed segments. This docume
nt's primary purpose is to detail the specific requirements of the Operations, A
dministration, and Maintenance (OAM) recommended to maintain a deterministic net
work. The document will be used in future work that defines the applicability of
and extension of OAM protocols for a deterministic network. With the implementa
tion of the OAM framework in DetNet, an operator will have a real-time view of t
he network infrastructure regarding the network's ability to respect the Service
Level Objective (SLO), such as packet delay, delay variation, and packet-loss r
atio, assigned to each DetNet flow.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9551"/>
<seriesInfo name="DOI" value="10.17487/RFC9551"/>
</reference>
<reference anchor="RFC9913" target="https://www.rfc-editor.org/info/rfc9
913" quoteTitle="true" derivedAnchor="RAW-TECHNOS">
<front>
<title>Reliable and Available Wireless (RAW) Technologies</title>
<author initials="P." surname="Thubert" fullname="Pascal Thubert" ro
le="editor">
</author>
<author initials="D." surname="Cavalcanti" fullname="Dave Cavalcanti
">
<organization showOnFrontPage="true">Intel Corporation</organizati
on>
</author>
<author initials="X." surname="Vilajosana" fullname="Xavier Vilajosa
na">
<organization showOnFrontPage="true">Universitat Oberta de Catalun
ya</organization>
</author>
<author initials="C." surname="Schmitt" fullname="Corinna Schmitt">
<organization showOnFrontPage="true">Research Institute CODE, UniB
w M</organization>
</author>
<author initials="J." surname="Farkas" fullname="János Farkas">
<organization showOnFrontPage="true">Ericsson</organization>
</author>
<date month="April" year="2026"/>
</front>
<seriesInfo name="RFC" value="9913"/>
<seriesInfo name="DOI" value="10.17487/RFC9913"/>
</reference>
<reference anchor="RFC4427" target="https://www.rfc-editor.org/info/rfc4
427" quoteTitle="true" derivedAnchor="RFC4427">
<front>
<title>Recovery (Protection and Restoration) Terminology for General
ized Multi-Protocol Label Switching (GMPLS)</title>
<author fullname="E. Mannie" initials="E." role="editor" surname="Ma
nnie"/>
<author fullname="D. Papadimitriou" initials="D." role="editor" surn
ame="Papadimitriou"/>
<date month="March" year="2006"/>
<abstract>
<t indent="0">This document defines a common terminology for Gener
alized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., p
rotection and restoration). The terminology is independent of the underlying tra
nsport technologies covered by GMPLS. This memo provides information for the Int
ernet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4427"/>
<seriesInfo name="DOI" value="10.17487/RFC4427"/>
</reference>
<reference anchor="RFC6291" target="https://www.rfc-editor.org/info/rfc6
291" quoteTitle="true" derivedAnchor="RFC6291">
<front>
<title>Guidelines for the Use of the "OAM" Acronym in the IETF</titl
e>
<author fullname="L. Andersson" initials="L." surname="Andersson"/>
<author fullname="H. van Helvoort" initials="H." surname="van Helvoo
rt"/>
<author fullname="R. Bonica" initials="R." surname="Bonica"/>
<author fullname="D. Romascanu" initials="D." surname="Romascanu"/>
<author fullname="S. Mansfield" initials="S." surname="Mansfield"/>
<date month="June" year="2011"/>
<abstract>
<t indent="0">At first glance, the acronym "OAM" seems to be well-
known and well-understood. Looking at the acronym a bit more closely reveals a s
et of recurring problems that are revisited time and again.</t>
<t indent="0">This document provides a definition of the acronym "
OAM" (Operations, Administration, and Maintenance) for use in all future IETF do
cuments that refer to OAM. There are other definitions and acronyms that will be
discussed while exploring the definition of the constituent parts of the "OAM"
term. This memo documents an Internet Best Current Practice.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="161"/>
<seriesInfo name="RFC" value="6291"/>
<seriesInfo name="DOI" value="10.17487/RFC6291"/>
</reference>
<reference anchor="RFC7799" target="https://www.rfc-editor.org/info/rfc7
799" quoteTitle="true" derivedAnchor="RFC7799">
<front>
<title>Active and Passive Metrics and Methods (with Hybrid Types In-
Between)</title>
<author fullname="A. Morton" initials="A." surname="Morton"/>
<date month="May" year="2016"/>
<abstract>
<t indent="0">This memo provides clear definitions for Active and
Passive performance assessment. The construction of Metrics and Methods can be d
escribed as either "Active" or "Passive". Some methods may use a subset of both
Active and Passive attributes, and we refer to these as "Hybrid Methods". This m
emo also describes multiple dimensions to help evaluate new methods as they emer
ge.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7799"/>
<seriesInfo name="DOI" value="10.17487/RFC7799"/>
</reference>
<reference anchor="RFC8557" target="https://www.rfc-editor.org/info/rfc8
557" quoteTitle="true" derivedAnchor="RFC8557">
<front>
<title>Deterministic Networking Problem Statement</title>
<author fullname="N. Finn" initials="N." surname="Finn"/>
<author fullname="P. Thubert" initials="P." surname="Thubert"/>
<date month="May" year="2019"/>
<abstract>
<t indent="0">This paper documents the needs in various industries
to establish multi-hop paths for characterized flows with deterministic propert
ies.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8557"/>
<seriesInfo name="DOI" value="10.17487/RFC8557"/>
</reference>
<reference anchor="TSN" target="https://1.ieee802.org/tsn/" quoteTitle="
true" derivedAnchor="TSN">
<front>
<title>Time-Sensitive Networking (TSN)</title>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
<date/>
</front>
</reference>
</references>
<references pn="section-9.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC9030" target="https://www.rfc-editor.org/info/rfc9
030" quoteTitle="true" derivedAnchor="6TiSCH-ARCH">
<front>
<title>An Architecture for IPv6 over the Time-Slotted Channel Hoppin
g Mode of IEEE 802.15.4 (6TiSCH)</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="T
hubert"/>
<date month="May" year="2021"/>
<abstract>
<t indent="0">This document describes a network architecture that
provides low-latency, low-jitter, and high-reliability packet delivery. It combi
nes a high-speed powered backbone and subnetworks using IEEE 802.15.4 time-slott
ed channel hopping (TSCH) to meet the requirements of low-power wireless determi
nistic applications.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9030"/>
<seriesInfo name="DOI" value="10.17487/RFC9030"/>
</reference>
<reference anchor="RFC8938" target="https://www.rfc-editor.org/info/rfc8
938" quoteTitle="true" derivedAnchor="DetNet-DP">
<front>
<title>Deterministic Networking (DetNet) Data Plane Framework</title
>
<author fullname="B. Varga" initials="B." role="editor" surname="Var
ga"/>
<author fullname="J. Farkas" initials="J." surname="Farkas"/>
<author fullname="L. Berger" initials="L." surname="Berger"/>
<author fullname="A. Malis" initials="A." surname="Malis"/>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<date month="November" year="2020"/>
<abstract>
<t indent="0">This document provides an overall framework for the
Deterministic Networking (DetNet) data plane. It covers concepts and considerati
ons that are generally common to any DetNet data plane specification. It describ
es related Controller Plane considerations as well.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8938"/>
<seriesInfo name="DOI" value="10.17487/RFC8938"/>
</reference>
<reference anchor="RFC9938" target="https://www.rfc-editor.org/info/rfc9
938" quoteTitle="true" derivedAnchor="DetNet-PLANE">
<front>
<title>A Framework for the Deterministic Networking (DetNet) Control
ler Plane</title>
<author fullname="A. Malis" initials="A." surname="Malis"/>
<author fullname="X. Geng" initials="X." role="editor" surname="Geng
"/>
<author fullname="M. Chen" initials="M." surname="Chen"/>
<author fullname="B. Varga" initials="B." surname="Varga"/>
<author fullname="CJ. Bernardos" initials="CJ." surname="Bernardos"/
>
<date month="March" year="2026"/>
<abstract>
<t indent="0">This document provides a framework overview for the
Deterministic Networking (DetNet) Controller Plane. It discusses concepts and re
quirements for the DetNet Controller Plane, which could be the basis for a futur
e solution specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9938"/>
<seriesInfo name="DOI" value="10.17487/RFC9938"/>
</reference>
<reference anchor="RFC8175" target="https://www.rfc-editor.org/info/rfc8
175" quoteTitle="true" derivedAnchor="DLEP">
<front>
<title>Dynamic Link Exchange Protocol (DLEP)</title>
<author fullname="S. Ratliff" initials="S." surname="Ratliff"/>
<author fullname="S. Jury" initials="S." surname="Jury"/>
<author fullname="D. Satterwhite" initials="D." surname="Satterwhite
"/>
<author fullname="R. Taylor" initials="R." surname="Taylor"/>
<author fullname="B. Berry" initials="B." surname="Berry"/>
<date month="June" year="2017"/>
<abstract>
<t indent="0">When routing devices rely on modems to effect commun
ications over wireless links, they need timely and accurate knowledge of the cha
racteristics of the link (speed, state, etc.) in order to make routing decisions
. In mobile or other environments where these characteristics change frequently,
manual configurations or the inference of state through routing or transport pr
otocols does not allow the router to make the best decisions. This document intr
oduces a new protocol called the Dynamic Link Exchange Protocol (DLEP), which pr
ovides a bidirectional, event-driven communication channel between the router an
d the modem to facilitate communication of changing link characteristics.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8175"/>
<seriesInfo name="DOI" value="10.17487/RFC8175"/>
</reference>
<reference anchor="RFC5714" target="https://www.rfc-editor.org/info/rfc5
714" quoteTitle="true" derivedAnchor="FRR">
<front>
<title>IP Fast Reroute Framework</title>
<author fullname="M. Shand" initials="M." surname="Shand"/>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<date month="January" year="2010"/>
<abstract>
<t indent="0">This document provides a framework for the developme
nt of IP fast- reroute mechanisms that provide protection against link or router
failure by invoking locally determined repair paths. Unlike MPLS fast-reroute,
the mechanisms are applicable to a network employing conventional IP routing and
forwarding. This document is not an Internet Standards Track specification; it
is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5714"/>
<seriesInfo name="DOI" value="10.17487/RFC5714"/>
</reference>
<reference anchor="RFC1122" target="https://www.rfc-editor.org/info/rfc1
122" quoteTitle="true" derivedAnchor="INT-ARCH">
<front>
<title>Requirements for Internet Hosts - Communication Layers</title
>
<author fullname="R. Braden" initials="R." role="editor" surname="Br
aden"/>
<date month="October" year="1989"/>
<abstract>
<t indent="0">This RFC is an official specification for the Intern
et community. It incorporates by reference, amends, corrects, and supplements th
e primary protocol standards documents relating to hosts. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="3"/>
<seriesInfo name="RFC" value="1122"/>
<seriesInfo name="DOI" value="10.17487/RFC1122"/>
</reference>
<reference anchor="NASA1" target="https://extapps.ksc.nasa.gov/Reliabili
ty/Documents/150814-3bWhatIsReliability.pdf" quoteTitle="true" derivedAnchor="NA
SA1">
<front>
<title>RELIABILITY: Definition &amp; Quantitative Illustration</titl
e>
<author initials="T." surname="Adams" fullname="Tim Adams">
<organization showOnFrontPage="true">NASA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="NASA2" target="https://extapps.ksc.nasa.gov/Reliabili
ty/Documents/160727.1_Availability_What_is_it.pdf" quoteTitle="true" derivedAnch
or="NASA2">
<front>
<title>Availability</title>
<author initials="T." surname="Adams" fullname="Tim Adams">
<organization showOnFrontPage="true">NASA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="RFC9450" target="https://www.rfc-editor.org/info/rfc9
450" quoteTitle="true" derivedAnchor="RAW-USE-CASES">
<front>
<title>Reliable and Available Wireless (RAW) Use Cases</title>
<author fullname="CJ. Bernardos" initials="CJ." role="editor" surnam
e="Bernardos"/>
<author fullname="G. Papadopoulos" initials="G." surname="Papadopoul
os"/>
<author fullname="P. Thubert" initials="P." surname="Thubert"/>
<author fullname="F. Theoleyre" initials="F." surname="Theoleyre"/>
<date month="August" year="2023"/>
<abstract>
<t indent="0">The wireless medium presents significant specific ch
allenges to achieve properties similar to those of wired deterministic networks.
At the same time, a number of use cases cannot be solved with wires and justify
the extra effort of going wireless. This document presents wireless use cases (
such as aeronautical communications, amusement parks, industrial applications, p
ro audio and video, gaming, Unmanned Aerial Vehicle (UAV) and vehicle-to-vehicle
(V2V) control, edge robotics, and emergency vehicles), demanding reliable and a
vailable behavior.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9450"/>
<seriesInfo name="DOI" value="10.17487/RFC9450"/>
</reference>
<reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc7
91" quoteTitle="true" derivedAnchor="RFC0791">
<front>
<title>Internet Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel"/>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="5"/>
<seriesInfo name="RFC" value="791"/>
<seriesInfo name="DOI" value="10.17487/RFC0791"/>
</reference>
<reference anchor="RFC2205" target="https://www.rfc-editor.org/info/rfc2
205" quoteTitle="true" derivedAnchor="RFC2205">
<front>
<title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification</title>
<author fullname="R. Braden" initials="R." role="editor" surname="Br
aden"/>
<author fullname="L. Zhang" initials="L." surname="Zhang"/>
<author fullname="S. Berson" initials="S." surname="Berson"/>
<author fullname="S. Herzog" initials="S." surname="Herzog"/>
<author fullname="S. Jamin" initials="S." surname="Jamin"/>
<date month="September" year="1997"/>
<abstract>
<t indent="0">This memo describes version 1 of RSVP, a resource re
servation setup protocol designed for an integrated services Internet. RSVP prov
ides receiver-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="RFC3366" target="https://www.rfc-editor.org/info/rfc3
366" quoteTitle="true" derivedAnchor="RFC3366">
<front>
<title>Advice to link designers on link Automatic Repeat reQuest (AR
Q)</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="L. Wood" initials="L." surname="Wood"/>
<date month="August" year="2002"/>
</front>
<seriesInfo name="BCP" value="62"/>
<seriesInfo name="RFC" value="3366"/>
<seriesInfo name="DOI" value="10.17487/RFC3366"/>
</reference>
<reference anchor="RFC4090" target="https://www.rfc-editor.org/info/rfc4
090" quoteTitle="true" derivedAnchor="RFC4090">
<front>
<title>Fast Reroute Extensions to RSVP-TE for LSP Tunnels</title>
<author fullname="P. Pan" initials="P." role="editor" surname="Pan"/
>
<author fullname="G. Swallow" initials="G." role="editor" surname="S
wallow"/>
<author fullname="A. Atlas" initials="A." role="editor" surname="Atl
as"/>
<date month="May" year="2005"/>
<abstract>
<t indent="0">This document defines RSVP-TE extensions to establis
h backup label-switched path (LSP) tunnels for local repair of LSP tunnels. Thes
e mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s o
f milliseconds, in the event of a failure.</t>
<t indent="0">Two methods are defined here. The one-to-one backup
method creates detour LSPs for each protected LSP at each potential point of loc
al repair. The facility backup method creates a bypass tunnel to protect a poten
tial failure point; by taking advantage of MPLS label stacking, this bypass tunn
el can protect a set of LSPs that have similar backup constraints. Both methods
can be used to protect links and nodes during network failure. The described beh
avior and extensions to RSVP allow nodes to implement either method or both and
to interoperate in a mixed network. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4090"/>
<seriesInfo name="DOI" value="10.17487/RFC4090"/>
</reference>
<reference anchor="RFC4655" target="https://www.rfc-editor.org/info/rfc4
655" quoteTitle="true" derivedAnchor="RFC4655">
<front>
<title>A Path Computation Element (PCE)-Based Architecture</title>
<author fullname="A. Farrel" initials="A." surname="Farrel"/>
<author fullname="J.-P. Vasseur" initials="J.-P." surname="Vasseur"/
>
<author fullname="J. Ash" initials="J." surname="Ash"/>
<date month="August" year="2006"/>
<abstract>
<t indent="0">Constraint-based path computation is a fundamental b
uilding block for traffic engineering systems such as Multiprotocol Label Switch
ing (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path
computation in large, multi-domain, multi-region, or multi-layer networks is com
plex and may require special computational components and cooperation between th
e different network domains.</t>
<t indent="0">This document specifies the architecture for a Path
Computation Element (PCE)-based model to address this problem space. This docume
nt does not attempt to provide a detailed description of all the architectural c
omponents, but rather it describes a set of building blocks for the PCE architec
ture from which solutions may be constructed. This memo provides information for
the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4655"/>
<seriesInfo name="DOI" value="10.17487/RFC4655"/>
</reference>
<reference anchor="RFC5880" target="https://www.rfc-editor.org/info/rfc5
880" quoteTitle="true" derivedAnchor="RFC5880">
<front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<author fullname="D. Katz" initials="D." surname="Katz"/>
<author fullname="D. Ward" initials="D." surname="Ward"/>
<date month="June" year="2010"/>
<abstract>
<t indent="0">This document describes a protocol intended to detec
t faults in the bidirectional path between two forwarding engines, including int
erfaces, data link(s), and to the extent possible the forwarding engines themsel
ves, with potentially very low latency. It operates independently of media, data
protocols, and routing protocols. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5880"/>
<seriesInfo name="DOI" value="10.17487/RFC5880"/>
</reference>
<reference anchor="RFC6378" target="https://www.rfc-editor.org/info/rfc6
378" quoteTitle="true" derivedAnchor="RFC6378">
<front>
<title>MPLS Transport Profile (MPLS-TP) Linear Protection</title>
<author fullname="Y. Weingarten" initials="Y." role="editor" surname
="Weingarten"/>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<author fullname="E. Osborne" initials="E." surname="Osborne"/>
<author fullname="N. Sprecher" initials="N." surname="Sprecher"/>
<author fullname="A. Fulignoli" initials="A." role="editor" surname=
"Fulignoli"/>
<date month="October" year="2011"/>
<abstract>
<t indent="0">This document is a product of a joint Internet Engin
eering Task Force (IETF) / International Telecommunications Union Telecommunicat
ions Standardization 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 transport network as
defined by the ITU-T.</t>
<t indent="0">This document addresses the functionality described
in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protoco
l that may be used to fulfill the function of the Protection State Coordination
for linear protection, as described in that document. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6378"/>
<seriesInfo name="DOI" value="10.17487/RFC6378"/>
</reference>
<reference anchor="RFC6551" target="https://www.rfc-editor.org/info/rfc6
551" quoteTitle="true" derivedAnchor="RFC6551">
<front>
<title>Routing Metrics Used for Path Calculation in Low-Power and Lo
ssy Networks</title>
<author fullname="JP. Vasseur" initials="JP." role="editor" surname=
"Vasseur"/>
<author fullname="M. Kim" initials="M." role="editor" surname="Kim"/
>
<author fullname="K. Pister" initials="K." surname="Pister"/>
<author fullname="N. Dejean" initials="N." surname="Dejean"/>
<author fullname="D. Barthel" initials="D." surname="Barthel"/>
<date month="March" year="2012"/>
<abstract>
<t indent="0">Low-Power and Lossy Networks (LLNs) have unique char
acteristics compared with traditional wired and ad hoc networks that require the
specification of new routing metrics and constraints. By contrast, with typical
Interior Gateway Protocol (IGP) routing metrics using hop counts or link metric
s, this document specifies a set of link and node routing metrics and constraint
s suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Ne
tworks (RPL). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6551"/>
<seriesInfo name="DOI" value="10.17487/RFC6551"/>
</reference>
<reference anchor="RFC8578" target="https://www.rfc-editor.org/info/rfc8
578" quoteTitle="true" derivedAnchor="RFC8578">
<front>
<title>Deterministic Networking Use Cases</title>
<author fullname="E. Grossman" initials="E." role="editor" surname="
Grossman"/>
<date month="May" year="2019"/>
<abstract>
<t indent="0">This document presents use cases for diverse industr
ies that have in common a need for "deterministic flows". "Deterministic" in thi
s context means that such flows provide guaranteed bandwidth, bounded latency, a
nd other properties germane to the transport of time-sensitive data. These use c
ases differ notably in their network topologies and specific desired behavior, p
roviding as a group broad industry context for Deterministic Networking (DetNet)
. For each use case, this document will identify the use case, identify represen
tative solutions 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="RFC8724" target="https://www.rfc-editor.org/info/rfc8
724" quoteTitle="true" derivedAnchor="RFC8724">
<front>
<title>SCHC: Generic Framework for Static Context Header Compression
and Fragmentation</title>
<author fullname="A. Minaburo" initials="A." surname="Minaburo"/>
<author fullname="L. Toutain" initials="L." surname="Toutain"/>
<author fullname="C. Gomez" initials="C." surname="Gomez"/>
<author fullname="D. Barthel" initials="D." surname="Barthel"/>
<author fullname="JC. Zuniga" initials="JC." surname="Zuniga"/>
<date month="April" year="2020"/>
<abstract>
<t indent="0">This document defines the Static Context Header Comp
ression and fragmentation (SCHC) framework, which provides both a header compres
sion mechanism and an optional fragmentation mechanism. SCHC has been designed w
ith Low-Power Wide Area Networks (LPWANs) in mind.</t>
<t indent="0">SCHC compression is based on a common static context
stored both in the LPWAN device and in the network infrastructure side. This do
cument defines a generic header compression mechanism and its application to com
press IPv6/UDP headers.</t>
<t indent="0">This document also specifies an optional fragmentati
on and reassembly mechanism. It can be used to support the IPv6 MTU requirement
over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, af
ter SCHC compression or when such compression was not possible, still exceed the
Layer 2 maximum payload size.</t>
<t indent="0">The SCHC header compression and fragmentation mechan
isms are independent of the specific LPWAN technology over which they are used.
This document defines generic functionalities and offers flexibility with regard
to parameter settings and mechanism choices. This document standardizes the exc
hange over the LPWAN between two SCHC entities. Settings and choices specific to
a technology or a product are expected to be grouped into profiles, which are s
pecified in other documents. Data models for the context and profiles are out of
scope.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8724"/>
<seriesInfo name="DOI" value="10.17487/RFC8724"/>
</reference>
<reference anchor="RFC8762" target="https://www.rfc-editor.org/info/rfc8
762" quoteTitle="true" derivedAnchor="RFC8762">
<front>
<title>Simple Two-Way Active Measurement Protocol</title>
<author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
<author fullname="G. Jun" initials="G." surname="Jun"/>
<author fullname="H. Nydell" initials="H." surname="Nydell"/>
<author fullname="R. Foote" initials="R." surname="Foote"/>
<date month="March" year="2020"/>
<abstract>
<t indent="0">This document describes the Simple Two-way Active Me
asurement Protocol (STAMP), which enables the measurement of both one-way and ro
und-trip performance metrics, like delay, delay variation, and packet loss.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8762"/>
<seriesInfo name="DOI" value="10.17487/RFC8762"/>
</reference>
<reference anchor="RFC8939" target="https://www.rfc-editor.org/info/rfc8
939" quoteTitle="true" derivedAnchor="RFC8939">
<front>
<title>Deterministic Networking (DetNet) Data Plane: IP</title>
<author fullname="B. Varga" initials="B." role="editor" surname="Var
ga"/>
<author fullname="J. Farkas" initials="J." surname="Farkas"/>
<author fullname="L. Berger" initials="L." surname="Berger"/>
<author fullname="D. Fedyk" initials="D." surname="Fedyk"/>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<date month="November" year="2020"/>
<abstract>
<t indent="0">This document specifies the Deterministic Networking
(DetNet) data plane operation for IP hosts and routers that provide DetNet serv
ice to IP-encapsulated data. No DetNet-specific encapsulation is defined to supp
ort IP flows; instead, the existing IP-layer and higher-layer protocol header in
formation is used to support flow identification and DetNet service delivery. Th
is document builds on the DetNet architecture (RFC 8655) and data plane framewor
k (RFC 8938).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8939"/>
<seriesInfo name="DOI" value="10.17487/RFC8939"/>
</reference>
<reference anchor="RFC9049" target="https://www.rfc-editor.org/info/rfc9
049" quoteTitle="true" derivedAnchor="RFC9049">
<front>
<title>Path Aware Networking: Obstacles to Deployment (A Bestiary of
Roads Not Taken)</title>
<author fullname="S. Dawkins" initials="S." role="editor" surname="D
awkins"/>
<date month="June" year="2021"/>
<abstract>
<t indent="0">This document is a product of the Path Aware Network
ing Research Group (PANRG). At the first meeting of the PANRG, the Research Grou
p agreed to catalog and analyze past efforts to develop and deploy Path Aware te
chniques, most of which were unsuccessful or at most partially successful, in or
der to extract insights and lessons for Path Aware networking researchers.</t>
<t indent="0">This document contains that catalog and analysis.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="9049"/>
<seriesInfo name="DOI" value="10.17487/RFC9049"/>
</reference>
<reference anchor="RFC9378" target="https://www.rfc-editor.org/info/rfc9
378" quoteTitle="true" derivedAnchor="RFC9378">
<front>
<title>In Situ Operations, Administration, and Maintenance (IOAM) De
ployment</title>
<author fullname="F. Brockners" initials="F." role="editor" surname=
"Brockners"/>
<author fullname="S. Bhandari" initials="S." role="editor" surname="
Bhandari"/>
<author fullname="D. Bernier" initials="D." surname="Bernier"/>
<author fullname="T. Mizrahi" initials="T." role="editor" surname="M
izrahi"/>
<date month="April" year="2023"/>
<abstract>
<t indent="0">In situ Operations, Administration, and Maintenance
(IOAM) collects operational and telemetry information in the packet while the pa
cket traverses a path between two points in the network. This document provides
a framework for IOAM deployment and provides IOAM deployment considerations and
guidance.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9378"/>
<seriesInfo name="DOI" value="10.17487/RFC9378"/>
</reference>
<reference anchor="RFC9473" target="https://www.rfc-editor.org/info/rfc9
473" quoteTitle="true" derivedAnchor="RFC9473">
<front>
<title>A Vocabulary of Path Properties</title>
<author fullname="R. Enghardt" initials="R." surname="Enghardt"/>
<author fullname="C. Krähenbühl" initials="C." surname="Krähenbühl"/
>
<date month="September" year="2023"/>
<abstract>
<t indent="0">Path properties express information about paths acro
ss a network and the services provided via such paths. In a path-aware network,
path properties may be fully or partially available to entities such as endpoint
s. This document defines and categorizes path properties. Furthermore, the docum
ent identifies several path properties that might be useful to endpoints or othe
r entities, e.g., for selecting between paths or for invoking some of the provid
ed services. This document is a product of the Path Aware Networking Research Gr
oup (PANRG).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9473"/>
<seriesInfo name="DOI" value="10.17487/RFC9473"/>
</reference>
<reference anchor="RFC9544" target="https://www.rfc-editor.org/info/rfc9
544" quoteTitle="true" derivedAnchor="RFC9544">
<front>
<title>Precision Availability Metrics (PAMs) for Services Governed b
y Service Level Objectives (SLOs)</title>
<author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
<author fullname="J. Halpern" initials="J." surname="Halpern"/>
<author fullname="X. Min" initials="X." surname="Min"/>
<author fullname="A. Clemm" initials="A." surname="Clemm"/>
<author fullname="J. Strassner" initials="J." surname="Strassner"/>
<author fullname="J. François" initials="J." surname="François"/>
<date month="March" year="2024"/>
<abstract>
<t indent="0">This document defines a set of metrics for networkin
g services with
performance requirements expressed as Service Level Objectives
(SLOs). These metrics, referred to as "Precision Availability Metrics
(PAMs)", are useful for defining and monitoring SLOs. For example,
PAMs can be used by providers and/or customers of an RFC 9543 Network
Slice Service to assess whether the service is provided in compliance
with its defined SLOs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9544"/>
<seriesInfo name="DOI" value="10.17487/RFC9544"/>
</reference>
<reference anchor="RFC9633" target="https://www.rfc-editor.org/info/rfc9
633" quoteTitle="true" derivedAnchor="RFC9633">
<front>
<title>Deterministic Networking (DetNet) YANG Data Model</title>
<author fullname="X. Geng" initials="X." surname="Geng"/>
<author fullname="Y. Ryoo" initials="Y." surname="Ryoo"/>
<author fullname="D. Fedyk" initials="D." surname="Fedyk"/>
<author fullname="R. Rahman" initials="R." surname="Rahman"/>
<author fullname="Z. Li" initials="Z." surname="Li"/>
<date month="October" year="2024"/>
<abstract>
<t indent="0">This document contains the specification for the Det
erministic Networking (DetNet) YANG data model for configuration and operational
data for DetNet flows. The model allows the provisioning of an end-to-end DetNe
t service on devices along the path without depending on any signaling protocol.
It also specifies operational status for flows.</t>
<t indent="0">The YANG module defined in this document conforms to
the Network Management Datastore Architecture (NMDA).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9633"/>
<seriesInfo name="DOI" value="10.17487/RFC9633"/>
</reference>
<reference anchor="RFC7490" target="https://www.rfc-editor.org/info/rfc7
490" quoteTitle="true" derivedAnchor="RLFA-FRR">
<front>
<title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="S. Previdi" initials="S." surname="Previdi"/>
<author fullname="M. Shand" initials="M." surname="Shand"/>
<author fullname="N. So" initials="N." surname="So"/>
<date month="April" year="2015"/>
<abstract>
<t indent="0">This document describes an extension to the basic IP
fast reroute mechanism, described in RFC 5286, that provides additional backup
connectivity for point-to-point link failures when none can be provided by the b
asic mechanisms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7490"/>
<seriesInfo name="DOI" value="10.17487/RFC7490"/>
</reference>
<reference anchor="RFC9522" target="https://www.rfc-editor.org/info/rfc9
522" quoteTitle="true" derivedAnchor="TE">
<front>
<title>Overview and Principles of Internet Traffic Engineering</titl
e>
<author fullname="A. Farrel" initials="A." role="editor" surname="Fa
rrel"/>
<date month="January" year="2024"/>
<abstract>
<t indent="0">This document describes the principles of traffic en
gineering (TE) in the Internet. The document is intended to promote better under
standing of the issues surrounding traffic engineering in IP networks and the ne
tworks that support IP networking and to provide a common basis for the developm
ent of traffic-engineering capabilities for the Internet. The principles, archit
ectures, and methodologies for performance evaluation and performance optimizati
on of operational networks are also discussed.</t>
<t indent="0">This work was first published as RFC 3272 in May 200
2. This document obsoletes RFC 3272 by making a complete update to bring the tex
t in line with best current practices for Internet traffic engineering and to in
clude references to the latest relevant work in the IETF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9522"/>
<seriesInfo name="DOI" value="10.17487/RFC9522"/>
</reference>
</references> </references>
<!--Normative References-->
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.9049.xml"/>
<!-- Path Aware Networking: Obstacles to Deployment -->
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
1122.xml"/>
<!-- Internet Architecture -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.8939.xml"/>
<!-- Deterministic Networking IP dataplane -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.8578.xml"/>
<!-- Deterministic Networking Use Cases -->
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D
.ietf-raw-use-cases.xml"/>
<!-- RAW use cases -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.0791.xml"/>
<!-- IP -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.2205.xml"/>
<!-- RSVP -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.9522.xml"/>
<!-- TE -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.9544.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.4655.xml"/>
<!-- PCE -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.3366.xml"/>
<!-- Advice to link designers on link Automatic Repeat reQuest (ARQ) -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.4090.xml"/>
<!-- Fast Reroute Extensions to RSVP-TE -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.5880.xml"/>
<!-- BFD -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.5714.xml"/>
<!-- IP Fast Reroute Framework -->
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
6378.xml"/>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
6551.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.7490.xml"/>
<!-- Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.8724.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.8938.xml"/>
<!-- Deterministic Networking (DetNet) Data Plane Framework -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.8175.xml"/>
<!-- Dynamic Link Exchange Protocol -->
<!--xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.
RFC.9016.xml"/-->
<!-- Flow and Service Information Model for Deterministic Networking (DetNet) -
->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.9378.xml"/>
<!-- Framework of Operations, Administration, and Maintenance (OAM) for Determi
nistic Networking (DetNet) -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
C.8762.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
C.9473.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RF
C.9633.xml"/>
<!--
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D
.ietf-opsawg-oam-characterization"/>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D
.ietf-detnet-controller-plane-framework"/>
<reference anchor="NASA1" target="https://extapps.ksc.nasa.gov/Reliability/D
ocuments/150814-3bWhatIsReliability.pdf">
<front>
<title>RELIABILITY: Definition &amp; Quantitative Illustration</title>
<author initials="T." surname="Adams" fullname="Tim Adams" >
<organization>NASA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="NASA2" target="https://extapps.ksc.nasa.gov/Reliability/Do
cuments/160727.1_Availability_What_is_it.pdf">
<front>
<title>Availability</title>
<author initials="T." surname="Adams" fullname="Tim Adams" >
<organization>NASA</organization>
</author>
<date/>
</front>
</reference>
<!--Informative References-->
</references>
</references> </references>
<section numbered="false" removeInRFC="false" toc="include" pn="section-appe
ndix.a">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.a-1">This architecture could never have
been completed without the support
and recommendations from the DetNet chairs <contact fullname="Janos Farkas
"/> and <contact fullname="Lou Berger"/>, and from <contact fullname="Dave Bl
ack"/>, the DetNet Tech Advisor. Many thanks to all of you.
</t>
<t indent="0" pn="section-appendix.a-2">The authors wish to thank <contact
fullname="Ketan Talaulikar"/>, as
well as <contact fullname="Balazs Varga"/>, <contact fullname="Dave Cavalc
anti"/>, <contact fullname="Don Fedyk"/>, <contact fullname="Nicolas Montavon
t"/>, and <contact fullname="Fabrice Theoleyre"/> for their
in-depth reviews during the development of this document.
</t>
<t indent="0" pn="section-appendix.a-3">The authors wish to thank <contact
fullname="Acee Lindem"/>, <contact fullname="Eva Schooler"/>, <contact fullname
="Rich Salz"/>, <contact fullname="Wesley Eddy"/>, <contact fullname="Behcet Sar
ikaya"/>, <contact fullname="Brian Haberman"/>, <contact fullname="Gorry Fairhur
st"/>,
<contact fullname="Éric Vyncke"/>, <contact fullname="Erik Kline"/>,
<contact fullname="Roman Danyliw"/>, and <contact fullname="Dave Thaler"/>
for their reviews and comments during the IETF Last Call and IESG review
cycle.
</t>
<t indent="0" pn="section-appendix.a-4">
Special thanks for <contact fullname="Mohamed Boucadair"/>, <contact fullnam
e="Giuseppe Fioccola"/>, and <contact fullname="Benoit Claise"/>
for their help dealing with OAM technologies.
</t>
</section>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.b">
<name slugifiedName="name-contributors">Contributors</name>
<t indent="0" pn="section-appendix.b-1">The editor wishes to thank the fol
lowing individuals
for their contributions to the text and the ideas discussed in this doc
ument:
</t>
<contact fullname="Lou Berger">
<organization showOnFrontPage="true">LabN Consulting, L.L.C</organizatio
n>
<address>
<email>lberger@labn.net</email>
</address>
</contact>
<contact fullname="Xavi Vilajosana">
<organization showOnFrontPage="true">Wireless Networks Research Lab, Uni
versitat Oberta de Catalunya</organization>
<address>
<email>xvilajosana@gmail.com</email>
</address>
</contact>
<contact fullname="Geogios Papadopolous">
<organization showOnFrontPage="true">IMT Atlantique</organization>
<address>
<email>georgios.papadopoulos@imt-atlantique.fr</email>
</address>
</contact>
<contact fullname="Remous-Aris Koutsiamanis">
<organization showOnFrontPage="true">IMT Atlantique</organization>
<address>
<email>remous-aris.koutsiamanis@imt-atlantique.fr</email>
</address>
</contact>
<contact fullname="Rex Buddenberg">
<organization showOnFrontPage="true">Retired</organization>
<address>
<email>buddenbergr@gmail.com</email>
</address>
</contact>
<contact fullname="Greg Mirsky">
<organization showOnFrontPage="true">Ericsson</organization>
<address>
<email>gregimirsky@gmail.com</email>
</address>
</contact>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.c">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="edi
tor">
<organization showOnFrontPage="true">Independent</organization>
<address>
<postal>
<city>Roquefort-les-Pins</city>
<code>06330</code>
<country>France</country>
</postal>
<email>pascal.thubert@gmail.com</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 244 change blocks. 
1806 lines changed or deleted 3014 lines changed or added

This html diff was produced by rfcdiff 1.48.