< draft-ietf-raw-architecture-00.txt   draft-ietf-raw-architecture-01.txt >
RAW P. Thubert, Ed. RAW P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational G.Z. Papadopoulos Intended status: Informational G.Z. Papadopoulos
Expires: 10 January 2022 IMT Atlantique Expires: 29 January 2022 IMT Atlantique
L. Berger L. Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
9 July 2021 28 July 2021
Reliable and Available Wireless Architecture/Framework Reliable and Available Wireless Architecture/Framework
draft-ietf-raw-architecture-00 draft-ietf-raw-architecture-01
Abstract Abstract
Reliable and Available Wireless (RAW) provides for high reliability Reliable and Available Wireless (RAW) provides for high reliability
and availability for IP connectivity over a wireless medium. The and availability for IP connectivity over a wireless medium. The
wireless medium presents significant challenges to achieve wireless medium presents significant challenges to achieve
deterministic properties such as low packet error rate, bounded deterministic properties such as low packet error rate, bounded
consecutive losses, and bounded latency. This document defines the consecutive losses, and bounded latency. This document defines the
RAW Architecture. It builds on the DetNet Architecture and discusses RAW Architecture following an OODA loop that involves OAM, PCE, PSE
specific challenges and technology considerations needed to deliver and PAREO functions. It builds on the DetNet Architecture and
DetNet service utilizing scheduled wireless segments and other media, discusses specific challenges and technology considerations needed to
e.g., frequency/time-sharing physical media resources with stochastic deliver DetNet service utilizing scheduled wireless segments and
traffic. other media, e.g., frequency/time-sharing physical media resources
with stochastic traffic.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 January 2022. This Internet-Draft will expire on 29 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The RAW problem . . . . . . . . . . . . . . . . . . . . . . . 5 2. The RAW problem . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Reliability and Availability . . . . . . . . . . . . . . 7 2.2. Reliability and Availability . . . . . . . . . . . . . . 8
2.2.1. High Availability Engineering Principles . . . . . . 8 2.2.1. High Availability Engineering Principles . . . . . . 8
2.2.2. Applying Reliability Concepts to Networking . . . . . 10 2.2.2. Applying Reliability Concepts to Networking . . . . . 11
2.2.3. Reliability in the Context of RAW . . . . . . . . . . 11 2.2.3. Reliability in the Context of RAW . . . . . . . . . . 11
2.3. Use Cases and Requirements Served . . . . . . . . . . . . 12 2.3. Use Cases and Requirements Served . . . . . . . . . . . . 13
2.3.1. Radio Access Protection . . . . . . . . . . . . . . . 13 2.3.1. Radio Access Protection . . . . . . . . . . . . . . . 13
2.3.2. End-to-End Protection in a Wireless Mesh . . . . . . 13 2.3.2. End-to-End Protection in a Wireless Mesh . . . . . . 14
2.4. Related Work at The IETF . . . . . . . . . . . . . . . . 14 2.4. Related Work at The IETF . . . . . . . . . . . . . . . . 14
3. The RAW Framework . . . . . . . . . . . . . . . . . . . . . . 15 3. The RAW Framework . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Scope and Prerequisites . . . . . . . . . . . . . . . . . 15 3.1. Scope and Prerequisites . . . . . . . . . . . . . . . . . 16
3.2. Routing Time Scale vs. Forwarding Time Scale . . . . . . 16 3.2. Routing Time Scale vs. Forwarding Time Scale . . . . . . 16
3.3. Wireless Tracks . . . . . . . . . . . . . . . . . . . . . 17 3.3. Wireless Tracks . . . . . . . . . . . . . . . . . . . . . 18
3.4. PAREO Functions . . . . . . . . . . . . . . . . . . . . . 18 3.4. Flow Identification vs. Path Identification . . . . . . . 19
3.4.1. Packet Replication . . . . . . . . . . . . . . . . . 19 3.5. Source-Routed vs. Distributed Forwarding Decision . . . . 21
3.4.2. Packet Elimination . . . . . . . . . . . . . . . . . 20 3.6. Encapsulation and Decapsulation . . . . . . . . . . . . . 22
3.4.3. Promiscuous Overhearing . . . . . . . . . . . . . . . 20 4. The RAW Architecture . . . . . . . . . . . . . . . . . . . . 22
3.4.4. Constructive Interference . . . . . . . . . . . . . . 20 4.1. The RAW Conceptual Model . . . . . . . . . . . . . . . . 22
4. The RAW Architecture . . . . . . . . . . . . . . . . . . . . 21 4.2. The OODA Loop . . . . . . . . . . . . . . . . . . . . . . 24
4.1. The RAW Conceptual Model . . . . . . . . . . . . . . . . 21 4.3. Observe: The RAW OAM . . . . . . . . . . . . . . . . . . 25
4.2. The Path Selection Engine . . . . . . . . . . . . . . . . 23 4.3.1. DetNet OAM . . . . . . . . . . . . . . . . . . . . . 26
4.3. RAW OAM . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3.2. RAW Extensions . . . . . . . . . . . . . . . . . . . 27
4.3.1. DetNet OAM . . . . . . . . . . . . . . . . . . . . . 25
4.3.2. RAW Extensions . . . . . . . . . . . . . . . . . . . 26
4.3.3. Observed Metrics . . . . . . . . . . . . . . . . . . 27 4.3.3. Observed Metrics . . . . . . . . . . . . . . . . . . 27
4.4. Flow Identification vs. Path Identification . . . . . . . 27 4.4. Orient: The Path Computation Engine . . . . . . . . . . . 28
4.5. Source-Routed vs. Distributed Forwarding Decision . . . . 30 4.5. Decide: The Path Selection Engine . . . . . . . . . . . . 28
4.6. Encapsulation and Decapsulation . . . . . . . . . . . . . 31 4.6. Act: The PAREO Functions . . . . . . . . . . . . . . . . 30
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 4.6.1. Packet Replication . . . . . . . . . . . . . . . . . 31
5.1. Forced Access . . . . . . . . . . . . . . . . . . . . . . 31 4.6.2. Packet Elimination . . . . . . . . . . . . . . . . . 32
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 4.6.3. Promiscuous Overhearing . . . . . . . . . . . . . . . 32
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 4.6.4. Constructive Interference . . . . . . . . . . . . . . 33
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.1. Forced Access . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . 32 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . 34 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Deterministic Networking is an attempt to emulate the properties of a Deterministic Networking is an attempt to emulate the properties of a
serial link over a switched fabric, by providing a bounded latency serial link over a switched fabric, by providing a bounded latency
and eliminating congestion loss, even when co-existing with best- and eliminating congestion loss, even when co-existing with best-
effort traffic. It is getting traction in various industries effort traffic. It is getting traction in various industries
including professional A/V, manufacturing, online gaming, and including professional A/V, manufacturing, online gaming, and
smartgrid automation, enabling cost and performance optimizations smartgrid automation, enabling cost and performance optimizations
(e.g., vs. loads of P2P cables). (e.g., vs. loads of P2P cables).
skipping to change at page 4, line 31 skipping to change at page 4, line 31
RAW provides DetNet elements that are specialized for short range RAW provides DetNet elements that are specialized for short range
radios. From this inheritance, RAW stays agnostic to the radio layer radios. From this inheritance, RAW stays agnostic to the radio layer
underneath though the capability to schedule transmissions is underneath though the capability to schedule transmissions is
assumed. How the PHY is programmed to do so, and whether the radio assumed. How the PHY is programmed to do so, and whether the radio
is single-hop or meshed, are unknown at the IP layer and not part of is single-hop or meshed, are unknown at the IP layer and not part of
the RAW abstraction. the RAW abstraction.
The "Deterministic Networking Architecture" [RFC8655] is composed of The "Deterministic Networking Architecture" [RFC8655] is composed of
three planes: the Application (User) Plane, the Controller Plane, and three planes: the Application (User) Plane, the Controller Plane, and
the Network Plane. The RAW Architecture extends the DetNet Network the Network Plane. The RAW Architecture extends the DetNet Network
Plane, to accomodate one or multiple hops of homogeneous or Plane, to accommodate one or multiple hops of homogeneous or
heterogeneous wireless technologies, e.g. a Wi-Fi6 Mesh or parallel heterogeneous wireless technologies, e.g. a Wi-Fi6 Mesh or parallel
CBRS access links federated by a 5G backhaul. CBRS access links federated by a 5G backhaul.
The establishment of a path is not in-scope for RAW. It may be the The establishment of a path is not in-scope for RAW. It may be the
product of a centralized Controller Plane as described for DetNet. product of a centralized Controller Plane as described for DetNet.
As opposed to wired networks, the action of installing a path over a As opposed to wired networks, the action of installing a path over a
set of wireless links may be very slow relative to the speed at which set of wireless links may be very slow relative to the speed at which
the radio conditions vary, and it makes sense in the wireless case to the radio conditions vary, and it makes sense in the wireless case to
provide redundant forwarding solutions along a complex path and to provide redundant forwarding solutions along a complex path and to
leave it to the Network Plane to select which of those forwarding leave it to the Network Plane to select which of those forwarding
skipping to change at page 5, line 5 skipping to change at page 5, line 5
conditions. conditions.
RAW distinguishes the longer time scale at which routes are computed RAW distinguishes the longer time scale at which routes are computed
from the the shorter forwarding time scale where per-packet decisions from the the shorter forwarding time scale where per-packet decisions
are made. RAW operates within the Network Plane at the forwarding are made. RAW operates within the Network Plane at the forwarding
time scale on one DetNet flow over a complex path called a Track. time scale on one DetNet flow over a complex path called a Track.
The Track is preestablished and installed by means outside of the The Track is preestablished and installed by means outside of the
scope of RAW; it may be strict or loose depending on whether each or scope of RAW; it may be strict or loose depending on whether each or
just a subset of the hops are observed and controlled by RAW. just a subset of the hops are observed and controlled by RAW.
The RAW Architecture covers Network Plane protocol elements such as The RAW Architecture is structured as an OODA Loop (Observe, Orient,
Operations, Administration and Maintenance (OAM) to observe some or Decide, Act). It involves:
all hops along a Track as well as the end-to-end packet delivery, and
in-band control to optimize the use of redundancy to achieve the 1. Network Plane measurement protocols for Operations,
required SLA with minimal use of constrained resources. Administration and Maintenance (OAM) to Observe some or all hops
along a Track as well as the end-to-end packet delivery
2. Controller plane elements to reports the links statistics to a
Path computation Element (PCE) in a centralized controller that
computes and installs the Tracks and provides meta data to Orient
the routing decision
3. A Runtime distributed Path Selection Engine (PSE) thar Decides
which subTrack to use for the next packet(s) that are routed
along the Track
4. Packet (hybrid) ARQ, Replication, Elimination and Ordering
Dataplane actions that operate at the DetNet Service Layer to
increase the reliability of the end-to-end transmission. The RAW
architecture also covers in-situ signalling when the decision is
Acted by a node that down the Track from the PSE.
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.
2. The RAW problem 2. The RAW problem
2.1. Terminology 2.1. Terminology
RAW reuses terminology defined for DetNet in the "Deterministic RAW reuses terminology defined for DetNet in the "Deterministic
Networking Architecture" [RFC8655], e.g., PREOF for Packet Networking Architecture" [RFC8655], e.g., PREOF for Packet
Replication, Elimination and Ordering Functions. Replication, Elimination and Ordering Functions.
RAW also reuses terminology defined for 6TiSCH in [6TiSCH-ARCHI] such RAW also reuses terminology defined for 6TiSCH in [6TiSCH-ARCHI] such
as the term Track. A Track as a complex path with associated PAREO as the term Track. A Track as a complex path with associated PAREO
operations. The concept is abstract to the underlaying technology operations. The concept is abstract to the underlaying technology
and applies to any fully or partially wireless mesh, including, e.g., and applies to any fully or partially wireless mesh, including, e.g.,
a Wi-Fi mesh. RAW specifies strict and loose Tracks depending on a Wi-Fi mesh. RAW specifies strict and loose Tracks depending on
whether the path is fully controlled by RAW or traverses an opaque whether the path is fully controlled by RAW or traverses an opaque
network where RAW cannot observe and control the individual hops. network where RAW cannot observe and control the individual hops.
RAW uses the following terminology: RAW uses the following terminology:
OODA: Observe, Orient, Decide, Act. The OODA Loop is a conceptual
cyclic model developed by USAF Colonel John Boyd, and that is
applicable in multiple domains where agility can provide benefits
against brute force.
PAREO: Packet (hybrid) ARQ, Replication, Elimination and Ordering. PAREO: Packet (hybrid) ARQ, Replication, Elimination and Ordering.
PAREO is a superset Of DetNet's PREOF that includes radio-specific PAREO is a superset Of DetNet's PREOF that includes radio-specific
techniques such as short range broadcast, MUMIMO, constructive techniques such as short range broadcast, MUMIMO, constructive
interference and overhearing, which can be leveraged separately or interference and overhearing, which can be leveraged separately or
combined to increase the reliability. combined to increase the reliability.
Flow: A collection of consecutive packets that must be placed on the Flow: A collection of consecutive packets that must be placed on the
same Track to receive an equivalent treatment from Ingress to same Track to receive an equivalent treatment from Ingress to
Egress within the Track. Multiple flows may be transported along Egress within the Track. Multiple flows may be transported along
the same Track. The subTrack that is selected for the flow may the same Track. The subTrack that is selected for the flow may
skipping to change at page 7, line 12 skipping to change at page 7, line 39
a QoS and/or PAREO treatment that is different from that of the a QoS and/or PAREO treatment that is different from that of the
packets of the data flows that are injected in the Track, or both. packets of the data flows that are injected in the Track, or both.
Limited OAM: An active OAM packet is a Limited OAM packet when it Limited OAM: An active OAM packet is a Limited OAM packet when it
observes the RAW operation over a node, a segment, or a subTrack observes the RAW operation over a node, a segment, or a subTrack
of the Track, though not from Ingress to Egress. It is injected of the Track, though not from Ingress to Egress. It is injected
in the datapath and extracted from the datapath around the in the datapath and extracted from the datapath around the
particular function or subnetwork (e.g., around a relay providing particular function or subnetwork (e.g., around a relay providing
a service layer replication point) that is being tested. a service layer replication point) that is being tested.
Reverse OAM: A Reverse OAM packet is an Out-of-Band OAM packet that Upstream OAM: An upstream OAM packet is an Out-of-Band OAM packet
traverses the Track from egress to ingress on the reverse that traverses the Track from egress to ingress on the reverse
direction, to capture and report OAM measurements upstream. The direction, to capture and report OAM measurements upstream. The
collection may capture all information along the whole Track, or collection may capture all information along the whole Track, or
it may only learn select data across all, or only a particular it may only learn select data across all, or only a particular
subTrack, or Segment of a Track. subTrack, or Segment of a Track.
[DetNet-OAM] provides additional terminology related to OAM in the [DetNet-OAM] provides additional terminology related to OAM in the
context of DetNet and by extension of RAW, whereas [RFC7799] defines context of DetNet and by extension of RAW, whereas [RFC7799] defines
the Active, Passive, and Hybrid OAM methods. the Active, Passive, and Hybrid OAM methods.
In the context of the RAW work, Reliability and Availability are In the context of the RAW work, Reliability and Availability are
skipping to change at page 12, line 22 skipping to change at page 12, line 50
long period of time. long period of time.
Transmission losses are typically not independent, and their nature Transmission losses are typically not independent, and their nature
and duration are unpredictable; as long as a physical object (e.g., a and duration are unpredictable; as long as a physical object (e.g., a
metallic trolley between peers) that affects the transmission is not metallic trolley between peers) that affects the transmission is not
removed, or as long as the interferer (e.g., a radar) keeps removed, or as long as the interferer (e.g., a radar) keeps
transmitting, a continuous stream of packets will be affected. transmitting, a continuous stream of packets will be affected.
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 Different forms of diversity are necessary to combat different causes
of loss and the use of diversity must be maximised to optimize the of loss and the use of diversity must be maximized to optimize the
PDR. PDR.
A single packet may be sent at different times (time diversity) over A single packet may be sent at different times (time diversity) over
diverse paths (spatial diversity) that rely on diverse radio channels diverse paths (spatial diversity) that rely on diverse radio channels
(frequency diversity) and diverse PHY technologies, e.g., narrowband (frequency diversity) and diverse PHY technologies, e.g., narrowband
vs. spread spectrum, or diverse codes. Using time diversity will vs. spread spectrum, or diverse codes. Using time diversity will
defeat short-term interferences; spatial diversity combats very local defeat short-term interferences; spatial diversity combats very local
causes such as multipath fading; narrowband and spread spectrum are causes such as multipath fading; narrowband and spread spectrum are
relatively innocuous to one another and can be used for diversity in relatively innocuous to one another and can be used for diversity in
the presence of the other. the presence of the other.
skipping to change at page 18, line 9 skipping to change at page 18, line 44
A Complex Track provides multiple N-ECMP forwarding solutions. The A Complex Track provides multiple N-ECMP forwarding solutions. The
Complex Track enables to support multi-path redundant forwarding by Complex Track enables to support multi-path redundant forwarding by
employing PRE functions [RFC8655] and the ingress and within the employing PRE functions [RFC8655] and the ingress and within the
Track. For example, a Complex Track may branch off and rejoin over Track. For example, a Complex Track may branch off and rejoin over
non-congruent segments. non-congruent segments.
In the context of RAW, some links or segments in the Track may be In the context of RAW, some links or segments in the Track may be
reversible, meaning that they can be used in either direction. In reversible, meaning that they can be used in either direction. In
that case, an indication in the packet signals the direction of the that case, an indication in the packet signals the direction of the
reversible links or segments that the packet traverses and thus reversible links or segments that the packet traverses and thus
places a constraint that prevents loops from occuring. An indidual places a constraint that prevents loops from occurring. An
packet follows a destination-oriented directed acyclic graph (DODAG) individual packet follows a destination-oriented directed acyclic
towards a destination Node inside the Complex Track. graph (DODAG) towards a destination Node inside the Complex Track.
3.4. PAREO Functions
RAW may control whether and how to use packet replication and
elimination (PRE), Automatic Repeat reQuest (ARQ), Hybrid ARQ (HARQ)
that includes Forward Error Correction (FEC) and coding, and other
wireless-specific techniques such as overhearing and constructive
interferences, in order to increase the reliabiility and availability
of the end-to-end transmission.
Collectively, those function are called PAREO for Packet (hybrid)
ARQ, Replication, Elimination and Ordering. By tuning dynamically
the use of PAREO functions, RAW avoids the waste of critical
resources such as spectrum and energy while providing that the
guaranteed SLA, e.g., by adding redundancy only when a spike of loss
is observed.
In a nutshell, PAREO establishes several paths in a network to
provide redundancy and parallel transmissions to bound the end-to-end
delay to traverse the network. Optionally, promiscuous listening
between paths is possible, such that the Nodes on one path may
overhear transmissions along the other path. Considering the
scenario shown in Figure 4, many different paths are possible for to
traverse the network from ingress to egress. A simple way to benefit
from this topology could be to use the two independent paths via
Nodes A, C, E and via B, D, F. But more complex paths are possible
by interleaving transmissions from the lower level of the path to the
upper level.
(A) -- (C) -- (E)
/ \
Ingress = | | | = Egress
\ /
(B) -- (D) -- (F)
Figure 4: A Ladder Shape with Two Parallel Paths
PAREO may also take advantage of the shared properties of the 3.4. Flow Identification vs. Path Identification
wireless medium to compensate for the potential loss that is incurred
with radio transmissions.
For instance, when the source sends to Node A, Node B may listen Section 4.7 of the DetNet Architecture [RFC8655] ties the app-flow
promiscuously and get a second chance to receive the frame without an identification which is an application-layer concept with the network
additional transmission. Note that B would not have to listen if it path identification that depends on the networking technology by
already received that particular frame at an earlier timeslot in a "exporting of flow identification", e.g., to a MPLS label.
dedicated transmission towards B.
The PAREO model can be implemented in both centralized and With RAW, this exporting operation is injective but not bijective.
distributed scheduling approaches. In the centralized approach, a e.g., a flow is fully placed within one RAW Track, but not all
Path Computation Element (PCE) scheduler calculates a Track and packets along that Track are necessarily part of the same flow. For
schedules the communication. In the distributed approach, the Track instance, out-of-band OAM packets must circulate in the exact same
is computed within the network, and signaled in the packets, e.g., fashion as the flows that they observe. It results that the flow
using BIER-TE, Segment Routing, or a Source Routing Header. identification that maps to an application layer flowat the network
layer must be separate from the path identification that is used to
forward a packet.
3.4.1. Packet Replication Section 3.4 of the DetNet data-plane framework [DetNet-DP] indicates
that for a DetNet IP Data Plane, a flow is identified by an IPv6
6-tuple. With RAW, that 6-tuple is not what indicates the Track, in
other words, the flow ID is not the Track ID.
By employing a Packet Replication procedure, a Node forwards a copy For instance, the 6TiSCH Architecture [6TiSCH-ARCHI] uses a
of each data packet to more than one successor. To do so, each Node combination of the address of the Egress End System and an instance
(i.e., Ingress and intermediate Node) sends the data packet multiple identifier in a Hop-by-hop option to indicate a Track. This way, if
times as separate unicast transmissions. For instance, in Figure 5, a packet "escapes" the Track, it will reach the Track Egress point
the Ingress Node is transmitting the packet to both successors, nodes through normal routing and be treated at the service layer through,
A and B, at two different times. say, elimination and reordering.
===> (A) => (C) => (E) === The RAW service includes forwarding over a subset of the Links that
// \\// \\// \\ form the Track (a subTrack). Packets from the same or a different
Ingress //\\ //\\ Egress flow that are routed through the same Track will not necessarily
\\ // \\ // \\ // traverse the same Links. The PSE selects a subTrack for a packet
===> (B) => (D) => (F) === based on the links that are preferred and those that should be
avoided at this time.
Figure 5: Packet Replication Each packet is forwarded within the subTrack that provides the best
adequation with the SLA of the flow and the energy and bandwidth
constraints of the network.
An example schedule is shown in Table 1. This way, the transmission Flow 1 (6-tuple) ----+
leverages with the time and spatial forms of diversity. |
Flow 2 (6-tuple) ---+ |
| |
OAM -----------+ | |
| | |
| | |
| | | | |
| v v v |
| |
+---------+---------+
|
|
Track i (Ingress IP Address, RPLinstanceId)
|
|
|
+---------+-----+--....-------+
| | |
| | |
subTrack 1 subTrack 2 subTrack n
| | |
| | |
V V V
+-----------------------------------+
| |
| Destination |
| |
+-----------------------------------+
+=========+======+======+======+======+======+======+======+ Figure 4: Flow Injection
| Channel | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
+=========+======+======+======+======+======+======+======+
| 0 | S->A | S->B | B->C | B->D | C->F | E->R | F->R |
+---------+------+------+------+------+------+------+------+
| 1 | | A->C | A->D | C->E | D->E | D->F | |
+---------+------+------+------+------+------+------+------+
Table 1: Packet Replication: Sample schedule With 6TiSCH, packets are tagged with the same (destination address,
instance ID) will experience the same RAW service regardless of the
IPv6 6-tuple that indicates the flow. The forwarding does not depend
on whether the packets transport application flows or OAM. In the
generic case, the Track or the subTrack can be signaled in the packet
through other means, e.g., encoded in the suffix of the destination
address as a Segment Routing Service Instruction [SR-ARCHI], or
leveraging Bit Index Explicit Replication [BIER] Traffic Engineering
[BIER-TE].
3.4.2. Packet Elimination 3.5. Source-Routed vs. Distributed Forwarding Decision
The replication operation increases the traffic load in the network, Within a large routed topology, the route-over mesh operation builds
due to packet duplications. This may occur at several stages inside a particular complex Track with one source and one or more
the Track, and to avoid an explosion of the number of copies, a destinations; within the Track, packets may follow different paths
Packet Elimination procedure must be applied as well. To this aim, and may be subject to RAW forwarding operations that include
once a Node receives the first copy of a data packet, it discards the replication, elimination, retries, overhearing and reordering.
subsequent copies.
The logical functions of Replication and Elimination may be The RAW forwarding decisions include the selection of points of
collocated in an intermediate Node, the Node first eliminating the replication and elimination, how many retries can take place, and a
redundant copies and then sending the packet exactly once to each of limit of validity for the packet beyond which the packet should be
the selected successors. destroyed rather than forwarded uselessly further down the Track.
3.4.3. Promiscuous Overhearing The decision to apply the RAW techniques must be done quickly, and
depends on a very recent and precise knowledge of the forwarding
conditions within the complex Track. There is a need for an
observation method to provide the RAW Data Plane with the specific
knowledge of the state of the Track for the type of flow of interest
(e.g., for a QoS level of interest). To observe the whole Track in
quasi real time, RAW considers existing tools such as L2-triggers,
DLEP, BFD and leverages in-band and out-of-band OAM to capture and
report that information to the PSE.
Considering that the wireless medium is broadcast by nature, any One possible way of making the RAW forwarding decisions within a
neighbor of a transmitter may overhear a transmission. By employing Track is to position a unique PSE at the Ingress and express its
the Promiscuous Overhearing operation, the next hops have additional decision in-band in the packet, which requires the explicit signaling
opportunities to capture the data packets. In Figure 6, when Node A of the subTrack within the Track. In that case, the RAW forwarding
is transmitting to its DP (Node C), the AP (Node D) and its sibling operation along the Track is encoded by the source, e.g., by
(Node B) may decode this data packet as well. As a result, by indicating the subTrack in the Segment Routing (SRv6) Service
employing corellated paths, a Node may have multiple opportunities to Instruction, or by leveraging BIER-TE such as done with [BIER-PREF].
receive a given data packet.
===> (A) ====> (C) ====> (E) ==== The alternate way is to operate the PSE in each forwarding Node,
// ^ | \\ \\ which makes the RAW forwarding decisions for a packet on its own,
Ingress | | \\ Egress based on its knowledge of the expectation (timeliness and
\\ | v \\ // reliability) for that packet and a recent observation of the rest of
===> (B) ====> (D) ====> (F) ==== the way across the possible paths based on OAM. Information about
the desired service should be placed in the packet and matched with
the forwarding Node's capabilities and policies.
Figure 6: Unicast with Overhearing In either case, a per-track/subTrack state is installed in all the
intermediate Nodes to recognize the packets that are following a
Track and determine the forwarding operation to be applied.
3.4.4. Constructive Interference 3.6. Encapsulation and Decapsulation
Constructive Interference can be seen as the reverse of Promiscuous In the generic case where the Track Ingress Node is not the source of
Overhearing, and refers to the case where two senders transmit the the Packet, the Ingress Node needs to encapsulate IP-in-IP to ensure
exact same signal in a fashion that the emitted symbols add up at the that the Destination IP Address is that of the Egress Node and that
receiver and permit a reception that would not be possible with a the necessary Headers (Routing Header, Segment Routing Header and/or
single sender at the same PHY mode and the same power level. Hop-By-Hop Header) can be added to the packet to signal the Track or
the subTrack, conforming [IPv6] that discourages the insertion of a
Header on the fly.
Constructive Interference was proposed on 5G, Wi-Fi7 and even tested In the specific case where the Ingress Node is the source of the
on IEEE Std 802.14.5. The hard piece is to synchronize the senders packet, the encapsulation can be avoided, provided that the source
to the point that the signals are emitted at slightly different time adds the necessary headers and that the destination is set to the
to offset the difference of propagation delay that corresponds to the Egress Node. Forwarding to a final destination beyond the Egress
difference of distance of the transmitters to the receiver at the Node is possible, e.g., with a Segment Routing Header that signals
speed of light to the point that the symbols are superposed long the rest of the way. In that case a Hop-by-Hop Header is not
enough to be recognizable. recommmended since its validity is within the Track only.
4. The RAW Architecture 4. The RAW Architecture
4.1. The RAW Conceptual Model 4.1. The RAW Conceptual Model
RAW inherits the conceptual model described in section 4 of the RAW inherits the conceptual model described in section 4 of the
DetNet Architecture [RFC8655]. RAW extends the DetNet service layer DetNet Architecture [RFC8655]. RAW extends the DetNet service layer
to provide additional agility against transmission loss. to provide additional agility against transmission loss.
A RAW Network Plane may be strict or loose, depending on whether RAW A RAW Network Plane may be strict or loose, depending on whether RAW
skipping to change at page 22, line 22 skipping to change at page 23, line 25
z-- Node z-- Node z-- Node z-- Node --z z-- Node z-- Node z-- Node z-- Node --z
Ingress --z / / z-- Egress Ingress --z / / z-- Egress
End \ \ .. . End End \ \ .. . End
Node ---z / / .. .. . z-- Node Node ---z / / .. .. . z-- Node
z-- RAW --z RAW ( non-RAW ) -- RAW --z z-- RAW --z RAW ( non-RAW ) -- RAW --z
Node z-- Node --- ( Nodes ) Node Node z-- Node --- ( Nodes ) Node
... . ... .
--z wireless wired --z wireless wired
z-- link --- link z-- link --- link
Figure 7: RAW Nodes Figure 5: RAW Nodes
The Link-Layer metrics are reported to the PCE in a time-aggregated, The Link-Layer metrics are reported to the PCE in a time-aggregated,
e.g., statistical fashion. Example Link-Layer metrics include e.g., statistical fashion. Example Link-Layer metrics include
typical Link bandwidth (the medium speed depends dynamically on the typical Link bandwidth (the medium speed depends dynamically on the
PHY mode and the number of users sharing the spectrum) and average PHY mode and the number of users sharing the spectrum) and average
and mean squared deviation of availability and reliability figures and mean squared deviation of availability and reliability figures
such as Packet Delivery Ratio (PDR) over long periods of time. such as Packet Delivery Ratio (PDR) over long periods of time.
Based on those metrics, the PCE installs the Track with enough Based on those metrics, the PCE installs the Track with enough
redundant forwarding solutions to ensure that the Network Plane can redundant forwarding solutions to ensure that the Network Plane can
skipping to change at page 23, line 5 skipping to change at page 24, line 9
segments, either interleaved inside the Track, or all the way to the segments, either interleaved inside the Track, or all the way to the
Egress End Node (e.g., a server in the Internet). RAW observes the Egress End Node (e.g., a server in the Internet). RAW observes the
Lower-Layer Links between RAW nodes (typically, radio links) and 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 end-to-end Network Layer operation to decide at all times which of
the PAREO diversity schemes is actioned by which RAW Nodes. the PAREO diversity schemes is actioned by which RAW Nodes.
Once a Track is established, per-segment and end-to-end reliability Once a Track is established, per-segment and end-to-end reliability
and availability statistics are periodically reported to the PCE to and availability statistics are periodically reported to the PCE to
assure that the SLA can be met or have it recompute the Track if not. assure that the SLA can be met or have it recompute the Track if not.
4.2. The Path Selection Engine 4.2. The OODA Loop
RAW separates the path computation time scale at which a complex path The RAW Architecture is structured as an OODA Loop (Observe, Orient,
is recomputed from the path selection time scale at which the Decide, Act). It involves:
forwarding decision is taken for one or a few packets (more in
Section 3.2). RAW operates at the path selection time scale. The
RAW problem is to decide, within the redundant solutions that are
proposed by the PCE, 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 Path Selection Engine (PSE) that is 1. Network Plane measurement protocols for Operations,
the counter-part of the PCE to perform rapid local adjustments of the Administration and Maintenance (OAM) to Observe some or all hops
forwarding tables within the diversity that the PCE has selected for along a Track as well as the end-to-end packet delivery, more in
the Track. The PSE enables to exploit the richer forwarding Section 4.3;
capabilities with PAREO and scheduled transmissions at a faster time
scale over the smaller domain that is the Track, in either a loose or
a strict fashion.
Compared to the PCE, the PSE operates on metrics that evolve faster, 2. Controller plane elements to reports the links statistics to a
but that needs to be advertised at a fast rate but only locally, Path computation Element (PCE) in a centralized controller that
within the Track. The forwarding decision may also change rapidly, computes and installs the Tracks and provides meta data to Orient
but wiht a scope that is also contained within the Track, with no the routing decision, more in Section 4.4;
visibility to the other Tracks and flows in the network. This is as
opposed to the PCE that needs to observe the whole network, and
optimize all the Tracks globally, which can only be done at a slow
pace and using long-term statistical metrics, as presented in
Table 2.
+===============+========================+===================+ 3. A Runtime distributed Path Selection Engine (PSE) thar Decides
| | PCE (Not in Scope) | PSE (In Scope) | which subTrack to use for the next packet(s) that are routed
+===============+========================+===================+ along the Track, more in Section 4.5;
| Operation | Centralized | Source-Routed or |
| | | Distributed |
+---------------+------------------------+-------------------+
| Communication | Slow, expensive | Fast, local |
+---------------+------------------------+-------------------+
| Time Scale | hours and above | seconds and below |
+---------------+------------------------+-------------------+
| Network Size | Large, many Tracks to | Small, within one |
| | optimize globally | Track |
+---------------+------------------------+-------------------+
| Considered | Averaged, Statistical, | Instant values / |
| Metrics | Shade of grey | boolean condition |
+---------------+------------------------+-------------------+
Table 2: PCE vs. PSE 4. Packet (hybrid) ARQ, Replication, Elimination and Ordering
Dataplane actions that operate at the DetNet Service Layer to
increase the reliability o fthe end-to-end transmission. The RAW
architecture also covers in-situ signalling when the decision is
Acted by a node that down the Track from the PSE, more in
Section 4.6.
The PSE sits in the DetNet Service sub-Layer of Edge and Relay Nodes. +-------> Orient (PCE) --------+
On the one hand, it operates on the packet flow, learning the Track | link stats, |
and path selection information from the packet, possibly making local | pre-trained model |
decision and retagging the packet to indicate so. On the other hand, | ... |
the PSE interacts with the lower layers and with its peers to obtain | |
up-to-date information about its radio links and the quality of the | v
overall Track, respectively, as illustrated in Figure 8. Observe (OAM) Decide (PSE)
^ |
| |
| |
+-------- Act (PAREO) <--------+
At DetNet
Service sublayer
| Figure 6: The RAW OODA Loop
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 8: PSE 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.
4.3. RAW OAM 4.3. Observe: The RAW OAM
RAW In-situ OAM operation in the Network Plane may observe either a RAW In-situ OAM operation in the Network Plane may observe either a
full Track or subTracks that are being used at this time. Active RAW full Track or subTracks that are being used at this time. Active RAW
OAM may be needed to observe the unused segments and evaluate the OAM may be needed to observe the unused segments and evaluate the
desirability of a rerouting decision. Finally, the RAW Service Layer desirability of a rerouting decision. Finally, the RAW Service Layer
Assurance may observe the individual PAREO operation of a relay node Assurance may observe the individual PAREO operation of a relay node
to ensure that it is conforming; this might require injecting an OAM to ensure that it is conforming; this might require injecting an OAM
packet at an upstream point inside the Track and extracting that packet at an upstream point inside the Track and extracting that
packet at another point downstream before it reaches the egress. packet at another point downstream before it reaches the egress.
skipping to change at page 25, line 19 skipping to change at page 25, line 39
|Ingress|- . ..... |Egress| |Ingress|- . ..... |Egress|
| End |------ RAN 2 -- . Internet ....---| End | | End |------ RAN 2 -- . Internet ....---| End |
|System |- .. ..... |System| |System |- .. ..... |System|
+-------+ \ . ...... +------+ +-------+ \ . ...... +------+
\ ... ... ..... \ ... ... .....
RAN n -------- ... ..... RAN n -------- ... .....
<------------------> <--------------------> <------------------> <-------------------->
Observed by OAM Opaque to OAM Observed by OAM Opaque to OAM
Figure 9: Observed Links in Radio Access Protection Figure 7: Observed Links in Radio Access Protection
In the case of a End-to-End Protection in a Wireless Mesh, the Track In the case of a End-to-End Protection in a Wireless Mesh, the Track
is strict and congruent with the path so all links are observed. is strict and congruent with the path so all links are observed.
Conversely, in the case of Radio Access Protection, the Track is Conversely, in the case of Radio Access Protection, the Track is
Loose and in that case only the first hop is observed; the rest of Loose and in that case only the first hop is observed; the rest of
the path is abstracted and considered infinitely reliable. the path is abstracted and considered infinitely reliable.
In the case of the Radio Access Protection, only the first hop is In the case of the Radio Access Protection, only the first hop is
protected; the loss of a packet that was sent over one of the protected; the loss of a packet that was sent over one of the
possible first hops is attributed to that first hop, even if a possible first hops is attributed to that first hop, even if a
skipping to change at page 27, line 27 skipping to change at page 27, line 43
medium itself. In other words, the captured information does not medium itself. In other words, the captured information does not
only relate to the experience of one packet as is the case for IOAM, only relate to the experience of one packet as is the case for IOAM,
but also to the medium itself. This makes an approach like HTS more but also to the medium itself. This makes an approach like HTS more
suitable as it can trigger the capture of multiple measurements over suitable as it can trigger the capture of multiple measurements over
a short period of time. On the other hand, the PSE needs a a short period of time. On the other hand, the PSE needs a
continuous measurement stream where a single trigger is followed by a continuous measurement stream where a single trigger is followed by a
periodic follow up capture. periodic follow up capture.
In other words, the best suited OAM method to enable the PSE make In other words, the best suited OAM method to enable the PSE make
accurate PAREO forwarding decisions is a periodic variation of the accurate PAREO forwarding decisions is a periodic variation of the
two-steps method flowing along the reverse Track, as a Reverse OAM two-steps method flowing along the reverse Track, as an upstream OAM
technique. [RAW-OAM] provides more information on the RAW OAM technique. [RAW-OAM] provides more information on the RAW OAM
problem and solution approaches. problem and solution approaches.
4.3.3. Observed Metrics 4.3.3. Observed Metrics
The Dynamic Link Exchange Protocol (DLEP) [RFC8175] from [MANET] can The Dynamic Link Exchange Protocol (DLEP) [RFC8175] from [MANET] can
be leveraged at each hop to derive generic radio metrics (e.g., based be leveraged at each hop to derive generic radio metrics (e.g., based
on LQI, RSSI, queueing delays and ETX) on individual hops. on LQI, RSSI, queueing delays and ETX) on individual hops.
Those lower-layer metrics are aggregated along a multihop segment Those lower-layer metrics are aggregated along a multihop segment
into abstract layer 3 information that reflect the instant into abstract layer 3 information that reflect the instant
reliability and latency of the observed path. reliability and latency of the observed path.
4.4. Flow Identification vs. Path Identification 4.4. Orient: The Path Computation Engine
Section 4.7 of the DetNet Architecture [RFC8655] ties the app-flow RAW separates the path computation time scale at which a complex path
identification which is an appliation layer concept with the network is recomputed from the path selection time scale at which the
path identification that depends on the networking technology by forwarding decision is taken for one or a few packets (see in
"exporting of flow identification", e.g., to a MPLS label. Section 3.2).
With RAW, this exporting operation is injective but not bijective. The path computation is out of scope, but RAW expects that the
e.g., a flow is fully placed within one RAW Track, but not all Controller plane protocol that installs the Track also provides
packets along that Track are necessarily part of the same flow. For related knowledge in the form of meta data about the links, segments
instance, out-of-band OAM packets must circulate in the exact same and possible subTracks. That meta data can be a pre-digested
fashion as the flows that they observe. It results that the flow statistical model, and may include prediction of future flaps and
identification that maps to to app-flow at the network layer must be packet loss, as well as recommended actions when that happens.
separate from the path identification that is used to forward a
packet.
Section 3.4 of the DetNet data-plane framework [DetNet-DP] indicates The meta data may include:
that for a DetNet IP Data Plane, a flow is identified by an IPv6
6-tuple. With RAW, that 6-tuple is not what indicates the Track, in
other words, the flow ID is not the Track ID.
For instance, the 6TiSCH Architecture [6TiSCH-ARCHI] uses a * Pre-Determined subTracks to match predictable error profiles
combination of the address of the Egress End System and an instance
identifier in a Hop-by-hop option to indicate a Track. This way, if
a packet "escapes" the Track, it will reach the Track Egress point
through normal routing and be treated at the service layer through,
say, elimination and reordering.
The RAW service includes forwarding over a subset of the Links that * Pre-Trained models
form the Track (a subTrack). Packets from the same or a different
flow that are routed through the same Track will not necessarily
traverse the same Links. The PSE selects a subTrack for a packet
based on the links that are preferred and those that should be
avoided at this time.
Each packet is forwarded within the subTrack that provides the best * Link Quality Statistics and their projected evolution
adequation with the SLA of the flow and the energy and bandwidth
constraints of the network.
Flow 1 (6-tuple) ----+ The Track is installed with measurable objectives that are computed
| by the PCE to achieve the RAW SLA. The objectives can be expressed
Flow 2 (6-tuple) ---+ | as any of maximum number of packet lost in a row, bounded latency,
| | maximal jitter, maximum nmuber of interleaved out of order packets,
OAM -----------+ | | average number of copies received at the elimination point, and
| | | maximal delay between the first and the last received copy of the
| | | same packet.
| | | | |
| v v v |
| |
+---------+---------+
|
|
Track i (Ingress IP Address, RPLinstanceId)
|
|
|
+---------+-----+--....-------+
| | |
| | |
subTrack 1 subTrack 2 subTrack n
| | |
| | |
V V V
+-----------------------------------+
| |
| Destination |
| |
+-----------------------------------+
Figure 10: Flow Injection 4.5. Decide: The Path Selection Engine
With 6TiSCH, packets are tagged with the same (destination address, The RAW OODA Loop operates at the path selection time scale to
instance ID) will experience the same RAW service regardless of the provide agility vs. the brute force approach of flooding the whole
IPv6 6-tuple that indicates the flow. The forwarding does not depend Track. The OODA Loop controls, within the redundant solutions that
on whether the packets transport application flows or OAM. In the are proposed by the PCE, which will be used for each packet to
generic case, the Track or the subTrack can be signaled in the packet provide a Reliable and Available service while minimizing the waste
through other means, e.g., encoded in the suffix of the destination of constrained resources.
address as a Segment Routing Service Instruction [SR-ARCHI], or
leveraging Bit Index Explicit Replication [BIER] Traffic Engineering
[BIER-TE].
4.5. Source-Routed vs. Distributed Forwarding Decision To that effect, RAW defines the Path Selection Engine (PSE) that is
the counterpart of the PCE to perform rapid local adjustments of the
forwarding tables within the diversity that the PCE has selected for
the Track. The PSE enables to exploit the richer forwarding
capabilities with PAREO and scheduled transmissions at a faster time
scale over the smaller domain that is the Track, in either a loose or
a strict fashion.
Within a large routed topology, the route-over mesh operation builds Compared to the PCE, the PSE operates on metrics that evolve faster,
a particular complex Track with one source and one or more but that needs to be advertised at a fast rate but only locally,
destinations; within the Track, packets may follow different paths within the Track. The forwarding decision may also change rapidly,
and may be subject to RAW forwarding operations that include but with a scope that is also contained within the Track, with no
replication, elimination, retries, overhearing and reordering. visibility to the other Tracks and flows in the network. This is as
opposed to the PCE that needs to observe the whole network, and
optimize all the Tracks globally, which can only be done at a slow
pace and using long-term statistical metrics, as presented in
Table 1.
The RAW forwarding decisions include the selection of points of +===============+========================+===================+
replication and elimination, how many retries can take place, and a | | PCE (Not in Scope) | PSE (In Scope) |
limit of validity for the packet beyond which the packet should be +===============+========================+===================+
destroyed rather than forwarded uselessly further down the Track. | Operation | Centralized | Source-Routed or |
| | | Distributed |
+---------------+------------------------+-------------------+
| Communication | Slow, expensive | Fast, local |
+---------------+------------------------+-------------------+
| Time Scale | hours and above | seconds and below |
+---------------+------------------------+-------------------+
| Network Size | Large, many Tracks to | Small, within one |
| | optimize globally | Track |
+---------------+------------------------+-------------------+
| Considered | Averaged, Statistical, | Instant values / |
| Metrics | Shade of grey | boolean condition |
+---------------+------------------------+-------------------+
The decision to apply the RAW techniques must be done quickly, and Table 1: PCE vs. PSE
depends on a very recent and precise knowledge of the forwarding
conditions within the complex Track. There is a need for an
observation method to provide the RAW Data Plane with the specific
knowledge of the state of the Track for the type of flow of interest
(e.g., for a QoS level of interest). To observe the whole Track in
quasi real time, RAW considers existing tools such as L2-triggers,
DLEP, BFD and leverages in-band and out-of-band OAM to capture and
report that information to the PSE.
One possible way of making the RAW forwarding decisions within a The PSE sits in the DetNet Service sub-Layer of Edge and Relay Nodes.
Track is to position a unique PSE at the Ingress and express its On the one hand, it operates on the packet flow, learning the Track
decision in-band in the packet, which requires the explicit signaling and path selection information from the packet, possibly making local
of the subTrack within the Track. In that case, the RAW forwarding decision and retagging the packet to indicate so. On the other hand,
operation along the Track is encoded by the source, e.g., by the PSE interacts with the lower layers and with its peers to obtain
indicating the subTrack in the Segment Routing (SRv6) Service up-to-date information about its radio links and the quality of the
Instruction, or by leveraging BIER-TE such as done with [BIER-PREF]. overall Track, respectively, as illustrated in Figure 8.
The alternate way is to operate the PSE in each forwarding Node, |
which makes the RAW forwarding decisions for a packet on its own, packet | going
based on its knowledge of the expectation (timeliness and down the | stack
reliability) for that packet and a recent observation of the rest of +==========v==========+=====================+=====================+
the way across the possible paths based on OAM. Information about | (iOAM + iCTRL) | (L2 Triggers, DLEP) | (oOAM) |
the desired service should be placed in the packet and matched with +==========v==========+=====================+=====================+
the forwarding Node's capabilities and policies. | 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
In either case, a per-track/subTrack state is installed in all the Figure 8: PSE
intermediate Nodes to recognize the packets that are following a
Track and determine the forwarding operation to be applied.
4.6. Encapsulation and Decapsulation 4.6. Act: The PAREO Functions
In the generic case where the Track Ingress Node is not the source of RAW may control whether and how to use packet replication and
the Packet, the Ingress Node needs to encapsulate IP-in-IP to ensure elimination (PRE), Automatic Repeat reQuest (ARQ), Hybrid ARQ (HARQ)
that the Destination IP Address is that of the Egress Node and that that includes Forward Error Correction (FEC) and coding, and other
the necessary Headers (Routing Header, Segment Routing Header and/or wireless-specific techniques such as overhearing and constructive
Hop-By-Hop Header) can be added to the packet to signal the Track or interferences, in order to increase the reliabiility and availability
the subTrack, conforming [IPv6] that discourages the insertion of a of the end-to-end transmission.
Header on the fly.
In the specific case where the Ingress Node is the source of the Collectively, those function are called PAREO for Packet (hybrid)
packet, the encapsulation can be avoided, provided that the source ARQ, Replication, Elimination and Ordering. By tuning dynamically
adds the necessary headers and that the destination is set to the the use of PAREO functions, RAW avoids the waste of critical
Egress Node. Forwarding to a final destination beyond the Egress resources such as spectrum and energy while providing that the
Node is possible, e.g., with a Segment Routing Header that signals guaranteed SLA, e.g., by adding redundancy only when a spike of loss
the rest of the way. In that case a Hop-by-Hop Header is not is observed.
recommmended since its validity is within the Track only.
In a nutshell, PAREO establishes several paths in a network to
provide redundancy and parallel transmissions to bound the end-to-end
delay to traverse the network. Optionally, promiscuous listening
between paths is possible, such that the Nodes on one path may
overhear transmissions along the other path. Considering the
scenario shown in Figure 9, many different paths are possible for to
traverse the network from ingress to egress. A simple way to benefit
from this topology could be to use the two independent paths via
Nodes A, C, E and via B, D, F. But more complex paths are possible
by interleaving transmissions from the lower level of the path to the
upper level.
(A) -- (C) -- (E)
/ \
Ingress = | | | = Egress
\ /
(B) -- (D) -- (F)
Figure 9: A Ladder Shape with Two Parallel Paths
PAREO may also take advantage of the shared properties of the
wireless medium to compensate for the potential loss that is incurred
with radio transmissions.
For instance, when the source sends to Node A, Node B may listen
promiscuously and get a second chance to receive the frame without an
additional transmission. Note that B would not have to listen if it
already received that particular frame at an earlier timeslot in a
dedicated transmission towards B.
The PAREO model can be implemented in both centralized and
distributed scheduling approaches. In the centralized approach, a
Path Computation Element (PCE) scheduler calculates a Track and
schedules the communication. In the distributed approach, the Track
is computed within the network, and signaled in the packets, e.g.,
using BIER-TE, Segment Routing, or a Source Routing Header.
4.6.1. Packet Replication
By employing a Packet Replication procedure, a Node forwards a copy
of each data packet to more than one successor. To do so, each Node
(i.e., Ingress and intermediate Node) sends the data packet multiple
times as separate unicast transmissions. For instance, in Figure 10,
the Ingress Node is transmitting the packet to both successors, nodes
A and B, at two different times.
===> (A) => (C) => (E) ===
// \\// \\// \\
Ingress //\\ //\\ Egress
\\ // \\ // \\ //
===> (B) => (D) => (F) ===
Figure 10: Packet Replication
An example schedule is shown in Table 2. This way, the transmission
leverages with the time and spatial forms of diversity.
+=========+======+======+======+======+======+======+======+
| Channel | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
+=========+======+======+======+======+======+======+======+
| 0 | S->A | S->B | B->C | B->D | C->F | E->R | F->R |
+---------+------+------+------+------+------+------+------+
| 1 | | A->C | A->D | C->E | D->E | D->F | |
+---------+------+------+------+------+------+------+------+
Table 2: Packet Replication: Sample schedule
4.6.2. Packet Elimination
The replication operation increases the traffic load in the network,
due to packet duplications. This may occur at several stages inside
the Track, and to avoid an explosion of the number of copies, a
Packet Elimination procedure must be applied as well. To this aim,
once a Node receives the first copy of a data packet, it discards the
subsequent copies.
The logical functions of Replication and Elimination may be
collocated in an intermediate Node, the Node first eliminating the
redundant copies and then sending the packet exactly once to each of
the selected successors.
4.6.3. Promiscuous Overhearing
Considering that the wireless medium is broadcast by nature, any
neighbor of a transmitter may overhear a transmission. By employing
the Promiscuous Overhearing operation, the next hops have additional
opportunities to capture the data packets. In Figure 11, when Node A
is transmitting to its DP (Node C), the AP (Node D) and its sibling
(Node B) may decode this data packet as well. As a result, by
employing corellated paths, a Node may have multiple opportunities to
receive a given data packet.
===> (A) ====> (C) ====> (E) ====
// ^ | \\ \\
Ingress | | \\ Egress
\\ | v \\ //
===> (B) ====> (D) ====> (F) ====
Figure 11: Unicast with Overhearing
4.6.4. Constructive Interference
Constructive Interference can be seen as the reverse of Promiscuous
Overhearing, and refers to the case where two senders transmit the
exact same signal in a fashion that the emitted symbols add up at the
receiver and permit a reception that would not be possible with a
single sender at the same PHY mode and the same power level.
Constructive Interference was proposed on 5G, Wi-Fi7 and even tested
on IEEE Std 802.14.5. The hard piece is to synchronize the senders
to the point that the signals are emitted at slightly different time
to offset the difference of propagation delay that corresponds to the
difference of distance of the transmitters to the receiver at the
speed of light to the point that the symbols are superposed long
enough to be recognizable.
5. Security Considerations 5. Security Considerations
RAW uses all forms of diversity including radio technology and RAW uses all forms of diversity including radio technology and
physical path to increase the reliability and availability in the physical path to increase the reliability and availability in the
face of unpredictable conditions. While this is not done face of unpredictable conditions. While this is not done
specifically to defeat an attacker, the amount of diversity used in specifically to defeat an attacker, the amount of diversity used in
RAW makes an attack harder to achieve. RAW makes an attack harder to achieve.
5.1. Forced Access 5.1. Forced Access
skipping to change at page 32, line 31 skipping to change at page 34, line 37
[6TiSCH-ARCHI] [6TiSCH-ARCHI]
Thubert, P., Ed., "An Architecture for IPv6 over the Time- Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021, RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>. <https://www.rfc-editor.org/info/rfc9030>.
[RAW-TECHNOS] [RAW-TECHNOS]
Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C.,
and J. Farkas, "Reliable and Available Wireless and J. Farkas, "Reliable and Available Wireless
Technologies", Work in Progress, Internet-Draft, draft- Technologies", Work in Progress, Internet-Draft, draft-
ietf-raw-technologies-01, 19 February 2021, ietf-raw-technologies-02, 7 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw- <https://datatracker.ietf.org/doc/html/draft-ietf-raw-
technologies-01>. technologies-02>.
[RAW-USE-CASES] [RAW-USE-CASES]
Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J.
Bernardos, "RAW use cases", Work in Progress, Internet- Bernardos, "RAW use cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-01, 21 February 2021, Draft, draft-ietf-raw-use-cases-02, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
cases-01>. cases-02>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
skipping to change at page 35, line 17 skipping to change at page 37, line 29
detnet-ip-oam-02>. detnet-ip-oam-02>.
[RAW-5G] Farkas, J., Dudda, T., Shapin, A., and S. Sandberg, "5G - [RAW-5G] Farkas, J., Dudda, T., Shapin, A., and S. Sandberg, "5G -
Ultra-Reliable Wireless Technology with Low Latency", Work Ultra-Reliable Wireless Technology with Low Latency", Work
in Progress, Internet-Draft, draft-farkas-raw-5g-00, 1 in Progress, Internet-Draft, draft-farkas-raw-5g-00, 1
April 2020, <https://datatracker.ietf.org/doc/html/draft- April 2020, <https://datatracker.ietf.org/doc/html/draft-
farkas-raw-5g-00>. farkas-raw-5g-00>.
[BIER-TE] Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering [BIER-TE] Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering
for Bit Index Explicit Replication (BIER-TE)", Work in for Bit Index Explicit Replication (BIER-TE)", Work in
Progress, Internet-Draft, draft-ietf-bier-te-arch-09, 30 Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9
October 2020, <https://datatracker.ietf.org/doc/html/ July 2021, <https://datatracker.ietf.org/doc/html/draft-
draft-ietf-bier-te-arch-09>. ietf-bier-te-arch-10>.
[IPoWIRELESS] [IPoWIRELESS]
Thubert, P., "IPv6 Neighbor Discovery on Wireless Thubert, P., "IPv6 Neighbor Discovery on Wireless
Networks", Work in Progress, Internet-Draft, draft- Networks", Work in Progress, Internet-Draft, draft-
thubert-6man-ipv6-over-wireless-09, 17 May 2021, thubert-6man-ipv6-over-wireless-09, 17 May 2021,
<https://datatracker.ietf.org/doc/html/draft-thubert-6man- <https://datatracker.ietf.org/doc/html/draft-thubert-6man-
ipv6-over-wireless-09>. ipv6-over-wireless-09>.
[RAW-OAM] Theoleyre, F., Papadopoulos, G. Z., Mirsky, G., and C. J. [RAW-OAM] Theoleyre, F., Papadopoulos, G. Z., Mirsky, G., and C. J.
Bernardos, "Operations, Administration and Maintenance Bernardos, "Operations, Administration and Maintenance
(OAM) features for RAW", Work in Progress, Internet-Draft, (OAM) features for RAW", Work in Progress, Internet-Draft,
draft-ietf-raw-oam-support-02, 3 June 2021, draft-ietf-raw-oam-support-02, 3 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-oam- <https://datatracker.ietf.org/doc/html/draft-ietf-raw-oam-
support-02>. support-02>.
[I-D.ietf-ippm-ioam-direct-export] [I-D.ietf-ippm-ioam-direct-export]
Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,
Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ
OAM Direct Exporting", Work in Progress, Internet-Draft, OAM Direct Exporting", Work in Progress, Internet-Draft,
draft-ietf-ippm-ioam-direct-export-03, 17 February 2021, draft-ietf-ippm-ioam-direct-export-05, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm- <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
ioam-direct-export-03>. ioam-direct-export-05>.
[DetNet-OAM] [DetNet-OAM]
Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., and C. J. Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., and C. J.
Bernardos, "Framework of Operations, Administration and Bernardos, "Framework of Operations, Administration and
Maintenance (OAM) for Deterministic Networking (DetNet)", Maintenance (OAM) for Deterministic Networking (DetNet)",
Work in Progress, Internet-Draft, draft-ietf-detnet-oam- Work in Progress, Internet-Draft, draft-ietf-detnet-oam-
framework-01, 19 May 2021, framework-03, 6 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-detnet- <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
oam-framework-01>. oam-framework-03>.
[I-D.mirsky-ippm-hybrid-two-step] [I-D.mirsky-ippm-hybrid-two-step]
Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid
Two-Step Performance Measurement Method", Work in Two-Step Performance Measurement Method", Work in
Progress, Internet-Draft, draft-mirsky-ippm-hybrid-two- Progress, Internet-Draft, draft-mirsky-ippm-hybrid-two-
step-09, 30 March 2021, step-11, 8 July 2021,
<https://datatracker.ietf.org/doc/html/draft-mirsky-ippm- <https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-
hybrid-two-step-09>. hybrid-two-step-11>.
[I-D.mirsky-ippm-epm] [I-D.mirsky-ippm-epm]
Mirsky, G., Min, X., and L. Han, "Error Performance Mirsky, G., Min, X., and L. Han, "Error Performance
Measurement in Packet-switched Networks", Work in Measurement in Packet-switched Networks", Work in
Progress, Internet-Draft, draft-mirsky-ippm-epm-03, 26 Progress, Internet-Draft, draft-mirsky-ippm-epm-03, 26
March 2021, <https://datatracker.ietf.org/doc/html/draft- March 2021, <https://datatracker.ietf.org/doc/html/draft-
mirsky-ippm-epm-03>. mirsky-ippm-epm-03>.
[I-D.mirsky-bfd-mpls-demand] [I-D.mirsky-bfd-mpls-demand]
Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS
LSP", Work in Progress, Internet-Draft, draft-mirsky-bfd- LSP", Work in Progress, Internet-Draft, draft-mirsky-bfd-
mpls-demand-09, 30 March 2021, mpls-demand-09, 30 March 2021,
<https://datatracker.ietf.org/doc/html/draft-mirsky-bfd- <https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-
mpls-demand-09>. mpls-demand-09>.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", Work in Progress, Internet-Draft, draft- for In-situ OAM", Work in Progress, Internet-Draft, draft-
ietf-ippm-ioam-data-12, 21 February 2021, ietf-ippm-ioam-data-14, 24 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm- <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
ioam-data-12>. ioam-data-14>.
[NASA] Adams, T., "RELIABILITY: Definition & Quantitative [NASA] Adams, T., "RELIABILITY: Definition & Quantitative
Illustration", <https://kscddms.ksc.nasa.gov/Reliability/ Illustration", <https://kscddms.ksc.nasa.gov/Reliability/
Documents/150814-3bWhatIsReliability.pdf>. Documents/150814-3bWhatIsReliability.pdf>.
[MANET] IETF, "Mobile Ad hoc Networking", [MANET] IETF, "Mobile Ad hoc Networking",
<https://dataTracker.ietf.org/doc/charter-ietf-manet/>. <https://dataTracker.ietf.org/doc/charter-ietf-manet/>.
[detnet] IETF, "Deterministic Networking", [detnet] IETF, "Deterministic Networking",
<https://dataTracker.ietf.org/doc/charter-ietf-detnet/>. <https://dataTracker.ietf.org/doc/charter-ietf-detnet/>.
 End of changes. 84 change blocks. 
372 lines changed or deleted 476 lines changed or added

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