| rfc9912v1.txt | rfc9912.txt | |||
|---|---|---|---|---|
| Internet Engineering Task Force (IETF) P. Thubert, Ed. | Internet Engineering Task Force (IETF) P. Thubert, Ed. | |||
| Request for Comments: 9912 February 2026 | Request for Comments: 9912 Independent | |||
| Category: Informational | Category: Informational February 2026 | |||
| ISSN: 2070-1721 | ISSN: 2070-1721 | |||
| Reliable and Available Wireless (RAW) Architecture | Reliable and Available Wireless (RAW) Architecture | |||
| Abstract | Abstract | |||
| Reliable and Available Wireless (RAW) extends the reliability and | Reliable and Available Wireless (RAW) extends the reliability and | |||
| availability of Deterministic Networking (DetNet) to networks | availability of Deterministic Networking (DetNet) to networks | |||
| composed of any combination of wired and wireless segments. The RAW | composed of any combination of wired and wireless segments. The RAW | |||
| architecture leverages and extends RFC 8655 ("Deterministic | architecture leverages and extends RFC 8655 ("Deterministic | |||
| skipping to change at line 210 ¶ | skipping to change at line 210 ¶ | |||
| RAW is agnostic to the lower layer, though the capability to control | RAW is agnostic to the lower layer, though the capability to control | |||
| latency is assumed to ensure the DetNet services that RAW extends. | latency is assumed to ensure the DetNet services that RAW extends. | |||
| How the lower layers are operated to do so (and whether a radio | How the lower layers are operated to do so (and whether a radio | |||
| network is single hop or meshed, for example) are opaque to the IP | network is single hop or meshed, for example) are opaque to the IP | |||
| layer and not part of the RAW abstraction. Nevertheless, cross-layer | layer and not part of the RAW abstraction. Nevertheless, cross-layer | |||
| optimizations may take place to ensure proper link awareness (such as | optimizations may take place to ensure proper link awareness (such as | |||
| link quality) and packet handling (such as scheduling). | link quality) and packet handling (such as scheduling). | |||
| The RAW architecture extends the DetNet Network Plane to accommodate | The RAW architecture extends the DetNet Network Plane to accommodate | |||
| one or multiple hops of homogeneous or heterogeneous wired and | one or multiple hops of homogeneous or heterogeneous wired and | |||
| wireless technologies. RAW adds reactivity to the DetNet Forwarding | wireless technologies. RAW adds reactivity to the DetNet forwarding | |||
| sub-layer to compensate the dynamics for the radio links in terms of | sub-layer to compensate the dynamics for the radio links in terms of | |||
| lossiness and bandwidth. This may apply, for instance, to mesh | lossiness and bandwidth. This may apply, for instance, to mesh | |||
| networks as illustrated in Figure 4 or diverse radio access networks | networks as illustrated in Figure 4 or diverse radio access networks | |||
| as illustrated in Figure 10. | as illustrated in Figure 10. | |||
| As opposed to wired links, the availability and performance of an | As opposed to wired links, the availability and performance of an | |||
| individual wireless link cannot be trusted over the long term; it | individual wireless link cannot be trusted over the long term; it | |||
| varies with transient service discontinuity, and any path that | varies with transient service discontinuity, and any path that | |||
| includes wireless hops is bound to face short periods of high loss. | includes wireless hops is bound to face short periods of high loss. | |||
| On the other hand, being broadcast in nature, the wireless medium | On the other hand, being broadcast in nature, the wireless medium | |||
| skipping to change at line 254 ¶ | skipping to change at line 254 ¶ | |||
| 1. a new and more dynamic sense of link metrics, with new | 1. a new and more dynamic sense of link metrics, with new | |||
| protocols such as the Dynamic Link Exchange Protocol (DLEP) | protocols such as the Dynamic Link Exchange Protocol (DLEP) | |||
| and Layer 2 (L2) triggers to keep Layer 3 (L3) up to date with | and Layer 2 (L2) triggers to keep Layer 3 (L3) up to date with | |||
| the link quality and availability, and | the link quality and availability, and | |||
| 2. an approach to multipath routing, where multiple link metrics | 2. an approach to multipath routing, where multiple link metrics | |||
| are considered since simple shortest-path cost loses its | are considered since simple shortest-path cost loses its | |||
| meaning with the instability of the metrics. | meaning with the instability of the metrics. | |||
| Redundant transmissions: Though feasible on any technology, | Redundant transmissions: Though feasible on any technology, | |||
| proactive (forward) and reactive (ack-based) error correction are | proactive (forward) and reactive (acknowledgment-based) error | |||
| typical for wireless media. Bounded latency can still be obtained | correction is typical for wireless media. Bounded latency can | |||
| on a wireless link while operating those technologies, provided | still be obtained on a wireless link while operating those | |||
| that link latency used in path selection allows for the extra | technologies, provided that link latency used in path selection | |||
| transmission or the introduced delay is compensated along the | allows for the extra transmission or the introduced delay is | |||
| path. In the case of coded fragments and retries, it makes sense | compensated along the path. In the case of coded fragments and | |||
| to vary all the possible physical properties of the transmission | retries, it makes sense to vary all the possible physical | |||
| to reduce the chances that the same effect causes the loss of both | properties of the transmission to reduce the chances that the same | |||
| original and redundant transmissions. | effect causes the loss of both original and redundant | |||
| transmissions. | ||||
| Relay coordination and constructive interference: Though it can be | Relay coordination and constructive interference: Though it can be | |||
| difficult to achieve at high speed, a fine time synchronization | difficult to achieve at high speed, a fine time synchronization | |||
| and a precise sense of phase allows the energy from multiple | and a precise sense of phase allows the energy from multiple | |||
| coordinated senders to add up at the receiver and actually improve | coordinated senders to add up at the receiver and actually improve | |||
| the signal quality, compensating for either distance or physical | the signal quality, compensating for either distance or physical | |||
| objects in the Fresnel zone that would reduce the link budget. | objects in the Fresnel zone that would reduce the link budget. | |||
| From a DetNet perspective, this may translate taking into account | From a DetNet perspective, this may translate to taking into | |||
| how transmission from one node may interfere with the transmission | account how transmission from one node may interfere with the | |||
| of another node attached to the same wireless sub-layer network. | transmission of another node attached to the same wireless sub- | |||
| layer network. | ||||
| RAW and DetNet enable application flows that require a special | RAW and DetNet enable application flows that require a special | |||
| treatment along paths that can provide that treatment. This may be | treatment along paths that can provide that treatment. This may be | |||
| seen as a form of Path Aware networking and may be subject to | seen as a form of Path Aware networking and may be subject to | |||
| impediments documented in [RFC9049]. | impediments documented in [RFC9049]. | |||
| The mechanism used to establish a path is not unique to, or | The mechanism used to establish a path is not unique to, or | |||
| necessarily impacted by, RAW. It is expected to be the product of | necessarily impacted by, RAW. The mechanism is expected to be the | |||
| the DetNet Controller Plane [DetNet-PLANE]; it may use a Path | product of the DetNet Controller Plane [DetNet-PLANE]; it may use a | |||
| Computation Element (PCE) [RFC4655] or the DetNet YANG data model | Path Computation Element (PCE) [RFC4655] or the DetNet YANG data | |||
| [RFC9633], or it may be computed in a distributed fashion ala the | model [RFC9633], or it may be computed in a distributed fashion as | |||
| Resource ReSerVation Protocol (RSVP) [RFC2205]. Either way, the | per the Resource ReSerVation Protocol (RSVP) [RFC2205]. Either way, | |||
| assumption is that it is slow relative to local forwarding operations | the assumption is that it is slow relative to local forwarding | |||
| along the path. To react fast enough to transient changes in the | operations along the path. To react fast enough to transient changes | |||
| radio transmissions, RAW leverages DetNet Network Plane enhancements | in the radio transmissions, RAW leverages DetNet Network Plane | |||
| to optimize the use of the paths and match the quality of the | enhancements to optimize the use of the paths and match the quality | |||
| transmissions over time. | of the transmissions over time. | |||
| 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; thus, in the wireless case, it makes sense | the radio conditions vary; thus, in the wireless case, it makes sense | |||
| to provide redundant forwarding solutions along alternate paths (see | to provide redundant forwarding solutions along alternate paths (see | |||
| Section 3.3) and to leave it to the Network Plane to select which of | Section 3.3) and to leave it to the Network Plane to select which of | |||
| those forwarding solutions are to be used for a given packet based on | those forwarding solutions are to be used for a given packet based on | |||
| the current conditions. The RAW Network Plane operations happen | the current conditions. The RAW Network Plane operations happen | |||
| within the scope of a recovery graph (see Section 3.3.2) that is pre- | within the scope of a recovery graph (see Section 3.3.2) that is pre- | |||
| established and installed by means outside of the scope of RAW. A | established and installed by means outside of the scope of RAW. A | |||
| skipping to change at line 320 ¶ | skipping to change at line 322 ¶ | |||
| entirety of the flows or a portion of them, the RAW Network Plane | entirety of the flows or a portion of them, the RAW Network Plane | |||
| operations may affect the metrics used in their rerouting decisions, | operations may affect the metrics used in their rerouting decisions, | |||
| which could potentially lead to oscillations; such effects must be | which could potentially lead to oscillations; such effects must be | |||
| avoided or dampened. | avoided or dampened. | |||
| 3. Terminology | 3. Terminology | |||
| RAW reuses terminology defined for DetNet in "Deterministic | RAW reuses terminology defined for DetNet in "Deterministic | |||
| Networking Architecture" [DetNet-ARCHI], e.g., "PREOF" to stand for | Networking Architecture" [DetNet-ARCHI], e.g., "PREOF" to stand for | |||
| "Packet Replication, Elimination, and Ordering Functions". RAW | "Packet Replication, Elimination, and Ordering Functions". RAW | |||
| inherits and augments the IETF art of protection as seen in DetNet | inherits and augments the IETF art of path protection as seen in | |||
| and Traffic Engineering. | DetNet and Traffic Engineering. | |||
| RAW also reuses terminology defined for Operations, Administration, | RAW also reuses terminology defined for Operations, Administration, | |||
| and Maintenance (OAM) protocols in Section 1.1 of "Framework of | and Maintenance (OAM) protocols in Section 1.1 of "Framework of | |||
| Operations, Administration, and Maintenance (OAM) for Deterministic | Operations, Administration, and Maintenance (OAM) for Deterministic | |||
| Networking (DetNet)" [DetNet-OAM] and in "Active and Passive Metrics | Networking (DetNet)" [DetNet-OAM] and in "Active and Passive Metrics | |||
| and Methods (with Hybrid Types In-Between)" [RFC7799]. | and Methods (with Hybrid Types In-Between)" [RFC7799]. | |||
| RAW also reuses terminology defined for MPLS in [RFC4427], such as | RAW also reuses terminology defined for MPLS in [RFC4427], such as | |||
| the term "recovery" to cover both protection and restoration for a | the term "recovery" to cover both protection and restoration for a | |||
| number of recovery types. That document defines a number of | number of recovery types. That document defines a number of | |||
| concepts, such as the recovery domain, that are used in RAW | concepts, such as the recovery domain, that are used in RAW | |||
| mechanisms and defines the new term "recovery graph". A recovery | mechanisms and defines the new term "recovery graph". A recovery | |||
| graph associates a topological graph with usage metadata that | graph associates a topological graph with usage metadata that | |||
| represents how the paths are built and used within the recovery | represents how the paths are built and used within the recovery | |||
| graph. The recovery graph provides excess bandwidth for the intended | graph. The recovery graph provides excess bandwidth for the intended | |||
| traffic over alternate potential paths, and the use of that bandwidth | traffic over alternate potential paths, and the use of that bandwidth | |||
| is optimized dynamically. | is optimized dynamically. | |||
| The concept of a recovery graph is agnostic to the underlying | ||||
| technology and applies, but is not limited to, any full or partial | ||||
| wireless mesh. RAW specifies strict and loose recovery graphs | ||||
| depending on whether the path is fully controlled by RAW or traverses | ||||
| an opaque network where RAW cannot observe and control the individual | ||||
| hops. | ||||
| RAW also reuses terminology defined for RSVP-TE in [RFC4090], such as | RAW also reuses terminology defined for RSVP-TE in [RFC4090], such as | |||
| the "Point of Local Repair (PLR)". The concept of a backup path is | the "Point of Local Repair (PLR)". The concept of a backup path is | |||
| generalized with protection path, which is the term mostly found in | generalized with protection path, which is the term mostly found in | |||
| recent standards and used in this document. | recent standards and used in this document. | |||
| RAW also reuses terminology defined for 6TiSCH in [6TiSCH-ARCHI] and | RAW also reuses terminology defined for 6TiSCH in [6TiSCH-ARCHI] and | |||
| equates the 6TiSCH concept of a Track with that of a recovery graph. | equates the 6TiSCH concept of a Track with that of a recovery graph. | |||
| The concept of a recovery graph is agnostic to the underlying | ||||
| technology and applies, but is not limited to, any full or partial | ||||
| wireless mesh. RAW specifies strict and loose recovery graphs | ||||
| depending on whether the path is fully controlled by RAW or traverses | ||||
| an opaque network where RAW cannot observe and control the individual | ||||
| hops. | ||||
| 3.1. Abbreviations | 3.1. Abbreviations | |||
| RAW uses the following abbreviations. | RAW uses the following abbreviations. | |||
| 3.1.1. ARQ | 3.1.1. ARQ | |||
| Automatic Repeat Request. A well-known mechanism that enables an | Automatic Repeat Request. A well-known mechanism that enables an | |||
| acknowledged transmission with retries to mitigate errors and loss. | acknowledged transmission with retries to mitigate errors and loss. | |||
| ARQ may be implemented at various layers in a network. ARQ is | ARQ may be implemented at various layers in a network. ARQ is | |||
| typically implemented per hop (not end to end) at Layer 2 in wireless | typically implemented per hop (not end to end) at Layer 2 in wireless | |||
| skipping to change at line 429 ¶ | skipping to change at line 431 ¶ | |||
| The RF power can come from any source: other transmitters using the | The RF power can come from any source: other transmitters using the | |||
| same technology, other radio technology using the same band, or | same technology, other radio technology using the same band, or | |||
| background radiation. For a single hop, RSSI may be used for LQI. | background radiation. For a single hop, RSSI may be used for LQI. | |||
| 3.1.9. LQI | 3.1.9. LQI | |||
| Link Quality Indicator. An indication of the quality of the data | Link Quality Indicator. An indication of the quality of the data | |||
| packets received by the receiver. It is typically derived from | packets received by the receiver. It is typically derived from | |||
| packet error statistics, with the exact method depending on the | packet error statistics, with the exact method depending on the | |||
| network stack being used. LQI values may be exposed to the | network stack being used. LQI values may be exposed to the | |||
| controller plane for each individual hop or cumulated along segments. | Controller Plane for each individual hop or cumulated along segments. | |||
| Outgoing LQI values can be calculated from coherent (demodulated) | Outgoing LQI values can be calculated from coherent (demodulated) | |||
| PER, RSSI, and incoming LQI values. | PER, RSSI, and incoming LQI values. | |||
| 3.1.10. OAM | 3.1.10. OAM | |||
| Operations, Administration, and Maintenance. Covers the processes, | Operations, Administration, and Maintenance. Covers the processes, | |||
| activities, tools, and standards involved with operating, | activities, tools, and standards involved with operating, | |||
| administering, managing, and maintaining any system. This document | administering, managing, and maintaining any system. This document | |||
| uses the term in conformance with "Guidelines for the Use of the | uses the term in conformance with "Guidelines for the Use of the | |||
| 'OAM' Acronym in the IETF" [RFC6291], and the system observed by the | 'OAM' Acronym in the IETF" [RFC6291], and the system observed by the | |||
| RAW OAM is the recovery graph. | RAW OAM is the recovery graph. | |||
| 3.1.11. OODA | 3.1.11. OODA | |||
| Observe, Orient, Decide, Act. A generic formalism to represent the | Observe, Orient, Decide, Act. A generic formalism to represent the | |||
| operational steps in a Control Loop. In the context of RAW, OODA is | operational steps in a control loop. In the context of RAW, OODA is | |||
| applied to network control and convergence; see Section 6.2 for more. | applied to network control and convergence; see Section 6.2 for more. | |||
| 3.1.12. SNR | 3.1.12. SNR | |||
| Signal-to-Noise Ratio. Also known as "S/N Ratio". A measure used in | Signal-to-Noise Ratio. Also known as "S/N Ratio". A measure used in | |||
| science and engineering that compares the level of a desired signal | science and engineering that compares the level of a desired signal | |||
| to the level of background noise. SNR is defined as the ratio of | to the level of background noise. SNR is defined as the ratio of | |||
| signal power to noise power, often expressed in decibels. | signal power to noise power, often expressed in decibels. | |||
| 3.2. Link and Direction | 3.2. Link and Direction | |||
| This document uses the following terms relating to links and | ||||
| direction in the context of RAW. | ||||
| 3.2.1. Flapping | 3.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 a duration of a subsecond to seconds. | typically a duration of a subsecond to seconds. | |||
| 3.2.2. Uplink | 3.2.2. Uplink | |||
| An uplink is the connection from end devices to data communication | An uplink is the connection from end devices to data communication | |||
| equipment. In the context of wireless, uplink refers to the | equipment. In the context of wireless, uplink refers to the | |||
| skipping to change at line 487 ¶ | skipping to change at line 492 ¶ | |||
| Downstream refers to the following the direction of the flow data | Downstream refers to the following the direction of the flow data | |||
| path along a recovery graph. | path along a recovery graph. | |||
| 3.2.5. Upstream | 3.2.5. Upstream | |||
| Upstream refers to going against the direction of the flow data path | Upstream refers to going against the direction of the flow data path | |||
| along a recovery graph. | along a recovery graph. | |||
| 3.3. Path and Recovery Graphs | 3.3. Path and Recovery Graphs | |||
| This document uses the following terms relating to paths and recovery | ||||
| graphs in the context of RAW. | ||||
| 3.3.1. Path | 3.3.1. Path | |||
| Section 1.3.3 of [INT-ARCHI] provides a definition of Path: | Section 1.3.3 of [INT-ARCHI] provides a definition of path: | |||
| | 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 [RFC9473] points to a longer, more modern definition of | Section 2 of [RFC9473] points to a longer, more modern definition of | |||
| path, which begins as follows: | path, which begins as follows: | |||
| skipping to change at line 548 ¶ | skipping to change at line 556 ¶ | |||
| covers the overall topology where the possible DetNet paths are all | covers the overall topology where the possible DetNet paths are all | |||
| contained. As such, the recovery graph coalesces all the possible | contained. As such, the recovery graph coalesces all the possible | |||
| paths a flow may experience, each with its own statistical | paths a flow may experience, each with its own statistical | |||
| probability to be used. | probability to be used. | |||
| 3.3.2. Recovery Graph | 3.3.2. Recovery Graph | |||
| A recovery graph is a networking graph that can be followed to | A recovery graph is a networking graph that can be followed to | |||
| transport packets with equivalent treatment and is associated with | transport packets with equivalent treatment and is associated with | |||
| usage metadata. In contrast to the definition of a path above, a | usage metadata. In contrast to the definition of a path above, a | |||
| recovery graph represents not an actual but a potential, is not | recovery graph represents a potential path, not an actual one. Also, | |||
| necessarily a linear sequence like a simple path, and is not | a recovery graph is not necessarily a linear sequence like a simple | |||
| necessarily fully traversed (flooded) by all packets of a flow like a | path and is not necessarily fully traversed (flooded) by all packets | |||
| DetNet Path. Still, and as a simplification, the casual reader may | of a flow like a DetNet path. Still, and as a simplification, the | |||
| consider that a recovery graph is very much like a DetNet path, | casual reader may consider that a recovery graph is very much like a | |||
| aggregating multiple paths that may overlap or fork and then rejoin, | DetNet path, aggregating multiple paths that may overlap or fork and | |||
| for instance, to enable a protection service by the PREOF operations. | then rejoin, for instance, to enable a protection service by the | |||
| PREOF operations. | ||||
| _________ | _________ | |||
| | | | | | | |||
| | IoT G/W | | | IoT G/W | | |||
| |_________| | |_________| | |||
| EGRESS <<=== Elimination at Egress | EGRESS <<=== Elimination at Egress | |||
| | | | | | | |||
| ---+--------+--+--------+-------- | ---+--------+--+--------+-------- | |||
| | Backbone | | | Backbone | | |||
| __|__ __|__ | __|__ __|__ | |||
| | | Backbone | | Backbone | | | Backbone | | Backbone | |||
| |__ __| Router |__ __| Router | |__ __| Router |__ __| Router | |||
| | # | | | # | | |||
| # \ # / <-- protection path | # \ # / <-- protection path | |||
| # # #-------# | # # #-------# | |||
| \ # / # ( Low-power ) | \ # / # ( Low-power ) | |||
| # # \ / # ( Lossy Network) | # # \ / # ( Lossy Network) | |||
| \ / | \ / | |||
| # INGRESS <<=== Replication at recovery graph Ingress | # INGRESS <<=== Replication at recovery graph ingress | |||
| | | | | |||
| # <-- source device | # <-- source device | |||
| #: Low-power device | #: Low-power device | |||
| Figure 1: Example IoT Recovery Graph to an IoT Gateway with 1+1 | Figure 1: Example IoT Recovery Graph to an IoT Gateway with 1+1 | |||
| Redundancy | Redundancy | |||
| Refining further, a recovery graph is defined as the coalescence of | Refining further, a recovery graph is defined as the coalescence of | |||
| the collection of all the feasible DetNet Paths that a packet for | all the feasible DetNet paths that a packet with an assigned flow may | |||
| which a flow is assigned to the recovery graph may be forwarded | be forwarded along. A packet that is assigned to the recovery graph | |||
| along. A packet that is assigned to the recovery graph experiences | experiences one of the feasible DetNet paths based on the current | |||
| one of the feasible DetNet Paths based on the current selection by | selection by the PLR at the time the packet traverses the network. | |||
| the PLR at the time the packet traverses the network. | ||||
| Refining even further, the feasible DetNet Paths within the recovery | Refining even further, the feasible DetNet paths within the recovery | |||
| graph may or may not be computed in advance; instead, they may be | graph may or may not be computed in advance; instead, they may be | |||
| decided upon the detection of a change from a clean slate. | decided upon the detection of a change from a clean slate. | |||
| Furthermore, the PLR decision may be distributed, which yields a | Furthermore, the PLR decision may be distributed, which yields a | |||
| large combination of possible and dependent decisions, with no node | large combination of possible and dependent decisions, with no node | |||
| in the network capable of reporting which is the current DetNet Path | in the network capable of reporting which is the current DetNet path | |||
| within the recovery graph. | within the recovery graph. | |||
| In DetNet [DetNet-ARCHI] terms, a recovery graph has the following | In DetNet [DetNet-ARCHI] terms, a recovery graph has the following | |||
| properties: | properties: | |||
| * A recovery graph is a Layer 3 abstraction built upon IP links | * A recovery graph is a Layer 3 abstraction built upon IP links | |||
| between routers. A router may form multiple IP links over a | between routers. A router may form multiple IP links over a | |||
| single radio interface. | single radio interface. | |||
| * A recovery graph has one Ingress and one Egress node, which | * A recovery graph has one ingress and one egress node, which | |||
| operate as DetNet Edge nodes. | operate as DetNet Edge nodes. | |||
| * The graph of a recovery graph is reversible, meaning that packets | * A recovery graph is reversible, meaning that packets can be routed | |||
| can be routed against the flow of data packets, e.g., to carry OAM | against the flow of data packets, e.g., to carry OAM measurements | |||
| measurements or control messages back to the Ingress. | or control messages back to the ingress. | |||
| * The vertices of that graph are DetNet Relay Nodes that operate at | * The vertices of a recovery graph are DetNet Relay nodes that | |||
| the DetNet Service sub-layer and provide the PREOF functions. | operate at the DetNet Service sub-layer and provide the PREOF | |||
| functions. | ||||
| * The topological edges of the graph are strict sequences of DetNet | * The topological edges of a recovery graph are strict sequences of | |||
| Transit nodes that operate at the DetNet Forwarding sub-layer. | DetNet Transit nodes that operate at the DetNet forwarding sub- | |||
| layer. | ||||
| Figure 2 illustrates the generic concept of a recovery graph, between | Figure 2 illustrates the generic concept of a recovery graph, between | |||
| an Ingress Node and an Egress Node. The recovery graph is composed | an ingress node and an egress node. The recovery graph is composed | |||
| of forward protection paths, forward Segments, and crossing Segments | of forward protection paths, forward segments, and crossing segments | |||
| (see the definitions of those terms in the next sections). The | (see the definitions of those terms in the next sections). The | |||
| recovery graph contains at least two protection paths: a main path | recovery graph contains at least two protection paths: a main path | |||
| and a backup path. | and a backup path. | |||
| ------------------- forward direction ----------------------> | ------------------- forward direction ----------------------> | |||
| a ==> b ==> C -=- F ==> G ==> h T1 | a ==> b ==> C -=- F ==> G ==> h T1 | |||
| / \ / | \ / | / \ / | \ / | |||
| I o n E -=- T2 | I o n E -=- T2 | |||
| \ / \ | / \ | \ / \ | / \ | |||
| p ==> q ==> R -=- T ==> U ==> v T3 | p ==> q ==> R -=- T ==> U ==> v T3 | |||
| I: Ingress | I: Ingress | |||
| E: Egress | E: Egress | |||
| T1, T2, T3: external targets | T1, T2, T3: external targets | |||
| Uppercase: DetNet Relay Nodes | Uppercase: DetNet Relay nodes | |||
| Lowercase: DetNet Transit nodes | Lowercase: DetNet Transit nodes | |||
| Figure 2: A Recovery Graph and Its Components | Figure 2: A Recovery Graph and Its Components | |||
| Of note: | Of note: | |||
| I ==> a ==> b ==> C: A forward Segment to targets F and o | I ==> a ==> b ==> C: A forward segment to targets F and o | |||
| C ==> o ==> T: A forward Segment to target T (and/or U) | C ==> o ==> T: A forward segment to target T (and/or U) | |||
| G | n | U: A crossing Segment to targets G or U | G | n | U: A crossing segment to targets G or U | |||
| I -> F -> E: A forward protection path to targets T1, T2, and T3 | I -> F -> E: A forward protection path to targets T1, T2, and T3 | |||
| I, a, b, C, F, G, h, E: A path to T1, T2, and/or T3 | I, a, b, C, F, G, h, E: A path to T1, T2, and/or T3 | |||
| I, p, q, R, o, F, G, h, E: A segment-crossing protection path | I, p, q, R, o, F, G, h, E: A segment-crossing protection path | |||
| 3.3.3. Forward and Crossing | 3.3.3. Forward and Crossing | |||
| Forward refers to progress towards the Egress of the recovery graph. | Forward refers to progress towards the egress of the recovery graph. | |||
| Forward links are directional, and packets that are forwarded along | Forward links are directional, and packets that are forwarded along | |||
| the recovery graph can only be transmitted along the link direction. | the recovery graph can only be transmitted along the link direction. | |||
| Crossing links are bidirectional, meaning that they can be used in | Crossing links are bidirectional, meaning that they can be used in | |||
| both directions, though a given packet may use the link in one | both directions, though a given packet may use the link in one | |||
| direction only. A Segment can be forward, in which case it is | direction only. A segment can be forward, in which case it is | |||
| composed of forward links only, or it can be crossing, in which case | composed of forward links only, or it can be crossing, in which case | |||
| it is composed of crossing links only. A protection path is always | it is composed of crossing links only. A protection path is always | |||
| forward, meaning that it is composed of forward links and Segments. | forward, meaning that it is composed of forward links and segments. | |||
| 3.3.4. Protection Path | 3.3.4. Protection Path | |||
| A protection path is an end-to-end forward path between the Ingress | A protection path is an end-to-end forward path between the ingress | |||
| and Egress Nodes of a recovery graph. A protection path in a | and egress nodes of a recovery graph. A protection path in a | |||
| recovery graph is expressed as a strict sequence of DetNet Relay | recovery graph is expressed as a strict sequence of DetNet Relay | |||
| Nodes or as a loose sequence of DetNet Relay Nodes that are joined by | nodes or as a loose sequence of DetNet Relay nodes that are joined by | |||
| Segments in the recovery graph. Background information on the | segments in the recovery graph. Background information on the | |||
| concepts related to protection paths can be found in [RFC4427] and | concepts related to protection paths can be found in [RFC4427] and | |||
| [RFC6378]. | [RFC6378]. | |||
| 3.3.5. Segment | 3.3.5. Segment | |||
| A Segment is a strict sequence of DetNet Transit nodes between two | A segment is a strict sequence of DetNet Transit nodes between two | |||
| DetNet Relay Nodes; a Segment of a recovery graph is composed | DetNet Relay nodes; a segment of a recovery graph is composed | |||
| topologically of two vertices of the recovery graph and one edge of | topologically of two vertices of the recovery graph and one edge of | |||
| the recovery graph between those vertices. | the recovery graph between those vertices. | |||
| 3.4. Deterministic Networking | 3.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 [DetNet-ARCHI] for deterministic networking and | Section 4.1.2 of [DetNet-ARCHI] for deterministic networking and | |||
| deterministic networks. This documents also uses the following | deterministic networks. This document also uses the following terms. | |||
| terms. | ||||
| 3.4.1. The DetNet Planes | 3.4.1. The DetNet Planes | |||
| [DetNet-ARCHI] defines three planes: the Application (User) Plane, | [DetNet-ARCHI] defines three planes: the Application (User) Plane, | |||
| the Controller Plane, and the Network Plane. The DetNet Network | the Controller Plane, and the Network Plane. The DetNet Network | |||
| Plane is composed of a Data Plane (packet forwarding) and an | Plane is composed of a Data Plane (packet forwarding) and an | |||
| Operational Plane where OAM operations take place. In the Network | Operational Plane where OAM operations take place. In the Network | |||
| Plane, the DetNet Service sub-layer focuses on flow protection (e.g., | Plane, the DetNet Service sub-layer focuses on flow protection (e.g., | |||
| using redundancy) and can be fully operated at Layer 3, while the | using redundancy) and can be fully operated at Layer 3, while the | |||
| DetNet forwarding sub-layer establishes the paths, associates the | DetNet forwarding sub-layer establishes the paths, associates the | |||
| flows to the paths, ensures the availability of the necessary | flows to the paths, ensures the availability of the necessary | |||
| resources, and leverages Layer 2 functionalities for timely delivery | resources, and leverages Layer 2 functionalities for timely delivery | |||
| to the next DetNet system. For more information, see Section 2. | to the next DetNet system. For more information, see Section 2. | |||
| 3.4.2. Flow | 3.4.2. Flow | |||
| A flow is a collection of consecutive IP packets defined by the upper | A flow is a collection of consecutive IP packets defined by the upper | |||
| layers and signaled by the same 5-tuple or 6-tuple (see Section 5.1 | layers and signaled by the same 5-tuple or 6-tuple (see Section 5.1 | |||
| of [RFC8939]). Packets of the same flow must be placed on the same | of [RFC8939]). Packets of the same flow must be placed on the same | |||
| recovery graph to receive an equivalent treatment from Ingress to | recovery graph to receive an equivalent treatment from ingress to | |||
| Egress within the recovery graph. Multiple flows may be transported | egress within the recovery graph. Multiple flows may be transported | |||
| along the same recovery graph. The DetNet Path that is selected for | along the same recovery graph. The DetNet path that is selected for | |||
| the flow may change over time under the control of the PLR. | the flow may change over time under the control of the PLR. | |||
| 3.4.3. Residence Time | 3.4.3. Residence Time | |||
| A residence time (RT) is defined as the time interval between when | A residence time (RT) is defined as the time interval between when | |||
| the reception of a packet starts and the transmission of the packet | the reception of a packet starts and the transmission of the packet | |||
| begins. In the context of RAW, RT is useful for a transit nodes, not | begins. In the context of RAW, RT is useful for a transit nodes, not | |||
| ingress or egress nodes. | ingress or egress nodes. | |||
| 3.4.4. L3 Deterministic Flow Identifier | 3.4.4. L3 Deterministic Flow Identifier | |||
| The classic IP 5-tuple that identifies a flow comprises the source | The classic IP 5-tuple that identifies a flow comprises the source | |||
| IP, destination IP, source port, destination port, and the Upper- | IP, destination IP, source port, destination port, and the Upper- | |||
| Layer Protocol (ULP). DetNet uses a 6-tuple where the extra field is | Layer Protocol (ULP). DetNet uses a 6-tuple where the extra field is | |||
| the Differentiated Services Code Point (DSCP) field in the packet | the Differentiated Services Code Point (DSCP) field in the packet | |||
| (see Section 3.3 of [DetNet-DP]). The IPv6 flow label is not used | (see Section 3.3 of [DetNet-DP]). The IPv6 flow label is not used | |||
| for that purpose. | for that purpose. | |||
| 3.4.5. Time-Sensitive Networking | 3.4.5. Time-Sensitive Networking | |||
| Time-Sensitive Networking (TSN) denotes the efforts at IEEE 802 for | Time-Sensitive Networking (TSN) denotes the IEEE efforts regarding | |||
| deterministic networking, originally for use on Ethernet. Wireless | deterministic networking, originally for use on Ethernet. See [TSN]. | |||
| TSN (WTSN) denotes extensions of the TSN work on wireless media such | Wireless TSN (WTSN) denotes extensions of the TSN work on wireless | |||
| as the selected RAW technologies [RAW-TECHNOS]. | media, such as the RAW technologies described in [RAW-TECHNOS]. | |||
| 3.4.6. Lower-Layer API | 3.4.6. Lower-Layer API | |||
| RAW includes the concept of a lower-layer API (LL API) that provides | RAW includes the concept of a lower-layer API (LL API) that provides | |||
| an interface between the lower-layer (e.g., wireless) technology and | an interface between the lower-layer (e.g., wireless) technology and | |||
| the DetNet layers. The LL API is technology dependent as what the | the DetNet layers. The LL API is technology dependent as what the | |||
| lower layers expose towards the DetNet layers may vary. Furthermore, | lower layers expose towards the DetNet layers may vary. Furthermore, | |||
| different RAW technologies are equipped with different reliability | different RAW technologies are equipped with different reliability | |||
| features (e.g., short-range broadcast, Multiple User - Multiple Input | features (e.g., short-range broadcast, Multiple User - Multiple Input | |||
| Multiple Output (MU-MIMO), PHY rate and other Modulation Coding | Multiple Output (MU-MIMO), physical layer (PHY) rate and other | |||
| Scheme (MCS) adaptation, coding and retransmissions methods, and | Modulation Coding Scheme (MCS) adaptation, coding and retransmissions | |||
| constructive interference and overhearing; see [RAW-TECHNOS] for more | methods, and constructive interference and overhearing; see | |||
| details). The LL API enables interactions between the reliability | [RAW-TECHNOS] for more details). The LL API enables interactions | |||
| functions provided by the lower layer and the reliability functions | between the reliability functions provided by the lower layer and the | |||
| provided by DetNet. That is, the LL API makes cross-layer | reliability functions provided by DetNet. That is, the LL API makes | |||
| optimization possible for the reliability functions of different | cross-layer optimization possible for the reliability functions of | |||
| layers depending on the actual exposure provided via the LL API by | different layers depending on the actual exposure provided via the LL | |||
| the given RAW technology. The Dynamic Link Exchange Protocol (DLEP) | API by the given RAW technology. The Dynamic Link Exchange Protocol | |||
| [DLEP] is an example of a protocol that can be used to implement the | (DLEP) [DLEP] is an example of a protocol that can be used to | |||
| LL API. | implement the LL API. | |||
| 3.5. Reliability and Availability | 3.5. Reliability and Availability | |||
| This document uses the following terms relating to reliability and | This document uses the following terms relating to reliability and | |||
| availability in the context of the RAW work. | availability in the context of the RAW work. | |||
| 3.5.1. Service Level Agreement | 3.5.1. Service Level Agreement | |||
| In the context of RAW, a Service Level Agreement (SLA) is a contract | In the context of RAW, a Service Level Agreement (SLA) is a contract | |||
| between a provider (the network) and a client, the application flow, | between a provider (the network) and a client (the application flow) | |||
| defining measurable metrics such as latency boundaries, consecutive | that defines measurable metrics such as latency boundaries, | |||
| losses, and Packet Delivery Ratio (PDR). | consecutive losses, and Packet Delivery Ratio (PDR). | |||
| 3.5.2. Service Level Objective | 3.5.2. Service Level Objective | |||
| A Service Level Objective (SLO) is one term in the SLA, 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 packet redundancy addresses an SLO of | instance, a dynamic tuning of packet redundancy addresses an SLO of | |||
| consecutive losses in a row by augmenting the chances of delivery of | consecutive losses in a row by augmenting the chances of delivery of | |||
| a packet that follows a loss. | a packet that follows a loss. | |||
| 3.5.3. Service Level Indicator | 3.5.3. Service Level Indicator | |||
| A Service Level Indicator (SLI) measures the compliance of an SLO to | A Service Level Indicator (SLI) measures the compliance of an SLO to | |||
| the terms of the contract. For instance, it can be the statistics of | the terms of the contract. For instance, it can be the statistics of | |||
| individual losses and losses in a row as time series. | individual losses or losses in a row during a certain amount of time. | |||
| 3.5.4. Precision Availability Metrics | 3.5.4. Precision Availability Metrics | |||
| Precision Availability Metrics (PAMs) [RFC9544] aim to capture | Precision Availability Metrics (PAMs) [RFC9544] aim to capture | |||
| service levels for a flow, specifically the degree to which the flow | service levels for a flow, specifically the degree to which the flow | |||
| complies with the SLOs that are in effect. | complies with the SLOs that are in effect. | |||
| 3.5.5. Reliability | 3.5.5. Reliability | |||
| Reliability is a measure of the probability that an item (e.g., | Reliability is a measure of the probability that an item (e.g., | |||
| system or network) will perform its intended function with no failure | system or network) will perform its intended function with no failure | |||
| for a stated period of time (or for a stated number of demands or | for a stated period of time (or for a stated number of demands or | |||
| load) under stated environmental conditions. In other words, | load) under stated environmental conditions. In other words, | |||
| reliability is the probability that an item will be in an uptime | reliability is the probability that an item will be in an uptime | |||
| state (i.e., fully operational or ready to perform) for a stated | state (i.e., fully operational or ready to perform) for a stated | |||
| mission (e.g., to provide an SLA). See more in [NASA1]. | mission (e.g., to provide an SLA). See more in [NASA1]. | |||
| 3.5.6. Availability | 3.5.6. Availability | |||
| Availability is the probability of an item's (e.g., a network's) | Availability is the probability of an item's (e.g., a network's) | |||
| mission readiness (e.g., to provide an SLA), an uptime state with the | mission readiness (e.g., to provide an SLA). Availability is | |||
| likelihood of a recoverable downtime state. Availability is | ||||
| expressed as (uptime)/(uptime+downtime). Note that it is | expressed as (uptime)/(uptime+downtime). Note that it is | |||
| availability that addresses downtime (including time for maintenance, | availability that addresses downtime (including time for maintenance, | |||
| repair, and replacement activities) and not reliability. See more in | repair, and replacement activities) and not reliability. See more in | |||
| [NASA2]. | [NASA2]. | |||
| 4. Reliable and Available Wireless | 4. Reliable and Available Wireless | |||
| 4.1. High Availability Engineering Principles | 4.1. High Availability Engineering Principles | |||
| The reliability criteria of a critical system pervade its elements, | The reliability criteria of a critical system pervade its elements, | |||
| skipping to change at line 953 ¶ | skipping to change at line 961 ¶ | |||
| networks, this is rarely the case. Packet loss cannot be fully | networks, this is rarely the case. Packet loss cannot be fully | |||
| avoided, and the systems are built to resist some loss. This can be | avoided, and the systems are built to resist some loss. This can be | |||
| done by using redundancy with retries (as in HARQ), Packet | done by using redundancy with retries (as in HARQ), Packet | |||
| Replication and Elimination (PRE) FEC, and Network Coding (e.g., | Replication and Elimination (PRE) FEC, and Network Coding (e.g., | |||
| using FEC with Static Context Header Compression (SCHC) [RFC8724] | using FEC with Static Context Header Compression (SCHC) [RFC8724] | |||
| fragments). Also, in a typical control loop, linear interpolation | fragments). Also, in a typical control loop, linear interpolation | |||
| from the previous measurements can be used. | from the previous measurements can be used. | |||
| However, the linear interpolation method cannot resist multiple | However, the linear interpolation method cannot resist multiple | |||
| consecutive losses, and a high MTBF is desired as a guarantee that | consecutive losses, and a high MTBF is desired as a guarantee that | |||
| this does not happen, in other words, that the number of losses in a | the number of losses in a row is bounded. In this case, what is | |||
| row can be bounded. In this case, what is really desired is a | really desired is a Maximum Consecutive Loss (MCL). If the number of | |||
| Maximum Consecutive Loss (MCL). (See also Section 5.9.5 of [DLEP].) | losses in a row passes the MCL, the control loop has to abort, and | |||
| If the number of losses in a row passes the MCL, the control loop has | the system (e.g., the production line) may need to enter an emergency | |||
| to abort, and the system (e.g., the production line) may need to | stop condition. | |||
| enter an emergency stop condition. | ||||
| Engineers that build automated processes may use the network | Engineers that build automated processes may use the network | |||
| reliability expressed in nines as an MTBF as a proxy to indicate an | reliability expressed in nines as the MTBF and as a proxy to indicate | |||
| MCL, e.g., as described in Section 7.4 of "Deterministic Networking | an MCL, e.g., as described in Section 7.4 of "Deterministic | |||
| Use Cases" [RFC8578]. | Networking Use Cases" [RFC8578]. | |||
| 4.3. Wireless Effects Affecting Reliability | 4.3. Wireless Effects Affecting Reliability | |||
| In contrast with wired networks, errors in transmission are the | In contrast with wired networks, errors in transmission are the | |||
| predominant source of packet loss in wireless networks. | predominant source of packet loss in wireless networks. | |||
| The root cause for the loss may be of multiple origins, calling for | The root cause for the loss may be of multiple origins, calling for | |||
| the use of different forms of diversity: | the use of different forms of diversity: | |||
| Multipath fading: A destructive interference by a reflection of the | Multipath fading: A destructive interference by a reflection of the | |||
| skipping to change at line 1022 ¶ | skipping to change at line 1029 ¶ | |||
| removed, or as long as the interferer (e.g., a radar in the ISM band) | removed, or as long as the interferer (e.g., a radar in the ISM band) | |||
| keeps transmitting, a continuous stream of packets are affected. | keeps transmitting, a continuous stream of packets are 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 maximized 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) leveraging diverse PHY technologies (e.g., | |||
| versus spread spectrum), or diverse codes. Using time diversity | narrowband versus spread spectrum or diverse codes). Using time | |||
| defeats short-term interferences; spatial diversity combats very | diversity defeats short-term interferences; spatial diversity combats | |||
| local causes of interference such as multipath fading; narrowband and | very local causes of interference such as multipath fading; | |||
| spread spectrum are relatively innocuous to one another and can be | narrowband and spread spectrum are relatively innocuous to one | |||
| used for diversity in the presence of the other. | another and can be used for diversity in the presence of the other. | |||
| 5. The RAW Conceptual Model | 5. The RAW Conceptual Model | |||
| RAW extends the conceptual model described in Section 4 of | RAW extends the conceptual model described in Section 4 of | |||
| "Deterministic Networking Architecture" [DetNet-ARCHI] with the PLR | "Deterministic Networking Architecture" [DetNet-ARCHI] with the PLR | |||
| at the Service sub-layer, as illustrated in Figure 3. The PLR (see | at the Service sub-layer, as illustrated in Figure 3. The PLR (see | |||
| Section 6.5) is a point of local reaction to provide additional | Section 6.5) provides additional agility against transmission loss. | |||
| agility against transmission loss. For example, the PLR can act | For example, the PLR can act based on indications from the lower | |||
| based on indications from the lower layer or based on OAM. | layer or based on OAM. | |||
| | packets going | ^ packets coming ^ | | packets going | ^ packets coming ^ | |||
| v down the stack v | up the stack | | v down the stack v | up the stack | | |||
| +-----------------------+ +-----------------------+ | +-----------------------+ +-----------------------+ | |||
| | Source | | Destination | | | Source | | Destination | | |||
| +-----------------------+ +-----------------------+ | +-----------------------+ +-----------------------+ | |||
| | Service sub-layer: | | Service sub-layer: | | | Service sub-layer: | | Service sub-layer: | | |||
| | Packet sequencing | | Duplicate elimination | | | Packet sequencing | | Duplicate elimination | | |||
| | Flow replication | | Flow merging | | | Flow replication | | Flow merging | | |||
| | Packet encoding | | Packet decoding | | | Packet encoding | | Packet decoding | | |||
| skipping to change at line 1062 ¶ | skipping to change at line 1069 ¶ | |||
| +-----------------------+ +-----------------------+ | +-----------------------+ +-----------------------+ | |||
| | Lower layers | | Lower layers | | | Lower layers | | Lower layers | | |||
| +-----------------------+ +-----------------------+ | +-----------------------+ +-----------------------+ | |||
| v ^ | v ^ | |||
| \_________________________/ | \_________________________/ | |||
| Figure 3: Extended DetNet Data Plane Protocol Stack | Figure 3: Extended DetNet Data Plane Protocol Stack | |||
| 5.1. The RAW Planes | 5.1. The RAW Planes | |||
| The RAW Nodes are DetNet Relay Nodes that operate in the RAW Network | The RAW nodes are DetNet Relay nodes that operate in the RAW Network | |||
| Plane and are capable of additional diversity mechanisms and | Plane and are capable of additional diversity mechanisms and | |||
| measurement functions related to the radio interface. RAW leverages | measurement functions related to the radio interface. RAW leverages | |||
| an Operational Plane orientation function (that typically operates | an Operational Plane orientation function (that typically operates | |||
| inside the Ingress Edge Nodes) to dynamically adapt the path of the | inside the ingress Edge nodes) to dynamically adapt the path of the | |||
| packets and optimize the resource usage. | packets and optimize the resource usage. | |||
| In the case of centralized routing operations, the RAW Controller | In the case of centralized routing operations, the RAW Controller | |||
| Plane Function (CPF) interacts with RAW Nodes over a Southbound API. | Plane Function (CPF) interacts with RAW nodes over a Southbound API. | |||
| It consumes data and information from the network and generates | It consumes data and information from the network and generates | |||
| knowledge and wisdom to help steer the traffic optimally inside a | knowledge and wisdom to help steer the traffic optimally inside a | |||
| recovery graph. | recovery graph. | |||
| DetNet Routing | DetNet Routing | |||
| CPF CPF CPF CPF | CPF CPF CPF CPF | |||
| Southbound API | Southbound API | |||
| _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- | _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- | |||
| skipping to change at line 1095 ¶ | skipping to change at line 1102 ¶ | |||
| Ingress __/ / \ / \ \____Egress | Ingress __/ / \ / \ \____Egress | |||
| End __ / \ / .- -- . \ ___ End | End __ / \ / .- -- . \ ___ End | |||
| Node \ / \ / .-( ). \ / Node | Node \ / \ / .-( ). \ / Node | |||
| \_ RAW ___ RAW ___(Non-RAW Nodes)__ RAW _/ | \_ RAW ___ RAW ___(Non-RAW Nodes)__ RAW _/ | |||
| Node Node (___.______.____) Node | Node Node (___.______.____) Node | |||
| Figure 4: RAW Nodes (Centralized Routing Case) | Figure 4: RAW Nodes (Centralized Routing Case) | |||
| When a new flow is defined, the routing function uses its current | When a new flow is defined, the routing function uses its current | |||
| knowledge of the network to build a new recovery graph between an | knowledge of the network to build a new recovery graph between an | |||
| Ingress End System and an Egress End System for that flow; it | ingress End System and an egress End System for that flow; it | |||
| indicates to the RAW Nodes where the PREOF and/or radio diversity and | indicates to the RAW nodes where the PREOF and/or radio diversity and | |||
| reliability operations may be actioned in the Network Plane. | reliability operations may be actioned in the Network Plane. | |||
| * The recovery graph may be strict, meaning that the DetNet | * The recovery graph may be strict, meaning that the DetNet | |||
| forwarding sub-layer operations are enforced end to end. | forwarding sub-layer operations are enforced end to end. | |||
| * The recovery graph may be expressed loosely to enable traversing a | * The recovery graph may be expressed loosely to enable traversing a | |||
| non-RAW subnetwork as in Figure 7. In that case, RAW cannot | non-RAW subnetwork as in Figure 7. In that case, RAW cannot | |||
| leverage end-to-end DetNet and cannot provide latency guarantees. | leverage end-to-end DetNet and cannot provide latency guarantees. | |||
| The information that the orientation function reports to the routing | The information that the orientation function reports to the routing | |||
| function includes may be a time-aggregated, e.g., statistical | function may be time aggregated (e.g., statistical), to match the | |||
| fashion, to match the longer-term operation of the routing function. | longer-term operation of the routing function. Example information | |||
| Example information includes link-layer metrics such as link | includes link-layer metrics such as link bandwidth (the medium speed | |||
| bandwidth (the medium speed depends dynamically on the mode of the | depends dynamically on the mode of the PHY layer), number of flows | |||
| PHY layer), number of flows (bandwidth that can be reserved for a | (bandwidth that can be reserved for a flow depends on the number and | |||
| flow depends on the number and size of flows sharing the spectrum), | size of flows sharing the spectrum), and the average and mean squared | |||
| and the average and mean squared deviation of availability and | deviation of availability and reliability metrics (such as PDR) over | |||
| reliability metrics (such as PDR) over long periods of time. It may | long periods of time. It may also report an aggregated Expected | |||
| also report an aggregated Expected Transmission Count (ETX) or a | Transmission Count (ETX) or a variation of it. | |||
| variation of it. | ||||
| Based on those metrics, the routing function installs the recovery | Based on those metrics, the routing function installs the recovery | |||
| graph with enough redundant forwarding solutions to ensure that the | graph with enough redundant forwarding solutions to ensure that the | |||
| Network Plane can reliably deliver the packets within an SLA | Network Plane can reliably deliver the packets within an SLA | |||
| associated with the flows that it transports. The SLA defines end- | associated with the flows that it transports. The SLA defines end- | |||
| to-end reliability and availability requirements, in which | to-end reliability and availability requirements, in which | |||
| reliability may be expressed as a successful delivery in order and | reliability may be expressed as a successful delivery in order and | |||
| within a bounded delay of at least one copy of a packet. | within a bounded delay of at least one copy of a packet. | |||
| Depending on the use case and the SLA, the recovery graph may | Depending on the use case and the SLA, the recovery graph may | |||
| comprise non-RAW segments, either interleaved inside the recovery | comprise non-RAW segments, either interleaved inside the recovery | |||
| graph (e.g., over tunnels) or all the way to the Egress End Node | graph (e.g., over tunnels) or all the way to the egress End node | |||
| (e.g., a server in the local wired domain). RAW observes the lower- | (e.g., a server in the local wired domain). RAW observes the lower- | |||
| layer links between RAW nodes (typically radio links) and the end-to- | layer links between RAW nodes (typically radio links) and the end-to- | |||
| end network-layer operation to decide at all times which of the | end network-layer operation to decide at all times which of the | |||
| diversity schemes is actioned by which RAW Nodes. | diversity schemes is actioned by which RAW nodes. | |||
| Once a recovery graph is established, per-segment and end-to-end | Once a recovery graph is established, per-segment and end-to-end | |||
| reliability and availability statistics are periodically reported to | reliability and availability statistics are periodically reported to | |||
| the routing function to ensure that the SLA can be met; if not, then | the routing function to ensure that the SLA can be met; if not, then | |||
| the recovery graph is recomputed. | the recovery graph is recomputed. | |||
| 5.2. RAW Versus Upper and Lower Layers | 5.2. RAW Versus Upper and Lower Layers | |||
| RAW builds on DetNet-provided features such as scheduling and | RAW builds on DetNet-provided features such as scheduling and | |||
| shaping. In particular, RAW inherits the DetNet guarantees on end- | shaping. In particular, RAW inherits the DetNet guarantees on end- | |||
| skipping to change at line 1154 ¶ | skipping to change at line 1160 ¶ | |||
| reliability mechanisms have no side effect on upper layers, e.g., on | reliability mechanisms have no side effect on upper layers, e.g., on | |||
| transport-layer packet recovery. RAW operations include possible | transport-layer packet recovery. RAW operations include possible | |||
| rerouting, which in turn may affect the ordering of a burst of | rerouting, which in turn may affect the ordering of a burst of | |||
| packets. RAW also inherits PREOF from DetNet, which can be used to | packets. RAW also inherits PREOF from DetNet, which can be used to | |||
| reorder packets before delivery to the upper layers. As a result, | reorder packets before delivery to the upper layers. As a result, | |||
| DetNet in general and RAW in particular offer a smoother transport | DetNet in general and RAW in particular offer a smoother transport | |||
| experience for the upper layers than the Internet at large, with | experience for the upper layers than the Internet at large, with | |||
| ultra-low jitter and loss. | ultra-low jitter and loss. | |||
| RAW improves the reliability of transmissions and the availability of | RAW improves the reliability of transmissions and the availability of | |||
| communication resources, and should be seen as a dynamic optimization | the communication resources and should be seen as a dynamic | |||
| of the use of redundancy to maintain it within certain boundaries. | optimization of the use of redundancy to maintain reliability and | |||
| For instance, ARQ (which provides one-hop reliability through | availability metrics within certain boundaries. For instance, ARQ | |||
| acknowledgements and retries) and FEC codes (such as turbo codes | (which provides one-hop reliability through acknowledgements and | |||
| which reduce the PER) are typically operated at Layer 2 and Layer 1, | retries) and FEC codes (such as turbo codes which reduce the PER) are | |||
| respectively. In both cases, redundant transmissions improve the | typically operated at Layer 2 and Layer 1, respectively. In both | |||
| one-hop reliability at the expense of energy and latency, which are | cases, redundant transmissions improve the one-hop reliability at the | |||
| the resources that RAW must control. In order to achieve its goals, | expense of energy and latency, which are the resources that RAW must | |||
| RAW may leverage the lower-layer operations by abstracting the | control. In order to achieve its goals, RAW may leverage the lower- | |||
| concept and providing hints to the lower layers on the desired | layer operations by abstracting the concept and providing hints to | |||
| outcome (e.g., in terms of reliability and timeliness), as opposed to | the lower layers on the desired outcome (e.g., in terms of | |||
| performing the actual operations at Layer 3. | reliability and timeliness), as opposed to performing the actual | |||
| operations at Layer 3. | ||||
| Guarantees such as bounded latency depend on the upper layers | Guarantees such as bounded latency depend on the upper layers | |||
| (transport or application) to provide the payload in volumes and at | (transport or application) to provide the payload in volumes and at | |||
| times that match the contract with the DetNet sub-layers and the | times that match the contract with the DetNet sub-layers and the | |||
| layers below. An excess of incoming traffic at the DetNet Ingress | layers below. An excess of incoming traffic at the DetNet ingress | |||
| may result in dropping or queueing of packets and can entail loss, | may result in dropping or queueing of packets and can entail loss, | |||
| latency, or jitter; this violates the guarantees that are provided | latency, or jitter; this violates the guarantees that are provided | |||
| inside the DetNet Network. | inside the DetNet Network. | |||
| When the traffic from upper layers matches the expectation of the | When the traffic from upper layers matches the expectation of the | |||
| lower layers, RAW still depends on DetNet mechanisms and the lower | lower layers, RAW still depends on DetNet mechanisms and the lower | |||
| layers to provide the timing and physical resource guarantees that | layers to provide the timing and physical resource guarantees that | |||
| are needed to match the traffic SLA. When the availability of the | are needed to match the traffic SLA. When the availability of the | |||
| physical resource varies, RAW acts on the distribution of the traffic | physical resource varies, RAW acts on the distribution of the traffic | |||
| to leverage alternates within a finite set of potential resources. | to leverage alternates within a finite set of potential resources. | |||
| skipping to change at line 1196 ¶ | skipping to change at line 1203 ¶ | |||
| specialized APIs (e.g., L2 triggers) via monitoring and measurement | specialized APIs (e.g., L2 triggers) via monitoring and measurement | |||
| protocols such as Bidirectional Forwarding Detection (BFD) [RFC5880] | protocols such as Bidirectional Forwarding Detection (BFD) [RFC5880] | |||
| and Simple Two-way Active Measurement Protocol (STAMP) [RFC8762], | and Simple Two-way Active Measurement Protocol (STAMP) [RFC8762], | |||
| respectively, or via a control protocol exchange with the lower layer | respectively, or via a control protocol exchange with the lower layer | |||
| (e.g., DLEP [DLEP]). It may then be processed and exported through | (e.g., DLEP [DLEP]). It may then be processed and exported through | |||
| OAM messaging or via a YANG data model and exposed to the Controller | OAM messaging or via a YANG data model and exposed to the Controller | |||
| Plane. | Plane. | |||
| 5.3. RAW and DetNet | 5.3. RAW and DetNet | |||
| RAW leverages the DetNet Forwarding sub-layer and requires the | RAW leverages the DetNet forwarding sub-layer and requires the | |||
| support of OAM in DetNet Transit Nodes (see Figure 3 of | support of OAM in DetNet Transit nodes (see Figure 3 of | |||
| [DetNet-ARCHI]) for the dynamic acquisition of link capacity and | [DetNet-ARCHI]) for the dynamic acquisition of link capacity and | |||
| state to maintain a strict RAW service end to end over a DetNet | state to maintain a strict RAW service end to end over a DetNet | |||
| Network. In turn, DetNet and thus RAW may benefit from or leverage | Network. In turn, DetNet and thus RAW may benefit from or leverage | |||
| functionality such as that provided by TSN at the lower layers. | functionality such as that provided by TSN at the lower layers. | |||
| RAW extends DetNet to improve the protection against link errors such | RAW extends DetNet to improve the protection against link errors such | |||
| as transient flapping that are far more common in wireless links. | as transient flapping that are far more common in wireless links. | |||
| Nevertheless, for the most part, the RAW methods are applicable to | Nevertheless, for the most part, the RAW methods are applicable to | |||
| wired links as well, e.g., when energy savings are desirable and the | wired links as well, e.g., when energy savings are desirable and the | |||
| available path diversity exceeds 1+1 linear redundancy. | available path diversity exceeds 1+1 linear redundancy. | |||
| RAW adds sub-layer functions that operate in the DetNet Operational | RAW adds sub-layer functions that operate in the DetNet Operational | |||
| Plane, which is part of the Network Plane. The RAW orientation | Plane, which is part of the Network Plane. The RAW orientation | |||
| function may run only in the DetNet Edge Nodes (Ingress Edge Node or | function may run only in the DetNet Edge nodes (ingress Edge node or | |||
| End System), or it can also run in DetNet Relay Nodes when the RAW | End System), or it can also run in DetNet Relay nodes when the RAW | |||
| operations are distributed along the recovery graph. The RAW Service | operations are distributed along the recovery graph. The RAW Service | |||
| sub-layer includes the PLR, which decides the DetNet Path for the | sub-layer includes the PLR, which decides the DetNet path for the | |||
| future packets of a flow along the DetNet Path, Maintenance End | future packets of a flow along the DetNet path, Maintenance End | |||
| Points (MEPs) on edge nodes, and Maintenance Intermediate Points | Points (MEPs) on edge nodes, and Maintenance Intermediate Points | |||
| (MIPs) within. The MEPs trigger, and learn from, OAM observations | (MIPs) within. The MEPs trigger, and learn from, OAM observations | |||
| and feed the PLR for its next decision. | and feed the PLR for its next decision. | |||
| As illustrated in Figure 5, RAW extends the DetNet Stack (see | As illustrated in Figure 5, RAW extends the DetNet Stack (see | |||
| Figure 4 of [DetNet-ARCHI] and Figure 3) with additional | Figure 4 of [DetNet-ARCHI] and Figure 3) with additional | |||
| functionality at the DetNet Service sub-layer for the actuation of | functionality at the DetNet Service sub-layer for the actuation of | |||
| PREOF based on the PLR decision. DetNet operates at Layer 3, | PREOF based on the PLR decision. DetNet operates at Layer 3, | |||
| leveraging abstractions of the lower layers and APIs that control | leveraging abstractions of the lower layers and APIs that control | |||
| those abstractions. For instance, DetNet already leverages lower | those abstractions. For instance, DetNet already leverages lower | |||
| skipping to change at line 1239 ¶ | skipping to change at line 1246 ¶ | |||
| effect, the LL API provides an abstraction to the DetNet layer that | effect, the LL API provides an abstraction to the DetNet layer that | |||
| can be used to push reliability and timing hints, like suggesting X | can be used to push reliability and timing hints, like suggesting X | |||
| retries (min, max) within a time window or sending unicast (one next | retries (min, max) within a time window or sending unicast (one next | |||
| hop) or multicast (for overhearing). In the other direction up the | hop) or multicast (for overhearing). In the other direction up the | |||
| stack, the RAW PLR needs hints about the radio conditions such as L2 | stack, the RAW PLR needs hints about the radio conditions such as L2 | |||
| triggers (e.g., RSSI, LQI, or ETX) over all the wireless hops. | triggers (e.g., RSSI, LQI, or ETX) over all the wireless hops. | |||
| RAW uses various OAM functionalities at the different layers. For | RAW uses various OAM functionalities at the different layers. For | |||
| instance, the OAM function in the DetNet Service sub-layer may | instance, the OAM function in the DetNet Service sub-layer may | |||
| perform Active and/or Hybrid OAM to estimate the link and path | perform Active and/or Hybrid OAM to estimate the link and path | |||
| availability, either end to end or limited to a Segment. The RAW | availability, either end to end or limited to a segment. The RAW | |||
| functions may be present in the Service sub-layer in DetNet Edge and | functions may be present in the Service sub-layer in DetNet Edge and | |||
| Relay Nodes. | Relay nodes. | |||
| +-----------------+ +-------------------+ | +-----------------+ +-------------------+ | |||
| | Routing | | OAM Control | | | Routing | | OAM Control | | |||
| +-----------------+ +-------------------+ | +-----------------+ +-------------------+ | |||
| Controller Plane | Controller Plane | |||
| +-+-+-+-+-+-+-+-+ Southbound Interface -+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ Southbound Interface -+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Network Plane | Network Plane | |||
| | | | | |||
| skipping to change at line 1270 ¶ | skipping to change at line 1277 ¶ | |||
| | Repair (PLR) | | End Point (MEP) | . | | Repair (PLR) | | End Point (MEP) | . | |||
| +-----------------+ +-------------------+ | | +-----------------+ +-------------------+ | | |||
| . | . | |||
| | | | | |||
| Figure 5: RAW Function Placement (Centralized Routing Case) | Figure 5: RAW Function Placement (Centralized Routing Case) | |||
| There are two main proposed models to deploy RAW and DetNet: strict | There are two main proposed models to deploy RAW and DetNet: strict | |||
| (Figure 6) and loose (Figure 7). In the strict model, illustrated in | (Figure 6) and loose (Figure 7). In the strict model, illustrated in | |||
| Figure 6, RAW operates over a continuous DetNet service end to end | Figure 6, RAW operates over a continuous DetNet service end to end | |||
| between the Ingress and the Egress Edge Nodes or End Systems. | between the ingress and the egress Edge nodes or End Systems. | |||
| In the loose model, illustrated in Figure 7, RAW may traverse a | In the loose model, illustrated in Figure 7, RAW may traverse a | |||
| section of the network that is not serviced by DetNet. RAW / OAM may | section of the network that is not serviced by DetNet. RAW OAM may | |||
| observe the end-to-end traffic and make the best of the available | observe the end-to-end traffic and make the best of the available | |||
| resources, but it may not expect the DetNet guarantees over all | resources, but it may not expect the DetNet guarantees over all | |||
| paths. For instance, the packets between two wireless entities may | paths. For instance, the packets between two wireless entities may | |||
| be relayed over a wired infrastructure, in which case RAW observes | be relayed over a wired infrastructure, in which case RAW observes | |||
| and controls the transmission over the wireless first and last hops, | and controls the transmission over the wireless first and last hops, | |||
| as well as end-to-end metrics such as latency, jitter, and delivery | as well as end-to-end metrics such as latency, jitter, and delivery | |||
| ratio. This operation is loose since the structure and properties of | ratio. This operation is loose since the structure and properties of | |||
| the wired infrastructure are ignored and may be either controlled by | the wired infrastructure are ignored and may be either controlled by | |||
| other means such as DetNet/TSN or neglected in the face of the | other means such as DetNet/TSN or neglected in the face of the | |||
| wireless hops. | wireless hops. | |||
| A minimal Forwarding sub-layer service is provided at all DetNet | A minimal forwarding sub-layer service is provided at all DetNet | |||
| Nodes to ensure that the OAM information flows. DetNet Relay Nodes | nodes to ensure that the OAM information flows. DetNet Relay nodes | |||
| may or may not support RAW services, whereas the DetNet Edge Nodes | may or may not support RAW services, whereas the DetNet Edge nodes | |||
| are required to support RAW in any case. DetNet guarantees, such as | are required to support RAW in any case. DetNet guarantees, such as | |||
| bounded latency, are provided end to end. RAW extends the DetNet | bounded latency, are provided end to end. RAW extends the DetNet | |||
| Service sub-layer to optimize the use of resources. | Service sub-layer to optimize the use of resources. | |||
| --------------------Flow Direction----------------------------------> | --------------------Flow Direction----------------------------------> | |||
| +---------+ | +---------+ | |||
| | RAW | | | RAW | | |||
| | Control | | | Control | | |||
| +---------+ +---------+ +---------+ | +---------+ +---------+ +---------+ | |||
| skipping to change at line 1315 ¶ | skipping to change at line 1322 ¶ | |||
| Ingress Transit Relay Egress | Ingress Transit Relay Egress | |||
| Edge ... Nodes ... Nodes ... Edge | Edge ... Nodes ... Nodes ... Edge | |||
| Node Node | Node Node | |||
| <------------------End-to-End DetNet Service-----------------------> | <------------------End-to-End DetNet Service-----------------------> | |||
| Figure 6: RAW over DetNet (Strict Model) | Figure 6: RAW over DetNet (Strict Model) | |||
| In the loose model (illustrated in Figure 7), RAW operates over a | In the loose model (illustrated in Figure 7), RAW operates over a | |||
| partial DetNet service where typically only the Ingress and the | partial DetNet service where typically only the ingress and the | |||
| Egress End Systems support RAW. The DetNet domain may extend beyond | egress End Systems support RAW. The DetNet domain may extend beyond | |||
| the Ingress Node, or there may be a DetNet domain starting at an | the ingress node, or there may be a DetNet domain starting at an | |||
| Ingress Edge Node at the first hop after the End System. | ingress Edge node at the first hop after the End System. | |||
| In the loose model, RAW cannot observe the hops in the network, and | In the loose model, RAW cannot observe the hops in the network, and | |||
| the path beyond the first hop is opaque; RAW can still observe the | the path beyond the first hop is opaque; RAW can still observe the | |||
| end-to-end behavior and use Layer 3 measurements to decide whether to | end-to-end behavior and use Layer 3 measurements to decide whether to | |||
| replicate a packet and select the first-hop interface(s). | replicate a packet and select the first-hop interface(s). | |||
| --------------------Flow Direction----------------------------------> | --------------------Flow Direction----------------------------------> | |||
| +---------+ | +---------+ | |||
| | RAW | | | RAW | | |||
| skipping to change at line 1349 ¶ | skipping to change at line 1356 ¶ | |||
| Ingress Transit Relay Tunnel Egress | Ingress Transit Relay Tunnel Egress | |||
| End ... Nodes ... Nodes ... ... End | End ... Nodes ... Nodes ... ... End | |||
| System System | System System | |||
| <---------------Partitioned DetNet Service-------------------------> | <---------------Partitioned DetNet Service-------------------------> | |||
| Figure 7: RAW over DetNet (Loose Model) | Figure 7: RAW over DetNet (Loose Model) | |||
| 6. The RAW Control Loop | 6. The RAW Control Loop | |||
| The RAW architecture is based on an abstract OODA Loop that controls | The RAW architecture is based on an abstract OODA loop that controls | |||
| the operation of a recovery graph. The generic concept involves the | the operation of a recovery graph. The generic concept involves the | |||
| following: | following: | |||
| 1. Operational Plane measurement protocols for OAM to observe (like | 1. Operational Plane measurement protocols allow OAM to observe | |||
| the first "O" in "OODA") some or all hops along a recovery graph | (like the first "O" in "OODA") some or all hops along a recovery | |||
| as well as the end-to-end packet delivery. | graph as well as the end-to-end packet delivery. | |||
| 2. The DetNet Controller Plane establishes primary and protection | 2. The DetNet Controller Plane establishes primary and protection | |||
| paths for use by the RAW Network Plane. The orientation function | paths for use by the RAW Network Plane. The orientation function | |||
| reports data and information such as link statistics to be used | reports data and information such as link statistics to be used | |||
| by the routing function to compute, install, and maintain the | by the routing function to compute, install, and maintain the | |||
| recovery graphs. The routing function may also generate | recovery graphs. The routing function may also generate | |||
| intelligence such as a trained model for link quality prediction, | intelligence such as a trained model for link quality prediction, | |||
| which in turn can be used by the orientation function (like the | which in turn can be used by the orientation function (like the | |||
| second "O" in "OODA") to influence the Path selection by the PLR | second "O" in "OODA") to influence the path selection by the PLR | |||
| within the RAW OODA loop. | within the RAW OODA loop. | |||
| 3. A PLR operates at the DetNet Service sub-layer and hosts the | 3. A PLR operates at the DetNet Service sub-layer and hosts the | |||
| decision function (like the "D" in "OODA"). The decision | decision function (like the "D" in "OODA"). The decision | |||
| function determines which DetNet Paths will be used for future | function determines which DetNet paths will be used for future | |||
| packets that are routed within the recovery graph. | packets that are routed within the recovery graph. | |||
| 4. Service protection actions that are actuated or triggered over | 4. Service protection actions are actuated or triggered over the LL | |||
| the LL API by the PLR to increase the reliability of the end-to- | API by the PLR to increase the reliability of the end-to- end | |||
| end transmissions. The RAW architecture also covers in-situ | transmissions. The RAW architecture also covers in-situ | |||
| signaling that is embedded within live user traffic [RFC9378] | signaling that is embedded within live user traffic [RFC9378] | |||
| (e.g., via OAM) when the decision is acted (like the "A" in | (e.g., via OAM) when the decision is acted (like the "A" in | |||
| "OODA") upon by a node that is downstream in the recovery graph | "OODA") upon by a node that is downstream in the recovery graph | |||
| from the PLR. | from the PLR. | |||
| 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 SLO(s) while minimizing the use | required reliability and availability SLO(s) while minimizing the use | |||
| of constrained resources such as spectrum and battery. | of constrained resources such as spectrum and battery. | |||
| 6.1. Routing Timescale Versus Forwarding Timescale | 6.1. Routing Timescale Versus Forwarding Timescale | |||
| With DetNet, the Controller Plane Function (CPF) handles the routing | With DetNet, the Controller Plane Function (CPF) handles the routing | |||
| computation and maintenance. With RAW, the routing operation is | computation and maintenance. With RAW, the routing operation is | |||
| segregated from the RAW Control Loop, so it may reside in the | segregated from the RAW control loop, so it may reside in the | |||
| Controller Plane, whereas the control loop itself happens in the | Controller Plane, whereas the control loop itself happens in the | |||
| Network Plane. To achieve RAW capabilities, the routing operation is | Network Plane. To achieve RAW capabilities, the routing operation is | |||
| extended to generate the information required by the orientation | extended to generate the information required by the orientation | |||
| function in the loop. For example, the routing function may propose | function in the loop. For example, the routing function may propose | |||
| DetNet Paths to be used as a reflex action in response to network | DetNet paths to be used as a reflex action in response to network | |||
| events or provide an aggregated history that the orientation function | events or provide an aggregated history that the orientation function | |||
| can use to make a decision. | can use to make a decision. | |||
| In a wireless mesh, the path to a routing function located in the | In a wireless mesh, the path to a routing function located in the | |||
| controller plane can be expensive and slow, possibly going across the | Controller Plane can be expensive and slow, possibly going across the | |||
| whole mesh and back. Reaching the Controller Plane can also be slow | whole mesh and back. Reaching the Controller Plane can also be slow | |||
| in regard to the speed of events that affect the forwarding operation | in regard to the speed of events that affect the forwarding operation | |||
| in the Network Plane at the radio layer. Note that a distributed | in the Network Plane at the radio layer. Note that a distributed | |||
| routing protocol may also take time and consume excessive wireless | routing protocol may also take time and consume excessive wireless | |||
| resources to reconverge to a new optimized state. | resources to reconverge to a new optimized state. | |||
| As a result, the DetNet routing function is not expected to be aware | As a result, the DetNet routing function is not expected to be aware | |||
| of and react to very transient changes. The abstraction of a link at | of and react to very transient changes. The abstraction of a link at | |||
| the routing level is expected to use statistical metrics that | the routing level is expected to use statistical metrics that | |||
| aggregate the behavior of a link over long periods of time and | aggregate the behavior of a link over long periods of time and | |||
| represent its properties as shades of gray as opposed to numerical | represent its properties as shades of gray as opposed to numerical | |||
| values such as a link quality indicator or a Boolean value for either | values such as a link quality indicator or a Boolean value for either | |||
| up or down. | up or down. | |||
| The interaction between the network nodes and the routing function is | The interaction between the network nodes and the routing function is | |||
| handled by the orientation function, which builds reports to the | handled by the orientation function, which reports to the routing | |||
| routing function and sends control information in a digested form | function and sends control information in a digested form back to the | |||
| back to the RAW node to be used inside a forwarding control loop for | RAW node to be used inside a forwarding control loop for traffic | |||
| traffic steering. | steering. | |||
| Figure 8 illustrates a Network Plane recovery graph with links P-Q | Figure 8 illustrates a Network Plane recovery graph with links P-Q | |||
| and N-E flapping, possibly in a transient fashion due to short-term | and N-E flapping, possibly in a transient fashion due to short-term | |||
| interferences and possibly for a longer time (e.g., due to obstacles | interferences and possibly for a longer time (e.g., due to obstacles | |||
| between the sender and the receiver or hardware failures). In order | between the sender and the receiver or hardware failures). In order | |||
| to maintain a received redundancy around a value of 2 (for instance), | to maintain a received redundancy around a value of 2 (for instance), | |||
| RAW may leverage a higher ARQ on these hops if the overall latency | RAW may leverage a higher ARQ on these hops if the overall latency | |||
| permits the extra delay or enable alternate paths between ingress I | permits the extra delay or enable alternate paths between ingress I | |||
| and egress E. For instance, RAW may enable protection path I ==> F | and egress E. For instance, RAW may enable protection path I ==> F | |||
| ==> N ==> Q ==> M ==> R ==> E that routes around both issues and | ==> N ==> Q ==> M ==> R ==> E that routes around both issues and | |||
| skipping to change at line 1510 ¶ | skipping to change at line 1517 ¶ | |||
| observe the local state of the links and some or all hops along a | observe the local state of the links and some or all hops along a | |||
| recovery graph as well as the end-to-end packet delivery (see more | recovery graph as well as the end-to-end packet delivery (see more | |||
| in Section 6.3). Information can also be provided by lower-layer | in Section 6.3). Information can also be provided by lower-layer | |||
| interfaces such as DLEP. | interfaces such as DLEP. | |||
| Orient: The orientation function reports data and information such | Orient: The orientation function reports data and information such | |||
| as the link statistics and leverages offline-computed wisdom and | as the link statistics and leverages offline-computed wisdom and | |||
| knowledge to orient the PLR for its forwarding decision (see more | knowledge to orient the PLR for its forwarding decision (see more | |||
| in Section 6.4). | in Section 6.4). | |||
| Decide: A local PLR decides which DetNet Path to use for future | Decide: A local PLR decides which DetNet path to use for future | |||
| packet(s) that are routed along the recovery graph (see more in | packet(s) that are routed along the recovery graph (see more in | |||
| Section 6.5). | Section 6.5). | |||
| Act: PREOF Data Plane actions are controlled by the PLR over the LL | Act: PREOF Data Plane actions are controlled by the PLR over the LL | |||
| API to increase the reliability of the end-to-end transmission. | API to increase the reliability of the end-to-end transmission. | |||
| The RAW architecture also covers in-situ signaling when the | The RAW architecture also covers in-situ signaling when the | |||
| decision is acted by a node that is down the recovery graph from | decision is acted by a node that is down the recovery graph from | |||
| the PLR (see more in Section 6.6). | the PLR (see more in Section 6.6). | |||
| +-------> Orientation ---------+ | +-------> Orientation ---------+ | |||
| skipping to change at line 1536 ¶ | skipping to change at line 1543 ¶ | |||
| | Service sub-layer | | | Service sub-layer | | |||
| | v | | v | |||
| Observe (OAM) Decide (PLR) | Observe (OAM) Decide (PLR) | |||
| ^ | | ^ | | |||
| | | | | | | |||
| | | | | | | |||
| +------- Act (LL API) <--------+ | +------- Act (LL API) <--------+ | |||
| Figure 9: The RAW OODA Loop | Figure 9: 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. | |||
| 6.3. Observe: RAW OAM | 6.3. Observe: RAW OAM | |||
| The RAW in-situ OAM operation in the Network Plane may observe either | The RAW in-situ OAM operation in the Network Plane may observe either | |||
| a full recovery graph or the DetNet Path that is being used at this | a full recovery graph or the DetNet path that is being used at this | |||
| time. As packets may be load balanced, replicated, eliminated, and/ | time. As packets may be load balanced, replicated, eliminated, and/ | |||
| or fragmented for Network Coding FEC, the RAW in-situ operation needs | or fragmented for Network Coding FEC, the RAW in-situ operation needs | |||
| to be able to signal which operation occurred to an individual | to be able to signal which operation occurred to an individual | |||
| packet. | packet. | |||
| Active RAW OAM may be needed to observe the unused segments and | Active RAW OAM may be needed to observe the unused segments and | |||
| evaluate the desirability of a rerouting decision. | evaluate the desirability of a rerouting decision. | |||
| Finally, the RAW Service sub-layer Assurance may observe the | Finally, the RAW Service sub-layer Service Assurance may observe the | |||
| individual PREOF operation of a DetNet Relay Node to ensure that it | individual PREOF operation of a DetNet Relay node to ensure that it | |||
| is conforming; this might require injecting an OAM packet at an | is conforming; this might require injecting an OAM packet at an | |||
| upstream point inside the recovery graph and extracting that packet | upstream point inside the recovery graph and extracting that packet | |||
| at another point downstream before it reaches the egress. | at another point downstream before it reaches the egress. | |||
| This observation feeds the RAW PLR that makes the decision on which | This observation feeds the RAW PLR that makes the decision on which | |||
| path is used at which RAW Node, for one packet or a small continuous | path is used at which RAW node, for one packet or a small continuous | |||
| series of packets. | series of packets. | |||
| In the case of end-to-end protection in a wireless mesh, the recovery | In the case of end-to-end protection in a wireless mesh, the recovery | |||
| graph is strict and congruent with the path so all links are | graph is strict and congruent with the path so all links are | |||
| observed. | observed. | |||
| Conversely, in the case of Radio Access Protection, illustrated in | Conversely, in the case of Radio Access Protection, illustrated in | |||
| Figure 10, the recovery graph is loose and only the first hop is | Figure 10, the recovery graph is loose and only the first hop is | |||
| observed; the rest of the path is abstracted and considered | observed; the rest of the path is abstracted and considered | |||
| infinitely reliable. The loss of a packet is attributed to the | infinitely reliable. The loss of a packet is attributed to the | |||
| skipping to change at line 1600 ¶ | skipping to change at line 1607 ¶ | |||
| <----------------------L3-----------------------> | <----------------------L3-----------------------> | |||
| Figure 10: Observed Links in Radio Access Protection | Figure 10: Observed Links in Radio Access Protection | |||
| 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 captured in intermediate nodes. In the | but there is no information captured in intermediate nodes. In the | |||
| example above, the tunnel underlay is opaque and not controlled by | example above, the tunnel underlay is opaque and not controlled by | |||
| RAW; still, RAW OAM measures the end-to-end latency and delivery | RAW; still, RAW OAM measures the end-to-end latency and delivery | |||
| ratio for packets sent via RAN 1, RAN 2, and RAN 3, and determines | ratio for packets sent via RAN 1, RAN 2, and RAN 3, and determines | |||
| whether a packet should be sent over either or a collection of those | whether a packet should be sent over either access link or a | |||
| access links. | collection of those access links. | |||
| 6.4. Orient: The RAW-Extended DetNet Operational Plane | 6.4. Orient: The RAW-Extended DetNet Operational Plane | |||
| RAW separates the long timescale at which a recovery graph is | RAW separates the long timescale at which a recovery graph is | |||
| computed and installed from the short timescale at which the | computed and installed from the short timescale at which the | |||
| forwarding decision is taken for one or a few packets (see | forwarding decision is taken for one or a few packets (see | |||
| Section 6.1) that experience the same path until the network | Section 6.1) that experience the same path until the network | |||
| conditions evolve and another path is selected within the same | conditions evolve and another path is selected within the same | |||
| recovery graph. | recovery graph. | |||
| The recovery graph computation is out of scope, but RAW expects that | The recovery graph computation is out of scope, but RAW expects that | |||
| the CPF that installs the recovery graph also provides related | the CPF that installs the recovery graph also provides related | |||
| knowledge in the form of metadata about the links, segments, and | knowledge in the form of metadata about the links, segments, and | |||
| possible DetNet Paths. That metadata can be a pre-digested | possible DetNet paths. That metadata can be a pre-digested | |||
| statistical model and may include prediction of future flaps and | statistical model and may include prediction of future flaps and | |||
| packet loss, as well as recommended actions when that happens. | packet loss, as well as recommended actions when that happens. | |||
| The metadata may include: | The metadata may include: | |||
| * A set of pre-determined DetNet Paths that are prepared to match | * A set of pre-determined DetNet paths that are prepared to match | |||
| expected link-degradation profiles, so the DetNet Relay Nodes can | expected link-degradation profiles, so the DetNet Relay nodes can | |||
| take reflex rerouting actions when facing a degradation that | take reflex rerouting actions when facing a degradation that | |||
| matches one such profile; and | matches one such profile; and | |||
| * Link-quality statistics history and pre-trained models (e.g., to | * Link-quality statistics history and pre-trained models (e.g., to | |||
| predict the short-term variation of quality of the links in a | predict the short-term variation of quality of the links in a | |||
| recovery graph). | recovery graph). | |||
| The recovery graph is installed with measurable objectives that are | The recovery graph is installed with measurable objectives that are | |||
| computed by the CPF to achieve the RAW SLA. The objectives can be | computed by the CPF to achieve the RAW SLA. The objectives can be | |||
| expressed as any of the maximum number of packets lost in a row, | expressed as any of the maximum number of packets lost in a row, | |||
| bounded latency, maximal jitter, maximum number of interleaved out- | bounded latency, maximal jitter, maximum number of interleaved out- | |||
| of-order packets, average number of copies received at the | of-order packets, average number of copies received at the | |||
| elimination point, and maximal delay between the first and the last | elimination point, and maximal delay between the first and the last | |||
| received copy of the same packet. | received copy of the same packet. | |||
| 6.5. Decide: The Point of Local Repair | 6.5. Decide: The Point of Local Repair | |||
| The RAW OODA Loop operates at the path selection timescale to provide | The RAW OODA loop operates at the path selection timescale to provide | |||
| agility versus the brute-force approach of flooding the whole | agility versus the brute-force approach of flooding the whole | |||
| recovery graph. The OODA Loop controls, within the redundant | recovery graph. Within the redundant solutions that are proposed by | |||
| solutions that are proposed by the routing function, which is used | the routing function, the OODA loop controls what is used for each | |||
| for each packet to provide a reliable and available service while | packet and provides a reliable and available service while minimizing | |||
| minimizing the waste of constrained resources. | the waste of constrained resources. | |||
| To that effect, RAW defines the Point of Local Repair (PLR), which | To that effect, RAW defines the Point of Local Repair (PLR), which | |||
| performs rapid local adjustments of the forwarding tables within the | performs rapid local adjustments of the forwarding tables within the | |||
| path diversity that is available in that in the recovery graph. The | path diversity that is available in that in the recovery graph. The | |||
| PLR enables exploitation of the richer forwarding capabilities at a | PLR enables exploitation of the richer forwarding capabilities at a | |||
| faster timescale over a portion of the recovery graph, in either a | faster timescale over a portion of the recovery graph, in either a | |||
| loose or a strict fashion. | loose or a strict fashion. | |||
| The PLR operates on metrics that evolve quickly and need to be | The PLR operates on metrics that evolve quickly and need to be | |||
| advertised at a fast rate (but only locally, within the recovery | advertised at a fast rate (but only locally, within the recovery | |||
| graph), and the PLR reacts on the metric updates by changing the | graph), and the PLR reacts to the metric updates by changing the | |||
| DetNet path in use for the affected flows. | DetNet path in use for the affected flows. | |||
| The rapid changes in the forwarding decisions are made and contained | The rapid changes in the forwarding decisions are made and contained | |||
| within the scope of a recovery graph, and the actions of the PLR are | within the scope of a recovery graph, and the actions of the PLR are | |||
| not signaled outside the recovery graph. This is as opposed to the | not signaled outside the recovery graph. This is as opposed to the | |||
| routing function that must observe the whole network and optimize all | routing function that must observe the whole network and optimize all | |||
| the recovery graphs globally, which can only be done at a slow pace | the recovery graphs globally, which can only be done at a slow pace | |||
| and with long-term statistical metrics, as presented in Table 1. | and with long-term statistical metrics, as presented in Table 1. | |||
| +===============+=========================+=====================+ | +===============+=========================+=====================+ | |||
| skipping to change at line 1686 ¶ | skipping to change at line 1693 ¶ | |||
| | | graphs to optimize | of protection paths | | | | graphs to optimize | of protection paths | | |||
| | | globally | | | | | globally | | | |||
| +===============+-------------------------+---------------------+ | +===============+-------------------------+---------------------+ | |||
| | Considered | Averaged, statistical, | Instantaneous | | | Considered | Averaged, statistical, | Instantaneous | | |||
| | Metrics | shade of grey | values / boolean | | | Metrics | shade of grey | values / boolean | | |||
| | | | condition | | | | | condition | | |||
| +===============+-------------------------+---------------------+ | +===============+-------------------------+---------------------+ | |||
| Table 1: Centralized Decision Versus PLR | Table 1: Centralized Decision Versus PLR | |||
| The PLR sits in the DetNet Forwarding sub-layer of Edge and Relay | The PLR sits in the DetNet forwarding sub-layer of Edge and Relay | |||
| Nodes. The PLR operates on the packet flow, learning the recovery | nodes. The PLR operates on the packet flow, learning the recovery | |||
| graph and path-selection information from the packet and possibly | graph and path-selection information from the packet and possibly | |||
| making a local decision and retagging the packet to indicate so. On | making a local decision and retagging the packet to indicate so. On | |||
| the other hand, the PLR interacts with the lower layers (through | the other hand, the PLR interacts with the lower layers (through | |||
| triggers and DLEP) and with its peers (through OAM) to obtain up-to- | triggers and DLEP) and with its peers (through OAM) to obtain up-to- | |||
| date information about its links and the quality of the overall | date information about its links and the quality of the overall | |||
| recovery graph, respectively, as illustrated in Figure 11. | recovery graph, respectively, as illustrated in Figure 11. | |||
| | | | | |||
| Packet | going | Packet | going | |||
| down the | stack | down the | stack | |||
| skipping to change at line 1719 ¶ | skipping to change at line 1726 ¶ | |||
| | Lower layers | | | Lower layers | | |||
| +..........v.....................^...................^.v........+ | +..........v.....................^...................^.v........+ | |||
| Frame | sent Frame | L2 ack Active | | OAM | Frame | sent Frame | L2 ack Active | | OAM | |||
| over | wireless in | in and | | out | over | wireless in | in and | | out | |||
| v | | v | v | | v | |||
| Figure 11: PLR Conceptual Interfaces | Figure 11: PLR Conceptual Interfaces | |||
| 6.6. Act: DetNet Path Selection and Reliability Functions | 6.6. Act: DetNet Path Selection and Reliability Functions | |||
| The main action by the PLR is the swapping of the DetNet Path within | The main action by the PLR is the swapping of the DetNet path within | |||
| the recovery graph for the future packets. The candidate DetNet | the recovery graph for the future packets. The candidate DetNet | |||
| Paths represent different energy and spectrum profiles and provide | paths represent different energy and spectrum profiles and provide | |||
| protection against different failures. | protection against different failures. | |||
| The LL API enriches the DetNet protection services (PREOF) with the | The LL API enriches the DetNet protection services (PREOF) with the | |||
| possibility to interact with lower-layer, one-hop reliability | possibility to interact with lower-layer, one-hop reliability | |||
| functions that are more typical to wireless than wired, including | functions that are more typical with wireless links than with wired | |||
| ARQ, FEC, and other techniques such as overhearing and constructive | ones, including ARQ, FEC, and other techniques such as overhearing | |||
| interferences. Because RAW may be leveraged on wired links (e.g., to | and constructive interferences. Because RAW may be leveraged on | |||
| save power), it is not expected that all lower layers support all | wired links (e.g., to save power), it is not expected that all lower | |||
| those capabilities. | layers support all those capabilities. | |||
| RAW provides hints to the lower-layer services on the desired | RAW provides hints to the lower-layer services on the desired | |||
| outcome, and the lower layer acts on those hints to provide the best | outcome, and the lower layer acts on those hints to provide the best | |||
| approximation of that outcome, e.g., a level of reliability for one- | approximation of that outcome, e.g., a level of reliability for one- | |||
| hop transmission within a bounded budget of time and/or energy. | hop transmission within a bounded budget of time and/or energy. | |||
| Thus, the LL API makes possible cross-layer optimization for | Thus, the LL API makes possible cross-layer optimization for | |||
| reliability depending on the actual abstraction provided. That is, | reliability depending on the actual abstraction provided. That is, | |||
| some reliability functions are controlled from Layer 3 using an | some reliability functions are controlled from Layer 3 using an | |||
| abstract interface, while they are really operated at the lower | abstract interface, while they are really operated at the lower | |||
| layers. | layers. | |||
| The RAW Path Selection can be implemented in both centralized and | The RAW path selection can be implemented in both centralized and | |||
| distributed approaches. In the centralized approach, the PLR may | distributed approaches. In the centralized approach, the PLR may | |||
| obtain a set of pre-computed DetNet paths matching a set of expected | obtain a set of pre-computed DetNet paths matching a set of expected | |||
| failures and apply the appropriate DetNet paths for the current state | failures and apply the appropriate DetNet paths for the current state | |||
| of the wireless links. In the distributed approach, the signaling in | of the wireless links. In the distributed approach, the signaling in | |||
| the packet may be more abstract than an explicit Path, and the PLR | the packet may be more abstract than an explicit path, and the PLR | |||
| decision might be revised along the selected DetNet Path based on a | decision might be revised along the selected DetNet path based on a | |||
| better knowledge of the rest of the way. | better knowledge of the rest of the way. | |||
| The dynamic DetNet Path selection in RAW avoids the waste of critical | The dynamic DetNet path selection in RAW avoids the waste of critical | |||
| resources such as spectrum and energy while providing for the assured | resources such as spectrum and energy while providing for the assured | |||
| SLA, e.g., by rerouting and/or adding redundancy only when a loss | SLA, e.g., by rerouting and/or adding redundancy only when a loss | |||
| spike is observed. | spike is observed. | |||
| 7. Security Considerations | 7. Security Considerations | |||
| 7.1. Collocated Denial-of-Service Attacks | 7.1. Collocated Denial-of-Service Attacks | |||
| RAW leverages diversity (e.g., spatial and time diversity, coding | RAW leverages diversity (e.g., spatial and time diversity, coding | |||
| diversity, and frequency diversity), possibly using heterogeneous | diversity, and frequency diversity), possibly using heterogeneous | |||
| skipping to change at line 1788 ¶ | skipping to change at line 1795 ¶ | |||
| 7.2. Layer 2 Encryption | 7.2. Layer 2 Encryption | |||
| Radio networks typically encrypt at the Media Access Control (MAC) | Radio networks typically encrypt at the Media Access Control (MAC) | |||
| layer to protect the transmission. If the encryption is per pair of | layer to protect the transmission. If the encryption is per pair of | |||
| peers, then certain RAW operations like promiscuous overhearing | peers, then certain RAW operations like promiscuous overhearing | |||
| become impractical. | become impractical. | |||
| 7.3. Forced Access | 7.3. Forced Access | |||
| A RAW policy may typically select the cheapest collection of links | A RAW policy typically selects the cheapest collection of links that | |||
| that matches the requested SLA, e.g., use free Wi-Fi versus paid 3GPP | matches the requested SLA, e.g., use free Wi-Fi versus paid 3GPP | |||
| access. By defeating the cheap connectivity (e.g., PHY-layer | 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. | |||
| Similar attacks may also be used to deplete resources in lower-power | Similar attacks may also be used to deplete resources in lower-power | |||
| nodes by forcing additional transmissions for FEC and ARQ, and attack | nodes by forcing additional transmissions for FEC and ARQ, and attack | |||
| metrics such as battery life of the nodes. By affecting the | metrics such as battery life of the nodes. By affecting the | |||
| transmissions and the associated routing metrics in one area, an | transmissions and the associated routing metrics in one area, an | |||
| attacker may force the traffic and cause congestion along a remote | attacker may force the traffic and cause congestion along a remote | |||
| path, thus reducing the overall throughput of the network. | path, thus reducing the overall throughput of the network. | |||
| 8. IANA Considerations | 8. IANA Considerations | |||
| This document has no IANA actions. | This document has no IANA actions. | |||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [DetNet-ARCHI] | ||||
| Finn, N., Thubert, P., Varga, B., and J. Farkas, | ||||
| "Deterministic Networking Architecture", RFC 8655, | ||||
| DOI 10.17487/RFC8655, October 2019, | ||||
| <https://www.rfc-editor.org/info/rfc8655>. | ||||
| [DetNet-OAM] | ||||
| Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos, | ||||
| CJ., Varga, B., and J. Farkas, "Framework of Operations, | ||||
| Administration, and Maintenance (OAM) for Deterministic | ||||
| Networking (DetNet)", RFC 9551, DOI 10.17487/RFC9551, | ||||
| March 2024, <https://www.rfc-editor.org/info/rfc9551>. | ||||
| [RAW-TECHNOS] | [RAW-TECHNOS] | |||
| Thubert, P., Ed., Cavalcanti, D., Vilajosana, X., Schmitt, | Thubert, P., Ed., Cavalcanti, D., Vilajosana, X., Schmitt, | |||
| C., and J. Farkas, "Reliable and Available Wireless (RAW) | C., and J. Farkas, "Reliable and Available Wireless (RAW) | |||
| Technologies", RFC 9913, DOI 10.17487/RFC9913, February | Technologies", RFC 9913, DOI 10.17487/RFC9913, February | |||
| 2026, <https://www.rfc-editor.org/info/rfc9913>. | 2026, <https://www.rfc-editor.org/info/rfc9913>. | |||
| [TSN] IEEE, "Time-Sensitive Networking (TSN)", | ||||
| <https://1.ieee802.org/tsn/>. | ||||
| [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery | [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery | |||
| (Protection and Restoration) Terminology for Generalized | (Protection and Restoration) Terminology for Generalized | |||
| Multi-Protocol Label Switching (GMPLS)", RFC 4427, | Multi-Protocol Label Switching (GMPLS)", RFC 4427, | |||
| DOI 10.17487/RFC4427, March 2006, | DOI 10.17487/RFC4427, March 2006, | |||
| <https://www.rfc-editor.org/info/rfc4427>. | <https://www.rfc-editor.org/info/rfc4427>. | |||
| [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>. | |||
| [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>. | |||
| [DetNet-ARCHI] | [TSN] IEEE, "Time-Sensitive Networking (TSN)", | |||
| Finn, N., Thubert, P., Varga, B., and J. Farkas, | <https://1.ieee802.org/tsn/>. | |||
| "Deterministic Networking Architecture", RFC 8655, | ||||
| DOI 10.17487/RFC8655, October 2019, | ||||
| <https://www.rfc-editor.org/info/rfc8655>. | ||||
| [DetNet-OAM] | ||||
| Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos, | ||||
| CJ., Varga, B., and J. Farkas, "Framework of Operations, | ||||
| Administration, and Maintenance (OAM) for Deterministic | ||||
| Networking (DetNet)", RFC 9551, DOI 10.17487/RFC9551, | ||||
| March 2024, <https://www.rfc-editor.org/info/rfc9551>. | ||||
| 9.2. Informative References | 9.2. Informative 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>. | |||
| [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to | [DetNet-DP] | |||
| Deployment (A Bestiary of Roads Not Taken)", RFC 9049, | Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. | |||
| DOI 10.17487/RFC9049, June 2021, | Bryant, "Deterministic Networking (DetNet) Data Plane | |||
| <https://www.rfc-editor.org/info/rfc9049>. | Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, | |||
| <https://www.rfc-editor.org/info/rfc8938>. | ||||
| [DetNet-PLANE] | ||||
| Malis, A. G., Geng, X., Ed., Chen, M., Varga, B., and C. | ||||
| J. Bernardos, "A Framework for Deterministic Networking | ||||
| (DetNet) Controller Plane", Work in Progress, Internet- | ||||
| Draft, draft-ietf-detnet-controller-plane-framework-14, 9 | ||||
| September 2025, <https://datatracker.ietf.org/doc/html/ | ||||
| draft-ietf-detnet-controller-plane-framework-14>. | ||||
| [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>. | ||||
| [FRR] Shand, M. and S. Bryant, "IP Fast Reroute Framework", | ||||
| RFC 5714, DOI 10.17487/RFC5714, January 2010, | ||||
| <https://www.rfc-editor.org/info/rfc5714>. | ||||
| [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, | |||
| DOI 10.17487/RFC1122, October 1989, | DOI 10.17487/RFC1122, October 1989, | |||
| <https://www.rfc-editor.org/info/rfc1122>. | <https://www.rfc-editor.org/info/rfc1122>. | |||
| [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. | [NASA1] Adams, T., "RELIABILITY: Definition & Quantitative | |||
| Bryant, "Deterministic Networking (DetNet) Data Plane: | Illustration", <https://extapps.ksc.nasa.gov/Reliability/ | |||
| IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, | Documents/150814-3bWhatIsReliability.pdf>. | |||
| <https://www.rfc-editor.org/info/rfc8939>. | ||||
| [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", | [NASA2] Adams, T., "Availability", | |||
| RFC 8578, DOI 10.17487/RFC8578, May 2019, | <https://extapps.ksc.nasa.gov/Reliability/ | |||
| <https://www.rfc-editor.org/info/rfc8578>. | Documents/160727.1_Availability_What_is_it.pdf>. | |||
| [RAW-USE-CASES] | [RAW-USE-CASES] | |||
| Bernardos, CJ., Ed., Papadopoulos, G., Thubert, P., and F. | Bernardos, CJ., Ed., Papadopoulos, G., Thubert, P., and F. | |||
| Theoleyre, "Reliable and Available Wireless (RAW) Use | Theoleyre, "Reliable and Available Wireless (RAW) Use | |||
| Cases", RFC 9450, DOI 10.17487/RFC9450, August 2023, | Cases", RFC 9450, DOI 10.17487/RFC9450, August 2023, | |||
| <https://www.rfc-editor.org/info/rfc9450>. | <https://www.rfc-editor.org/info/rfc9450>. | |||
| [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>. | |||
| [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. | [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. | |||
| Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | |||
| Functional Specification", RFC 2205, DOI 10.17487/RFC2205, | Functional Specification", RFC 2205, DOI 10.17487/RFC2205, | |||
| September 1997, <https://www.rfc-editor.org/info/rfc2205>. | September 1997, <https://www.rfc-editor.org/info/rfc2205>. | |||
| [TE] Farrel, A., Ed., "Overview and Principles of Internet | ||||
| Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, | ||||
| January 2024, <https://www.rfc-editor.org/info/rfc9522>. | ||||
| [RFC9544] Mirsky, G., Halpern, J., Min, X., Clemm, A., Strassner, | ||||
| J., and J. François, "Precision Availability Metrics | ||||
| (PAMs) for Services Governed by Service Level Objectives | ||||
| (SLOs)", RFC 9544, DOI 10.17487/RFC9544, March 2024, | ||||
| <https://www.rfc-editor.org/info/rfc9544>. | ||||
| [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path | ||||
| Computation Element (PCE)-Based Architecture", RFC 4655, | ||||
| DOI 10.17487/RFC4655, August 2006, | ||||
| <https://www.rfc-editor.org/info/rfc4655>. | ||||
| [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on | [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on | |||
| link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, | link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, | |||
| DOI 10.17487/RFC3366, August 2002, | DOI 10.17487/RFC3366, August 2002, | |||
| <https://www.rfc-editor.org/info/rfc3366>. | <https://www.rfc-editor.org/info/rfc3366>. | |||
| [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast | [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast | |||
| Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, | Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, | |||
| DOI 10.17487/RFC4090, May 2005, | DOI 10.17487/RFC4090, May 2005, | |||
| <https://www.rfc-editor.org/info/rfc4090>. | <https://www.rfc-editor.org/info/rfc4090>. | |||
| [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path | ||||
| Computation Element (PCE)-Based Architecture", RFC 4655, | ||||
| DOI 10.17487/RFC4655, August 2006, | ||||
| <https://www.rfc-editor.org/info/rfc4655>. | ||||
| [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5880] 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>. | |||
| [FRR] Shand, M. and S. Bryant, "IP Fast Reroute Framework", | ||||
| RFC 5714, DOI 10.17487/RFC5714, January 2010, | ||||
| <https://www.rfc-editor.org/info/rfc5714>. | ||||
| [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, | [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, | |||
| N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- | N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- | |||
| TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, | TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, | |||
| October 2011, <https://www.rfc-editor.org/info/rfc6378>. | October 2011, <https://www.rfc-editor.org/info/rfc6378>. | |||
| [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., | [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., | |||
| and D. Barthel, "Routing Metrics Used for Path Calculation | and D. Barthel, "Routing Metrics Used for Path Calculation | |||
| in Low-Power and Lossy Networks", RFC 6551, | in Low-Power and Lossy Networks", RFC 6551, | |||
| DOI 10.17487/RFC6551, March 2012, | DOI 10.17487/RFC6551, March 2012, | |||
| <https://www.rfc-editor.org/info/rfc6551>. | <https://www.rfc-editor.org/info/rfc6551>. | |||
| [RLFA-FRR] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. | [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", | |||
| So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", | RFC 8578, DOI 10.17487/RFC8578, May 2019, | |||
| RFC 7490, DOI 10.17487/RFC7490, April 2015, | <https://www.rfc-editor.org/info/rfc8578>. | |||
| <https://www.rfc-editor.org/info/rfc7490>. | ||||
| [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. | [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. | |||
| Zuniga, "SCHC: Generic Framework for Static Context Header | Zuniga, "SCHC: Generic Framework for Static Context Header | |||
| Compression and Fragmentation", RFC 8724, | Compression and Fragmentation", RFC 8724, | |||
| DOI 10.17487/RFC8724, April 2020, | DOI 10.17487/RFC8724, April 2020, | |||
| <https://www.rfc-editor.org/info/rfc8724>. | <https://www.rfc-editor.org/info/rfc8724>. | |||
| [DetNet-DP] | [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple | |||
| Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. | Two-Way Active Measurement Protocol", RFC 8762, | |||
| Bryant, "Deterministic Networking (DetNet) Data Plane | DOI 10.17487/RFC8762, March 2020, | |||
| Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, | <https://www.rfc-editor.org/info/rfc8762>. | |||
| <https://www.rfc-editor.org/info/rfc8938>. | ||||
| [DLEP] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. | [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. | |||
| Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, | Bryant, "Deterministic Networking (DetNet) Data Plane: | |||
| DOI 10.17487/RFC8175, June 2017, | IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, | |||
| <https://www.rfc-editor.org/info/rfc8175>. | <https://www.rfc-editor.org/info/rfc8939>. | |||
| [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to | ||||
| Deployment (A Bestiary of Roads Not Taken)", RFC 9049, | ||||
| DOI 10.17487/RFC9049, June 2021, | ||||
| <https://www.rfc-editor.org/info/rfc9049>. | ||||
| [RFC9378] Brockners, F., Ed., Bhandari, S., Ed., Bernier, D., and T. | [RFC9378] Brockners, F., Ed., Bhandari, S., Ed., Bernier, D., and T. | |||
| Mizrahi, Ed., "In Situ Operations, Administration, and | Mizrahi, Ed., "In Situ Operations, Administration, and | |||
| Maintenance (IOAM) Deployment", RFC 9378, | Maintenance (IOAM) Deployment", RFC 9378, | |||
| DOI 10.17487/RFC9378, April 2023, | DOI 10.17487/RFC9378, April 2023, | |||
| <https://www.rfc-editor.org/info/rfc9378>. | <https://www.rfc-editor.org/info/rfc9378>. | |||
| [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple | ||||
| Two-Way Active Measurement Protocol", RFC 8762, | ||||
| DOI 10.17487/RFC8762, March 2020, | ||||
| <https://www.rfc-editor.org/info/rfc8762>. | ||||
| [RFC9473] Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path | [RFC9473] Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path | |||
| Properties", RFC 9473, DOI 10.17487/RFC9473, September | Properties", RFC 9473, DOI 10.17487/RFC9473, September | |||
| 2023, <https://www.rfc-editor.org/info/rfc9473>. | 2023, <https://www.rfc-editor.org/info/rfc9473>. | |||
| [RFC9544] Mirsky, G., Halpern, J., Min, X., Clemm, A., Strassner, | ||||
| J., and J. François, "Precision Availability Metrics | ||||
| (PAMs) for Services Governed by Service Level Objectives | ||||
| (SLOs)", RFC 9544, DOI 10.17487/RFC9544, March 2024, | ||||
| <https://www.rfc-editor.org/info/rfc9544>. | ||||
| [RFC9633] Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, | [RFC9633] Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, | |||
| "Deterministic Networking (DetNet) YANG Data Model", | "Deterministic Networking (DetNet) YANG Data Model", | |||
| RFC 9633, DOI 10.17487/RFC9633, October 2024, | RFC 9633, DOI 10.17487/RFC9633, October 2024, | |||
| <https://www.rfc-editor.org/info/rfc9633>. | <https://www.rfc-editor.org/info/rfc9633>. | |||
| [DetNet-PLANE] | [RLFA-FRR] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. | |||
| Malis, A. G., Geng, X., Ed., Chen, M., Varga, B., and C. | So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", | |||
| J. Bernardos, "A Framework for Deterministic Networking | RFC 7490, DOI 10.17487/RFC7490, April 2015, | |||
| (DetNet) Controller Plane", Work in Progress, Internet- | <https://www.rfc-editor.org/info/rfc7490>. | |||
| Draft, draft-ietf-detnet-controller-plane-framework-14, 9 | ||||
| September 2025, <https://datatracker.ietf.org/doc/html/ | ||||
| draft-ietf-detnet-controller-plane-framework-14>. | ||||
| [NASA1] Adams, T., "RELIABILITY: Definition & Quantitative | ||||
| Illustration", <https://extapps.ksc.nasa.gov/Reliability/ | ||||
| Documents/150814-3bWhatIsReliability.pdf>. | ||||
| [NASA2] Adams, T., "Availability", | [TE] Farrel, A., Ed., "Overview and Principles of Internet | |||
| <https://extapps.ksc.nasa.gov/Reliability/ | Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, | |||
| Documents/160727.1_Availability_What_is_it.pdf>. | January 2024, <https://www.rfc-editor.org/info/rfc9522>. | |||
| Acknowledgments | Acknowledgments | |||
| This architecture could never have been completed without the support | This architecture could never have been completed without the support | |||
| and recommendations from the DetNet chairs Janos Farkas and Lou | and recommendations from the DetNet chairs Janos Farkas and Lou | |||
| Berger, and from Dave Black, the DetNet Tech Advisor. Many thanks to | Berger, and from Dave Black, the DetNet Tech Advisor. Many thanks to | |||
| all of you. | all of you. | |||
| The authors wish to thank Ketan Talaulikar, as well as Balazs Varga, | The authors wish to thank Ketan Talaulikar, as well as Balazs Varga, | |||
| Dave Cavalcanti, Don Fedyk, Nicolas Montavont, and Fabrice Theoleyre | Dave Cavalcanti, Don Fedyk, Nicolas Montavont, and Fabrice Theoleyre | |||
| skipping to change at line 2047 ¶ | skipping to change at line 2054 ¶ | |||
| Retired | Retired | |||
| Email: buddenbergr@gmail.com | Email: buddenbergr@gmail.com | |||
| Greg Mirsky | Greg Mirsky | |||
| Ericsson | Ericsson | |||
| Email: gregimirsky@gmail.com | Email: gregimirsky@gmail.com | |||
| Author's Address | Author's Address | |||
| Pascal Thubert (editor) | Pascal Thubert (editor) | |||
| Independent | ||||
| 06330 Roquefort-les-Pins | 06330 Roquefort-les-Pins | |||
| France | France | |||
| Email: pascal.thubert@gmail.com | Email: pascal.thubert@gmail.com | |||
| End of changes. 108 change blocks. | ||||
| 292 lines changed or deleted | 300 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||