3. Terminology
This section preserves the RFC text for the RAW architecture, including RAW, DetNet, TSN, OAM, PREOF, PLR, PSE, PCE, PDR, SLA, SLO, SLI, recovery graphs, protection paths, LL API, diagrams, tables, and security considerations.
Original RFC Text
3. Terminology
RAW reuses terminology defined for DetNet in "Deterministic
Networking Architecture" [DetNet-ARCH], e.g., "PREOF" to stand for
"Packet Replication, Elimination, and Ordering Functions". RAW
inherits and augments IETF recovery mechanisms such as the ones
provided in DetNet [DetNet-ARCH] and in Traffic Engineering, e.g.,
[RFC4090].
RAW also reuses terminology defined for Operations, Administration,
and Maintenance (OAM) protocols in Section 1.1 of "Framework of
Operations, Administration, and Maintenance (OAM) for Deterministic
Networking (DetNet)" [DetNet-OAM] and in "Active and Passive Metrics
and Methods (with Hybrid Types In-Between)" [RFC7799].
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. That document defines a number of
concepts, such as the recovery domain, that are used in RAW
mechanisms and defines the new term "recovery graph". A recovery
graph associates a topological graph with usage metadata that
represents how the paths are built and used within the recovery
graph. The recovery graph provides excess bandwidth for the intended
traffic over alternate potential paths, and the use of that bandwidth
is optimized dynamically.
The concept of a 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.
RAW also reuses terminology defined for RSVP-TE in [RFC4090], such as
the "Point of Local Repair (PLR)". The concept of a backup path is
generalized with protection path, which is the term mostly found in
recent standards and used in this document.
RAW also reuses terminology defined for 6TiSCH in [6TiSCH-ARCH] and
equates the 6TiSCH concept of a Track with that of a recovery graph.
3.1. Abbreviations
RAW uses the following abbreviations.
ARQ
Automatic Repeat Request. A well-known mechanism that enables an
acknowledged transmission with retries to mitigate errors and
loss. ARQ may be implemented at various layers in a network. ARQ
is typically implemented per hop (not end to end) at Layer 2 in
wireless networks. ARQ improves delivery on lossy wireless.
Additionally, ARQ retransmission may be further limited by a
bounded time to meet end-to-end packet latency constraints.
Additional details and considerations for ARQ are detailed in
[RFC3366].
FEC
Forward Error Correction. Adding redundant data to protect
against a partial loss without retries.
HARQ
Hybrid ARQ. A combination of FEC and ARQ.
ETX
Expected Transmission Count. A statistical metric that represents
the expected total number of packet transmissions (including
retransmissions) required to successfully deliver a packet along a
path, used by 6TiSCH [RFC6551].
ISM
Industrial, Scientific, and Medical. Refers to a group of radio
bands or parts of the radio spectrum (e.g., 2.4 GHz and 5 GHz)
that are internationally reserved for the use of radio frequency
(RF) energy intended for industrial, scientific, and medical
requirements (e.g., by microwaves, depth radars, and medical
diathermy machines). Cordless phones, Bluetooth and Low-Power
Wireless Personal Area Network (LoWPAN) devices, near-field
communication (NFC) devices, garage door openers, baby monitors,
and Wi-Fi networks may all use the ISM frequencies, although these
low-power transmitters are not considered to be ISM devices. In
general, communications equipment operating in ISM bands must
tolerate any interference generated by ISM applications, and users
have no regulatory protection from ISM device operation in these
bands.
PER
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.
PDR
Packet Delivery Ratio (PDR). The ratio of the number of
successfully delivered data packets to the total number of packets
transmitted from the sender to the receiver.
RSSI
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 technology
using the same band, or background radiation. For a single hop,
RSSI may be used for LQI.
LQI
Link Quality Indicator. An indication of the quality of the data
packets received by the receiver. It is typically derived from
packet error statistics, with the exact method depending on the
network stack being used. 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.
OAM
Operations, Administration, and Maintenance. Covers the
processes, activities, tools, and standards involved with
operating, administering, managing, and maintaining any system.
This document uses the term in conformance with "Guidelines for
the Use of the 'OAM' Acronym in the IETF" [RFC6291], and the
system observed by the RAW OAM is the recovery graph.
OODA
Observe, Orient, Decide, Act. A generic formalism to represent the
operational steps in a control loop. In the context of RAW, OODA
is applied to network control and convergence; see Section 6.2 for
more.
SNR
Signal-to-Noise Ratio. Also known as "S/N Ratio". A measure used
in science and engineering that compares the level of a desired
signal to the level of background noise. SNR is defined as the
ratio of signal power to noise power, often expressed in decibels.
3.2. Link and Direction
This document uses the following terms relating to links and
direction in the context of RAW.
3.2.1. Flapping
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 to seconds.
3.2.2. Uplink
An uplink is the connection from end devices to data communication
equipment. In the context of wireless, uplink refers to the
connection between a station (STA) and a controller (AP) or a User
Equipment (UE) and a Base Station (BS) such as a 3GPP 5G gNodeB
(gNB).
3.2.3. Downlink
A downlink is the reverse direction from uplink.
3.2.4. Downstream
Downstream refers to the following the direction of the flow data
path along a recovery graph.
3.2.5. Upstream
Upstream refers to going against the direction of the flow data path
along a recovery graph.
3.3. Path and Recovery Graphs
This document uses the following terms relating to paths and recovery
graphs in the context of RAW.
3.3.1. Path
Section 1.3.3 of [INT-ARCH] provides a definition of path:
| At a given moment, all the IP datagrams from a particular source
| host to a particular destination host will typically traverse the
| same sequence of gateways. We use the term "path" for this
| sequence. Note that a path is uni-directional; it is not unusual
| to have different paths in the two directions between a given host
| pair.
Section 2 of [RFC9473] points to a longer, more modern definition of
path, which begins as follows:
| A sequence of adjacent path elements over which a packet can be
| transmitted, starting and ending with a node.
|
| 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
| packets are transmitted may change. A path definition can be
| strict (i.e., the exact sequence of path elements remains the
| same) or loose (i.e., the start and end node remain the same, but
| the path elements between them may vary over time).
|
| The representation of a path and its properties may depend on the
| entity considering the path. On the one hand, the representation
| may differ due to entities having partial visibility of path
| elements comprising a path or their visibility changing over time.
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 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 or one fragment of a packet that conserves its uniqueness and
integrity. For instance, if C replicates to E and F and if D
eliminates duplicates, 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 paths may be fully non-congruent; alternatively,
they may intersect at replication or elimination points.
With DetNet and RAW, a packet may be duplicated, fragmented, and
network coded, and the various byproducts may travel different paths
that are not necessarily end to end 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, but it still matches the
experience of a packet that traverses the network.
With RAW, the path experienced by a packet is subject to change from
one packet to the next, but all the possible experiences are all
contained within a finite set. Therefore, we introduce the term
"recovery graph" (see the next section) that coalesces 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 a flow may experience, each with its own statistical
probability to be used.
3.3.2. Recovery Graph
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 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. 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.
_________
| |
| IoT G/W |
|_________|
EGRESS <<=== Elimination at Egress
| |
---+--------+--+--------+--------
| Backbone |
__|__ __|__
| | Backbone | | Backbone
|__ __| Router |__ __| Router
| # |
# \ # / <-- protection path
# # #-------#
\ # / # ( Low-power )
# # \ / # ( Lossy Network)
\ /
# INGRESS <<=== Replication at recovery graph ingress
|
# <-- source device
#: Low-power device
Figure 1: Example IoT Recovery Graph to an IoT Gateway with 1+1
Redundancy
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. A packet that is assigned to the recovery graph
experiences one of the feasible DetNet paths based on the current
selection by the PLR at the time the packet traverses the network.
Refining even further, the feasible DetNet paths within the recovery
graph may or may not be computed in advance; instead, they may be
decided upon the detection of a change from a clean slate.
Furthermore, the PLR decision may be distributed, which yields a
large combination of possible and dependent decisions, with no node
in the network capable of reporting which is the current DetNet path
within the recovery graph.
In DetNet [DetNet-ARCH] terms, a recovery graph has the following
properties:
* A recovery graph is a Layer 3 abstraction built upon IP links
between routers. A router may form multiple IP links over a
single radio interface.
* A recovery graph has one ingress and one egress node, which
operate as DetNet edge nodes.
* 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.
* 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.
Figure 2 illustrates the generic concept of a recovery graph, between
an ingress node and an egress node. The recovery graph is composed
of forward protection paths, forward segments, and crossing segments
(see the definitions of those terms in the next sections). The
recovery graph contains at least two protection paths: a main path
and a backup path.
------------------- forward direction ---------------------->
a ==> b ==> C -=- F ==> G ==> h T1
/ \ / | \ /
I o n E -=- T2
\ / \ | / \
p ==> q ==> R -=- T ==> U ==> v T3
I: Ingress
E: Egress
T1, T2, T3: external targets
Uppercase: DetNet relay nodes
Lowercase: DetNet transit nodes
Figure 2: A Recovery Graph and Its Components
Of note:
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: A segment-crossing protection path
3.3.3. Forward and Crossing
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 only be transmitted along the link direction.
Crossing links are bidirectional, 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 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
forward, meaning that it is composed of forward links and segments.
3.3.4. Protection Path
A protection path is an end-to-end forward path between the ingress
and egress nodes of a recovery graph. A protection path in a
recovery graph is expressed as a strict sequence of DetNet relay
nodes or as a loose sequence of DetNet relay nodes that are joined by
segments in the recovery graph. Background information on the
concepts related to protection paths can be found in [RFC4427] and
[RFC6378].
3.3.5. Segment
A segment is a strict sequence of DetNet transit nodes between two
DetNet relay nodes; a segment of a recovery graph is composed
topologically of two vertices of the recovery graph and one edge of
the recovery graph between those vertices.
3.4. Deterministic Networking
This document reuses the terminology in Section 2 of [RFC8557] and
Section 4.1.2 of [DetNet-ARCH] for deterministic networking and
deterministic networks. This document also uses the following terms.
3.4.1. The DetNet Planes
[DetNet-ARCH] defines three planes: the Application (User) Plane, the
Controller Plane, and the Network Plane. The DetNet Network Plane is
composed of a Data Plane (packet forwarding) and an Operational Plane
where OAM operations take place. In the Network Plane, the DetNet
Service sub-layer 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, associates the flows to the paths,
ensures the availability of the necessary resources, and leverages
Layer 2 functionalities for timely delivery to the next DetNet
system. For more information, see Section 2.
3.4.2. Flow
A flow is a collection of consecutive IP packets defined by the upper
layers and signaled by the same 5-tuple or 6-tuple (see Section 5.1
of [RFC8939]). Packets of the same flow must be placed on the same
recovery graph to receive an equivalent treatment from ingress to
egress 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 control of the PLR.
3.4.3. Residence Time
A residence time (RT) is defined as the time interval between when
the reception of a packet starts and the transmission of the packet
begins. In the context of RAW, RT is useful for a transit nodes, not
ingress or egress nodes.
3.4.4. L3 Deterministic Flow Identifier
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.
3.4.5. Time-Sensitive Networking
Time-Sensitive Networking (TSN) denotes the IEEE 802 efforts
regarding deterministic networking, originally for use on Ethernet.
See [TSN]. Wireless TSN (WTSN) denotes extensions of the TSN work on
wireless media, e.g., the RAW technologies described in
[RAW-TECHNOS].
3.4.6. Lower-Layer API
RAW includes the concept of a lower-layer API (LL API) that provides
an interface between the lower-layer (e.g., wireless) technology and
the DetNet layers. The LL API is technology dependent as what the
lower layers expose towards the DetNet layers may vary. Furthermore,
different RAW technologies are equipped with different reliability
features (e.g., short-range broadcast, Multiple User - Multiple Input
Multiple Output (MU-MIMO), physical layer (PHY) rate and other
Modulation Coding Scheme (MCS) adaptation, coding and retransmissions
methods, and constructive interference and overhearing; see
[RAW-TECHNOS] for more details). The LL API enables interactions
between the reliability functions provided by the lower layer and the
reliability functions provided by DetNet. That is, the LL API makes
cross-layer optimization possible for the reliability functions of
different layers depending on the actual exposure provided via the LL
API by the given RAW technology. The Dynamic Link Exchange Protocol
(DLEP) [DLEP] is an example of a protocol that can be used to
implement the LL API.
3.5. Reliability and Availability
In the context of the RAW work, reliability and availability are
defined as follows, along with the following other terms.
3.5.1. Service Level Agreement
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 defines measurable metrics such as latency boundaries,
consecutive losses, and Packet Delivery Ratio (PDR).
3.5.2. Service Level Objective
A Service Level Objective (SLO) is one term in the SLA, for which
specific network setting and operations are implemented. For
instance, a dynamic 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.
3.5.3. Service Level Indicator
A Service Level Indicator (SLI) measures the compliance of an SLO to
the terms of the contract. For instance, it can be the statistics of
individual losses or losses in a row during a certain amount of time.
3.5.4. Precision Availability Metrics
Precision Availability Metrics (PAMs) [RFC9544] aim to capture
service levels for a flow, specifically the degree to which the flow
complies with the SLOs that are in effect.
3.5.5. Reliability
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 period of time (or for a stated number of demands or
load) under stated environmental 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) for a stated
mission (e.g., to provide an SLA). See more in [NASA1].
3.5.6. Availability
Availability is the probability of an item's (e.g., a network's)
mission readiness (e.g., to provide an SLA). Availability is
expressed as (uptime)/(uptime+downtime). Note that it is
availability that addresses downtime (including time for maintenance,
repair, and replacement activities) and not reliability. See more in
[NASA2].