| < draft-ietf-raw-architecture-02.txt | draft-ietf-raw-architecture-03.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: 2 June 2022 IMT Atlantique | Expires: 18 July 2022 IMT Atlantique | |||
| 29 November 2021 | 14 January 2022 | |||
| Reliable and Available Wireless Architecture | Reliable and Available Wireless Architecture | |||
| draft-ietf-raw-architecture-02 | draft-ietf-raw-architecture-03 | |||
| 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 following an OODA loop that involves OAM, PCE, PSE | RAW Architecture following an OODA loop that involves OAM, PCE, PSE | |||
| and PAREO functions. It builds on the DetNet Architecture and | and PAREO functions. It builds on the DetNet Architecture and | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
| 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 2 June 2022. | This Internet-Draft will expire on 18 July 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 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 Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised 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.1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.1.2. Link and Direction . . . . . . . . . . . . . . . . . 6 | 2.1.2. Link and Direction . . . . . . . . . . . . . . . . . 7 | |||
| 2.1.3. Path and Tracks . . . . . . . . . . . . . . . . . . . 7 | 2.1.3. Path and Tracks . . . . . . . . . . . . . . . . . . . 7 | |||
| 2.1.4. Deterministic Networking . . . . . . . . . . . . . . 8 | 2.1.4. Deterministic Networking . . . . . . . . . . . . . . 8 | |||
| 2.1.5. Reliability and Availability . . . . . . . . . . . . 9 | 2.1.5. Reliability and Availability . . . . . . . . . . . . 9 | |||
| 2.1.6. OAM variations . . . . . . . . . . . . . . . . . . . 10 | 2.1.6. OAM variations . . . . . . . . . . . . . . . . . . . 10 | |||
| 2.2. Reliability and Availability . . . . . . . . . . . . . . 11 | 2.2. Reliability and Availability . . . . . . . . . . . . . . 11 | |||
| 2.2.1. High Availability Engineering Principles . . . . . . 11 | 2.2.1. High Availability Engineering Principles . . . . . . 12 | |||
| 2.2.2. Applying Reliability Concepts to Networking . . . . . 14 | 2.2.2. Applying Reliability Concepts to Networking . . . . . 14 | |||
| 2.2.3. Reliability in the Context of RAW . . . . . . . . . . 15 | 2.2.3. Reliability in the Context of RAW . . . . . . . . . . 15 | |||
| 2.3. Routing Time Scale vs. Forwarding Time Scale . . . . . . 16 | 2.3. Routing Time Scale vs. Forwarding Time Scale . . . . . . 16 | |||
| 3. The RAW Conceptual Model . . . . . . . . . . . . . . . . . . 18 | 3. The RAW Conceptual Model . . . . . . . . . . . . . . . . . . 18 | |||
| 4. The OODA Loop . . . . . . . . . . . . . . . . . . . . . . . . 20 | 4. The OODA Loop . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 5. Observe: The RAW OAM . . . . . . . . . . . . . . . . . . . . 21 | 4.1. Observe: The RAW OAM . . . . . . . . . . . . . . . . . . 21 | |||
| 6. Orient: The Path Computation Engine . . . . . . . . . . . . . 22 | 4.2. Orient: The Path Computation Engine . . . . . . . . . . . 22 | |||
| 7. Decide: The Path Selection Engine . . . . . . . . . . . . . . 22 | 4.3. Decide: The Path Selection Engine . . . . . . . . . . . . 22 | |||
| 8. Act: The PAREO Functions . . . . . . . . . . . . . . . . . . 24 | 4.4. Act: The PAREO Functions . . . . . . . . . . . . . . . . 24 | |||
| 8.1. Packet Replication . . . . . . . . . . . . . . . . . . . 25 | 4.4.1. Packet Replication . . . . . . . . . . . . . . . . . 25 | |||
| 8.2. Packet Elimination . . . . . . . . . . . . . . . . . . . 26 | 4.4.2. Packet Elimination . . . . . . . . . . . . . . . . . 26 | |||
| 8.3. Promiscuous Overhearing . . . . . . . . . . . . . . . . . 26 | 4.4.3. Promiscuous Overhearing . . . . . . . . . . . . . . . 26 | |||
| 8.4. Constructive Interference . . . . . . . . . . . . . . . . 27 | 4.4.4. Constructive Interference . . . . . . . . . . . . . . 27 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
| 9.1. Forced Access . . . . . . . . . . . . . . . . . . . . . . 27 | 5.1. Forced Access . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 | 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 | |||
| 13.2. Informative References . . . . . . . . . . . . . . . . . 29 | 9.2. Informative References . . . . . . . . . . . . . . . . . 30 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
| 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). | |||
| Bringing determinism in a packet network means eliminating the | Bringing determinism in a packet network means eliminating the | |||
| statistical effects of multiplexing that result in probabilistic | statistical effects of multiplexing that result in probabilistic | |||
| jitter and loss. This can be approached with a tight control of the | jitter and loss. This can be approached with a tight control of the | |||
| physical resources to maintain the amount of traffic within a | physical resources to maintain the amount of traffic within a | |||
| budgetted volume of data per unit of time that fits the physical | budgeted volume of data per unit of time that fits the physical | |||
| capabilities of the underlying network, and the use of time-shared | capabilities of the underlying network, and the use of time-shared | |||
| resources (bandwidth and buffers) per circuit, and/or by shaping and/ | resources (bandwidth and buffers) per circuit, and/or by shaping and/ | |||
| or scheduling the packets at every hop. | or scheduling the packets at every hop. | |||
| This innovation was initially introduced on wired networks, with IEEE | This innovation was initially introduced on wired networks, with IEEE | |||
| 802.1 Time Sensitive networking (TSN) - for Ethernet LANs - and IETF | 802.1 Time Sensitive networking (TSN) - for Ethernet LANs - and IETF | |||
| DetNet. But the wired and the wireless media are fundamentally | DetNet. But the wired and the wireless media are fundamentally | |||
| different at the physical level and in the possible abstractions that | different at the physical level and in the possible abstractions that | |||
| can be built for IPv6 [IPoWIRELESS]. Nevertheless, deterministic | can be built for IPv6 [IPoWIRELESS]. Nevertheless, deterministic | |||
| capabilities are required in a number of wireless use cases as well | capabilities are required in a number of wireless use cases as well | |||
| skipping to change at page 4, line 21 ¶ | skipping to change at page 4, line 21 ¶ | |||
| layer-3. | layer-3. | |||
| While the generic "Deterministic Networking Problem Statement" | While the generic "Deterministic Networking Problem Statement" | |||
| [RFC8557] applies to both the wired and the wireless media, the | [RFC8557] applies to both the wired and the wireless media, the | |||
| methods to achieve RAW must extend those used to support time- | methods to achieve RAW must extend those used to support time- | |||
| sensitive networking over wires, as a RAW solution has to address | sensitive networking over wires, as a RAW solution has to address | |||
| less consistent transmissions, energy conservation and shared | less consistent transmissions, energy conservation and shared | |||
| spectrum efficiency. | spectrum efficiency. | |||
| RAW provides DetNet elements that are specialized for IPv6 flows | RAW provides DetNet elements that are specialized for IPv6 flows | |||
| [IPv6] over deterministic short range radios [RAW-TECHNOS]. | [IPv6] over selected deterministic radios technologies [RAW-TECHNOS]. | |||
| Conceptually, RAW is agnostic to the radio layer underneath though | Conceptually, RAW is agnostic to the radio layer underneath though | |||
| the capability to schedule transmissions is assumed. How the PHY is | the capability to schedule transmissions is assumed. How the PHY is | |||
| programmed to do so, and whether the radio is single-hop or meshed, | programmed to do so, and whether the radio is single-hop or meshed, | |||
| are unknown at the IP layer and not part of the RAW abstraction. | are unknown at the IP layer and not part of the RAW abstraction. | |||
| Nevertheless, cross-layer optimizations may take place to ensure | Nevertheless, cross-layer optimizations may take place to ensure | |||
| proper link awareness (think, link quality) and packet handling | proper link awareness (think, link quality) and packet handling | |||
| (think, scheduling). | (think, scheduling). | |||
| 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 accommodate 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. | |||
| RAW and DetNet associate application that that require a particular | RAW and DetNet route application flows that require a special | |||
| treatment to a path that was provisionned to procure that treatment. | treatment along the paths that will provide that treatment. This may | |||
| This may be seen as a form of Path Aware Networking and may be | be seen as a form of Path Aware Networking and may be subject to | |||
| subject to impediments documented in [RFC9049]. | impediments documented in [RFC9049]. | |||
| 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 | |||
| solutions are to be used for a given packet based on the current | solutions are to be used for a given packet based on the current | |||
| 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 is structured as an OODA Loop (Observe, Orient, | The RAW Architecture is based on an abstract OODA Loop (Observe, | |||
| Decide, Act). It involves: | Orient, Decide, Act). The generic concept involves: | |||
| 1. Network Plane measurement protocols for Operations, | 1. Network Plane measurement protocols for Operations, | |||
| Administration and Maintenance (OAM) to Observe some or all hops | Administration and Maintenance (OAM) to Observe some or all hops | |||
| along a Track as well as the end-to-end packet delivery | along a Track as well as the end-to-end packet delivery | |||
| 2. Controller plane elements to reports the links statistics to a | 2. Controller plane elements to reports the links statistics to a | |||
| Path computation Element (PCE) in a centralized controller that | Path computation Element (PCE) in a centralized controller that | |||
| computes and installs the Tracks and provides meta data to Orient | computes and installs the Tracks and provides meta data to Orient | |||
| the routing decision | the routing decision | |||
| 3. A Runtime distributed Path Selection Engine (PSE) that Decides | 3. A Runtime distributed Path Selection Engine (PSE) that Decides | |||
| which subTrack to use for the next packet(s) that are routed | which subTrack to use for the next packet(s) that are routed | |||
| along the Track | along the Track | |||
| 4. Packet (hybrid) ARQ, Replication, Elimination and Ordering | 4. Packet (hybrid) ARQ, Replication, Elimination and Ordering | |||
| Dataplane actions that operate at the DetNet Service Layer to | Dataplane actions that operate at the DetNet Service Layer to | |||
| increase the reliability of the end-to-end transmission. The RAW | increase the reliability of the end-to-end transmissions. The | |||
| architecture also covers in-situ signalling when the decision is | RAW architecture also covers in-situ signalling when the decision | |||
| Acted by a node that down the Track from the PSE. | is Acted by a node that down the Track from the PSE. | |||
| The overall OODA Loop optimizes the use of redundancy to achieve the | The overall OODA Loop optimizes the use of redundancy to achieve the | |||
| required reliability and availability Service Level Agreement (SLA) | required reliability and availability Service Level Agreement (SLA) | |||
| while minimizing the use of constrained resources such as spectrum | while minimizing the use of constrained resources such as spectrum | |||
| and battery. | and battery. | |||
| This document presents the RAW problem and associated terminology in | ||||
| Section 2, and elaborates in Section 4 on the OODA loop based on the | ||||
| RAW conceptual model presented in Section 3. | ||||
| 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 associates a complex path with PAREO and | |||
| operations. The concept is abstract to the underlaying technology | shaping operations. The concept is agnostic to the underlaying | |||
| and applies to any fully or partially wireless mesh, including, e.g., | technology and applies to any fully or partially wireless mesh, | |||
| a Wi-Fi mesh. RAW specifies strict and loose Tracks depending on | including, e.g., a Wi-Fi mesh. RAW specifies strict and loose Tracks | |||
| whether the path is fully controlled by RAW or traverses an opaque | depending on whether the path is fully controlled by RAW or traverses | |||
| network where RAW cannot observe and control the individual hops. | an opaque network where RAW cannot observe and control the individual | |||
| hops. | ||||
| RAW uses the following terminology and acronyms: | RAW uses the following terminology and acronyms: | |||
| 2.1.1. Acronyms | 2.1.1. Acronyms | |||
| 2.1.1.1. ARQ | 2.1.1.1. ARQ | |||
| Automatic Repeat Request, enabling an acknowledged transmission and | Automatic Repeat Request, enabling an acknowledged transmission and | |||
| retries. ARQ is a typical model at Layer-2 on a wireless medium. It | retries. ARQ is a typical model at Layer-2 on a wireless medium. | |||
| is typically avoided end-to-end on deterministic flows because it | ARQ is typically implemented hop-by-hop and not end-to-end in | |||
| introduces excessive indetermination in latency, but a limited number | wireless networks. Else, it introduces excessive indetermination in | |||
| of retries within a bounded time may be used over a wireless link and | latency, but a limited number of retries within a bounded time may be | |||
| yet respect end-to-end constraints. | used within end-to-end constraints. | |||
| 2.1.1.2. OAM | 2.1.1.2. OAM | |||
| OAM stands for Operations, Administration, and Maintenance, and | OAM stands for Operations, Administration, and Maintenance, and | |||
| covers the processes, activities, tools, and standards involved with | covers the processes, activities, tools, and standards involved with | |||
| operating, administering, managing and maintaining any system. This | operating, administering, managing and maintaining any system. This | |||
| document uses the terms Operations, Administration, and Maintenance, | document uses the terms Operations, Administration, and Maintenance, | |||
| in conformance with the 'Guidelines for the Use of the "OAM" Acronym | in conformance with the 'Guidelines for the Use of the "OAM" Acronym | |||
| in the IETF' [RFC6291] and the system observed by the RAW OAM is the | in the IETF' [RFC6291] and the system observed by the RAW OAM is the | |||
| Track. | Track. | |||
| skipping to change at page 6, line 47 ¶ | skipping to change at page 6, line 48 ¶ | |||
| Observe, Orient, Decide, Act. The OODA Loop is a conceptual cyclic | Observe, Orient, Decide, Act. The OODA Loop is a conceptual cyclic | |||
| model developed by USAF Colonel John Boyd, and that is applicable in | model developed by USAF Colonel John Boyd, and that is applicable in | |||
| multiple domains where agility can provide benefits against brute | multiple domains where agility can provide benefits against brute | |||
| force. | force. | |||
| 2.1.1.4. PAREO | 2.1.1.4. PAREO | |||
| Packet (hybrid) ARQ, Replication, Elimination and Ordering. PAREO is | Packet (hybrid) ARQ, Replication, Elimination and Ordering. PAREO is | |||
| a superset Of DetNet's PREOF that includes radio-specific techniques | a superset Of DetNet's PREOF that includes radio-specific techniques | |||
| such as short range broadcast, MUMIMO, constructive interference and | such as short range broadcast, MUMIMO, PHY rate and other Modulation | |||
| Coding Scheme (MCS) adaptation, constructive interference and | ||||
| overhearing, which can be leveraged separately or combined to | overhearing, which can be leveraged separately or combined to | |||
| increase the reliability. | increase the reliability. | |||
| 2.1.2. Link and Direction | 2.1.2. Link and Direction | |||
| 2.1.2.1. Flapping | 2.1.2.1. Flapping | |||
| In the context of RAW, a link flaps when the reliability of the | In the context of RAW, a link flaps when the reliability of the | |||
| wireless connectivity drops abruptly for a short period of time, | wireless connectivity drops abruptly for a short period of time, | |||
| typically of a subsecond to seconds duration. | typically of a subsecond to seconds duration. | |||
| 2.1.2.2. Uplink | 2.1.2.2. Uplink | |||
| Connection from end-devices to a data communication equipment. In | Connection from end-devices to a data communication equipment. In | |||
| the context of wireless, uplink refers to the connection between a | the context of wireless, uplink refers to the connection between a | |||
| station (STA) and a controller (AP) or a User Equipment (UE) to a | station (STA) and a controller (AP) or a User Equipment (UE) to a | |||
| Base Station (BS) such as a 3GPP 5G gNodeB (gNb). | Base Station (BS) such as a 3GPP 5G gNodeB (gNb). | |||
| 2.1.2.3. Downlink | 2.1.2.3. Downlink | |||
| The reverse direction from uplink. | The reverse direction from uplink. | |||
| 2.1.2.4. Downstream | 2.1.2.4. Downstream | |||
| Following the the direction of the flow data path along a Track. | Following the direction of the flow data path along a Track. | |||
| 2.1.2.5. Upstream | 2.1.2.5. Upstream | |||
| Against the direction of the flow data path along a Track. | Against the direction of the flow data path along a Track. | |||
| 2.1.3. Path and Tracks | 2.1.3. Path and Tracks | |||
| 2.1.3.1. Path | 2.1.3.1. Path | |||
| Quoting section 1.1.3 of [INT-ARCHI]: | Quoting section 1.1.3 of [INT-ARCHI]: | |||
| | "At a given moment, all the IP datagrams from a particular source | | At a given moment, all the IP datagrams from a particular source | |||
| | host to a particular destination host will typically traverse the | | host to a particular destination host will typically traverse the | |||
| | same sequence of gateways. We use the term "path" for this | | same sequence of gateways. We use the term "path" for this | |||
| | sequence. Note that a path is uni-directional; it is not unusual | | sequence. Note that a path is uni-directional; it is not unusual | |||
| | to have different paths in the two directions between a given host | | to have different paths in the two directions between a given host | |||
| | pair.". | | pair. | |||
| Section 2 of [I-D.irtf-panrg-path-properties] points to a longer, | Section 2 of [I-D.irtf-panrg-path-properties] points to a longer, | |||
| more modern definition of path, which begins as follows: | more modern definition of path, which begins as follows: | |||
| | A sequence of adjacent path elements over which a packet can be | | A sequence of adjacent path elements over which a packet can f be | |||
| | transmitted, starting and ending with a node. A path is | | transmitted, starting and ending with a node. A path is | |||
| | unidirectional. Paths are time-dependent, i.e., the sequence of | | unidirectional. Paths are time-dependent, i.e., the sequence of | |||
| | path elements over which packets are sent from one node to another | | path elements over which packets are sent from one node to another | |||
| | may change. A path is defined between two nodes. | | may change. A path is defined between two nodes. | |||
| It follows that the general acceptance of a path is a linear sequence | It follows that the general acceptance of a path is a linear sequence | |||
| of nodes, as opposed to a multi-dimensional graph. In the context of | of nodes, as opposed to a multi-dimensional graph. In the context of | |||
| this document, a path is observed by following one copy of a packet | this document, a path is observed by following one copy of a packet | |||
| that is injected in a Track and possibly replicated within. | that is injected in a Track and possibly replicated within. | |||
| 2.1.3.2. Track | 2.1.3.2. Track | |||
| A networking graph that can be followed to transport packets with | A networking graph that can be followed to transport packets with | |||
| equivalent treatment; as opposed to the definition of a path above, a | equivalent treatment; as opposed to the definition of a path above, a | |||
| Track Track is not necessarily linear. It may contain multiple paths | Track is not necessarily a linear sequence. It may contain multiple | |||
| that may fork and rejoin, for instance to enable the RAW PAREO | paths that may fork and rejoin, for instance to enable the RAW PAREO | |||
| operations. | operations. | |||
| In DetNet [RFC8655] terms, a Track has the following properties: | In DetNet [RFC8655] terms, a Track has the following properties: | |||
| * A Track has one Ingress and one Egress nodes, which operate as | * A Track has one Ingress and one Egress nodes, which operate as | |||
| DetNet Edge nodes. | DetNet Edge nodes. | |||
| * A Track is reversible, meaning that packets can be routed against | * A Track is reversible, meaning that packets can be routed against | |||
| the flow of data packets, e.g., to carry OAM measurements or | the flow of data packets, e.g., to carry OAM measurements or | |||
| control messages back to the Ingress. | control messages back to the Ingress. | |||
| skipping to change at page 9, line 7 ¶ | skipping to change at page 9, line 7 ¶ | |||
| Southwards along a bidirectional Segment, but never bounces back. | Southwards along a bidirectional Segment, but never bounces back. | |||
| 2.1.4. Deterministic Networking | 2.1.4. Deterministic Networking | |||
| This document reuses the terminology in section 2 of [RFC8557] and | This document reuses the terminology in section 2 of [RFC8557] and | |||
| section 4.1.2 of [RFC8655] for deterministic networking and | section 4.1.2 of [RFC8655] for deterministic networking and | |||
| deterministic networks. | deterministic networks. | |||
| 2.1.4.1. Flow | 2.1.4.1. Flow | |||
| A collection of consecutive packets that must be placed on the same | A collection of consecutive IP packets defined by the upper layers | |||
| Track to receive an equivalent treatment from Ingress to Egress | and signaled by the same 5 or 6-tuple, see section 5.1 of [RFC8939]. | |||
| within the Track. Multiple flows may be transported along the same | Packets of the same flow must be placed on the same Track to receive | |||
| Track. The subTrack that is selected for the flow may change over | an equivalent treatment from Ingress to Egress within the Track. | |||
| time under the control of the PSE. | Multiple flows may be transported along the same Track. The subTrack | |||
| that is selected for the flow may change over time under the control | ||||
| of the PSE. | ||||
| 2.1.4.2. Deterministic Flow Identifier (L2) | 2.1.4.2. Deterministic Flow Identifier (L2) | |||
| A tuple identified by a stream_handle, and provided by a bridge, in | A tuple identified by a stream_handle, and provided by a bridge, in | |||
| accordance with IEEE 802.1CB. The tuple comprises at least src MAC, | accordance with IEEE 802.1CB. The tuple comprises at least src MAC, | |||
| dst MAC, VLAN ID, and L2 priority. Continuous streams are | dst MAC, VLAN ID, and L2 priority. Continuous streams are | |||
| characterized by bandwidth and max packet size; scheduled streams are | characterized by bandwidth and max packet size; scheduled streams are | |||
| characterized by a repeating pattern of timed transmissions. | characterized by a repeating pattern of timed transmissions. | |||
| 2.1.4.3. Deterministic Flow Identifier (L3) | 2.1.4.3. Deterministic Flow Identifier (L3) | |||
| See section 3.3 of [DetNet-DP]. The classical IP 5-tuple that | See section 3.3 of [DetNet-DP]. The classical IP 5-tuple that | |||
| identifies a flow comprises the src IP, dst IP, src port, dest port, | identifies a flow comprises the src IP, dst IP, src port, dest port, | |||
| and the upper layer protocol (ULP). DetNet uses a 6-tuple where the | and the upper layer protocol (ULP). DetNet uses a 6-tuple where the | |||
| extra field is the DSCP field in the packet. The IPv6 flow label is | extra field is the DSCP field in the packet. The IPv6 flow label is | |||
| not used. for that purpose. | not used for that purpose. | |||
| 2.1.4.4. TSN | ||||
| TSN stands for Time Sensitive Networking and denotes the efforts at | ||||
| IEEE 802 for deterministic networking, originally for use on | ||||
| Ethernet. Wireless TSN (WTSN) denotes extensions of the TSN work on | ||||
| wireless media such as the selected RAW technologies [RAW-TECHNOS]. | ||||
| 2.1.5. Reliability and Availability | 2.1.5. Reliability and Availability | |||
| In the context of the RAW work, Reliability and Availability are | In the context of the RAW work, Reliability and Availability are | |||
| defined as follows: | defined as follows: | |||
| 2.1.5.1. Service Level Agreement | 2.1.5.1. Service Level Agreement | |||
| In the context of RAW, an SLA (service level agreement) is a contract | In the context of RAW, an SLA (service level agreement) is a contract | |||
| between a provider, the network, and a client, the application flow, | between a provider, the network, and a client, the application flow, | |||
| about measurable metrics such as latency boundaries, consecutive | about measurable metrics such as latency boundaries, consecutive | |||
| losses, and packet delivery ratio (PDR). | losses, and packet delivery ratio (PDR). | |||
| 2.1.5.2. Service Level Objective | 2.1.5.2. Service Level Objective | |||
| A service level objective (SLO) is one term in the SLO, for which | A service level objective (SLO) is one term in the SLA, for which | |||
| specific network setting and operations are implemented. For | specific network setting and operations are implemented. For | |||
| instance, a dynamic tuning of the packet redundancy will address an | instance, a dynamic tuning of the packet redundancy will address an | |||
| SLO of consecutive losses in a row by augmenting the chances of | SLO of consecutive losses in a row by augmenting the chances of | |||
| delivery of a packet that follows a loss.). | delivery of a packet that follows a loss.). | |||
| 2.1.5.3. Service Level Indicator | 2.1.5.3. Service Level Indicator | |||
| A service level indicator (SLI) measures the complience of an SLO to | A service level indicator (SLI) measures the compliance of an SLO to | |||
| the terms of the contrast. It can be for instance the statistics of | the terms of the contrast. It can be for instance the statistics of | |||
| individual losses and losses in a row as time series.). | individual losses and losses in a row as time series.). | |||
| 2.1.5.4. Reliability | 2.1.5.4. Reliability | |||
| Reliability is a measure of the probability that an item will perform | Reliability is a measure of the probability that an item will perform | |||
| its intended function for a specified interval under stated | its intended function for a specified interval under stated | |||
| conditions (SLA). RAW expresses reliability in terms of Mean Time | conditions (SLA). RAW expresses reliability in terms of Mean Time | |||
| Between Failure (MTBF) and Maximum Consecutive Failures (MCF). More | Between Failure (MTBF) and Maximum Consecutive Failures (MCF). More | |||
| in [NASA].). | in [NASA].). | |||
| skipping to change at page 11, line 43 ¶ | skipping to change at page 12, line 4 ¶ | |||
| begins. In the context of RAW, RT is useful for a transit node, not | begins. In the context of RAW, RT is useful for a transit node, not | |||
| ingress or egress. | ingress or egress. | |||
| 2.1.6.7. Additional References | 2.1.6.7. Additional References | |||
| [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. | |||
| 2.2. Reliability and Availability | 2.2. Reliability and Availability | |||
| 2.2.1. High Availability Engineering Principles | 2.2.1. High Availability Engineering Principles | |||
| The reliability criteria of a critical system pervade through its | The reliability criteria of a critical system pervades through its | |||
| elements, and if the system comprises a data network then the data | elements, and if the system comprises a data network then the data | |||
| network is also subject to the inherited reliability and availability | network is also subject to the inherited reliability and availability | |||
| criteria. It is only natural to consider the art of high | criteria. It is only natural to consider the art of high | |||
| availability engineering and apply it to wireless communications in | availability engineering and apply it to wireless communications in | |||
| the context of RAW. | the context of RAW. | |||
| There are three principles [pillars] of high availability | There are three principles [pillars] of high availability | |||
| engineering: | engineering: | |||
| 1. elimination of single points of failure | 1. elimination of single points of failure | |||
| skipping to change at page 12, line 39 ¶ | skipping to change at page 12, line 47 ¶ | |||
| the same fate if the bundle is cut. The same effect can happen with | the same fate if the bundle is cut. The same effect can happen with | |||
| virtual links that end up in a same physical transport through the | virtual links that end up in a same physical transport through the | |||
| games of encapsulation. In a same fashion, an interferer or an | games of encapsulation. In a same fashion, an interferer or an | |||
| obstacle may affect multiple wireless transmissions at the same time, | obstacle may affect multiple wireless transmissions at the same time, | |||
| even between different sets of peers. | even between different sets of peers. | |||
| Intermediate network Nodes such as routers, switches and APs, wire | Intermediate network Nodes such as routers, switches and APs, wire | |||
| bundles and the air medium itself can become single points of | bundles and the air medium itself can become single points of | |||
| failure. For High Availability, it is thus required to use | failure. For High Availability, it is thus required to use | |||
| physically link- and Node-disjoint paths; in the wireless space, it | physically link- and Node-disjoint paths; in the wireless space, it | |||
| is also required to use the highest possible degree of diversity in | is also required to use the highest possible degree of diversity | |||
| the transmissions over the air to combat the additional causes of | (time, space, code, frequency, channel width) in the transmissions | |||
| transmission loss. | over the air to combat the additional causes of transmission loss. | |||
| From an economics standpoint, executing this principle properly | From an economics standpoint, executing this principle properly | |||
| generally increases capitalization expense because of the redundant | generally increases capitalization expense because of the redundant | |||
| equipment. In a constrained network where the waste of energy and | equipment. In a constrained network where the waste of energy and | |||
| bandwidth should be minimized, an excessive use of redundant links | bandwidth should be minimized, an excessive use of redundant links | |||
| must be avoided; for RAW this means that the extra bandwidth must be | must be avoided; for RAW this means that the extra bandwidth must be | |||
| used wisely and with parcimony. | used wisely and with parcimony. | |||
| 2.2.1.2. Reliable Crossover | 2.2.1.2. Reliable Crossover | |||
| skipping to change at page 14, line 15 ¶ | skipping to change at page 14, line 19 ¶ | |||
| "Overview and Principles of Internet Traffic Engineering" [TE] | "Overview and Principles of Internet Traffic Engineering" [TE] | |||
| discusses the importance of measurement for network protection, and | discusses the importance of measurement for network protection, and | |||
| provides abstract an method for network survivability with the | provides abstract an method for network survivability with the | |||
| analysis of a traffic matrix as observed by SNMP, probing techniques, | analysis of a traffic matrix as observed by SNMP, probing techniques, | |||
| FTP, IGP link state advertisements, and more. | FTP, IGP link state advertisements, and more. | |||
| Those measurements are needed in the context of RAW to inform the | Those measurements are needed in the context of RAW to inform the | |||
| controller and make the long term reactive decision to rebuild a | controller and make the long term reactive decision to rebuild a | |||
| complex path. But RAW itself operates in the Network Plane at a | complex path. But RAW itself operates in the Network Plane at a | |||
| faster time scale. To act on the Data Plane, RAW needs live | faster time scale. To act on the Data Plane, RAW needs live | |||
| information from the Operational Plane , e.g., using Bidirectional | information from the Operational Plane , e.g., using Dynamic Link | |||
| Forwarding Detection [BFD] and its variants (bidirectional and remote | Exchange Protocol (DLEP) [DLEP] to obtain timely and accurate | |||
| BFD) to protect a link, and OAM techniques to protect a path. | knowledge of the characteristics of the link (speed, state, etc.). | |||
| 2.2.2. Applying Reliability Concepts to Networking | 2.2.2. Applying Reliability Concepts to Networking | |||
| The terms Reliability and Availability are defined for use in RAW in | The terms Reliability and Availability are defined for use in RAW in | |||
| Section 2.1 and the reader is invited to read [NASA] for more details | Section 2.1 and the reader is invited to read [NASA] for more details | |||
| on the general definition of Reliability. Practically speaking a | on the general definition of Reliability. Practically speaking a | |||
| number of nines is often used to indicate the reliability of a data | number of nines is often used to indicate the reliability of a data | |||
| link, e.g., 5 nines indicate a Packet Delivery Ratio (PDR) of | link, e.g., 5 nines indicate a Packet Delivery Ratio (PDR) of | |||
| 99.999%. | 99.999%. | |||
| skipping to change at page 15, line 32 ¶ | skipping to change at page 15, line 35 ¶ | |||
| a reflection on a physical structure (echo). The reflections take | a reflection on a physical structure (echo). The reflections take | |||
| a longer path and are delayed by the extra distance divided by the | a longer path and are delayed by the extra distance divided by the | |||
| speed of light in the medium. Depending on the frequency, the | speed of light in the medium. Depending on the frequency, the | |||
| echo lands with a different phase which may add up to | echo lands with a different phase which may add up to | |||
| (constructive interference) or cancel the direct signal | (constructive interference) or cancel the direct signal | |||
| (destructive interference). | (destructive interference). | |||
| The affected frequencies depend on the relative position of the | The affected frequencies depend on the relative position of the | |||
| sender, the receiver, and all the reflecting objects in the | sender, the receiver, and all the reflecting objects in the | |||
| environment. A given hop will suffer from multipath fading for | environment. A given hop will suffer from multipath fading for | |||
| multiple packets in a row till the something moves that changes | multiple packets in a row till a phyqical movement changes the | |||
| the reflection patterns. | reflection patterns. | |||
| Co-channel Interference Energy in the spectrum used for the | Co-channel Interference Energy in the spectrum used for the | |||
| transmission confuses the receiver. | transmission confuses the receiver. | |||
| The wireless medium itself is a Shared Risk Link Group (SRLG) for | The wireless medium itself is a Shared Risk Link Group (SRLG) for | |||
| nearby users of the same spectrum, as an interference may affect | nearby users of the same spectrum, as an interference may affect | |||
| multiple co-channel transmissions between different peers within | multiple co-channel transmissions between different peers within | |||
| the interference domain of the interferer, possibly even when they | the interference domain of the interferer, possibly even when they | |||
| use different technologies. | use different technologies. | |||
| skipping to change at page 18, line 24 ¶ | skipping to change at page 18, line 24 ¶ | |||
| 3. The RAW Conceptual Model | 3. 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 | |||
| observes and takes actions on all hops or not. For instance, the | observes and takes actions on all hops or not. For instance, the | |||
| packets between two wireless entities may be relayed over a wired | packets between two wireless entities may be relayed over a wired | |||
| infrastructure such as a Wi-Fi extended service set (ESS) or a 5G | infrastructure such as a Wi-Fi extended service set (ESS) or a 5G | |||
| Core; in that case, RAW observes and control the transmission over | Core; in that case, RAW observes and controls the transmission over | |||
| the wireless first and last hops, as well as end-to-end metrics such | the wireless first and last hops, as well as end-to-end metrics such | |||
| as latency, jitter, and delivery ratio. This operation is loose | as latency, jitter, and delivery ratio. This operation is loose | |||
| since the structure and properties of the wired infrastructure are | since the structure and properties of the wired infrastructure are | |||
| ignored, and may be either controlled by other means such as DetNet/ | ignored, and may be either controlled by other means such as DetNet/ | |||
| TSN, or neglected in the face of the wireless hops. | TSN, or neglected in the face of the wireless hops. | |||
| A Controller Plane Function (CPF) called the Path Computation Element | A Controller Plane Function (CPF) called the Path Computation Element | |||
| (PCE) [RFC4655] interacts with RAW Nodes over a Southbound API. The | (PCE) [RFC4655] interacts with RAW Nodes over a Southbound API. The | |||
| RAW Nodes are DetNet relays that are capable of additional diversity | RAW Nodes are DetNet relays that are capable of additional diversity | |||
| mechanisms and measurement functions related to the radio interface, | mechanisms and measurement functions related to the radio interface, | |||
| skipping to change at page 19, line 27 ¶ | skipping to change at page 19, line 27 ¶ | |||
| Node z-- Node --- ( Nodes ) Node | Node z-- Node --- ( Nodes ) Node | |||
| ... . | ... . | |||
| --z wireless wired | --z wireless wired | |||
| z-- link --- link | z-- link --- link | |||
| Figure 2: RAW Nodes | Figure 2: 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), number of flows (bandwidth that can be reserved for a | |||
| and mean squared deviation of availability and reliability figures | flomw depends on the number and size of flows sharing the spectrum) | |||
| such as Packet Delivery Ratio (PDR) over long periods of time. | and average and mean squared deviation of availability and | |||
| reliability figures 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 | |||
| reliably deliver the packets within a System Level Agreement (SLA) | reliably deliver the packets within a System Level Agreement (SLA) | |||
| associated to the flows that it transports. The SLA defines end-to- | associated to the flows that it transports. The SLA defines end-to- | |||
| end reliability and availability requirements, where reliability may | end reliability and availability requirements, where reliability may | |||
| be expressed as a successful delivery in order and within a bounded | be expressed as a successful delivery in order and within a bounded | |||
| delay of at least one copy of a packet. | delay of at least one copy of a packet. | |||
| Depending on the use case and the SLA, the Track may comprise non-RAW | Depending on the use case and the SLA, the Track may comprise non-RAW | |||
| skipping to change at page 20, line 13 ¶ | skipping to change at page 20, line 13 ¶ | |||
| 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. The OODA Loop | 4. The OODA Loop | |||
| The RAW Architecture is structured as an OODA Loop (Observe, Orient, | The RAW Architecture is structured as an OODA Loop (Observe, Orient, | |||
| Decide, Act). It involves: | Decide, Act). It involves: | |||
| 1. Network Plane measurement protocols for Operations, | 1. Network Plane measurement protocols for Operations, | |||
| Administration and Maintenance (OAM) to Observe some or all hops | Administration and Maintenance (OAM) to Observe some or all hops | |||
| along a Track as well as the end-to-end packet delivery, more in | along a Track as well as the end-to-end packet delivery, more in | |||
| Section 5; | Section 4.1; | |||
| 2. Controller plane elements to reports the links statistics to a | 2. Controller plane elements to reports the links statistics to a | |||
| Path computation Element (PCE) in a centralized controller that | Path computation Element (PCE) in a centralized controller that | |||
| computes and installs the Tracks and provides meta data to Orient | computes and installs the Tracks and provides meta data to Orient | |||
| the routing decision, more in Section 6; | the routing decision, more in Section 4.2; | |||
| 3. A Runtime distributed Path Selection Engine (PSE) thar Decides | 3. A Runtime distributed Path Selection Engine (PSE) thar Decides | |||
| which subTrack to use for the next packet(s) that are routed | which subTrack to use for the next packet(s) that are routed | |||
| along the Track, more in Section 7; | along the Track, more in Section 4.3; | |||
| 4. Packet (hybrid) ARQ, Replication, Elimination and Ordering | 4. Packet (hybrid) ARQ, Replication, Elimination and Ordering | |||
| Dataplane actions that operate at the DetNet Service Layer to | Dataplane actions that operate at the DetNet Service Layer to | |||
| increase the reliability o fthe end-to-end transmission. The RAW | increase the reliability o fthe end-to-end transmission. The RAW | |||
| architecture also covers in-situ signalling when the decision is | architecture also covers in-situ signalling when the decision is | |||
| Acted by a node that down the Track from the PSE, more in | Acted by a node that down the Track from the PSE, more in | |||
| Section 8. | Section 4.4. | |||
| +-------> Orient (PCE) --------+ | +-------> Orient (PCE) --------+ | |||
| | link stats, | | | link stats, | | |||
| | pre-trained model | | | pre-trained model | | |||
| | ... | | | ... | | |||
| | | | | | | |||
| | v | | v | |||
| Observe (OAM) Decide (PSE) | Observe (OAM) Decide (PSE) | |||
| ^ | | ^ | | |||
| | | | | | | |||
| skipping to change at page 21, line 5 ¶ | skipping to change at page 21, line 5 ¶ | |||
| At DetNet | At DetNet | |||
| Service sublayer | Service sublayer | |||
| Figure 3: The RAW OODA Loop | Figure 3: The RAW OODA Loop | |||
| The overall OODA Loop optimizes the use of redundancy to achieve the | The overall OODA Loop optimizes the use of redundancy to achieve the | |||
| required reliability and availability Service Level Agreement (SLA) | required reliability and availability Service Level Agreement (SLA) | |||
| while minimizing the use of constrained resources such as spectrum | while minimizing the use of constrained resources such as spectrum | |||
| and battery. | and battery. | |||
| 5. Observe: The RAW OAM | 4.1. 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. As packets | |||
| OAM may be needed to observe the unused segments and evaluate the | may be load balanced, replicated, eliminated, and / or fragmented for | |||
| desirability of a rerouting decision. Finally, the RAW Service Layer | Network Coding (NC) forward error correction (FEC), the RAW In-situ | |||
| Assurance may observe the individual PAREO operation of a relay node | operation needs to be able to signal which operation occured to an | |||
| to ensure that it is conforming; this might require injecting an OAM | individual packet. | |||
| packet at an upstream point inside the Track and extracting that | ||||
| packet at another point downstream before it reaches the egress. | Active RAW OAM may be needed to observe the unused segments and | |||
| evaluate the desirability of a rerouting decision. | ||||
| Finally, the RAW Service Layer Assurance may observe the individual | ||||
| PAREO operation of a relay node 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 another point downstream before | ||||
| it reaches the egress. | ||||
| This observation feeds the RAW PSE that makes the decision on which | This observation feeds the RAW PSE that makes the decision on which | |||
| PAREO function in actioned at which RAW Node, for one a small | PAREO function is actioned at which RAW Node, for one a small | |||
| continuous series of packets. | continuous series of packets. | |||
| ... .. | ... .. | |||
| RAN 1 ----- ... .. ... | RAN 1 ----- ... .. ... | |||
| / . .. .... | / . .. .... | |||
| +-------+ / . .. .... +------+ | +-------+ / . .. .... +------+ | |||
| |Ingress|- . ..... |Egress| | |Ingress|- . ..... |Egress| | |||
| | End |------ RAN 2 -- . Internet ....---| End | | | End |------ RAN 2 -- . Internet ....---| End | | |||
| |System |- .. ..... |System| | |System |- .. ..... |System| | |||
| +-------+ \ . ...... +------+ | +-------+ \ . ...... +------+ | |||
| skipping to change at page 22, line 14 ¶ | skipping to change at page 22, line 14 ¶ | |||
| The Links that are not observed by OAM are opaque to it, meaning that | The Links that are not observed by OAM are opaque to it, meaning that | |||
| the OAM information is carried across and possibly echoed as data, | the OAM information is carried across and possibly echoed as data, | |||
| but there is no information capture in intermediate nodes. In the | but there is no information capture in intermediate nodes. In the | |||
| example above, the Internet is opaque and not controlled by RAW; | example above, the Internet is opaque and not controlled by RAW; | |||
| still the RAW OAM measures the end-to-end latency and delivery ratio | still the RAW OAM measures the end-to-end latency and delivery ratio | |||
| for packets sent via each if RAN 1, RAN 2 and RAN 3, and determines | for packets sent via each if RAN 1, RAN 2 and RAN 3, and determines | |||
| whether a packet should be sent over either or a collection of those | whether a packet should be sent over either or a collection of those | |||
| access links. | access links. | |||
| 6. Orient: The Path Computation Engine | 4.2. Orient: The Path Computation Engine | |||
| RAW separates the path computation time scale at which a complex path | RAW separates the path computation time scale at which a complex path | |||
| is recomputed from the path selection time scale at which the | is recomputed from the path selection time scale at which the | |||
| forwarding decision is taken for one or a few packets (see in | forwarding decision is taken for one or a few packets (see in | |||
| Section 2.3). | Section 2.3). | |||
| The path computation is out of scope, but RAW expects that the | The path computation is out of scope, but RAW expects that the | |||
| Controller plane protocol that installs the Track also provides | Controller plane protocol that installs the Track also provides | |||
| related knowledge in the form of meta data about the links, segments | related knowledge in the form of meta data about the links, segments | |||
| and possible subTracks. That meta data can be a pre-digested | and possible subTracks. That meta data can be a pre-digested | |||
| skipping to change at page 22, line 44 ¶ | skipping to change at page 22, line 44 ¶ | |||
| * Link Quality Statistics and their projected evolution | * Link Quality Statistics and their projected evolution | |||
| The Track is installed with measurable objectives that are computed | The Track is installed with measurable objectives that are computed | |||
| by the PCE to achieve the RAW SLA. The objectives can be expressed | by the PCE to achieve the RAW SLA. The objectives can be expressed | |||
| as any of maximum number of packet lost in a row, bounded latency, | as any of maximum number of packet lost in a row, bounded latency, | |||
| maximal jitter, maximum nmuber of interleaved out of order packets, | maximal jitter, maximum nmuber of interleaved out of order packets, | |||
| average number of copies received at the elimination point, and | average number of copies received at the elimination point, and | |||
| maximal delay between the first and the last received copy of the | maximal delay between the first and the last received copy of the | |||
| same packet. | same packet. | |||
| 7. Decide: The Path Selection Engine | 4.3. Decide: The Path Selection Engine | |||
| The RAW OODA Loop operates at the path selection time scale to | The RAW OODA Loop operates at the path selection time scale to | |||
| provide agility vs. the brute force approach of flooding the whole | provide agility vs. the brute force approach of flooding the whole | |||
| Track. The OODA Loop controls, within the redundant solutions that | Track. The OODA Loop controls, within the redundant solutions that | |||
| are proposed by the PCE, which will be used for each packet to | are proposed by the PCE, which will be used for each packet to | |||
| provide a Reliable and Available service while minimizing the waste | provide a Reliable and Available service while minimizing the waste | |||
| of constrained resources. | of constrained resources. | |||
| To that effect, RAW defines the Path Selection Engine (PSE) that is | To that effect, RAW defines the Path Selection Engine (PSE) that is | |||
| the counterpart of the PCE to perform rapid local adjustments of the | the counterpart of the PCE to perform rapid local adjustments of the | |||
| forwarding tables within the diversity that the PCE has selected for | forwarding tables within the diversity that the PCE has selected for | |||
| the Track. The PSE enables to exploit the richer forwarding | the Track. The PSE enables to exploit the richer forwarding | |||
| capabilities with PAREO and scheduled transmissions at a faster time | capabilities with PAREO and scheduled transmissions at a faster time | |||
| scale over the smaller domain that is the Track, in either a loose or | scale over the smaller domain that is the Track, in either a loose or | |||
| a strict fashion. | a strict fashion. | |||
| Compared to the PCE, the PSE operates on metrics that evolve faster, | Compared to the PCE, the PSE operates on metrics that evolve faster, | |||
| but that needs to be advertised at a fast rate but only locally, | but that need to be advertised at a fast rate but only locally, | |||
| within the Track. The forwarding decision may also change rapidly, | within the Track. The forwarding decision may also change rapidly, | |||
| but with a scope that is also contained within the Track, with no | but with a scope that is also contained within the Track, with no | |||
| visibility to the other Tracks and flows in the network. This is as | 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 | opposed to the PCE that must observe the whole network and optimize | |||
| optimize all the Tracks globally, which can only be done at a slow | all the Tracks globally, which can only be done at a slow pace and | |||
| pace and using long-term statistical metrics, as presented in | using long-term statistical metrics, as presented in Table 1. | |||
| Table 1. | ||||
| +===============+========================+===================+ | +===============+========================+===================+ | |||
| | | PCE (Not in Scope) | PSE (In Scope) | | | | PCE (Not in Scope) | PSE (In Scope) | | |||
| +===============+========================+===================+ | +===============+========================+===================+ | |||
| | Operation | Centralized | Source-Routed or | | | Operation | Centralized | Source-Routed or | | |||
| | | | Distributed | | | | | Distributed | | |||
| +---------------+------------------------+-------------------+ | +---------------+------------------------+-------------------+ | |||
| | Communication | Slow, expensive | Fast, local | | | Communication | Slow, expensive | Fast, local | | |||
| +---------------+------------------------+-------------------+ | +---------------+------------------------+-------------------+ | |||
| | Time Scale | hours and above | seconds and below | | | Time Scale | hours and above | seconds and below | | |||
| skipping to change at page 24, line 27 ¶ | skipping to change at page 24, line 27 ¶ | |||
| | and Forward | metrics about Links | OAM packets | | | and Forward | metrics about Links | OAM packets | | |||
| +..........v..........+..........^..........+.........^.v.........+ | +..........v..........+..........^..........+.........^.v.........+ | |||
| | Lower layers | | | Lower layers | | |||
| +..........v.....................^....................^.v.........+ | +..........v.....................^....................^.v.........+ | |||
| frame | sent Frame | L2 Ack oOAM | | packet | frame | sent Frame | L2 Ack oOAM | | packet | |||
| over | wireless In | In | | and out | over | wireless In | In | | and out | |||
| v | | v | v | | v | |||
| Figure 5: PSE | Figure 5: PSE | |||
| 8. Act: The PAREO Functions | 4.4. Act: The PAREO Functions | |||
| RAW may control whether and how to use packet replication and | RAW may control whether and how to use packet replication and | |||
| elimination (PRE), Automatic Repeat reQuest (ARQ), Hybrid ARQ (HARQ) | elimination (PRE), Automatic Repeat reQuest (ARQ), Hybrid ARQ (HARQ) | |||
| that includes Forward Error Correction (FEC) and coding, and other | that includes Forward Error Correction (FEC) and coding, and other | |||
| wireless-specific techniques such as overhearing and constructive | wireless-specific techniques such as overhearing and constructive | |||
| interferences, in order to increase the reliabiility and availability | interferences, in order to increase the reliabiility and availability | |||
| of the end-to-end transmission. | of the end-to-end transmission. | |||
| Collectively, those function are called PAREO for Packet (hybrid) | Collectively, those function are called PAREO for Packet (hybrid) | |||
| ARQ, Replication, Elimination and Ordering. By tuning dynamically | ARQ, Replication, Elimination and Ordering. By tuning dynamically | |||
| the use of PAREO functions, RAW avoids the waste of critical | the use of PAREO functions, RAW avoids the waste of critical | |||
| resources such as spectrum and energy while providing that the | resources such as spectrum and energy while providing that the | |||
| guaranteed SLA, e.g., by adding redundancy only when a spike of loss | guaranteed SLA, e.g., by adding redundancy only when a spike of loss | |||
| is observed. | is observed. | |||
| In a nutshell, PAREO establishes several paths in a network to | In a nutshell, PAREO establishes several paths in a network to | |||
| provide redundancy and parallel transmissions to bound the end-to-end | provide redundancy and parallel transmissions to bound the end-to-end | |||
| delay to traverse the network. Optionally, promiscuous listening | delay to traverse the network. Optionally, promiscuous listening | |||
| between paths is possible, such that the Nodes on one path may | between paths is possible, such that the Nodes on one path may | |||
| overhear transmissions along the other path. Considering the | overhear transmissions along the other path. Considering the | |||
| scenario shown in Figure 6, many different paths are possible for to | scenario shown in Figure 6, many different paths are possible to | |||
| traverse the network from ingress to egress. A simple way to benefit | traverse the network from ingress to egress. A simple way to benefit | |||
| from this topology could be to use the two independent paths via | 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 | 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 | by interleaving transmissions from the lower level of the path to the | |||
| upper level. | upper level. | |||
| (A) -- (C) -- (E) | (A) -- (C) -- (E) | |||
| / \ | / \ | |||
| Ingress = | | | = Egress | Ingress = | | | = Egress | |||
| \ / | \ / | |||
| skipping to change at page 25, line 42 ¶ | skipping to change at page 25, line 42 ¶ | |||
| already received that particular frame at an earlier timeslot in a | already received that particular frame at an earlier timeslot in a | |||
| dedicated transmission towards B. | dedicated transmission towards B. | |||
| The PAREO model can be implemented in both centralized and | The PAREO model can be implemented in both centralized and | |||
| distributed scheduling approaches. In the centralized approach, a | distributed scheduling approaches. In the centralized approach, a | |||
| Path Computation Element (PCE) scheduler calculates a Track and | Path Computation Element (PCE) scheduler calculates a Track and | |||
| schedules the communication. In the distributed approach, the Track | schedules the communication. In the distributed approach, the Track | |||
| is computed within the network, and signaled in the packets, e.g., | is computed within the network, and signaled in the packets, e.g., | |||
| using BIER-TE, Segment Routing, or a Source Routing Header. | using BIER-TE, Segment Routing, or a Source Routing Header. | |||
| 8.1. Packet Replication | 4.4.1. Packet Replication | |||
| By employing a Packet Replication procedure, a Node forwards a copy | 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 | 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 | (i.e., Ingress and intermediate Node) sends the data packet multiple | |||
| times as separate unicast transmissions. For instance, in Figure 7, | times as separate unicast transmissions. For instance, in Figure 7, | |||
| the Ingress Node is transmitting the packet to both successors, nodes | the Ingress Node is transmitting the packet to both successors, nodes | |||
| A and B, at two different times. | A and B, at two different times. | |||
| ===> (A) => (C) => (E) === | ===> (A) => (C) => (E) === | |||
| // \\// \\// \\ | // \\// \\// \\ | |||
| skipping to change at page 26, line 26 ¶ | skipping to change at page 26, line 26 ¶ | |||
| +=========+======+======+======+======+======+======+======+ | +=========+======+======+======+======+======+======+======+ | |||
| | Channel | 0 | 1 | 2 | 3 | 4 | 5 | 6 | | | Channel | 0 | 1 | 2 | 3 | 4 | 5 | 6 | | |||
| +=========+======+======+======+======+======+======+======+ | +=========+======+======+======+======+======+======+======+ | |||
| | 0 | S->A | S->B | B->C | B->D | C->F | E->R | F->R | | | 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 | | | | 1 | | A->C | A->D | C->E | D->E | D->F | | | |||
| +---------+------+------+------+------+------+------+------+ | +---------+------+------+------+------+------+------+------+ | |||
| Table 2: Packet Replication: Sample schedule | Table 2: Packet Replication: Sample schedule | |||
| 8.2. Packet Elimination | 4.4.2. Packet Elimination | |||
| The replication operation increases the traffic load in the network, | The replication operation increases the traffic load in the network, | |||
| due to packet duplications. This may occur at several stages inside | due to packet duplications. This may occur at several stages inside | |||
| the Track, and to avoid an explosion of the number of copies, a | the Track, and to avoid an explosion of the number of copies, a | |||
| Packet Elimination procedure must be applied as well. To this aim, | 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 | once a Node receives the first copy of a data packet, it discards the | |||
| subsequent copies. | subsequent copies. | |||
| The logical functions of Replication and Elimination may be | The logical functions of Replication and Elimination may be | |||
| collocated in an intermediate Node, the Node first eliminating the | collocated in an intermediate Node, the Node first eliminating the | |||
| redundant copies and then sending the packet exactly once to each of | redundant copies and then sending the packet exactly once to each of | |||
| the selected successors. | the selected successors. | |||
| 8.3. Promiscuous Overhearing | 4.4.3. Promiscuous Overhearing | |||
| Considering that the wireless medium is broadcast by nature, any | Considering that the wireless medium is broadcast by nature, any | |||
| neighbor of a transmitter may overhear a transmission. By employing | neighbor of a transmitter may overhear a transmission. By employing | |||
| the Promiscuous Overhearing operation, the next hops have additional | the Promiscuous Overhearing operation, the next hops have additional | |||
| opportunities to capture the data packets. In Figure 8, when Node A | opportunities to capture the data packets. In Figure 8, when Node A | |||
| is transmitting to its DP (Node C), the AP (Node D) and its sibling | 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 | (Node B) may decode this data packet as well. As a result, by | |||
| employing corellated paths, a Node may have multiple opportunities to | employing corellated paths, a Node may have multiple opportunities to | |||
| receive a given data packet. | receive a given data packet. | |||
| ===> (A) ====> (C) ====> (E) ==== | ===> (A) ====> (C) ====> (E) ==== | |||
| // ^ | \\ \\ | // ^ | \\ \\ | |||
| Ingress | | \\ Egress | Ingress | | \\ Egress | |||
| \\ | v \\ // | \\ | v \\ // | |||
| ===> (B) ====> (D) ====> (F) ==== | ===> (B) ====> (D) ====> (F) ==== | |||
| Figure 8: Unicast with Overhearing | Figure 8: Unicast with Overhearing | |||
| 8.4. Constructive Interference | Variations on the same idea such as link-layer anycast and multicast | |||
| may also be used to reach more than one next-hop with a single frame. | ||||
| 4.4.4. Constructive Interference | ||||
| Constructive Interference can be seen as the reverse of Promiscuous | Constructive Interference can be seen as the reverse of Promiscuous | |||
| Overhearing, and refers to the case where two senders transmit the | 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 | 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 | receiver and permit a reception that would not be possible with a | |||
| single sender at the same PHY mode and the same power level. | single sender at the same PHY mode and the same power level. | |||
| Constructive Interference was proposed on 5G, Wi-Fi7 and even tested | 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 | 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 the point that the signals are emitted at slightly different time | |||
| to offset the difference of propagation delay that corresponds to the | to offset the difference of propagation delay that corresponds to the | |||
| difference of distance of the transmitters to the receiver at the | difference of distance of the transmitters to the receiver at the | |||
| speed of light to the point that the symbols are superposed long | speed of light to the point that the symbols are superposed long | |||
| enough to be recognizable. | enough to be recognizable. | |||
| 9. 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. | |||
| 9.1. Forced Access | 5.1. Forced Access | |||
| RAW will typically select the cheapest collection of links that | RAW will typically select the cheapest collection of links that | |||
| matches the requested SLA, for instance, leverage free WI-Fi vs. paid | matches the requested SLA, for instance, leverage free WI-Fi vs. paid | |||
| 3GPP access. By defeating the cheap connectivity (e.g., PHY-layer | 3GPP access. By defeating the cheap connectivity (e.g., PHY-layer | |||
| interference) the attacker can force an End System to use the paid | interference) the attacker can force an End System to use the paid | |||
| access and increase the cost of the transmission for the user. | access and increase the cost of the transmission for the user. | |||
| 10. IANA Considerations | 6. IANA Considerations | |||
| This document has no IANA actions. | This document has no IANA actions. | |||
| 11. Contributors | 7. Contributors | |||
| The editor wishes to thank: | The editor wishes to thank: | |||
| Xavi Vilajosana: Wireless Networks Research Lab, Universitat Oberta | Xavi Vilajosana: Wireless Networks Research Lab, Universitat Oberta | |||
| de Catalunya | de Catalunya | |||
| Remous-Aris Koutsiamanis: IMT Atlantique | Remous-Aris Koutsiamanis: IMT Atlantique | |||
| Nicolas Montavont: IMT Atlantique | Nicolas Montavont: IMT Atlantique | |||
| Rex Buddenberg: Individual contributor | Rex Buddenberg: Individual contributor | |||
| Greg Mirsky: ZTE | Greg Mirsky: ZTE | |||
| for their contributions to the text and ideas exposed in this | for their contributions to the text and ideas exposed in this | |||
| document. | document. | |||
| 12. Acknowledgments | 8. Acknowledgments | |||
| TBD | TBD | |||
| 13. References | 9. References | |||
| 13.1. Normative References | 9.1. Normative References | |||
| [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>. | |||
| [INT-ARCHI] | [INT-ARCHI] | |||
| Braden, R., Ed., "Requirements for Internet Hosts - | Braden, R., Ed., "Requirements for Internet Hosts - | |||
| Communication Layers", STD 3, RFC 1122, | Communication Layers", STD 3, RFC 1122, | |||
| skipping to change at page 29, line 10 ¶ | skipping to change at page 29, line 17 ¶ | |||
| Bernardos, "RAW use cases", Work in Progress, Internet- | Bernardos, "RAW use cases", Work in Progress, Internet- | |||
| Draft, draft-ietf-raw-use-cases-03, 20 October 2021, | Draft, draft-ietf-raw-use-cases-03, 20 October 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- | <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- | |||
| cases-03>. | cases-03>. | |||
| [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)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | ||||
| <https://www.rfc-editor.org/info/rfc5880>. | ||||
| [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, | [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, | |||
| D., and S. Mansfield, "Guidelines for the Use of the "OAM" | D., and S. Mansfield, "Guidelines for the Use of the "OAM" | |||
| Acronym in the IETF", BCP 161, RFC 6291, | Acronym in the IETF", BCP 161, RFC 6291, | |||
| DOI 10.17487/RFC6291, June 2011, | DOI 10.17487/RFC6291, June 2011, | |||
| <https://www.rfc-editor.org/info/rfc6291>. | <https://www.rfc-editor.org/info/rfc6291>. | |||
| [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | |||
| Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | |||
| May 2016, <https://www.rfc-editor.org/info/rfc7799>. | May 2016, <https://www.rfc-editor.org/info/rfc7799>. | |||
| skipping to change at page 29, line 42 ¶ | skipping to change at page 29, line 45 ¶ | |||
| [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem | [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem | |||
| Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, | Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, | |||
| <https://www.rfc-editor.org/info/rfc8557>. | <https://www.rfc-editor.org/info/rfc8557>. | |||
| [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, | [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, | |||
| "Deterministic Networking Architecture", RFC 8655, | "Deterministic Networking Architecture", RFC 8655, | |||
| DOI 10.17487/RFC8655, October 2019, | DOI 10.17487/RFC8655, October 2019, | |||
| <https://www.rfc-editor.org/info/rfc8655>. | <https://www.rfc-editor.org/info/rfc8655>. | |||
| [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. | ||||
| Bryant, "Deterministic Networking (DetNet) Data Plane: | ||||
| IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, | ||||
| <https://www.rfc-editor.org/info/rfc8939>. | ||||
| [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to | [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to | |||
| Deployment (A Bestiary of Roads Not Taken)", RFC 9049, | Deployment (A Bestiary of Roads Not Taken)", RFC 9049, | |||
| DOI 10.17487/RFC9049, June 2021, | DOI 10.17487/RFC9049, June 2021, | |||
| <https://www.rfc-editor.org/info/rfc9049>. | <https://www.rfc-editor.org/info/rfc9049>. | |||
| 13.2. Informative References | 9.2. Informative References | |||
| [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
| DOI 10.17487/RFC0791, September 1981, | DOI 10.17487/RFC0791, September 1981, | |||
| <https://www.rfc-editor.org/info/rfc791>. | <https://www.rfc-editor.org/info/rfc791>. | |||
| [TE] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. | [TE] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. | |||
| Xiao, "Overview and Principles of Internet Traffic | Xiao, "Overview and Principles of Internet Traffic | |||
| Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, | Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, | |||
| <https://www.rfc-editor.org/info/rfc3272>. | <https://www.rfc-editor.org/info/rfc3272>. | |||
| skipping to change at page 30, line 36 ¶ | skipping to change at page 30, line 47 ¶ | |||
| So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", | So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", | |||
| RFC 7490, DOI 10.17487/RFC7490, April 2015, | RFC 7490, DOI 10.17487/RFC7490, April 2015, | |||
| <https://www.rfc-editor.org/info/rfc7490>. | <https://www.rfc-editor.org/info/rfc7490>. | |||
| [DetNet-DP] | [DetNet-DP] | |||
| Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. | Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. | |||
| Bryant, "Deterministic Networking (DetNet) Data Plane | Bryant, "Deterministic Networking (DetNet) Data Plane | |||
| Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, | Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, | |||
| <https://www.rfc-editor.org/info/rfc8938>. | <https://www.rfc-editor.org/info/rfc8938>. | |||
| [DLEP] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. | ||||
| Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, | ||||
| DOI 10.17487/RFC8175, June 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8175>. | ||||
| [I-D.irtf-panrg-path-properties] | [I-D.irtf-panrg-path-properties] | |||
| Enghardt, T. and C. Kraehenbuehl, "A Vocabulary of Path | Enghardt, T. and C. Kraehenbuehl, "A Vocabulary of Path | |||
| Properties", Work in Progress, Internet-Draft, draft-irtf- | Properties", Work in Progress, Internet-Draft, draft-irtf- | |||
| panrg-path-properties-04, 25 October 2021, | panrg-path-properties-04, 25 October 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-irtf-panrg- | <https://datatracker.ietf.org/doc/html/draft-irtf-panrg- | |||
| path-properties-04>. | path-properties-04>. | |||
| [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-10, 18 November 2021, | thubert-6man-ipv6-over-wireless-11, 15 December 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-thubert-6man- | <https://datatracker.ietf.org/doc/html/draft-thubert-6man- | |||
| ipv6-over-wireless-10>. | ipv6-over-wireless-11>. | |||
| [DetNet-OAM] | [DetNet-OAM] | |||
| Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos, | Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos, | |||
| C. J., Varga, B., and J. Farkas, "Framework of Operations, | C. J., Varga, B., and J. Farkas, "Framework of Operations, | |||
| Administration and Maintenance (OAM) for Deterministic | Administration and Maintenance (OAM) for Deterministic | |||
| Networking (DetNet)", Work in Progress, Internet-Draft, | Networking (DetNet)", Work in Progress, Internet-Draft, | |||
| draft-ietf-detnet-oam-framework-05, 14 October 2021, | draft-ietf-detnet-oam-framework-05, 14 October 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-detnet- | <https://datatracker.ietf.org/doc/html/draft-ietf-detnet- | |||
| oam-framework-05>. | oam-framework-05>. | |||
| End of changes. 63 change blocks. | ||||
| 114 lines changed or deleted | 146 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/ | ||||