rfc9912.original.xml   rfc9912.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- Compiles with XML2RFC v3 https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc-dev <!DOCTYPE rfc [
.cgi --> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
<?rfc tocompact="yes"?> etf-raw-architecture-30" number="9912" consensus="true" ipr="trust200902" update
<?rfc tocdepth="3"?> s="" tocInclude="true" obsoletes="" submissionType="IETF" xml:lang="en" version=
<?rfc tocindent="yes"?> "3" sortRefs="false" symRefs="true">
<?rfc symrefs="yes"?>
<?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>
<title abbrev="RAW Architecture">Reliable and Available Wireless
Architecture</title>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor <front>
'>
<organization abbrev=''>Without Affiliation</organization> <!-- [rfced] *AD, Janos Farkas (document shepherd) sent an email to the RPC on
<address> 2026 Jan 16 saying that the [6TiSCH-ARCHI] should be moved from the
<postal> normative references section to the informative references section. We
<city>Roquefort-les-Pins</city> made this change, but please review and let us know if you approve. We
<code>06330</code> consider changes to normative references to be "beyond editorial".
<country>France</country> -->
</postal>
<email>pascal.thubert@gmail.com</email> <!-- [rfced] Please note that the title of the document has been updated as
</address> follows. We have added the abbreviation "RAW" to align with the title of
</author> draft-ietf-raw-technologies-17 (RFC 9913).
Original:
Reliable and Available Wireless Architecture
Current:
Reliable and Available Wireless (RAW) Architecture
-->
<!-- [rfced] We have removed "Without Affiliation" from the document header
and Author's Addresses section to align with draft-ietf-raw-technologies
and draft-ietf-roll-dao-projection.
Note: Per Section 4.1.2 of RFC 7322 ("RFC Style Guide"), an author's
affiliation may be left blank or include "Independent", "Individual
Contributor", "Retired", or a similar term. Please let us know if you prefer
to use one of these terms instead, and we will apply that to all documents in
this cluster.
-->
<title abbrev="RAW Architecture">Reliable and Available Wireless (RAW) Archite
cture</title>
<seriesInfo name="RFC" value="9912"/>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'
>
<organization></organization>
<address>
<postal>
<city>Roquefort-les-Pins</city>
<code>06330</code>
<country>France</country>
</postal>
<email>pascal.thubert@gmail.com</email>
</address>
</author>
<date month="February" year="2026"/>
<area>RTG</area>
<workgroup>detnet</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<date/>
<area>Routing Area</area>
<workgroup>DetNet</workgroup>
<keyword>Draft</keyword>
<abstract> <abstract>
<t> <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>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
Deterministic Networking aims at providing bounded latency and eliminating Deterministic Networking (DetNet) aims to provide bounded latency and elimina
congestion loss, even when co-existing with best-effort traffic. te
congestion loss, even when coexisting 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"/>.
</t> </t>
<t> <t>
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"/> initially focused on wir ed
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>
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"/>. With scheduled radios
radios such as Time Slotted Channel Hopping (TSCH) and Orthogonal Frequency such as Time-Slotted Channel Hopping (TSCH) and Orthogonal
Division Multiple Access (OFDMA) (see <xref target="I-D.ietf-raw-technologies Frequency-Division Multiple Access (OFDMA) being developed
"/> for more on both of these and other technologies as well) to provide determinism over wireless links at the lower layers, providing
being developed to provide determinism over wireless links at the lower DetNet capabilities has become possible. See <xref target="RFC9913"/>
layers, providing DetNet capabilities has become possible. for more on TSCH, OFDMA, and other technologies.
</t> </t>
<t> <t>
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> <t>
The intent of RAW is to meet Service Level Objectives (SLOs) in terms of P DR, maximum contiguous losses, or latency boundaries for DetNet flows over mixes of wired and wireless networks, including wireless access and meshes (see <xref target="problem"/> for more on the RAW problem).
The intent of RAW is to meet Service Level Objectives (SLO) in terms of pack This document introduces and/or leverages terminology (see <xref target="term
et delivery ratio (PDR), maximum contiguous losses or latency boundaries for Det s"/>), principles (see <xref target="raw"/>), and concepts such as protection pa
Net flows over mixes of wired and wireless networks, including wireless access a ths and recovery graphs to put together a conceptual model for RAW (see <xref ta
nd meshes (see <xref target="problem"/> for more on the RAW problem). rget="model"/>). Based on that model, this document elaborates on an in-network
optimization control loop (see <xref target="control"/>).
This document introduces and/or leverages terminology (see <xref target="term
s"/>), principles (see <xref target="raw"/>), and concepts such as protection p
ath and recovery graph, to put together a conceptual model for RAW (see <xref ta
rget="model"/>), and, based on that model, elaborate on an
in-network optimization control loop (see <xref target="control"/>).
</t> </t>
</section> </section>
<!-- Introduction -->
<!-- 000000000000000000000 -->
<section anchor="problem" numbered="true" toc="default"> <section anchor="problem" numbered="true" toc="default">
<name>The RAW problem</name> <name>The RAW Problem</name>
<t> <t>
While the generic <xref target="RFC8557">"Deterministic Networking While the generic "Deterministic Networking Problem Statement" <xref
Problem Statement"</xref> applies to both the wired and the wireless media, target="RFC8557"/> applies to both wired and wireless media, the "Determinist
the <xref target="RFC8655">"Deterministic Networking Architecture" ic Networking Architecture" <xref
</xref> must be extended to address less consistent target="RFC8655"/> 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>
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>
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"/>. Conceptually, RAW is agnostic to
Conceptually, RAW is agnostic to the lower layer, though the the lower layer, though the capability to control latency is assumed to
capability to control latency is assumed to assure the DetNet services that R ensure the DetNet services that RAW extends. How the lower layers are
AW extends. operated to do so (and whether a radio network is single hop or
How the lower layers are operated to do so, and, e.g., whether a radio networ meshed, for example) are opaque to the IP layer and not part of the RAW abstr
k is single-hop or meshed, are opaque to the IP layer and not part of the RAW ab action.
straction.
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>
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"/> or
diverse radio access networks as illustrated in <xref target ="Figranp2"/>. diverse radio access networks as illustrated in <xref target ="Figranp2"/>.
</t> </t>
<t> <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>
Those capabilities include: Those capabilities include:
</t> </t>
<dl> <dl>
<dt>Promiscuous Overhearing:</dt><dd> Some wired and wireless <dt>Promiscuous overhearing:</dt><dd> 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>L2-aware routing:</dt>
<dd><t>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
dynamic sense of link metrics, with new protocols such as DLEP and L2-trigge <ol>
r to <li>a new and more dynamic sense of link metrics, with new protocols
keep L3 up to date with the link quality and availability, and 2) an such as the Dynamic Link Exchange Protocol (DLEP) and Layer 2 (L2) trigger
approach to multipath routing, where multiple link metrics are s to keep Layer 3 (L3) up to date with the link quality
considered since simple shortest-path cost loses its meaning with and availability, and</li>
the instability of the metrics. <li>an approach to multipath routing, where multiple link metrics are
considered since simple shortest-path cost loses its meaning with the
instability of the metrics.</li>
</ol>
</dd> </dd>
<!-- [rfced] May we update "ack-based" to either "acknowledgment-based" or
"ACK-based" in the text below to clarify its meaning?
Original:
Redundant transmissions: Though feasible on any technology,
proactive (forward) and reactive (ack-based) error correction are
typical to the wireless media.
Perhaps:
Redundant transmissions: Though feasible on any technology,
proactive (forward) and reactive (acknowledgment-based) error correction i
s
typical for wireless media.
-->
<dt>Redundant transmissions:</dt><dd>Though feasible on any technology, proa ctive <dt>Redundant transmissions:</dt><dd>Though feasible on any technology, proa ctive
(forward) and reactive (ack-based) error correction are typical to the wirel ess (forward) and reactive (ack-based) error correction are typical for wireless
media. Bounded latency can still be obtained on a wireless link while media. Bounded latency can still be obtained on a wireless 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
be difficult to achieve at high speed, a fine time synchronization and a <!-- [rfced] Should "translate taking" here be updated to "translate to taking"?
precise sense of phase allows the energy from multiple coordinated senders
to add up at the receiver and actually improve the signal quality, Original:
From a DetNet perspective, this may translate taking into account
how transmission from one node may interfere with the transmission
of another node attached to the same wireless sub-layer network.
Perhaps:
From a DetNet perspective, this may translate to taking into account
how transmission from one node may interfere with the transmission
of another node attached to the same wireless sub-layer network.
-->
<dt>Relay coordination and constructive interference:</dt><dd>Though it
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
may translate taking into account how transmission from one node may translate taking into account how transmission from one node may interfere
interfere with the transmission of another node attached to the same with the transmission of another node attached to the same wireless
wireless sub-layer network. sub-layer network.
</dd> </dd>
</dl> </dl>
<t> <t>
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"/>.
</t> </t>
<!-- [rfced] Will readers understand what "It" refers to in the second
sentence (e.g., to "path", "mechanism", "RAW")? Also, how may we clarify
"ala"?
Original:
The mechanisms used to establish a path is not unique to, or
necessarily impacted by, RAW. It is expected to be the product of
the DetNet Controller Plane
[I-D.ietf-detnet-controller-plane-framework], and may use a Path
computation Element (PCE) [RFC4655] or the DetNet Yang Data Model
[RFC9633], or may be computed in a distributed fashion ala Resource
ReSerVation Protocol (RSVP) [RFC2205].
Perhaps:
The mechanism used to establish a path is not unique to, or
necessarily impacted by, RAW. The mechanism is expected to be the product of
the DetNet Controller Plane [DetNet-PLANE]; it may use a Path
Computation Element (PCE) [RFC4655] or the DetNet YANG data model
[RFC9633], or it may be computed in a distributed fashion as per the
Resource ReSerVation Protocol (RSVP) [RFC2205].
-->
<t> <t>
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 necessarily
impacted by, RAW. It is expected to be the product of the DetNet impacted by, RAW. It is expected to be the product of the DetNet Controller
Controller Plane <xref Plane <xref target="I-D.ietf-detnet-controller-plane-framework"/>; it may
target="I-D.ietf-detnet-controller-plane-framework"/>, and may use use a Path Computation Element (PCE) <xref target="RFC4655"/> or the DetNet
a Path computation Element (PCE) <xref target="RFC4655"/> or the YANG data model <xref target="RFC9633"/>, or it may be computed in a
DetNet Yang Data Model <xref target="RFC9633"/>, or may be distributed fashion ala the Resource ReSerVation Protocol (RSVP) <xref
computed in a distributed fashion ala target="RFC2205"/>. Either way, the assumption is that it is slow relative
Resource ReSerVation Protocol (RSVP) <xref target="RFC2205"/>. to local forwarding operations along the path. To react fast enough to
Either way, the assumption is that it is slow relative to transient changes in the radio transmissions, RAW leverages DetNet Network
local forwarding operations along the path. Plane enhancements to optimize the use of the paths and match the quality
To react fast enough to transient changes in the radio transmissions, RAW lev of the transmissions over time.
erages DetNet Network Plane enhancements to
optimize the use of the paths and match the quality of the transmissions over
time.
</t> </t>
<t> <t>
As opposed to wired As opposed to wired networks, the action of installing a path over a set of
networks, the action of installing a path over a set of wireless links wireless links may be very slow relative to the speed at which the radio
may be very slow relative to the speed at which the radio conditions vary, conditions vary; thus, in the wireless case, it makes sense to provide
and it makes sense in the wireless case to provide redundant forwarding redundant forwarding solutions along alternate paths (see <xref
solutions along a alternate paths (see <xref target="pt"/>) and to leave it target="pt"/>) and to leave it to the Network Plane to select which of
to the Network Plane to select which of those forwarding solutions are to be those forwarding solutions are to be used for a given packet based on the
used for a given packet based on the current conditions. current conditions. The RAW Network Plane operations happen within the
The RAW Network Plane operations happen within the scope of a recovery graph scope of a recovery graph (see <xref target="trk"/>) that is
(see <xref target="trk"/>) that is pre-established and installed pre-established and installed by means outside of the scope of RAW.
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>
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
mescale"/>). target= "timescale"/>). The RAW Network Plane operations happen at a
The RAW Network Plane operations happen at a time-scale that sits timewise be timescale that sits timewise between the routing and the forwarding
tween the timescales. Within the resources delineated by a recovery graph, their
routing and the forwarding time-scales. Their goal is to select dynamically, goal is to dynamically select the protection path(s) that the upcoming
within the resources delineated by a recovery graph, the protection path(s) that packets of a DetNet flow shall follow. As they influence the path for the
the upcoming packets of a DetNet flow shall follow. As they influence the path entirety of the flows or a portion of them, the RAW Network Plane operations
for entire or portion of flows, the RAW Network Plane operations may affect the may
metrics used in their rerouting decision, which could potentially lead to oscill affect the metrics used in their rerouting decisions, which could
ations; such effects must be avoided or dampened. potentially lead to oscillations; such effects must be avoided or dampened.
</t> </t>
</section> <!-- The RAW problem --> </section>
<section anchor="terms" numbered="true" toc="default"> <section anchor="terms" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>RAW reuses terminology defined for DetNet in the <xref target="RFC8655"> <!-- [rfced] Will readers know what "IETF art of Protection" is? Also, is a
"Deterministic Networking Architecture"</xref>, e.g., PREOF for Packet reference needed in this sentence?
Replication, Elimination and Ordering Functions. RAW inherits and augments
the IETF art of Protection as seen in DetNet and Traffic Engineering. Original:
RAW inherits and
augments the IETF art of Protection as seen in DetNet and Traffic
Engineering.
-->
<t>RAW reuses terminology defined for DetNet in "Deterministic Networking
Architecture" <xref target="RFC8655"/>, e.g., "PREOF" to stand for "Packet
Replication, Elimination, and Ordering Functions". RAW inherits and
augments the IETF art of protection as seen in DetNet and Traffic
Engineering.
</t> </t>
<t>RAW reuses terminology defined for Operations, Administration, and Mainte <t>RAW also reuses terminology defined for Operations, Administration, and
nance (OAM) protocols Maintenance (OAM) protocols in Section <xref target="RFC9551" sectionFormat=
in Section 1.1 of the <xref target="RFC9551"> "Framework of OAM for DetNet" < "bare"
/xref> and section="1.1"/> of "Framework of Operations, Administration, and Maintenance
<xref target="RFC7799">"Active and Passive Metrics and Methods (with Hybrid T (OAM) for Deterministic Networking (DetNet)" <xref target="RFC9551"/> and in
ypes In-Between)" </xref>. "Active and Passive
Metrics and Methods (with Hybrid Types In-Between)" <xref
target="RFC7799"/>.
<!-- <!-- [rfced] For clarity, we have replaced the comma in the text below with
<xref target="I-D.ietf-opsawg-oam-characterization">"Guidelines for Character "for". Please review to ensure this update does not change your meaning.
izing OAM"</xref>
provides additional semantics of the terms Active, Passive, Hybrid, and In-Pa Original:
cket OAM that are consistent with
<xref target="RFC7799"/>. It also warns about potential inconsistencies in t RAW also reuses terminology defined for MPLS in [RFC4427] such as the
he way the terms "in-band" and "out-of-band" are used across the IETF; the DetNe term recovery as covering both Protection and Restoration, a number
t reference for those terms is <xref target="RFC9551"/>. of recovery types.
Current:
RAW also reuses terminology defined for MPLS in [RFC4427] such as the
term "recovery" to cover both protection and restoration for a number
of recovery types.
-->
-->
</t> </t>
<t> <t>
RAW also reuses terminology defined for MPLS in <xref target= RAW also reuses terminology defined for MPLS in <xref target="RFC4427"
"RFC4427" format="default"/> such as the term recovery as covering format="default"/>, such as the term "recovery" to cover both protection
both Protection and Restoration, a number of recovery types. and restoration for a number of recovery types. That document defines a
That document defines a number of concepts such as recovery domain that are number of concepts, such as the recovery domain, that are used in RAW
used in the RAW mechanisms, and defines the new term recovery graph. mechanisms and defines the new term "recovery graph". A recovery graph
A recovery graph associates a topological graph with usage metadata that associates a topological graph with usage metadata that represents how the
represents how the paths are built and used within the recovery graph. paths are built and used within the recovery graph. The recovery graph
The recovery graph provides excess bandwidth for the intended traffic over a provides excess bandwidth for the intended traffic over alternate
lternate potential paths, and potential paths, and the use of that bandwidth is optimized dynamically.
the use of that bandwidth is optimized dynamically.
</t> </t>
<t> <t>
RAW also reuses terminology defined for RSVP-TE in <xref target= RAW also reuses terminology defined for RSVP-TE in <xref target=
"RFC4090" format="default"/> such as the Point of Local Repair (PLR). "RFC4090" format="default"/>, such as the "Point of Local Repair (PLR)".
The concept of backup path is generalized with protection path, which is the The concept of a backup path is generalized with protection path, which is t
he
term mostly found in recent standards and used in this document. term mostly found in recent standards and used in this document.
</t> </t>
<t> <t>
RAW also reuses terminology defined for 6TiSCH in <xref target= RAW also reuses terminology defined for 6TiSCH in <xref target=
"RFC9030" format="default"/> and equates the 6TiSCH concept of a Track with "RFC9030" format="default"/> and equates the 6TiSCH concept of a Track with
that of a recovery graph. that of a recovery graph.
</t> </t>
<!-- [rfced] This sentence appears at the end of Section 3. Please review the
placement, and let us know if this should be added to (or moved to
follow) the third paragraph in Section 3, which also discusses recovery graphs.
Original:
The concept of recovery graph is agnostic to the underlying
technology and applies but is not limited to any full or partial
wireless mesh. 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 and control the individual
hops.
-->
<t> <t>
The concept of recovery graph is agnostic to The concept of a recovery graph is agnostic to
the underlying technology and applies but is not limited to any full or 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>
<!-- [rfced] Section 3.1: If no objections, we will update this section to use
<dl> instead of a separate subsection for each abbreviation. Note that
this aligns with the format used in draft-ietf-roll-dao-projection-40
(also part of Cluster 538) and is more typical in the RFC Series.
-->
<section><name>Abbreviations</name>
<t> <t>
RAW uses the following terminology and acronyms: RAW uses the following abbreviations.
</t> </t>
<section><name>Acronyms</name>
<section><name>ARQ</name> <section><name>ARQ</name>
<t> <t>
Automatic Repeat Request, a well-known mechanism, enabling an acknowledged Automatic Repeat Request. A well-known mechanism that enables an acknowledged
transmission with retries to mitigate errors and loss. ARQ may be transmission with retries to mitigate errors and loss. ARQ may be
implemented at various layers in a network. ARQ is typically implemented at implemented at various layers in a network. ARQ is typically implemented
Layer-2, per hop and not end-to-end in wireless networks. ARQ improves per hop (not end to end) at Layer 2 in wireless networks. ARQ improves
delivery on lossy wireless. Additionally, ARQ retransmission may be further delivery on lossy wireless. Additionally, ARQ retransmission may be further
limited by a bounded time to meet end-to-end packet latency constraints. limited by a bounded time to meet end-to-end packet latency constraints.
Additional details and considerations for ARQ are detailed in Additional details and considerations for ARQ are detailed in
<xref target="RFC3366"/>. <xref target="RFC3366"/>.
</t> </t>
</section> </section>
<section><name>FEC</name> <section><name>FEC</name>
<t> <t>
Forward Error Correction, adding redundant data to protect against a partial Forward Error Correction. Adding redundant data to protect against a partial
loss without retries. loss without retries.
</t> </t>
</section> </section>
<section><name>HARQ</name> <section><name>HARQ</name>
<t> <t>
Hybrid ARQ, combining FEC and ARQ. Hybrid ARQ. A combination of FEC and ARQ.
</t> </t>
</section> </section>
<section><name>ETX</name> <section><name>ETX</name>
<t> <t>
Expected Transmission Count: a statistical metric that represents the expect Expected Transmission Count. A statistical metric that represents the
ed total number of packet transmissions (including retransmissions) required to expected total number of packet transmissions (including retransmissions)
successfully deliver a packet along a path, used by 6TiSCH <xref target="RFC6551 required to successfully deliver a packet along a path, used by 6TiSCH
"/>. <xref target="RFC6551"/>.
</t> </t>
</section> </section>
<section><name>ISM</name> <section><name>ISM</name>
<t> <t>
Industrial, Scientific, and Medical. Refers to a
The industrial, scientific, and medical (ISM) radio band refers to a group o group of radio bands or parts of the radio spectrum (e.g., 2.4 GHz and 5
f radio bands or parts of the radio spectrum (e.g., 2.4 GHz and 5 GHz) that are GHz) that are internationally reserved for the use of radio frequency (RF)
internationally reserved for the use of radio frequency (RF) energy intended for energy intended for industrial, scientific, and medical requirements (e.g.,
scientific, medical, and industrial requirements, e.g., by microwaves, depth ra by microwaves, depth radars, and medical diathermy
dars, and medical diathermy machines. Cordless phones, Bluetooth and LoWPAN devi machines). Cordless phones, Bluetooth and Low-Power Wireless Personal Area N
ces, near-field communication (NFC) devices, garage door openers, baby monitors, etwork (LoWPAN) devices, near-field
and Wi-Fi networks may all use the ISM frequencies, although these low-power tr communication (NFC) devices, garage door openers, baby monitors, and Wi-Fi
ansmitters are not considered to be ISM devices. In general, communications equi networks may all use the ISM frequencies, although these low-power
pment operating in ISM bands must tolerate any interference generated by ISM app transmitters are not considered to be ISM devices. In general,
lications, and users have no regulatory protection from ISM device operation in communications equipment operating in ISM bands must tolerate any
these bands. interference generated by ISM applications, and users have no regulatory
protection from ISM device operation in these bands.
</t> </t>
</section> </section>
<section><name>PER and PDR</name> <section><name>PER</name>
<t> <t>
Packet Error Rate. The ratio of the number of
packets received in error to the total number of transmitted packets. A
packet is considered to be in error if even a single bit within the packet
is received incorrectly.</t>
</section>
The Packet Error Rate (PER) is defined as the ratio of the number of packets <section><name>PDR</name>
received in error to the total number of transmitted packets. A packet is consi <t>Packet Delivery Ratio (PDR). The ratio of the number of
dered to be in error if even a single bit within the packet is received incorrec successfully delivered data packets to the total number of
tly. In contrast, the Packet Delivery Ratio (PDR) indicates the ratio of the num packets transmitted from the sender to the receiver.</t>
ber successful delivery of data packets to the total number of transmitted pack
ets from the sender to the receiver.
</t>
</section> </section>
<section><name>RSSI</name> <section><name>RSSI</name>
<t> <t>
Received Signal Strength Indication (a.k.a. Energy Detection Level): a measu re of incoherent (raw) RF power in a channel. The RF power can come from any sou rce: other transmitters using the same technology, other radio technology using the same band, or background radiation. For a single-hop, RSSI may be used for L QI. Received Signal Strength Indication. Also known as "Energy Detection Level". A measure of the incoherent (raw) RF power in a channel. The RF power can come from any source: other transmitters using the same technology, other radio techn ology using the same band, or background radiation. For a single hop, RSSI may b e used for LQI.
</t> </t>
</section> </section>
<section><name>LQI</name> <section><name>LQI</name>
<t> <t>
Link Quality Indicator. An indication of the quality of the data packets rec
The link quality indicator (LQI) is an indication of the quality of the data eived by the receiver.
packets received by the receiver. It is typically derived from packet error statistics, with the exact method
It is typically derived from packet error statistics, the exact method depen depending on the network stack being used.
ding on the network stack being used.
LQI values may be exposed to the controller plane for each individual hop or cumulated along segments. LQI values may be exposed to the controller plane for each individual hop or cumulated along segments.
Outgoing LQI values can be calculated from coherent (demodulated) PER, RSSI and incoming LQI values. Outgoing LQI values can be calculated from coherent (demodulated) PER, RSSI, and incoming LQI values.
</t> </t>
</section> </section>
<section><name>OAM</name> <section><name>OAM</name>
<t> <t>
OAM stands for Operations, Administration, and Maintenance, and Operations, Administration, and Maintenance. Covers the processes,
covers the processes, activities, tools, and standards involved activities, tools, and standards involved with operating, administering,
with operating, administering, managing, and maintaining any managing, and maintaining any system. This document uses the term
system. This document uses the terms Operations, Administration, in conformance with "Guidelines for the Use of the 'OAM' Acronym in the IE
and Maintenance, in conformance with the <xref target="RFC6291"> TF" <xref
'Guidelines for the Use of the "OAM" Acronym in the IETF'</xref> target="RFC6291"/>, and the system observed by the RAW OAM is the
and the system observed by the RAW OAM is the recovery graph. recovery graph.
</t> </t>
</section> </section>
<section><name>OODA</name> <section><name>OODA</name>
<t> <t>
OODA (Observe, Orient, Decide, Act) is a generic formalism to represent the Observe, Orient, Decide, Act. A generic formalism to represent the
operational steps in a Control Loop. In the context of RAW, OODA is applied operational steps in a Control Loop. In the context of RAW, OODA is
to network applied to network control and convergence; see <xref
control and convergence, more in <xref target="ooda"/>. target="ooda"/> for more.
</t> </t>
</section> </section>
<section><name>SNR</name> <section><name>SNR</name>
<t> <t>
Signal-Noise Ratio (a.k.a. S/N): a measure used in science and engineering t Signal-to-Noise Ratio. Also known as "S/N Ratio". A measure used in science
hat compares the level of a desired signal to the level of background noise. SNR and engineering that compares the level of a desired signal to the level
is defined as the ratio of signal power to noise power, often expressed in deci of background noise. SNR is defined as the ratio of signal power to noise
bels. power, often expressed in decibels.
</t> </t>
</section> </section>
</section>
</section><!--Acronyms--> <!-- [rfced] May we update these section titles to use the plural "Links" and
"Paths"?
Original:
3.2. Link and Direction
3.3. Path and Recovery Graphs
Perhaps:
3.2. Links and Direction
3.3. Paths and Recovery Graphs
-->
<!-- [rfced] Introductory text
a) Sections 3.4 and 3.5 contain introductory sentences. We have updated them
as shown below. Please let us know any concerns.
Original:
This document reuses the terminology in section 2 of [RFC8557] and
section 4.1.2 of [DetNet-ARCHI] for deterministic networking and
deterministic networks.
...
In the context of the RAW work, Reliability and Availability are
defined as follows:
Current:
This document reuses the terminology in Section 2 of [RFC8557] and
in Section 4.1.2 of [DetNet-ARCHI] for deterministic networking and
deterministic networks. This document also uses the following terms.
...
This document uses the following terms relating to reliability and
availability in the context of the RAW work.
b) Should Sections 3.2 and 3.3 contain similar introductory sentences? If so,
please provide the text.
Perhaps:
This document uses the following terms relating to links and direction
in the context of RAW.
...
This document uses the following terms relating to paths and recovery graphs
in the context of RAW.
-->
<section><name>Link and Direction</name> <section><name>Link and Direction</name>
<section><name>Flapping</name> <section><name>Flapping</name>
<!-- [rfced] Will "a subsecond to seconds duration" be clear to readers?
Original:
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 subsecond to seconds duration.
Perhaps:
In the context of RAW, a link flaps when the reliability of the
wireless connectivity drops abruptly for a short period of time,
typically a duration of a subsecond or a second.
-->
<t> <t>
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
subsecond to seconds duration. a duration of a subsecond to seconds.
</t> </t>
</section> </section>
<section><name>Uplink</name> <section><name>Uplink</name>
<t> <t>
Connection from end-devices to data communication equipment. In the An uplink is the connection from end devices to data communication equipmen t. In the
context of wireless, uplink refers to the connection between a station context of wireless, uplink refers to the connection between a station
(STA) and a controller (AP) or a User Equipment (UE) to a Base Station (BS) (STA) and a controller (AP) or a User Equipment (UE) and a Base Station (BS
such as a 3GPP 5G gNodeB (gNb). )
such as a 3GPP 5G gNodeB (gNB).
</t> </t>
</section> </section>
<section><name>Downlink</name> <section><name>Downlink</name>
<t> <t>
The reverse direction from uplink. A downlink is the reverse direction from uplink.
</t> </t>
</section> </section>
<section><name>Downstream</name> <section><name>Downstream</name>
<t> <t>
Following the direction of the flow data path along a recovery graph. Downstream refers to the following the direction of the flow data path alon g a recovery graph.
</t> </t>
</section> </section>
<section><name>Upstream</name> <section><name>Upstream</name>
<t> <t>
Against the direction of the flow data path along a recovery graph. Upstream refers to going against the direction of the flow data path along a recovery graph.
</t> </t>
</section> </section>
</section><!-- Link and Direction --> </section>
<section anchor="pt"><name>Path and Recovery Graphs</name> <section anchor="pt"><name>Path and Recovery Graphs</name>
<section><name>Path</name> <section><name>Path</name>
<t> <t>
Quoting section 1.1.3 of <xref target="RFC1122"/>:
<!-- [rfced] FYI - We updated the direct quotes in Section 3.3.1 to exactly
match the text in Section 1.3.3 of [INT-ARCHI] and Section 2 of
[RFC9473].
-->
<xref target="RFC1122" section="1.3.3"/> provides a definition of Path:
</t> </t>
<blockquote> <blockquote>
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>
Section 2 of <xref target="RFC9473"/> points to a <xref target="RFC9473" section="2"/> 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>
<t> <t>
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><t>
Paths are unidirectional and time-dependent, i.e., there can be a Paths are unidirectional and time dependent, i.e., there can be a
variety of paths from one node to another, and the path over which variety of paths from one node to another, and the path over which
packets are transmitted may change. A path definition can be packets are transmitted may change. A path definition can be strict
fixed (i.e., the exact sequence of path elements remains the (i.e., the exact sequence of path elements remains the same) or loose
same) or mutable (i.e., the start and end node remain the same, but (i.e., the start and end node remain the same, but the path elements
the path elements between them may vary over time). between them may vary over time).
</t><t> </t><t>
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>
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->C->E->D->B and
A->C->F->D->B. Those paths are called protection paths. Protection A->C->F->D->B. Those paths are called protection paths. Protection
paths may be fully non-congruent, and alternatively may intersect at 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> 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>
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"><name>Recovery Graph</name>
<t>A networking graph that can be followed to transport packets with <!-- [rfced] Section 3.3.2: Please clarify "represents not an actual but a
equivalent treatment, associated with usage metadata; as opposed to the potential" in this text.
definition of a path above, a recovery graph represents not an actual but a
potential, it is not necessarily a linear sequence like a simple path, and Original:
is not
necessarily fully traversed (flooded) by all packets of a flow like a DetNet A networking graph that can be followed to transport packets with
Path. Still, and as a simplification, the casual reader may consider that a equivalent treatment, associated with usage metadata; as opposed to
recovery graph is very much like a DetNet path, aggregating multiple paths t the definition of a path above, a recovery graph represents not an
hat may actual but a potential, it is not necessarily a linear sequence like
overlap, fork and rejoin, for instance to enable a protection service by the a simple path, and is not necessarily fully traversed (flooded) by
PREOF operations. all packets of a flow like a DetNet Path.
Perhaps:
A recovery graph is a networking graph that can be followed to transport pack
ets with
equivalent treatment and is associated with usage metadata. In contrast to
the definition of a path above, a recovery graph represents a
potential path, not an actual one. Also, a recovery graph is not necessarily
a
linear sequence like
a simple path and is not necessarily fully traversed (flooded) by
all packets of a flow like a DetNet Path.
-->
<t>A recovery graph is a networking graph that can be followed to
transport packets with equivalent treatment and is associated with usage
metadata. In contrast to the definition of a path above,
a recovery graph represents not an actual but a potential, is not
necessarily a linear sequence like a simple path, and is not necessarily
fully traversed (flooded) by all packets of a flow like a DetNet
Path. Still, and as a simplification, the casual reader may consider that
a recovery graph is very much like a DetNet path, aggregating multiple
paths that may overlap or fork and then rejoin, for instance, to enable a
protection service by the PREOF operations.
</t> </t>
<figure anchor="Figtrk"> <figure anchor="Figtrk">
<name>Example IoT Recovery Graph to an IoT Gateway with 1+1 Redundancy </name> <name>Example IoT Recovery Graph to an IoT Gateway with 1+1 Redundancy </name>
<artwork align="center" name="" type="" alt=""> <artwork align="center" name="" type="" alt=""><![CDATA[
<![CDATA[
_________ _________
| | | |
| IoT G/W | | IoT G/W |
|_________| |_________|
EGRESS <<=== Elimination at Egress EGRESS <<=== Elimination at Egress
| | | |
---+--------+--+--------+-------- ---+--------+--+--------+--------
| Backbone | | Backbone |
__|__ __|__ __|__ __|__
| | Backbone | | Backbone | | Backbone | | Backbone
|__ __| Router |__ __| Router |__ __| Router |__ __| Router
| # | | # |
# \ # / <-- protection path # \ # / <-- protection path
# # #-------# # # #-------#
\ # / # ( Low-power ) \ # / # ( Low-power )
# # \ / # ( Lossy Network) # # \ / # ( Lossy Network)
\ / \ /
# INGRESS <<=== Replication at recovery graph Ingress # INGRESS <<=== Replication at recovery graph Ingress
| |
# <-- source device # <-- source device
#: Low-power device
]]></artwork>
</figure>
#: Low-power device <!-- [rfced] Is "coalescence of the collection" redundant? Also, how may we
revise "for which a flow is assigned to the recovery graph" to improve
clarity?
]]> Original:
</artwork> Refining further, a recovery graph is defined as the coalescence of
</figure> the collection of all the feasible DetNet Paths that a packet for
which a flow is assigned to the recovery graph may be forwarded
along.
<t> Perhaps:
Refining further, a recovery graph is defined as the coalescence of
all the feasible DetNet Paths that a packet with an assigned flow
may be forwarded along.
-->
<t>
Refining further, a recovery graph is defined as the coalescence of the coll ection Refining further, a recovery graph is defined as the coalescence of the coll ection
of all the feasible DetNet Paths that a packet for which a flow is assigned to the of all the feasible DetNet Paths that a packet for which a flow is assigned to the
recovery graph may be forwarded along. recovery graph may be forwarded along.
A packet that is assigned to the recovery graph experiences one of the feasi ble A packet that is assigned to the recovery graph experiences one of the feasi ble
DetNet Paths based on the current selection by the PLR at the time the DetNet Paths based on the current selection by the PLR at the time the
packet traverses the network. packet traverses the network.
</t> </t>
<t> <t>
Refining even further, the feasible DetNet Paths within the recovery graph m ay or may 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 not be computed in advance; instead, they may be 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 aph. capable of reporting which is the current DetNet Path within the recovery gr aph.
</t> </t>
<t> <t>
In DetNet <xref target="RFC8655"/> terms, a recovery graph has the following In DetNet <xref target="RFC8655"/> terms, a recovery graph has the following
properties: properties:
</t> </t>
<ul> <ul>
<li> <li>
A recovery graph is a Layer-3 abstraction built upon IP links between router 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><li>
A recovery graph has one Ingress and one Egress node, which operate as DetNe t Edge A recovery graph has one Ingress and one Egress node, which operate as DetNe t Edge
nodes. nodes.
</li><li> </li><li>
<!-- [rfced] The bulleted list in Section 3.3.2 lists the properties of a
recovery graph. We have the following questions.
a) Is "graph of a recovery graph" correct here?
Original:
* The graph of a recovery graph is reversible, meaning that packets
can be routed against the flow of data packets, e.g., to carry OAM
measurements or control messages back to the Ingress.
Perhaps:
* A recovery graph is reversible, meaning that packets
can be routed against the flow of data packets, e.g., to carry OAM
measurements or control messages back to the Ingress.
b) In the first bullet below, should "that graph" be updated to "a recovery
graph"? In the second bullet below, should "of the graph" be updated to "of a
recovery graph"? Or is the current correct in both instances?
Original:
* The vertices of that graph are DetNet Relay Nodes that operate at
the DetNet Service sub-layer and provide the PREOF functions.
* The topological edges of the graph are strict sequences of DetNet
Transit nodes that operate at the DetNet Forwarding sub-layer.
Perhaps:
* The vertices of a recovery graph are DetNet Relay Nodes that operate at
the DetNet Service sub-layer and provide the PREOF functions.
* The topological edges of a recovery graph are strict sequences of DetNet
Transit nodes that operate at the DetNet Forwarding sub-layer.
-->
The graph of a recovery graph is reversible, meaning that packets can be rou ted against 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 the flow of data packets, e.g., to carry OAM measurements or control
messages back to the Ingress. messages back to the Ingress.
</li><li> </li><li>
The vertices of that graph are DetNet Relay Nodes that operate at the The vertices of that graph are DetNet Relay Nodes that operate at the
DetNet Service sub-layer and provide the PREOF functions. DetNet Service sub-layer and provide the PREOF functions.
</li><li> </li><li>
The topological edges of the graph are strict sequences of DetNet Transit The topological edges of the graph are strict sequences of DetNet Transit
nodes that operate at the DetNet Forwarding sub-layer. nodes that operate at the DetNet Forwarding sub-layer.
</li> </li>
</ul> </ul>
<t> <t>
<xref target='TRK'/> illustrates the generic concept of a recovery graph, <xref target='TRK'/> illustrates the generic concept of a recovery graph,
between an Ingress Node and an Egress Node. between an Ingress Node and an Egress Node.
The recovery graph is composed of forward protection paths and forward or cr The recovery graph is composed of forward protection paths, forward Segments
ossing , and crossing
Segments (see the definition for those terms in the next sections). Segments (see the definitions of those terms in the next sections).
The recovery graph contains at least 2 protection paths as a main path and a The recovery graph contains at least two protection paths: a main path and a
backup path. backup path.
</t> </t>
<figure anchor='TRK'><name>A Recovery Graph and its Components</name>
<artwork align="center"><![CDATA[
<!-- [rfced] FYI - For Figure 3, we moved the information about the segments
and paths out of the figure.
-->
<figure anchor='TRK'><name>A Recovery Graph and Its Components</name>
<artwork align="center"><![CDATA[
------------------- forward direction ----------------------> ------------------- forward direction ---------------------->
a ==> b ==> C -=- F ==> G ==> h T1 I: Ingress a ==> b ==> C -=- F ==> G ==> h T1
/ \ / | \ / E: Egress / \ / | \ /
I o n E -=- T2 T1, T2, T3: I o n E -=- T2
\ / \ | / \ External \ / \ | / \
p ==> q ==> R -=- T ==> U ==> v T3 Targets p ==> q ==> R -=- T ==> U ==> v T3
I: Ingress
E: Egress
T1, T2, T3: external targets
Uppercase: DetNet Relay Nodes Uppercase: DetNet Relay Nodes
Lowercase: DetNet Transit 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
I, p, q, R, o, F, G, h, E : segment-crossing protection path
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Of note:</t>
<dl newline="false" spacing="normal">
<dt>I ==> a ==> b ==> C:</dt><dd>A forward Segment to targets F and o</dd>
<dt>C ==> o ==> T:</dt><dd>A forward Segment to target T (and/or U)</dd>
<dt>G | n | U:</dt><dd>A crossing Segment to targets G or U</dd>
<dt>I -> F -> E:</dt><dd>A forward protection path to targets T1, T2, and T3</
dd>
<dt>I, a, b, C, F, G, h, E:</dt><dd>A path to T1, T2, and/or T3</dd>
<dt>I, p, q, R, o, F, G, h, E:</dt><dd>A segment-crossing protection path</dd>
</dl>
</section> </section>
<section><name>Forward and Crossing</name> <section><name>Forward and Crossing</name>
<t> <t>
Forward refers to progress towards the recovery graph Egress. Forward links are 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><name>Protection Path</name>
<t> <t>
An end-to-end forward path between the Ingress and Egress Nodes of a 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"/> and <xref target="RFC6378"/> target="RFC4427"/> and <xref target="RFC6378"/>.
</t> </t>
</section> </section>
<section><name>Segment</name> <section><name>Segment</name>
<t> <t>
A strict sequence of DetNet Transit nodes between 2 DetNet Relay Nodes; a 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 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><!--Path and recovery graphs--> </section>
<section><name>Deterministic Networking</name> <section><name>Deterministic Networking</name>
<t>This document reuses the terminology in section 2 of <t>This document reuses the terminology in
<xref target="RFC8557"/> and section 4.1.2 of <xref target="RFC8655"/> <xref target="RFC8557" section="2"/> and <xref target="RFC8655" section="4.1
for deterministic networking and deterministic networks. .2"/>
for deterministic networking and deterministic networks. This documents also
uses the following terms.
</t> </t>
<section><name>The DetNet Planes</name> <section><name>The DetNet Planes</name>
<t> <t>
<xref target="RFC8655"/> defines three planes: the Application (User) Plane, the Controller Plane, <xref target="RFC8655"/> 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
to the next DetNet system. For more information, see <xref target='problem'/>
.
</t> </t>
</section> </section>
<section><name>Flow</name> <section><name>Flow</name>
<t> <t>
A collection of consecutive IP packets defined by the upper layers and A flow is a collection of consecutive IP packets defined by the upper layers
signaled by the same 5 or 6-tuple (see section 5.1 of and
<xref target="RFC8939"/>). Packets of the same flow must be placed signaled by the same 5-tuple or 6-tuple (see
<xref target="RFC8939" section="5.1"/>). Packets of the same flow must be pl
aced
on the same recovery graph to receive an equivalent treatment from Ingress t o Egress 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><name>Residence Time</name> <section><name>Residence Time</name>
<t> <t>
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> </t>
</section> </section>
<section><name>L3 Deterministic Flow Identifier </name> <section><name>L3 Deterministic Flow Identifier </name>
<!-- [rfced] FYI - To improve clarity, we moved the first sentence below to a
parenthetical within the second sentence. Please let us know any
objections.
Original:
See section 3.3 of [DetNet-DP]. The classic IP 5-tuple that
identifies a flow comprises the source IP, destination IP, source
port, destination port, and the upper layer protocol (ULP). DetNet
uses a 6-tuple where the extra field is the DSCP field in the packet.
The IPv6 flow label is not used for that purpose.
Perhaps:
The classic IP 5-tuple that
identifies a flow comprises the source IP, destination IP, source
port, destination port, and the Upper-Layer Protocol (ULP). DetNet
uses a 6-tuple where the extra field is the Differentiated Services
Code Point (DSCP) field in the packet (see Section 3.3 of [DetNet-DP]).
The IPv6 flow label is not used for that purpose.
-->
<t> <t>
See section 3.3 of <xref target="RFC8938"/>. The classic IP 5-tuple that The classic IP 5-tuple that
identifies a flow comprises the source IP, destination IP, source port, identifies a flow comprises the source IP, destination IP, source port,
destination port, and destination port, and
the upper layer protocol (ULP). DetNet uses a 6-tuple where the extra field the Upper-Layer Protocol (ULP). DetNet uses a 6-tuple where the extra field
is the DSCP field in the packet. The IPv6 flow label is not used for that is the Differentiated Services Code Point (DSCP) field in the packet (see <
xref target="RFC8938" section="3.3"/>). The IPv6 flow label is not used for that
purpose. purpose.
</t> </t>
</section> </section>
<section><name>TSN</name> <section><name>Time-Sensitive Networking</name>
<t>
TSN stands for Time-Sensitive Networking and denotes the efforts at IEEE <!-- [rfced] Updates to Section 3.4.5
a) We made some updates to this sentence (see Current text below). Would
adding a citation to [TSN] also be helpful here (see Perhaps text below)?
Also, please review "the efforts at IEEE 802"? Is the intended meaning "the
IEEE efforts"?
Original:
3.4.5. TSN
TSN stands for Time-Sensitive Networking and denotes the efforts at
IEEE 802 for deterministic networking, originally for use on
Ethernet.
Current:
3.4.5. Time-Sensitive Networking
Time-Sensitive Networking (TSN) denotes the efforts at IEEE 802 regarding
for deterministic networking, originally for use on
Ethernet. See [TSN].
Perhaps:
3.4.5. Time-Sensitive Networking
Time-Sensitive Networking (TSN) denotes the IEEE efforts regarding
for deterministic networking, originally for use on
Ethernet. See [TSN].
b) May we update "the selected RAW technologies [RAW-TECHNOS]" as follows? Or
is another meaning intended?
Original:
Wireless TSN (WTSN) denotes extensions of the TSN work on
wireless media such as the selected RAW technologies [RAW-TECHNOS].
Perhaps:
Wireless TSN (WTSN) denotes extensions of the TSN work on
wireless media, such as the RAW technologies described in [RAW-TECHNOS].
-->
<t>
Time-Sensitive Networking (TSN) denotes the efforts at IEEE
802 for deterministic networking, originally for use on Ethernet. Wireless 802 for deterministic networking, originally for use on Ethernet. Wireless
TSN (WTSN) denotes extensions of the TSN work on wireless media such as TSN (WTSN) denotes extensions of the TSN work on wireless media such as
the selected RAW technologies <xref target="I-D.ietf-raw-technologies"/>. the selected RAW technologies <xref target="RFC9913"/>.
</t> </t>
</section> </section>
<section><name>Lower-Layer API</name> <section><name>Lower-Layer API</name>
<t> <t>
In addition, RAW includes the concept of a lower-layer API (LL RAW includes the concept of a lower-layer API (LL
API), that provides an interface between the API) that provides an interface between the
lower layer (e.g., wireless) technology and the DetNet layers. The LL API is 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), PHY rate
other Modulation Coding Scheme (MCS) adaptation, coding and retransmissions m and other Modulation Coding Scheme (MCS) adaptation, coding and
ethods, constructive retransmissions methods, and constructive interference and overhearing;
interference and overhearing, see <xref target="I-D.ietf-raw-technologies"/> see <xref target="RFC9913"/> for more details).
for 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"/> <xref target="RFC8175"/> is an
an example of a protocol that can be used to implement the LL API.
example protocol that can be used to implement the LL API.
</t> </t>
</section> </section>
</section><!--Deterministic Networking --> </section>
<section><name>Reliability and Availability</name> <section><name>Reliability and Availability</name>
<t> <t>This document uses the following terms relating to reliability and
In the context of the RAW work, Reliability and Availability are defined as availability in the context of the RAW work.
follows: </t>
</t>
<!-- [rfced] This sentence is difficult to parse. How does "the application
flow" connect to the rest of the sentence?
Original:
In the context of RAW, an SLA (service level agreement) is a contract
between a provider (the network) and a client, the application flow,
defining measurable metrics such as latency boundaries, consecutive
losses, and packet delivery ratio (PDR).
Perhaps:
In the context of RAW, a Service Level Agreement (SLA) is a contract
between a provider (the network) and a client that defines the application fl
ow
and measurable metrics such as latency boundaries, consecutive
losses, and Packet Delivery Ratio (PDR).
Or:
In the context of RAW, a Service Level Agreement (SLA) is a contract
between a provider (the network) and a client (the application flow) that def
ines
measurable metrics such as latency boundaries, consecutive
losses, and Packet Delivery Ratio (PDR).
-->
<section><name>Service Level Agreement</name> <section><name>Service Level Agreement</name>
<t> <t>
In the context of RAW, an SLA (service level agreement) is a contract In the context of RAW, a Service Level Agreement (SLA) is a contract
between a provider (the network) and a client, the application flow, between a provider (the network) and a client, the application flow,
defining measurable metrics such as latency boundaries, consecutive losses, defining measurable metrics such as latency boundaries, consecutive losses,
and packet delivery ratio (PDR). and Packet Delivery Ratio (PDR).
</t> </t>
</section> </section>
<section><name>Service Level Objective</name> <section><name>Service Level Objective</name>
<t> <t>
A service level objective (SLO) is one term in the SLA, for which specific 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><name>Service Level Indicator</name> <section><name>Service Level Indicator</name>
<!-- [rfced] Will "losses in a row as time series" be clear to readers?
Original:
It can be for instance, the statistics of
individual losses and losses in a row as time series.
Perhaps:
For instance, it can be the statistics of
individual losses or losses in a row during a certain amount of time.
-->
<t> <t>
A service level indicator (SLI) measures the compliance of an SLO to the A Service Level Indicator (SLI) measures the compliance of an SLO to the
terms of the contract. It can be for instance, the statistics of individual terms of the contract. For instance, it can be the statistics of individual
losses and losses in a row as time series. losses and losses in a row as time series.
</t> </t>
</section> </section>
<section><name> Precision Availability Metrics</name> <section><name>Precision Availability Metrics</name>
<t> <t>
Precision Availability Metrics (PAMs) <xref target="RFC9544"/> aim Precision Availability Metrics (PAMs) <xref target="RFC9544"/> aim
at capturing service levels for a flow, specifically the degree to which 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><name>Reliability</name>
<t> <t>
Reliability is a measure of the probability that an item (e.g., system, 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"/>.
</t> </t>
</section> </section>
<section><name>Availability</name> <section><name>Availability</name>
<!-- [rfced] This sentence may be difficult to read because of the
parentheticals. Also, does the text starting with "an uptime
state..." refer to availability or mission readiness? Please review.
Original:
Availability is the probability of an items (e.g., a network's)
mission readiness (e.g., to provide an SLA), an uptime state with the
likelihood of a recoverable downtime state.
Perhaps:
Availability is the probability of an item's
mission readiness (e.g., probability of a network to provide an SLA);
it is an uptime state with the
likelihood of a recoverable downtime state.
-->
<t> <t>
Availability is the probability of an item’s (e.g., a network’s) mission Availability is the probability of an item's (e.g., a network's)
readiness (e.g., to provide an SLA), an uptime state with the likelihood mission readiness (e.g., to provide an SLA), an uptime state with the
of a recoverable downtime state. Availability is expressed as likelihood of a recoverable downtime state.
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"/>.
</t> </t>
</section> </section>
</section><!--Reliability and Availability--> </section>
</section>
</section><!-- Terminology -->
<!-- 1111111111111111 -->
<section anchor="raw" numbered="true" toc="default"> <section anchor="raw" numbered="true" toc="default">
<name>Reliable and Available Wireless</name> <name>Reliable and Available Wireless</name>
<!-- 2222222222222222 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>High Availability Engineering Principles</name> <name>High Availability Engineering Principles</name>
<t> <t>
The reliability criteria of a critical system pervade through its elements, The reliability criteria of a critical system pervade its elements,
and if the system comprises a data network and then the data network is also and if the system comprises a data network, 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> <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>
<li>elimination of each single point of failure</li> <li>elimination of each single point of failure</li>
<li>reliable crossover</li> <li>reliable crossover</li>
<li>prompt detection of failures as they occur</li> <li>prompt detection of failures as they occur</li>
</ol> </ol>
<t> <t>
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>
<!-- 333333333333333333333 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Elimination of Single Points of Failure</name> <name>Elimination of Single Points of Failure</name>
<t> <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>
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>
<!-- [rfced] FYI - We updated these sentences as follows to improve
readability of "it is thus required to use" and "it is also required to
use". Let us know any concerns.
Original:
For high availability, it is thus required to use
physically link-disjoint and node-disjoint paths; in the wireless
space, it is also required to use the highest possible degree of
diversity (time, space, code, frequency, and channel width) in the
transmissions over the air to combat the additional causes of
transmission loss.
Perhaps:
Thus, for high availability, the use of
physically link-disjoint and node-disjoint paths is required; in the wireless
space, the use of the highest possible degree of
diversity (time, space, code, frequency, and channel width) in the
transmissions over the air is also required to combat the additional causes o
f
transmission loss.
-->
<t> <t>
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>
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>
<!--Elimination of Single Points of Failure-->
<!-- 333333333333333333333 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Reliable Crossover</name> <name>Reliable Crossover</name>
<t> <t>
Having backup equipment has a limited value unless it can be reliably Backup equipment has limited value unless it can be reliably
switched into use within the down-time parameters. switched into use within the downtime parameters.
IP Routers execute reliable crossover continuously because IP routers execute reliable crossover continuously because
the routers use any alternate routes that are available <xref target= the routers use any alternate routes that are available <xref target=
"RFC0791"/>. This is due to the stateless nature of IP datagrams and the "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"/> analyzes
mechanisms for fast failure detection and path repair for IP Fast-Reroute (F mechanisms for fast failure detection and path repair for IP Fast Reroute (F
RR), 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"/> and
backup label-switched path (LSP) tunnels for the local repair of LSP tunnels backup Label Switched Path (LSP) tunnels for the local repair of LSP tunnels
using RSVP-TE <xref target="RFC4090"/>. using RSVP-TE <xref target="RFC4090"/>.
</t> </t>
<t> <t>
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>
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-->
<!-- 333333333333333333333 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Prompt Notification of Failures</name> <name>Prompt Notification of Failures</name>
<t> <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 detected in order to direct maintenance. the end user rarely sees a failure. However, a failure that occurs must stil l be detected in order to direct maintenance.
</t> </t>
<t> <t>
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>
<t> <t>
<xref target="RFC9522"> "Overview and Principles of Internet Traffic Engineering" <xref target="RFC9
"Overview and Principles of Internet Traffic Engineering"</xref> discusses 522"/> discusses
the importance of measurement for network protection, and provides an 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> <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"/>.
</t> </t>
</section> </section>
<!--Prompt Notification of Failures-->
</section> </section>
<!--Reliability Engineering-->
<!-- 22222222222222222222 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Applying Reliability Concepts to Networking</name> <name>Applying Reliability Concepts to Networking</name>
<t> <t>
The terms Reliability and Availability are defined for use in RAW in The terms "reliability" and "availability" are defined for use in RAW in
<xref target="terms"/> and the reader is invited to read <xref target="terms"/>, and the reader is invited to read
<xref target="NASA1"/> and <xref target="NASA2"/> <xref target="NASA1"/> and <xref target="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>
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>
<!-- [rfced] FYI - To make this text easier to read and understand, we updated
the "e.g., using redundancy..." phrase to be two separate sentences. Please
review and let us know any objections.
Original:
Packet loss cannot be fully avoided and the systems are built to resist
some loss, e.g., using redundancy with Retries (as in HARQ), Packet
Replication and Elimination (PRE) FEC, Network Coding (e.g., using FEC with
SCHC [RFC8724] fragments), or, in a typical control loop, by linear
interpolation from the previous measurements.
Perhaps:
Packet loss cannot be fully
avoided, and the systems are built to resist some loss. This can be
done by using redundancy with retries (as in HARQ), Packet
Replication and Elimination (PRE) FEC, and Network Coding (e.g.,
using FEC with Static Context Header Compression (SCHC) [RFC8724]
fragments). Also, in a typical control loop, linear interpolation
from the previous measurements can be used.
-->
<t> <t>
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"/> f
ragments). Also, in a typical control
loop, linear interpolation from the previous measurements can be used.
</t> </t>
<t> <t>
But the linear interpolation method cannot resist multiple consecutive <!-- [rfced] Would updating the text starting with "as a guarantee that
this..." as follows make this test more clear and concise?
Original:
But the linear interpolation method cannot resist multiple
consecutive losses, and a high MTBF is desired as a guarantee that
this does not happen, in other words that the number of losses-in-
a-row can be bounded.
Perhaps:
However, the linear interpolation method cannot resist multiple
consecutive losses, and a high MTBF is desired as a guarantee that
the number of losses in a row is bounded.
-->
<!-- [rfced] The following text points to Section 5.9.5 of RFC 8175
[DLEP]; however, RFC 8175 does not have a Section 5.9.5. What section
would you like to point to?
Original:
In that case, what is really desired is a
Maximum Consecutive Loss (MCL). (See also Section 5.9.5 of [DLEP].)
-->
However, the linear interpolation method cannot resist multiple consecutive
losses, and a high MTBF is desired as a guarantee that this does not happen, losses, and a high MTBF is desired as a guarantee that this does not happen,
in other words that the number of losses-in-a-row can be bounded. In that ca in other words, that the number of losses in a row can be bounded. In this c
se, what is ase, what is
really desired is a Maximum Consecutive Loss (MCL). (See also section really desired is a Maximum Consecutive Loss (MCL). (See also
5.9.5 in <xref target="RFC8175"/>.) <xref target="RFC8175" section="5.9.5"/>.)
If the number of losses in a row passes the MCL, the control loop has to If the number of losses in a row passes the MCL, the control loop has to
abort and the system, e.g., the production line, may need to enter an abort, and the system (e.g., the production line) may need to enter an
emergency stop condition. emergency stop condition.
</t> </t>
<!-- [rfced] Will readers understand "as an MTBF as a proxy" in this sentence?
Also, please confirm that Section 7.4 of [RFC8578] is correct here. We do
not see "reliability", "MTBF", or "MCL" in that section.
Original:
Engineers that build automated processes may use the network
reliability expressed in nines as an MTBF as a proxy to indicate an
MCL, e.g., as described in section 7.4 of the "Deterministic
Networking Use Cases" [RFC8578].
Perhaps:
Engineers that build automated processes may use the network
reliability expressed in nines as the MTBF and as a proxy to indicate an
MCL, e.g., as described in Section 7.4 of the "Deterministic
Networking Use Cases" [RFC8578].
Or:
Engineers that build automated processes may use the network
reliability expressed in nines as the MTBF, which is then used as a
proxy to indicate an
MCL, e.g., as described in Section 7.4 of the "Deterministic
Networking Use Cases" [RFC8578].
-->
<t> <t>
Engineers that build automated processes may use the network reliability Engineers that build automated processes may use the network reliability
expressed in nines as an MTBF as a proxy to indicate an MCL, e.g., as expressed in nines as an MTBF as a proxy to indicate an MCL, e.g., as
described in section 7.4 of the <xref target="RFC8578">"Deterministic described in Section <xref target="RFC8578" sectionFormat="bare" section="7.
Networking Use Cases"</xref>. 4"/> of "Deterministic Networking Use Cases" <xref target="RFC8578"/>.
</t> </t>
</section> </section>
<!--Applying Reliability concepts to Networking-->
<!-- 22222222222222222222 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Wireless Effects Affecting Reliability</name> <name>Wireless Effects Affecting Reliability</name>
<t> <t>
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>
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>
<dt>Multipath Fading:</dt> <dt>Multipath fading:</dt>
<dd> <dd>
<t>A destructive interference by a reflection of the original signal. <t>A destructive interference by a reflection of the original signal.
</t> </t>
<t>A radio signal may be received directly <t>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>
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>Co-channel interference:</dt>
<dd> <dd>
<t> <t>
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>
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>Obstacle in Fresnel zone:</dt>
<dd> <dd>
<t> <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>
skipping to change at line 1075 skipping to change at line 1554
<t> <t>
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>
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>
<!-- [rfced] Please review the series in this sentences (i.e., "on diverse
radio channels... and diverse PHY technologies ... , or diverse
codes"). Should this be a series of two items or three items?
Original:
A single packet may be sent at different times (time diversity) over
diverse paths (spatial diversity) that rely on diverse radio channels
(frequency diversity) and diverse PHY technologies, e.g., narrowband
vs. spread spectrum, or diverse codes.
Perhaps (two items):
A single packet may be sent at different times (time diversity) over
diverse paths (spatial diversity) that rely either on diverse radio channels
(frequency diversity) and diverse PHY technologies (e.g., narrowband
versus spread spectrum) or on diverse codes.
Or (three items):
A single packet may be sent at different times (time diversity) over
diverse paths (spatial diversity) that rely on diverse radio channels
(frequency diversity), diverse PHY technologies (e.g., narrowband
versus spread spectrum), or diverse codes.
-->
<t> <t>
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 diverse
paths (spatial diversity) that rely on diverse radio channels (frequency paths (spatial diversity) that rely on diverse radio channels (frequency
diversity) and diverse PHY technologies, e.g., narrowband vs. spread diversity) and diverse PHY technologies (e.g., narrowband versus spread
spectrum, or diverse codes. spectrum), or diverse codes.
Using time diversity defeats short-term interferences; Using time diversity defeats short-term interferences;
spatial diversity combats very local causes of interference such as multipat h fading; spatial diversity combats very local causes of interference such as multipat h fading;
narrowband and spread spectrum are relatively innocuous to one another and narrowband and spread spectrum are relatively innocuous to one another and
can be used for diversity in the presence of the other. can be used for diversity in the presence of the other.
</t> </t>
</section> </section>
<!--Reliability in the Context of RAW-->
</section> <!-- Reliable and Available Wireless -->
<!-- 000000000000000000000 --> </section>
<section anchor="model" numbered="true" toc="default"> <section anchor="model" numbered="true" toc="default">
<name>The RAW Conceptual Model</name> <name>The RAW Conceptual Model</name>
<!-- [rfced] Is "point of local reaction" correct here? We ask because we see
"Point of Local Repair" elsewhere in the document, including in Section
6.5 (mentioned in this sentence).
Original:
The PLR (see Section 6.5) is a point of
local reaction to provide additional agility against transmission
loss.
Perhaps:
The PLR (see Section 6.5)
provides additional agility against transmission
loss.
-->
<t> <t>
RAW extends the conceptual model described in section 4 of the DetNet RAW extends the conceptual model described in Section <xref
Architecture <xref target="RFC8655"/> with the PLR at the Service sub-layer, target="RFC8655" sectionFormat="bare" section="4"/> of "Deterministic
as illustrated in <xref target='FigLayers'/>. The PLR Networking Architecture" <xref target="RFC8655"/> with the PLR at the
(see <xref target='PLRpce'/>) is a point of local reaction to Service sub-layer, as illustrated in <xref target='FigLayers'/>. The PLR
provide additional agility against transmission loss. The PLR can act, e.g., (see <xref target='PLRpce'/>) is a point of local reaction to provide
based on indications from the lower layer or based on OAM. additional agility against transmission loss. For example, the PLR can act
based on indications from the lower layer or based on OAM.
</t> </t>
<figure anchor="FigLayers"> <figure anchor="FigLayers">
<name>Extended DetNet Data-Plane Protocol Stack</name> <name>Extended DetNet Data Plane Protocol Stack</name>
<artwork align="left" name="" type="" alt=""> <artwork align="left" name="" type="" alt=""><![CDATA[
| 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 | | |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| 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="default"> <section anchor="plane" numbered="true" toc="default">
<name>The RAW Planes</name> <name>The RAW Planes</name>
<t> <t>
The RAW Nodes are DetNet Relay Nodes that operate in the RAW Network Plane an d The RAW Nodes are DetNet Relay Nodes that operate in the RAW Network Plane an 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 tes inside the Ingress RAW leverages an Operational Plane orientation function (that typically opera 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>
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">
<name>RAW Nodes (Centralized Routing Case)</name> <name>RAW Nodes (Centralized Routing Case)</name>
<artwork align="center" name="" type="" alt=""> <artwork align="center" name="" type="" alt=""><![CDATA[
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>
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 n Egress the network to build a new recovery graph between an Ingress End System and a n Egress
End System for that flow; it indicates to the RAW Nodes where the PREOF and/o r radio End System for that flow; it indicates to the RAW Nodes where the PREOF and/o 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>
<li> <li>
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>
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'/>.
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>
<!-- [rfced] How may we update "includes may be a time-aggregated (e.g.,
statistical) fashion" for clarity?
Original:
The information that the orientation function reports to the routing
function includes may be a time-aggregated, e.g., statistical
fashion, to match the longer-term operation of the routing function.
Perhaps:
The information that the orientation function reports to the routing
function may be time aggregated (e.g., statistical),
to match the longer-term operation of the routing function.
-->
<t> <t>
The information that the orientation function reports to the routing functio The information that the orientation function reports to the routing
n function includes may be a time-aggregated, e.g., statistical fashion, to
includes may be a time-aggregated, e.g., statistical fashion, to match the lo match the longer-term operation of the routing function. Example
nger-term information includes link-layer metrics such as link bandwidth (the medium
operation of the routing function. speed depends dynamically on the mode of the PHY layer), number
Example information includes Link-Layer metrics such as Link of flows (bandwidth that can be reserved for a flow depends on the number
bandwidth (the medium speed depends dynamically on the mode of the physical and size of flows sharing the spectrum), and the average and mean squared
(PHY) layer), number of deviation of availability and reliability metrics (such as PDR)
flows (bandwidth that can be reserved for a flow depends on the number and over long periods of time. It may also report an aggregated
size of flows sharing the spectrum) and average and mean squared deviation Expected Transmission Count (ETX) or a variation of it. </t><t> Based on
of availability and reliability metrics, such as Packet Delivery Ratio (PDR) those metrics, the routing function installs the recovery graph with
over long periods of time. It may also report an aggregated expected enough redundant forwarding solutions to ensure that the Network Plane can
transmission count (ETX), or a variation of it. reliably deliver the packets within an SLA associated with the flows that
</t><t> it transports. The SLA defines end-to-end reliability and availability
Based on those metrics, the routing function installs the recovery graph wit requirements, in which reliability may be expressed as a successful
h enough delivery in order and within a bounded delay of at least one copy of a
redundant forwarding solutions to ensure that the Network Plane can reliably packet. </t><t> Depending on the use case and the SLA, the recovery graph
deliver the packets within an SLA associated with the may comprise non-RAW segments, either interleaved inside the recovery
flows that it transports. graph (e.g., over tunnels) or all the way to the Egress End Node (e.g., a
The SLA defines end-to-end reliability and availability requirements, in whi server in the local wired domain). RAW observes the lower-layer links
ch between RAW nodes (typically radio links) and the end-to-end network-layer
reliability may be expressed as a successful delivery in-order and within a operation to decide at all times which of the diversity schemes is
bounded delay of at least one copy of a packet. actioned by which RAW Nodes. </t><t> Once a recovery graph is
</t><t> established, per-segment and end-to-end reliability and availability
Depending on the use case and the SLA, the recovery graph may comprise non-R statistics are periodically reported to the routing function to ensure
AW that the SLA can be met; if not, then the recovery graph is recomputed.
segments, either interleaved inside the recovery graph (e.g. over tunnels),
or all the way to the Egress End Node (e.g., a server in the local wired
domain). RAW observes the
Lower-Layer Links between RAW nodes (typically, radio links) and the
end-to-end Network Layer operation to decide at all times which of the
diversity schemes is actioned by which RAW Nodes.
</t><t>
Once a recovery graph is established, per-segment and end-to-end reliability
and availability statistics are periodically reported to the routing function
to ensure
that the SLA can be met or if not, then have the recovery graph recomputed.
</t> </t>
</section>
</section> <!--The RAW Network Plane -->
<section anchor="layers" numbered="true" toc="default"> <section anchor="layers" numbered="true" toc="default">
<name>RAW vs. Upper and Lower Layers</name> <name>RAW Versus Upper and Lower Layers</name>
<t>RAW builds on DetNet-provided features such as scheduling and shaping. <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>
<!-- [rfced] Will readers understand what "it" refers to in this sentence?
Original:
RAW improves the reliability of transmissions and the availability of
the communication resources, and should be seen as a dynamic
optimization of the use of redundancy to maintain it within certain
boundaries.
Perhaps:
RAW improves the reliability of transmissions and the availability of
the communication resources and should be seen as a dynamic
optimization of the use of redundancy to maintain reliability and availabilit
y
within certain boundaries.
-->
<t> <t>
RAW improves the reliability of transmissions and the availability of the RAW improves the reliability of transmissions and the availability of
communication resources, and should be seen as a dynamic optimization of the use of communication resources, and should be seen as a dynamic optimization of the use of
redundancy to maintain it within certain boundaries. redundancy to maintain it within certain boundaries.
For instance, ARQ, which provides 1-hop reliability through acknowledgements For instance, ARQ (which provides one-hop reliability through acknowledgemen
and retries, ts and retries)
and FEC codes such as turbo codes which reduce the PER, are typically operat and FEC codes (such as turbo codes which reduce the PER) are typically opera
ed at Layer-2 and Layer-1 respectively. ted at Layer 2 and Layer 1, respectively.
In both cases, redundant transmissions improve the 1-hop reliability at the In both cases, redundant transmissions improve the one-hop reliability at th
expense of energy and latency, which are the resources that RAW must control. e expense of energy and latency, which are the resources that RAW must control.
In order to achieve its goals, RAW may leverage the lower-layer operations In order to achieve its goals, RAW may leverage the lower-layer operations
by abstracting the concept and providing hints to the lower layers by abstracting the concept and providing hints to the lower layers
on the desired outcome, e.g., in terms of reliability and timeliness, on the desired outcome (e.g., in terms of reliability and timeliness),
as opposed to performing the actual operations at Layer-3. as opposed to performing the actual operations at Layer 3.
</t> </t>
<t> <t>
Guarantees such as bounded latency depend on the upper layers (Transport or Guarantees such as bounded latency depend on the upper layers (transport or
Application) to provide the payload in volumes and at times that match the application) to provide the payload in volumes and at times that match the
contract with the DetNet sub-layers and the layers below. Excess of contract with the DetNet sub-layers and the layers below. An excess of
incoming traffic at the DetNet Ingress may result in dropping or incoming traffic at the DetNet Ingress may result in dropping or
queueing of packets, and can entail loss, latency, or jitter, and queueing of packets and can entail loss, latency, or jitter; this violates t
therefore, violate the guarantees that are provided inside the DetNet Networ he guarantees that are provided inside the DetNet Network.
k.
</t> </t>
<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>
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"/> and Simple Two-way Active Measurement Protocol (STA
r via a control protocol exchange with the MP) <xref target="RFC8762"/>, respectively, or via a control protocol exchange w
lower layer via, e.g., DLEP <xref target="RFC8175"/>. It may then be ith the
processed and exported through OAM messaging or via a YANG data model, lower layer (e.g., DLEP <xref target="RFC8175"/>). 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> <!--The RAW Network Plane --> </section>
<section anchor="DetNet" numbered="true" toc="default"> <section anchor="DetNet" numbered="true" toc="default">
<name>RAW and DetNet</name> <name>RAW and DetNet</name>
<t> <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"/>) for the OAM in DetNet Transit Nodes (see Figure 3 of <xref target="RFC8655"/>) 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>
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>
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 ge The RAW orientation function may run only in the DetNet Edge Nodes (Ingress Ed 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 The RAW Service sub-layer includes the PLR, which decides the DetNet Path for 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>
As illustrated in <xref target='FigDN'/>, RAW extends the DetNet Stack (see As illustrated in <xref target='FigDN'/>, RAW extends the DetNet Stack (see
Figure 4 of <xref target="RFC8655"/> and <xref target='FigLayers'/>) with Figure 4 of <xref target="RFC8655"/> and <xref target='FigLayers'/>) 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>
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 d
or limited to a Segment. The RAW or limited to a Segment. The RAW
functions may be present in the Service sub-layer in DetNet Edge and Relay Nod es. functions may be present in the Service sub-layer in DetNet Edge and Relay Nod es.
</t> </t>
<figure anchor="FigDN"> <figure anchor="FigDN">
<name>RAW function placement (Centralized Routing Case)</name> <name>RAW Function Placement (Centralized Routing Case)</name>
<artwork align="left" name="" type="" alt=""> <artwork align="left" name="" type="" alt=""><![CDATA[
+-----------------+ +-------------------+ +-----------------+ +-------------------+
| 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> There are two main proposed models to deploy RAW and DetNet. In the first
model (strict) (illustrated in <xref target="FigDN2"/>), RAW operates over a <!-- [rfced] Please review the paragraphs before Figure 6 (strict model) and
continuous DetNet Service end-to-end between the Ingress and the Egress Edge Figure 7 (loose model) and let us know if any changes are needed to place
text about the loose model together before Figure 7.
-->
<t>There are two main proposed models to deploy RAW and DetNet: strict (<xref ta
rget="FigDN2"/>) and loose (<xref target="FigDN3"/>). In the
strict model, illustrated in <xref target="FigDN2"/>, RAW operates over a
continuous DetNet service end to end between the Ingress and the Egress Edge
Nodes or End Systems. Nodes or End Systems.
</t> </t>
<t> <t>
sIn the second model (loose), RAW may traverse a section of the network that In the loose model, illustrated in <xref target="FigDN3"/>, RAW may traverse
is not serviced by DetNet. RAW / OAM may observe the end-to-end traffic and make a section of the network that
the best of the available resources, but it may not expect the DetNet guarantee is not serviced by DetNet. RAW / OAM may observe the end-to-end traffic and
s over all paths. For instance, make the best of the available resources, but it may not expect the DetNet
the packets between two wireless entities may be relayed over a wired guarantees over all paths. For instance, the packets between two wireless
infrastructure, in which case RAW observes and controls the transmission entities may be relayed over a wired infrastructure, in which case RAW
over the wireless first and last hops, as well as end-to-end metrics such as observes and controls the transmission over the wireless first and last
latency, jitter, and delivery ratio. This operation is loose since the hops, as well as end-to-end metrics such as latency, jitter, and delivery
structure and properties of the wired infrastructure are ignored, and may be ratio. This operation is loose since the structure and properties of the
either controlled by other means such as DetNet/TSN, or neglected in the wired infrastructure are ignored and may be either controlled by other
face of the wireless hops. means such as DetNet/TSN or neglected in the face of the wireless hops.
</t> </t>
<t> <t>
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 pport to ensure that the OAM information flows. DetNet Relay Nodes may or may not su pport
RAW services, whereas the DetNet Edge Nodes are required to support RAW in any case. RAW services, whereas the DetNet Edge Nodes are required to support RAW in any 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"> <figure anchor="FigDN2">
<name>(Strict) RAW over DetNet</name> <name>RAW over DetNet (Strict Model)</name>
<artwork align="left" name="" type="" alt=""> <artwork align="left" name="" type="" alt=""><![CDATA[
--------------------Flow Direction----------------------------------> --------------------Flow Direction---------------------------------->
+---------+ +---------+
| 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-----------------------> <------------------End-to-End DetNet Service----------------------->
]]></artwork>
</artwork>
</figure> </figure>
<t> In the second model (loose), illustrated in <xref target="FigDN3"/>, RAW <t>In the loose model (illustrated in <xref target="FigDN3"/>), RAW
operates over a partial DetNet Service where typically only the Ingress and operates over a partial DetNet service where typically only the Ingress and
the Egress End Systems support RAW. The DetNet Domain may extend beyond the the Egress End Systems support RAW. The DetNet domain may extend beyond the
Ingress Node, or there may be a DetNet domain starting at an Ingress Ingress Node, or there may be a DetNet domain starting at an Ingress
Edge Node at the first hop after the End System. Edge Node at the first hop after the End System.
</t> </t>
<t> <t>
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"> <!-- [rfced] FYI - We have adjusted the titles of Figures 6 and 7 to make them
<name>Loose RAW</name> consistent with one another; please review.
<artwork align="left" name="" type="" alt="">
Original:
Figure 6: (Strict) RAW over DetNet
Figure 7: Loose RAW
Current:
Figure 6: RAW over DetNet (Strict Model)
Figure 7: RAW over DetNet (Loose Model)
-->
<figure anchor="FigDN3">
<name>RAW over DetNet (Loose Model)</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
--------------------Flow Direction----------------------------------> --------------------Flow Direction---------------------------------->
+---------+ +---------+
| 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-------------------------> <---------------Partitioned DetNet Service------------------------->
]]></artwork>
</artwork>
</figure> </figure>
</section> <!-- RAW and DetNet --> </section>
<!-- 1111111111111 -->
</section> <!-- The RAW Conceptual Model --> </section>
<section anchor="control" numbered="true" toc="default"> <section anchor="control" numbered="true" toc="default">
<name>The RAW Control Loop</name> <name>The RAW Control Loop</name>
<t> <t>
The RAW Architecture is based on an abstract OODA Loop that controls the oper The RAW architecture is based on an abstract OODA
ation of a Recovery Graph. Loop that controls the operation of a recovery graph. The generic
The generic concept involves: concept involves the following:
</t> </t>
<!-- [rfced] Some of the items in the numbered list in Section 6 are complete
sentences and others are not. How may we update to create parallel
structure?
Original:
1. 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 the end-to-end packet delivery.
2. The DetNet Controller Plane establish primary and protection
paths for use by the RAW Network Plane. ...
3. A PLR operates at the DetNet Service sub-layer and hosts the
decision function (like the D in OODA) of which DetNet Paths to
use for the future packets that are routed within the recovery
graph.
4. Service protection actions that are actuated or triggered over
the LL API by the PLR to increase the reliability of the end-to-
end transmissions. ...
Perhaps (make #1 and #4 into complete sentences):
1. Operational Plane measurement protocols 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.
2. The DetNet Controller Plane establishes primary and protection
paths for use by the RAW Network Plane. ...
3. A PLR operates at the DetNet Service sub-layer and hosts the
decision function (like the D in OODA). The decision function determines
which DetNet Paths will be
used for future packets that are routed within the recovery
graph.
4. Service protection actions are actuated or triggered over
the LL API by the PLR to increase the reliability of the end-to-
end transmissions. ...
-->
<ol> <ol>
<li> Operational Plane measurement protocols for OAM to observe (like the <li>Operational Plane measurement protocols for OAM to observe (like
first O in OODA) some or all hops along a recovery graph as well as the first "O" in "OODA") some or all hops along a recovery graph as well a
s
the end-to-end packet delivery. the end-to-end packet delivery.
</li> </li>
<li> <li>
The DetNet Controller Plane establish primary and protection paths The DetNet Controller Plane establishes primary and protection
for use by the RAW Network Plane. paths for use by the RAW Network Plane. The orientation function
The orientation function reports reports data and information such as link statistics to be used by the
data and information such as link statistics to be used routing function to compute, install, and maintain the recovery
by the routing function to compute, install, and maintain the graphs. The routing function may also generate intelligence such as a
recovery graphs. The routing function may also generate intelligence such trained model for link quality prediction, which in turn can be used by
as a trained model the orientation function (like the second "O" in "OODA") to influence the
for link quality prediction, which in turn can be used by the orientation Path selection 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>A PLR operates at the DetNet Service sub-layer and hosts the
sub-layer and hosts the decision function (like the D in OODA) of which Det decision function (like the "D" in "OODA"). The decision function determin
Net Paths to use es which DetNet Paths will be used
for the future packets that are routed within the recovery graph. 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>Service protection actions that are actuated or triggered over the LL
API by the PLR to increase the reliability of the end-to-end transmissions. 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 transmissions.
live user traffic <xref target="RFC9378"/>, e.g., via OAM, when the decision is The RAW architecture also covers in-situ signaling that is embedded
acted (like the A in OODA) upon by a node that is downstream in the recover within live user traffic <xref target="RFC9378"/> (e.g., via OAM) when
y graph from the PLR. 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>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="default"> <section anchor="timescale" numbered="true" toc="default">
<name>Routing Time-Scale vs. Forwarding Time-Scale</name> <name>Routing Timescale Versus Forwarding Timescale</name>
<t> <t>
With DetNet, the Controller Plane Function handles the routing With DetNet, the Controller Plane Function (CPF) handles the routing computat
computation and maintenance. With RAW, the routing operation is ion
segregated from the RAW Control Loop, so it may reside in the Controller Plan and maintenance. With RAW, the routing operation is segregated from the RAW
e Control Loop, so it may reside in the Controller Plane, whereas the control
whereas the control loop itself happens in the Network Plane. To achieve RAW loop itself happens in the Network Plane. To achieve RAW capabilities, the
capabilities, the routing operation is extended to generate the information requ routing operation is extended to generate the information required by the
ired by the orientation function in the loop. orientation function in the loop. For example, the routing function may prop
The routing function may, e.g., propose DetNet Paths to be used as a reflex ose
action in response to network events, or provide an aggregated history that DetNet Paths to be used as a reflex action in response to network events
the orientation function can use to make a decision. or provide an aggregated history that the orientation function can use to
make a decision.
</t> </t>
<t> <t>
In a wireless mesh, the path to a routing function located in the controller In a wireless mesh, the path to a routing function located in the controller
plane can be expensive and 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><t>
As a result, the DetNet routing function is not expected to be aware of and t 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>
<!-- [rfced] How may we clarify "builds reports to the routing function"?
Original:
The interaction between the network nodes and the routing function is
handled by the orientation function, which builds reports to the
routing function and sends control information in a digested form ...
Perhaps:
The interaction between the network nodes and the routing function is
handled by the orientation function, which builds reports for the
routing function and sends control information in a digested form ...
Or:
The interaction between the network nodes and the routing function is
handled by the orientation function, which reports to the
routing function and sends control information in a digested form ...
-->
The interaction between the network nodes and the routing function is handled by the orientation function, which The interaction between the network nodes and the routing function is handled by the orientation function, which
builds reports to the routing function and builds reports to the routing function and
sends control information in a digested form back to the RAW node, to be used inside a forwarding control loop for sends control information in a digested form back to the RAW node to be used inside a forwarding control loop for
traffic steering. traffic steering.
</t><t> </t><t>
<xref target="Figcontrol"/> illustrates a Network Plane recovery graph <xref target="Figcontrol"/> 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 ==> E For instance, RAW may enable protection path I ==> F ==> N ==> Q ==> M ==> R ==> 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 ==> A ==> B ==> C ==> D ==> E.
</t>
</t>
<figure anchor="Figcontrol"> <figure anchor="Figcontrol">
<name>Time-Scales</name> <name>Timescales</name>
<artwork align="center" name="" type="" alt=""> <artwork align="center" name="" type="" alt=""><![CDATA[
<![CDATA[
+----------------+ +----------------+
| DetNet | | DetNet |
| Routing | | Routing |
+----------------+ +----------------+
^ ^
| |
Slow Slow
| Controller Plane | Controller Plane
_-._-._-._-._-._-. | ._-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-. | ._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-. | _-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-._-. | _-._-._-._-._-._-._-._-._-._-._-._-
skipping to change at line 1566 skipping to change at line 2182
( 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 -------> ) - <------ Fast -------> )
( -._ .- ( -._ .-
(_.___.._____________.____.._ __-____) (_.___.._____________.____.._ __-____)
*** = flapping at this time *** = flapping at this time
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t> <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>
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 ich upcoming packets / flows. the short-term decision of which of these possibilities should be used for wh ich upcoming packets and flows.
</t> </t>
<t> <t>
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>
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 >
<!--Routing time-scale vs. Forwarding time-scale-->
<section anchor="ooda" numbered="true" toc="default"> <section anchor="ooda" numbered="true" toc="default">
<name>OODA Loop</name> <name>OODA Loop</name>
<t> <t>
The RAW architecture applies the generic OODA model to continuously optimize
The RAW Architecture applies the generic OODA model to continuously optimize the
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>
<dt>Observe:</dt><dd> Network Plane measurements, including protocols for <dt>Observe:</dt><dd> Network Plane measurements, including protocols for
OAM, to Observe the local state of the links and some or all hops along a OAM, observe the local state of the links and some or all hops along a rec
recovery graph as well as overy graph as well as
the end-to-end packet delivery (see more in <xref target = "aom"/>). the end-to-end packet delivery (see more in <xref target="aom"/>).
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>Orient:</dt><dd>
The orientation function, which reports data and information such as the l The orientation function reports data and information such as the link
ink 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" />);
</dd> </dd>
<dt>Decide:</dt><dd> A local PLR that decides which DetNet Path to use <dt>Decide:</dt><dd>A local PLR decides which DetNet Path to use
for the future packet(s) that are routed along the recovery graph for future packet(s) that are routed along the recovery graph
(see more in <xref target = "PLRpce" />); (see more in <xref target="PLRpce"/>).
</dd> </dd>
<dt>Act:</dt><dd> PREOF Data Plane <dt>Act:</dt><dd>PREOF Data Plane actions are controlled by the PLR over
actions are controlled by the PLR over the LL API to increase the the LL API to increase the reliability of the end-to-end
reliability of the end-to-end transmission. The RAW architecture also transmission. The RAW architecture also covers in-situ signaling when
covers in-situ signaling when the decision is Acted by a node that is the decision is acted by a node that is down the recovery graph from the
down the recovery graph from the PLR (see more in PLR (see more in <xref target="reliability"/>).
<xref target = "reliability" />).
</dd> </dd>
</dl> </dl>
<figure anchor="oodaloop"> <figure anchor="oodaloop">
<name>The RAW OODA Loop</name> <name>The RAW OODA Loop</name>
<artwork align="center" name="" type="" alt=""> <artwork align="center" name="" type="" alt=""><![CDATA[
<![CDATA[
+-------> 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)
^ | ^ |
skipping to change at line 1654 skipping to change at line 2265
| | | |
...................................... ......................................
| | | |
| Service sub-layer | | Service sub-layer |
| v | v
Observe (OAM) Decide (PLR) Observe (OAM) Decide (PLR)
^ | ^ |
| | | |
| | | |
+------- Act (LL API) <--------+ +------- Act (LL API) <--------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> The overall OODA Loop optimizes the use of redundancy to achieve the <t> The overall OODA Loop optimizes the use 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 > <!-- A OODA Loop --> </section >
<section anchor="aom" numbered="true" toc="default"> <section anchor="aom" numbered="true" toc="default">
<name>Observe: The RAW OAM </name><t> <name>Observe: RAW OAM </name><t>
RAW In-situ OAM operation in the Network Plane may observe either a full The RAW in-situ OAM operation in the Network Plane may observe either a full
recovery graph or the DetNet Path that is being used at this time. As packet s may be load recovery graph or the DetNet Path that is being used at this time. As packet s may be load
balanced, replicated, eliminated, and / or fragmented for Network Coding balanced, replicated, eliminated, and/or fragmented for Network Coding
FEC, the RAW In-situ operation needs to be 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>
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>
<!-- [rfced] Will readers understand what "Assurance" means here? We do not
see this used elsewhere in the document.
Original:
Finally, the RAW Service sub-layer Assurance may observe the
individual PREOF operation of a DetNet Relay Node to ensure that it
is conforming;
-->
<t> <t>
Finally, the RAW Service sub-layer Assurance may observe the individual PREO F Finally, the RAW Service sub-layer Assurance may observe the individual PREO F
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>
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>
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>
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"/>, 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">
<name>Observed Links in Radio Access Protection</name> <name>Observed Links in Radio Access Protection</name>
<artwork align="center" name="" type="" alt=""> <artwork align="center" name="" type="" alt=""><![CDATA[
<![CDATA[
Opaque to OAM Opaque to OAM
<----------------------------> <---------------------------->
.- .. - .. .- .. - ..
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------> <-------L2------>
Observed by OAM Observed by OAM
<----------------------L3-----------------------> <----------------------L3----------------------->
]]></artwork> ]]></artwork>
</figure> </figure>
<!-- [rfced] What is being connected by "either" in the phrase "either or a
collection of those access links". How should this text be clarified?
Original:
; still the 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 or a collection of those
access links.
-->
<t> <t>
The Links that are not observed by OAM are opaque to it, meaning that the 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 OAM information is carried across and possibly echoed as data, but there is
no information captured in intermediate nodes. In the example above, the 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 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 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 RAN 3, and determines whether a packet should be sent over either or a
collection of those access links. collection of those access links.
</t> </t>
</section> </section>
<!-- Observe: The RAW OAM -->
<section anchor="pce" numbered="true" toc="default"> <section anchor="pce" numbered="true" toc="default">
<name>Orient: The RAW-extended DetNet Operational Plane</name> <name>Orient: The RAW-Extended DetNet Operational Plane</name>
<t> <t>
RAW separates the long time-scale at which a recovery graph is computed and i RAW separates the long timescale at which a recovery graph is computed and in
nstalled, stalled
from the short time-scale at which the forwarding decision is taken for one from the short timescale at which the forwarding decision is taken for one
or for a few packets (see <xref target="timescale"/>) that experience the or a few packets (see <xref target="timescale"/>) 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>
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>
The metadata may include: The metadata may include:
</t> </t>
<ul> <ul>
<li> <li>
A set of Pre-Determined DetNet Paths that are prepared to match A set of pre-determined DetNet Paths that are prepared to match
expected link-degradation profiles, so the DetNet Relay Nodes can take reflex rerouting actions when expected link-degradation profiles, so the DetNet Relay Nodes can take reflex rerouting actions when
facing a degradation that matches one such profile; facing a degradation that matches one such profile; and
</li> </li>
<li> <li>
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>
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="default"> <section anchor="PLRpce" numbered="true" toc="default">
<name>Decide: The Point of Local Repair</name> <name>Decide: The Point of Local Repair</name>
<!-- [rfced] This sentence does not parse. Please clarify.
Original:
The OODA Loop controls, within the redundant solutions that are proposed by
the routing function, which is used for each packet to provide a Reliable and
Available service while minimizing the waste of constrained resources.
Perhaps:
Within the redundant solutions that are proposed by
the routing function, the OODA Loop controls what is used for each packet and
provides a reliable and
available service while minimizing the waste of constrained resources.
-->
<t> <t>
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 graph
.
The OODA Loop controls, within the redundant solutions that are proposed The OODA Loop controls, within the redundant solutions that are proposed
by the routing function, which is used for each packet to provide a Reliable by the routing function, which is used for each packet to provide a reliable
and and
Available service while minimizing the waste of constrained resources. available service while minimizing the waste of constrained resources.
</t><t> </t><t>
To that effect, RAW defines the Point of Local Repair (PLR), which performs To that effect, RAW defines the Point of Local Repair (PLR), which performs
rapid local adjustments of the forwarding tables within the path diversity th at is rapid local adjustments of the forwarding tables within the path diversity th at is
available in that in the recovery graph. The PLR enables exploitation of available in that in the recovery graph. The PLR enables exploitation of
the richer forwarding capabilities at a faster time-scale over a portion of the richer forwarding capabilities at a faster timescale over a portion of
the recovery graph, in either a loose or a strict fashion. the recovery graph, in either a loose or a strict fashion.
</t> </t>
<!-- [rfced] This sentence is difficult to follow. We updated as shown below.
Please review and to confirm that the updated text accurately conveys the
intended meaning.
Original:
The PLR operates on metrics that evolve faster, but that need to be
advertised at a fast rate but only locally, within the recovery
graph, and reacts on the metric updates by changing the DetNet path
in use for the affected flows.
Updated:
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 the PLR reacts to the metric updates by changing the DetNet path
in use for the affected flows.
-->
<t> <t>
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 on
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>
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"/>.
</t> </t>
<table anchor="PCEPLRtable"><name>Centralized Decision vs. PLR</name> <table anchor="PCEPLRtable"><name>Centralized Decision Versus PLR</name>
<thead> <thead>
<tr> <tr>
<th> </th> <th></th>
<th align='center'> Controller Plane </th> <th>Controller Plane</th>
<th align='center'> PLR </th> <th>PLR</th>
</tr> </tr>
</thead>
</thead><tbody> <tbody>
<tr><th>Communication</th>
<tr><td>Communication <td>Slow, distributed</td>
</td> <td>Fast, local</td>
<td align='center'>Slow, distributed</td> </tr>
<td align='center'>Fast, local</td> <tr><th>Timescale (order)</th>
</tr> <td>Path computation + round trip, milliseconds to seconds</td>
<td>Lookup + protection switch, micro to milliseconds</td>
<tr><td>Time-Scale (order)</td> </tr>
<td align='center'>Path computation + round trip, milliseconds to s <tr><th>Network Size</th>
econds</td> <td>Large, many recovery graphs to optimize globally</td>
<td align='center'>Lookup + protection switch, micro to millisecond <td>Small, limited set of protection paths</td>
s</td> </tr>
</tr> <tr><th>Considered Metrics</th>
<td>Averaged, statistical, shade of grey</td>
<tr><td>Network Size</td> <td>Instantaneous values / boolean condition</td>
<td align='center'>Large, many recovery graphs to optimize globally </tr>
</td>
<td align='center'>Small, limited set of protection paths</td>
</tr>
<tr><td>Considered Metrics</td>
<td align='center'>Averaged, statistical, shade of grey</td>
<td align='center'>Instantaneous values / boolean condition</td>
</tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The PLR sits in the DetNet Forwarding sub-layer of Edge and Relay Nodes. 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"/>.
</t> </t>
<figure anchor="Figlearn"> <figure anchor="Figlearn">
<name>PLR Conceptual Interfaces</name> <name>PLR Conceptual Interfaces</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
| |
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 < end-to-end | | packet tagging > Maintain < end-to-end |
+----------v----------+ Forwarding | OAM packets | +----------v----------+ Forwarding | OAM packets |
| Forwarding decision < State +---------^---------| | Forwarding decision < State +---------^---------|
+----------v----------+ | Enrich or | +----------v----------+ | Enrich or |
+ Retag Packet | Learn abstracted > Regenerate | + Retag packet | Learn abstracted > 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> ]]></artwork>
</figure> </figure>
</section> </section>
<!--PCE vs. PLR-->
<!-- 11111111111111111 -->
<section anchor="reliability" numbered="true" toc="default"> <section anchor="reliability" numbered="true" toc="default">
<name>Act: DetNet Path Selection and Reliability Functions</name> <name>Act: DetNet Path Selection and Reliability Functions</name>
<t> <t>
The main action by the PLR is the swapping of the DetNet Path within the 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>
<!-- [rfced] Please clarify "more typical to wireless than wired".
Original:
The LL API enriches the DetNet protection services (PREOF) with
potential possibility to interact with lower-layer one-hop
reliability functions that are more typical to wireless than wired,
including ARQ, FEC, and other techniques such as overhearing and
constructive interferences.
Perhaps:
The LL API enriches the DetNet protection services (PREOF) with the
possibility to interact with lower-layer, one-hop
reliability functions that are more typical with wireless links than with wir
ed ones,
including ARQ, FEC, and other techniques such as overhearing and
constructive interferences.
-->
<t>The LL API enriches the DetNet protection services (PREOF) <t>The LL API enriches the DetNet protection services (PREOF)
with potential possibility to interact with lower-layer one-hop reliability with the possibility to interact with lower-layer, one-hop reliability
functions that are more typical to wireless than wired, including ARQ, FEC, functions that are more typical to wireless than wired, including ARQ, FEC,
and other techniques such as overhearing and constructive interferences. and other techniques such as overhearing and constructive interferences.
Because RAW may be leveraged on wired links, Because RAW may be leveraged on wired links
e.g., to save power, it is not expected that all lower layers support all (e.g., to save power), it is not expected that all lower layers support all
those capabilities. those capabilities.
</t> </t>
<t> <t>
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>
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>
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> <!-- Act: The reliability Functions-->
</section> </section>
<!-- The RAW Control Loop -->
<!-- 000000000000000000000 --> </section>
<section anchor="SecurityConsiderations" numbered="true" toc="default"> <section anchor="SecurityConsiderations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Collocated Denial of Service Attacks</name> <name>Collocated Denial-of-Service Attacks</name>
<t> <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> <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="default"> <section numbered="true" toc="default">
<name>Layer-2 encryption</name> <name>Layer 2 Encryption</name>
<t> <t>
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><!-- Layer-2 encryption --> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Forced Access</name> <name>Forced Access</name>
<!-- [rfced] Should "may typically select" be updated to "may select" or
"typically selects"?
Original:
A RAW policy may typically select the cheapest collection of links
that matches the requested SLA, e.g., use free Wi-Fi vs. paid 3GPP
access.
Perhaps:
A RAW policy may select the cheapest collection of links
that matches the requested SLA, e.g., use free Wi-Fi vs. paid 3GPP
access.
Or:
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.
-->
<t> <t>
A RAW policy may typically select the cheapest collection of links that A RAW policy may typically select 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 attacker
can force an End System to use the paid access and increase the cost of the can force an End System to use the paid access and increase the cost of the
transmission for the user. transmission for the user.
</t> </t>
<t> <t>
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> </section>
<!--Security Considerations-->
<!-- 000000000000000000000 -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions. <t>This document has no IANA actions.</t>
</t>
</section>
<!--IANA Considerations-->
<!-- 000000000000000000000 -->
<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="I-D.ietf-raw-technologies" to="RAW-TECHNOS"/> <displayreference target="RFC9913" to="RAW-TECHNOS"/>
<displayreference target="I-D.ietf-raw-use-cases" to="RAW-USE-CASES"/> <displayreference target="RFC9450" to="RAW-USE-CASES"/>
<displayreference target="RFC1122" to="INT-ARCHI"/>
<displayreference target="RFC9522" to="TE"/>
<displayreference target="RFC8175" to="DLEP"/>
<displayreference target="RFC7490" to="RLFA-FRR"/>
<displayreference target="RFC5714" to="FRR"/>
<displayreference target="RFC8938" to="DetNet-DP"/>
<displayreference target="RFC8655" to="DetNet-ARCHI"/>
<displayreference target="RFC9030" to="6TiSCH-ARCHI"/>
<displayreference target="RFC9551" to="DetNet-OAM"/>
<displayreference target="RFC1122" to="INT-ARCHI"/> <displayreference target="I-D.ietf-detnet-controller-plane-framework" to="De
<displayreference target="RFC9522" to="TE"/> tNet-PLANE"/>
<displayreference target="RFC8175" to="DLEP"/>
<displayreference target="RFC7490" to="RLFA-FRR"/>
<displayreference target="RFC5714" to="FRR"/>
<displayreference target="RFC8938" to="DetNet-DP"/>
<!--displayreference target="RFC9016" to="DetNet-Flow"/-->
<displayreference target="RFC8655" to="DetNet-ARCHI"/>
<displayreference target="RFC9030" to="6TiSCH-ARCHI"/>
<displayreference target="RFC9551" to="DetNet-OAM"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D <!-- [rfced] Would you like the references to be alphabetized
.ietf-raw-technologies.xml"/> or left in their current order?
<!-- Reliable and Available Wireless Technologies --> -->
<!-- [RFC9913 / RAW_TECHNOS]
draft-ietf-raw-technologies-17
companion doc RFC 9913
-->
<reference anchor="RFC9913" target="https://www.rfc-editor.org/info/rfc9913">
<front>
<title>Reliable and Available Wireless (RAW) Technologies</title>
<author initials="P." surname="Thubert" fullname="Pascal Thubert" role="edit
or">
</author>
<author initials="D." surname="Cavalcanti" fullname="Dave Cavalcanti">
<organization>Intel Corporation</organization>
</author>
<author initials="X." surname="Vilajosana" fullname="Xavier Vilajosana">
<organization>Universitat Oberta de Catalunya</organization>
</author>
<author initials="C." surname="Schmitt" fullname="Corinna Schmitt">
<organization>Research Institute CODE, UniBw M</organization>
</author>
<author initials="J." surname="Farkas" fullname="János Farkas">
<organization>Ericsson</organization>
</author>
<date month='February' year='2026'/>
</front>
<seriesInfo name="RFC" value="9913"/>
<seriesInfo name="DOI" value="10.17487/RFC9913"/>
</reference>
<reference anchor="TSN" target="https://1.ieee802.org/tsn/"> <reference anchor="TSN" target="https://1.ieee802.org/tsn/">
<front> <front>
<title>Time-Sensitive Networking (TSN)</title> <title>Time-Sensitive Networking (TSN)</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4427.
9030.xml"/> xml"/>
<!-- 6TiSCH Architecture --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6291.
xml"/>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.
4427.xml"/> xml"/>
<!-- Internet Architecture --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8557.
xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.
.6291.xml"/> xml"/>
<!-- Guidelines for the Use of the "OAM" Acronym in the IETF --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9551.
xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.7799.xml"/>
<!-- Active and Passive Metrics and Methods for OAM -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.8557.xml"/>
<!-- DetNet problem statement -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.8655.xml"/>
<!-- Deterministic Networking Architecture -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.9551.xml"/>
</references> </references>
<!--Normative References-->
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9030.
.9049.xml"/> xml"/>
<!-- Path Aware Networking: Obstacles to Deployment --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9049.
xml"/>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1122.
1122.xml"/> xml"/>
<!-- Internet Architecture --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8939.
xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8578.
.8939.xml"/> xml"/>
<!-- Deterministic Networking IP dataplane --> <!-- [RAW-USE-CASES]
-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9450.
.8578.xml"/> xml"/>
<!-- Deterministic Networking Use Cases --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D xml"/>
.ietf-raw-use-cases.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2205.
<!-- RAW use cases --> xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9522.
.0791.xml"/> xml"/>
<!-- IP --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9544.
xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.
.2205.xml"/> xml"/>
<!-- RSVP --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3366.
xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4090.
.9522.xml"/> xml"/>
<!-- TE --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC xml"/>
.9544.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5714.
xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6378.
.4655.xml"/> xml"/>
<!-- PCE --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6551.
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC xml"/>
.3366.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7490.
<!-- Advice to link designers on link Automatic Repeat reQuest (ARQ) --> xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8724.
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC xml"/>
.4090.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8938.
<!-- Fast Reroute Extensions to RSVP-TE --> xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8175.
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC xml"/>
.5880.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9378.
<!-- BFD --> xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8762.
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC xml"/>
.5714.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9473.
<!-- IP Fast Reroute Framework --> xml"/>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9633.
6378.xml"/> 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 draft-ietf-detnet-controller-plane-framework-14
.ietf-opsawg-oam-characterization"/> IESG State: IESG Evaluation::AD Followup as of 09/18/25
--> -->
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D
.ietf-detnet-controller-plane-framework"/> <reference anchor="I-D.ietf-detnet-controller-plane-framework" target="https://d
atatracker.ietf.org/doc/html/draft-ietf-detnet-controller-plane-framework-14">
<front>
<title>A Framework for Deterministic Networking (DetNet) Controller Plane<
/title>
<author initials="A. G." surname="Malis" fullname="Andrew G. Malis">
<organization>Independent</organization>
</author>
<author initials="X." surname="Geng" fullname="Xuesong Geng" role="editor"
>
<organization>Huawei</organization>
</author>
<author initials="M." surname="Chen" fullname="Mach Chen">
<organization>Huawei</organization>
</author>
<author initials="B." surname="Varga" fullname="Balazs Varga">
<organization>Ericsson</organization>
</author>
<author initials="C. J." surname="Bernardos" fullname="Carlos J. Bernardos
">
<organization>Universidad Carlos III de Madrid</organization>
</author>
<date month="September" day="9" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-controller-plane-f
ramework-14" />
</reference>
<reference anchor="NASA1" target="https://extapps.ksc.nasa.gov/Reliability/D ocuments/150814-3bWhatIsReliability.pdf"> <reference anchor="NASA1" target="https://extapps.ksc.nasa.gov/Reliability/D ocuments/150814-3bWhatIsReliability.pdf">
<front> <front>
<title>RELIABILITY: Definition &amp; Quantitative Illustration</title> <title>RELIABILITY: Definition &amp; Quantitative Illustration</title>
<author initials="T." surname="Adams" fullname="Tim Adams" > <author initials="T." surname="Adams" fullname="Tim Adams" >
<organization>NASA</organization> <organization>NASA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
skipping to change at line 2181 skipping to change at line 2826
<reference anchor="NASA2" target="https://extapps.ksc.nasa.gov/Reliability/Do cuments/160727.1_Availability_What_is_it.pdf"> <reference anchor="NASA2" target="https://extapps.ksc.nasa.gov/Reliability/Do cuments/160727.1_Availability_What_is_it.pdf">
<front> <front>
<title>Availability</title> <title>Availability</title>
<author initials="T." surname="Adams" fullname="Tim Adams" > <author initials="T." surname="Adams" fullname="Tim Adams" >
<organization>NASA</organization> <organization>NASA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<!--Informative References-->
</references> </references>
</references> </references>
<section numbered="false">
<name>Acknowledgments</name>
<t>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="D
ave
Black"/>, the DetNet Tech Advisor. Many thanks to all of you.
</t>
<t>The authors wish to thank <contact fullname="Ketan Talaulikar"/>, as
well as <contact fullname="Balazs Varga"/>, <contact fullname="Dave
Cavalcanti"/>, <contact fullname="Don Fedyk"/>, <contact fullname="Nicolas
Montavont"/>, and <contact fullname="Fabrice Theoleyre"/> for their
in-depth reviews during the development of this document.
</t>
<t>The authors wish to thank <contact fullname="Acee Lindem"/>, <contact
fullname="Eva Schooler"/>, <contact fullname="Rich Salz"/>, <contact
fullname="Wesley Eddy"/>, <contact fullname="Behcet Sarikaya"/>, <contact
fullname="Brian Haberman"/>, <contact fullname="Gorry Fairhurst"/>,
<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>
Special thanks for <contact fullname="Mohamed Boucadair"/>, <contact
fullname="Giuseppe Fioccola"/>, and <contact fullname="Benoit Claise"/>
for their help dealing with OAM technologies.
</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>The editor wishes to thank the following individuals
for their contributions to the text and the ideas discussed in this doc
ument:
</t>
<contact fullname="Lou Berger">
<organization>LabN Consulting, L.L.C</organization>
<address>
<email>lberger@labn.net</email>
</address>
</contact>
<contact fullname="Xavi Vilajosana">
<organization>Wireless Networks Research Lab, Universitat Oberta de Catalu
nya</organization>
<address>
<email>xvilajosana@gmail.com</email>
</address>
</contact>
<contact fullname="Geogios Papadopolous">
<organization>IMT Atlantique</organization>
<address>
<email>georgios.papadopoulos@imt-atlantique.fr</email>
</address>
</contact>
<contact fullname="Remous-Aris Koutsiamanis">
<organization>IMT Atlantique</organization>
<address>
<email>remous-aris.koutsiamanis@imt-atlantique.fr</email>
</address>
</contact>
<contact fullname="Rex Buddenberg">
<organization>Retired</organization>
<address>
<email>buddenbergr@gmail.com</email>
</address>
</contact>
<contact fullname="Greg Mirsky">
<organization>Ericsson</organization>
<address>
<email>gregimirsky@gmail.com</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
<!-- [rfced] Terminology:
a) "sub-layer" (with hyphen) is used consistently in this document, but
"sublayer" (no hyphen) is used in the other documents in cluster 538
(draft-ietf-raw-technologies and draft-ietf-roll-dao-projection). May we
update usage in this document to align with the other documents in the
cluster? Note that we see mixed usage in past RFCs; for example, RFC 9030
uses "sublayer", but RFC 8655 uses "sub-layer".
b) We note the following capitalization inconsistencies in the names of
nodes. Please review and let us know how to update for consistency.
RAW Node
RAW node
Ingress Node
Ingress node
Egress Node
Egress node
DetNet Edge nodes
DetNet Edge Nodes
edge nodes
DetNet Transit Nodes
DetNet Transit nodes
transit node
DetNet Relay Node
c) We also note inconsistencies in the terms below throughout the text. Should
these be uniform? If so, please let us know which form is preferred.
RAW OAM
RAW / OAM
DetNet Path
DetNet path
Protection Path
protection path
path selection
Path selection (i.e., DetNet Path selection)
Path Selection (i.e., RAW Path Selection)
Control Loop
control loop
OODA Loop
OODA loop
Segment
segment
Ingress
ingress
Egress
egress
DetNet Forwarding sub-layer
DetNet forwarding sub-layer
Controller Plane
controller plane
d) FYI - We updated "gNb" to "gNB" to align with usage in RFC-to-be 9913 aka
draft-ietf-raw-technologies-17 and other documents in the RFC Series.
-->
<!-- [rfced] Abbreviations
a) Below is the first instance of "PHY" in this document. How should this be
expanded? As "Physical"?
Original:
Furthermore, the different RAW technologies are equipped with
different reliability features, e.g., short range broadcast,
Multiple-User, Multiple-Input, and Multiple-Output (MUMIMO), PHY rate
and other Modulation Coding Scheme (MCS) adaptation, coding and
retransmissions methods, constructive interference and overhearing,
see [RAW-TECHNOS] for details.
b) FYI - We updated the expansion of SNR as follows to align with the
expansion used in previous RFCs.
Original:
Signal-Noise Ratio
Updated:
Signal-to-Noise Ratio
c) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Deterministic Networking (DetNet)
Dynamic Link Exchange Protocol (DLEP)
Differentiated Services Code Point (DSCP)
Static Context Header Compression (SCHC)
Bidirectional Forwarding Detection (BFD)
Media Access Control (MAC)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
 End of changes. 345 change blocks. 
1002 lines changed or deleted 1683 lines changed or added

This html diff was produced by rfcdiff 1.48.