Reliable and Available Wireless Architecture
draft-ietf-raw-architecture-17
| Document | Type | Active Internet-Draft (detnet WG) | |
|---|---|---|---|
| Author | Pascal Thubert | ||
| Last updated | 2024-03-04 | ||
| Replaces | draft-pthubert-raw-architecture | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Associated WG milestones |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-raw-architecture-17
--------------------Flow Direction---------------------------------->
+---------+
| RAW |
| Control |
+---------+ +---------+ +---------+
| RAW + | | DetNet | | RAW + |
| DetNet | | Only | | DetNet |
| Service | | Service | | Service |
+---------+----------------------+---+ +---+---------+
| DetNet | | DetNet |
| Forwarding | | Forwarding |
+------------------------------------+ +-------------+
Ingress Transit Relay Internet Egress
End ... Nodes ... Nodes ... ... End
System System
<----------------------No Guarantee-------------------------------->
Figure 7: Loose RAW
5. The RAW Control Loop
5.1. Routing Time Scale vs. Forwarding Time Scale
With DetNet, the Controller Plane Function handles the routing
computation and maintenance. With RAW, the routing part of the CPF
(rCPF) is segregated from the RAW Control Loop, so it may reside
outside of the RAW network. To achieve RAW capabilities, the rCPF is
extended to generate the information required by the local aCPF,
which acts as the orientation component in the loop. The rCPF may,
e.g., propose DetNet Paths to be used as a reflex action in response
to network events, or by provide aggregated history that the aCPF can
use to make an oriented decision.
In a wireless mesh, the path to the DetNet CPF can be expensive and
slow, possibly going across the whole mesh and back. Reaching to the
CPF can also be slow in regards to the speed of events that affect
the forwarding operation at the radio layer. Note that a distributed
routing protocol may also take time and consume excessive wireless
resources to reconverge to a new optimized state.
Thubert Expires 5 September 2024 [Page 30]
Internet-Draft RAW Architecture March 2024
As a result, the DetNet CPF is not expected to be aware of and to
react to 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 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 value for either up or down.
The interaction with the (remote) RAW rCPF is handled by a (local)
aCPF that builds reports to the rCPF and digests the control
information back, to be used inside a forwarding control loop for
traffic steering.
+----------------+
| DetNet |
| Routing |
| CPF |
+----------------+
^
|
Slow
|
_-._-._-._-._-._-. | ._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-. | _-._-._-._-._-._-._-._-._-._-._-._-
|
Expensive
|
.... | .......
.... . | . .......
.... v ...
.. A-------B-------C---D ..
... / \ / \ ..
. I ----M-------N--***-- E ..
.. \ / / ...
.. P--***--Q-----M---R ....
.. ....
. <----- Fast -------> ....
....... ....
.................
*** = flapping at this time
Figure 8: Time Scales
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 between a transmitter and a receiver, and will
Thubert Expires 5 September 2024 [Page 31]
Internet-Draft RAW Architecture March 2024
cancel the line of sight transmission for a few seconds, or a radar
measures the depth of a pool and interferes on a particular channel
for a split second.
There is thus a desire to separate the long term computation of the
route and the short term forwarding decision. In that model, the
routing operation computes a recovery graph that enables multiple
Non-Equal Cost Multi-Path (N-ECMP) forwarding solutions along so-
called protection paths, and leaves it to the Network Plane to make
the per-packet decision of which of these possibilities should 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 MPLS-TP or BFD over a collection of SD-WAN tunnels. RAW
formalizes a forwarding time scale that is an order(s) of magnitude
shorter than the controller plane routing time scale, and separates
the protocols and metrics that are used at both scales. Routing can
operate on long term statistics such as delivery ratio over minutes
to hours, but as a first approximation can ignore flapping. On the
other hand, the RAW forwarding decision is made at the scale of the
packet rate, and uses information that must be pertinent at the
present time for the current transmission(s).
5.2. A OODA Loop
OODA (Observe, Orient, Decide, Act) is a generic formalism to
represent the operational steps in a Control Loop. The RAW
Architecture applies that generic model to continuously optimize the
spectrum and energy used to forward packets within a recovery graph,
instantiating the OODA steps as follows:
Observe: Network Plane measurements, including protocols for
Operations, Administration and Maintenance (OAM), to Observe the
local state of the links and some or all hops along a recovery
graph as well as the end-to-end packet delivery, more in
Section 5.3;
Orient: An asynchronous CPF that reports data and information such
as the link statistics, and leverages offline-computed wisdom and
knowledge to Orient the PLR for its forwarding decision, more in
Section 5.4;
Decide: A local PLR that decides which DetNet Path to use for the
future packet(s) that are routed along the recovery graph, more in
Section 5.5;
Act: PREOF Dataplane actions are controlled from the DetNet Service
Thubert Expires 5 September 2024 [Page 32]
Internet-Draft RAW Architecture March 2024
sub-layer to increase the reliability of the end-to-end
transmission. The RAW architecture also covers in-situ signaling
when the decision is Acted by a node that down the recovery graph
from the PLR, more in Section 5.6.
+-------> Orient (aCPF) -------+
| reflex actions |
| pre-trained model |
| ... |
| v
Observe (OAM) Decide (PLR)
^ |
| |
| |
+-------- Act (PREOF) <--------+
At DetNet
Service sub-layer
Figure 9: The RAW OODA Loop
The overall OODA Loop optimizes the use of redundancy to achieve the
required reliability and availability Service Level Agreement (SLA)
while minimizing the use of constrained resources such as spectrum
and battery.
5.3. Observe: The RAW OAM
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 packets may be load balanced, replicated, eliminated, and /
or fragmented for Network Coding (NC) forward error correction (FEC),
the RAW In-situ operation needs to be able to signal which operation
occured to an individual packet.
Active RAW OAM may be needed to observe the unused segments and
evaluate the desirability of a rerouting decision.
Finally, the RAW Service sub-layer Assurance may observe the
individual PREOF operation of a relay node to ensure that it is
conforming; this might require injecting an OAM packet at an upstream
point inside the recovery graph and extracting that packet at another
point downstream before it reaches the egress.
This observation feeds the RAW PLR that makes the decision on which
path is used at which RAW Node, for one a small continuous series of
packets.
Thubert Expires 5 September 2024 [Page 33]
Internet-Draft RAW Architecture March 2024
... ..
RAN 1 ----- ... .. ...
/ . .. ....
+-------+ / . .. .... +------+
|Ingress|- . ..... |Egress|
| End |------ RAN 2 -- . Internet ....---| End |
|System |- .. ..... |System|
+-------+ \ . ...... +------+
\ ... ... .....
RAN n -------- ... .....
<------------------> <-------------------->
Observed by OAM Opaque to OAM
Figure 10: Observed Links in Radio Access Protection
In the case of a End-to-End Protection in a Wireless Mesh, the
recovery graph is strict and congruent with the path so all links are
observed.
Conversely, in the case of Radio Access Protection illustrated in
Figure 10, the recovery graph is Loose and only the first hop is
observed; the rest of the path is abstracted and considered
infinitely reliable. The loss if a packet is attributed to the first
hop Radio Access Network (RAN), even if a particular loss effectively
happens 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.
The Links that are not observed by OAM are opaque to it, meaning that
the OAM information is carried across and possibly echoed as data,
but there is no information capture in intermediate nodes. In the
example above, the Internet is opaque and not controlled by RAW;
still the RAW OAM measures the end-to-end latency and delivery ratio
for packets sent via each if RAN 1, RAN 2 and RAN 3, and determines
whether a packet should be sent over either or a collection of those
access links.
5.4. Orient: The RAW-extended DetNet Operational Plane
RAW separates the long time scale at which a recovery graph is
elaborated and installed, from the short time scale at which the
forwarding decision is taken for one or a few packets (see in
Section 5.1) that will experience the same path until the network
conditions evolve and another path is selected within the same
recovery graph.
Thubert Expires 5 September 2024 [Page 34]
Internet-Draft RAW Architecture March 2024
The recovery graph computation is out of scope, but RAW expects that
the CPF that installs the recovery graph also provides related
knowledge in the form of meta data about the links, segments and
possible DetNet Paths. That meta data can be a pre-digested
statistical model, and may include prediction of future flaps and
packet loss, as well as recommended actions when that happens.
The meta data may include:
* A set of Pre-Determined DetNet Paths that are prepared to match
expected link degradation profiles, so the DDCPEs can take reflex
rerouting actions when facing a degradation that matches one such
profile.
* 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
The recovery graph is installed with measurable objectives that are
computed by the rCPF to achieve the RAW SLA. The objectives can be
expressed as any of maximum number of packet lost in a row, bounded
latency, maximal jitter, maximum number of interleaved out of order
packets, average number of copies received at the elimination point,
and maximal delay between the first and the last received copy of the
same packet.
5.5. Decide: The Point of Local Repair
The RAW OODA Loop operates at the path selection time scale to
provide agility vs. the brute force approach of flooding the whole
recovery graph. The OODA Loop controls, within the redundant
solutions that are proposed by the acynchronous CPF, which will be
used for each packet to provide a Reliable and Available service
while minimizing the waste of constrained resources.
To that effect, RAW defines the Point of Local Repair (PLR) as a
synchronous CPF that performs rapid local adjustments of the
forwarding tables within the diversity that the asynchronous CPF has
in store for the recovery graph. The PLR enables to exploit the
richer forwarding capabilities at a faster time scale over the
smaller domain that is the recovery graph, in either a loose or a
strict fashion.
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 metrics updates by changing the DetNet path
in use for the affected flows.
Thubert Expires 5 September 2024 [Page 35]
Internet-Draft RAW Architecture March 2024
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 outside the recovery graph. This is as opposed to the
rCPF that must observe the whole network and optimize all the
recovery graphs globally, which can only be done at a slow pace and
using long-term statistical metrics, as presented in Table 1.
+===============+=============================+===================+
| | rCPF | PLR (In Scope) |
+===============+=============================+===================+
| Operation | Typically Centralized | Source-Routed or |
| | | Distributed |
+---------------+-----------------------------+-------------------+
| Communication | Slow, expensive | Fast, local |
+---------------+-----------------------------+-------------------+
| Time Scale | hours and above | seconds and below |
+---------------+-----------------------------+-------------------+
| Network Size | Large, many recovery graphs | Small, within one |
| | to optimize globally | recovery graph |
+---------------+-----------------------------+-------------------+
| Considered | Averaged, Statistical, | Instant values / |
| Metrics | Shade of grey | boolean condition |
+---------------+-----------------------------+-------------------+
Table 1: CPF vs. PLR
The PLR sits in the DetNet Service sub-Layer of Edge and Relay Nodes.
On the one hand, it operates on the packet flow, learning the
recovery graph and path selection information from the packet,
possibly making local decision and 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 (through iOAM and
oOAM) to obtain up-to-date information about its links and the
quality of the overall recovery graph, respectively, as illustrated
in Figure 11.
Thubert Expires 5 September 2024 [Page 36]
Internet-Draft RAW Architecture March 2024
|
packet | going
down the | stack
+==========v==========+=====================+=====================+
| (iOAM + iCTRL) | (L2 Triggers, DLEP) | (oOAM) |
+==========v==========+=====================+=====================+
| Learn from | | Learn from |
| packet tagging > Maintain < end-to-end |
+----------v----------+ Forwarding | OAM packets |
| Forwarding decision < State +---------^-----------|
+----------v----------+ | Enrich or |
+ Retag Packet | Learn abstracted > Regenerate |
| and Forward | metrics about Links | OAM packets |
+..........v..........+..........^..........+.........^.v.........+
| Lower layers |
+..........v.....................^....................^.v.........+
frame | sent Frame | L2 Ack oOAM | | packet
over | wireless In | In | | and out
v | | v
Figure 11: PLR Interfaces
5.6. Act: DetNet Path Selection and reliability functions
The main action by the PLR is the swapping of the DetNet Path within
the recovery graph for the future packets. The candidate DetNet
Paths represent different energy and spectrum profiles, and provide
protection against different failures.
The RAW API enriches the DetNet protection services (PREOF) with
potential possiblity to interact with lower layer one-hop reliability
functions that are more typical to wireless than wires, including
Automatic Repeat reQuest (ARQ), Forward Error Correction (FEC),
Hybrid ARQ (HARQ) that includes both, and other techniques such as
overhearing and constructive interferences. Because RAW may be
leveraged on wired links, e.g., to save power, it is not expected
that all lower layers support all those capabilities.
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 that outcome, e.g., a level of reliability for one-
hop transmission within a bounded budget of time and/or energy.
Thus, the RAW API makes possible cross-layer optimization for
reliability depending on the actual abstraction provided. That is,
some reliability functions are controlled from Layer-3 using an
abstract interface, while they are really operated at the lower
layers.
Thubert Expires 5 September 2024 [Page 37]
Internet-Draft RAW Architecture March 2024
The RAW Path Selection can be implemented in both centralized and
distributed scheduling approaches. 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 for the
current state of the wireless links. 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 the select DetNet
Path based on a better knowledge of the rest of the way.
The dynamic DetNet Path selection in RAW avoids the waste of critical
resources such as spectrum and energy while providing for the
guaranteed SLA, e.g., by rerouting and/or adding redundancy only when
a spike of loss is observed.
6. Security Considerations
RAW uses all forms of diversity including radio technology and
physical path to increase the reliability and availability in the
face of unpredictable conditions. While this is not done
specifically to defeat an attacker, the amount of diversity used in
RAW makes an attack harder to achieve.
6.1. Layer-2 encryption
Radio networks typically encrypt at the MAC layer to protect the
transmission. If the encryption is per pair of peers, then certain
RAW operations like promiscuous overhearing become impossible.
6.2. Forced Access
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 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 transmission for the user.
7. IANA Considerations
This document has no IANA actions.
8. Contributors
The editor wishes to thank the document co-authors:
Lou Berger: Lab N
Xavi Vilajosana: Wireless Networks Research Lab, Universitat Oberta
de Catalunya
Thubert Expires 5 September 2024 [Page 38]
Internet-Draft RAW Architecture March 2024
Geogios Papadopolous: IMT Atlantique
Remous-Aris Koutsiamanis: IMT Atlantique
Rex Buddenberg: Individual contributor
Greg Mirsky: Ericsson
for their contributions to the text and ideas exposed in this
document.
9. Acknowledgments
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.
The authors wish to thank Balazs Varga, Dave Cavalcanti, Don Fedyk,
Nicolas Montavont, and Fabrice Theoleyre for their in-depth reviews
during the development of this document.
10. References
10.1. Normative References
[6TiSCH-ARCHI]
Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>.
[INT-ARCHI]
Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006,
<https://www.rfc-editor.org/info/rfc4427>.
[RAW-TECHNOS]
Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C.,
and J. Farkas, "Reliable and Available Wireless
Technologies", Work in Progress, Internet-Draft, draft-
Thubert Expires 5 September 2024 [Page 39]
Internet-Draft RAW Architecture March 2024
ietf-raw-technologies-08, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-
technologies-08>.
[RAW-USE-CASES]
Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F.
Theoleyre, "RAW Use-Cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-11, 17 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
cases-11>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
RFC 8578, DOI 10.17487/RFC8578, May 2019,
<https://www.rfc-editor.org/info/rfc8578>.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,
<https://www.rfc-editor.org/info/rfc8557>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
<https://www.rfc-editor.org/info/rfc8939>.
Thubert Expires 5 September 2024 [Page 40]
Internet-Draft RAW Architecture March 2024
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/info/rfc9049>.
10.2. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[TE] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
Xiao, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002,
<https://www.rfc-editor.org/info/rfc3272>.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
DOI 10.17487/RFC3366, August 2002,
<https://www.rfc-editor.org/info/rfc3366>.
[STD 62] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002,
<https://www.rfc-editor.org/info/rfc3411>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[FRR] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>.
Thubert Expires 5 September 2024 [Page 41]
Internet-Draft RAW Architecture March 2024
[RLFA-FRR] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
[DetNet-DP]
Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane
Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
<https://www.rfc-editor.org/info/rfc8938>.
[DLEP] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
DOI 10.17487/RFC8175, June 2017,
<https://www.rfc-editor.org/info/rfc8175>.
[I-D.irtf-panrg-path-properties]
Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path
Properties", Work in Progress, Internet-Draft, draft-irtf-
panrg-path-properties-08, 6 March 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-panrg-
path-properties-08>.
[IPoWIRELESS]
Thubert, P. and M. Richardson, "Architecture and Framework
for IPv6 over Non-Broadcast Access", Work in Progress,
Internet-Draft, draft-thubert-6man-ipv6-over-wireless-15,
8 March 2023, <https://datatracker.ietf.org/doc/html/
draft-thubert-6man-ipv6-over-wireless-15>.
[DetNet-OAM]
Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos,
C. J., Varga, B., and J. Farkas, "Framework of Operations,
Administration and Maintenance (OAM) for Deterministic
Networking (DetNet)", Work in Progress, Internet-Draft,
draft-ietf-detnet-oam-framework-11, 8 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
oam-framework-11>.
[NASA] Adams, T., "RELIABILITY: Definition & Quantitative
Illustration", <https://kscddms.ksc.nasa.gov/Reliability/
Documents/150814-3bWhatIsReliability.pdf>.
Author's Address
Pascal Thubert (editor)
06330 Roquefort-les-Pins
France
Thubert Expires 5 September 2024 [Page 42]
Internet-Draft RAW Architecture March 2024
Email: pascal.thubert@gmail.com
Thubert Expires 5 September 2024 [Page 43]