| < draft-ietf-raw-oam-support-02.txt | draft-ietf-raw-oam-support-03.txt > | |||
|---|---|---|---|---|
| RAW F. Theoleyre | RAW F. Theoleyre | |||
| Internet-Draft CNRS | Internet-Draft CNRS | |||
| Updates: draft-ietf-raw-oam-support-01 G. Papadopoulos | Intended status: Informational G.Z. Papadopoulos | |||
| (if approved) IMT Atlantique | Expires: 21 July 2022 IMT Atlantique | |||
| Intended status: Informational G. Mirsky | G. Mirsky | |||
| Expires: December 5, 2021 ZTE Corp. | Ericsson | |||
| CJ. Bernardos | CJ. Bernardos | |||
| UC3M | UC3M | |||
| June 3, 2021 | 17 January 2022 | |||
| Operations, Administration and Maintenance (OAM) features for RAW | Operations, Administration and Maintenance (OAM) features for RAW | |||
| draft-ietf-raw-oam-support-02 | draft-ietf-raw-oam-support-03 | |||
| Abstract | Abstract | |||
| Some critical applications may use a wireless infrastructure. | Some critical applications may use a wireless infrastructure. | |||
| However, wireless networks exhibit a bandwidth of several orders of | However, wireless networks exhibit a bandwidth of several orders of | |||
| magnitude lower than wired networks. Besides, wireless transmissions | magnitude lower than wired networks. Besides, wireless transmissions | |||
| are lossy by nature; the probability that a packet cannot be decoded | are lossy by nature; the probability that a packet cannot be decoded | |||
| correctly by the receiver may be quite high. In these conditions, | correctly by the receiver may be quite high. In these conditions, | |||
| providing high reliability and a low delay is challenging. This | providing high reliability and a low delay is challenging. This | |||
| document lists the requirements of the Operation, Administration, and | document lists the requirements of the Operation, Administration, and | |||
| Maintenance (OAM) features recommended to construct a predictable | Maintenance (OAM) features are recommended to construct a predictable | |||
| communication infrastructure on top of a collection of wireless | communication infrastructure on top of a collection of wireless | |||
| segments. This document describes the benefits, problems, and trade- | segments. This document describes the benefits, problems, and trade- | |||
| offs for using OAM in wireless networks to achieve Service Level | offs for using OAM in wireless networks to achieve Service Level | |||
| Objectives (SLO). | Objectives (SLO). | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on December 5, 2021. | This Internet-Draft will expire on 21 July 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
| publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
| carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
| to this document. Code Components extracted from this document must | extracted from this document must include Revised BSD License text as | |||
| include Simplified BSD License text as described in Section 4.e of | described in Section 4.e of the Trust Legal Provisions and are | |||
| the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Revised BSD License. | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 | 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 | |||
| 2. Role of OAM in RAW . . . . . . . . . . . . . . . . . . . . . 6 | 2. Role of OAM in RAW . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.1. Link concept and quality . . . . . . . . . . . . . . . . 7 | 2.1. Link concept and quality . . . . . . . . . . . . . . . . 7 | |||
| 2.2. Broadcast Transmissions . . . . . . . . . . . . . . . . . 7 | 2.2. Broadcast Transmissions . . . . . . . . . . . . . . . . . 8 | |||
| 2.3. Complex Layer 2 Forwarding . . . . . . . . . . . . . . . 8 | 2.3. Complex Layer 2 Forwarding . . . . . . . . . . . . . . . 8 | |||
| 2.4. End-to-end delay . . . . . . . . . . . . . . . . . . . . 8 | 2.4. End-to-end delay . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.1. Information Collection . . . . . . . . . . . . . . . . . 8 | 3.1. Information Collection . . . . . . . . . . . . . . . . . 9 | |||
| 3.2. Continuity Check . . . . . . . . . . . . . . . . . . . . 9 | 3.2. Continuity Check . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.3. Connectivity Verification . . . . . . . . . . . . . . . . 9 | 3.3. Connectivity Verification . . . . . . . . . . . . . . . . 9 | |||
| 3.4. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 9 | 3.4. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.5. Fault Verification/detection . . . . . . . . . . . . . . 10 | 3.5. Fault Verification/detection . . . . . . . . . . . . . . 10 | |||
| 3.6. Fault Isolation/identification . . . . . . . . . . . . . 10 | 3.6. Fault Isolation/identification . . . . . . . . . . . . . 10 | |||
| 4. Administration . . . . . . . . . . . . . . . . . . . . . . . 10 | 4. Administration . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 4.1. Worst-case metrics . . . . . . . . . . . . . . . . . . . 11 | 4.1. Worst-case metrics . . . . . . . . . . . . . . . . . . . 11 | |||
| 4.2. Efficient data retrieval . . . . . . . . . . . . . . . . 11 | 4.2. Efficient measurement retrieval (Passive OAM) . . . . . . 11 | |||
| 4.3. Reporting OAM packets to the source . . . . . . . . . . . 12 | 4.3. Reporting OAM packets to the source (Active OAM) . . . . 12 | |||
| 5. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 5. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 5.1. Soft transition after reconfiguration . . . . . . . . . . 13 | 5.1. Soft transition after reconfiguration . . . . . . . . . . 13 | |||
| 5.2. Predictive maintenance . . . . . . . . . . . . . . . . . 13 | 5.2. Predictive maintenance . . . . . . . . . . . . . . . . . 13 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
| 9. Informative References . . . . . . . . . . . . . . . . . . . 14 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | 10. Informative References . . . . . . . . . . . . . . . . . . . 14 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
| 1. Introduction | 1. Introduction | |||
| Reliable and Available Wireless (RAW) is an effort that extends | Reliable and Available Wireless (RAW) is an effort that extends | |||
| DetNet to approach end-to-end deterministic performances over a | DetNet to approach end-to-end deterministic performances over a | |||
| network that includes scheduled wireless segments. In wired | network that includes scheduled wireless segments. In wired | |||
| networks, many approaches try to enable Quality of Service (QoS) by | networks, many approaches try to enable Quality of Service (QoS) by | |||
| implementing traffic differentiation so that routers handle each type | implementing traffic differentiation so that routers handle each type | |||
| of packets differently. However, this differentiated treatment was | of packets differently. However, this differentiated treatment was | |||
| expensive for most applications. | expensive for most applications. | |||
| Deterministic Networking (DetNet) [RFC8655] has proposed to provide a | Deterministic Networking (DetNet) [RFC8655] has proposed to provide a | |||
| bounded end-to-end latency on top of the network infrastructure, | bounded end-to-end latency on top of the network infrastructure, | |||
| comprising both Layer 2 bridged and Layer 3 routed segments. Their | comprising both Layer 2 bridged and Layer 3 routed segments. Their | |||
| work encompasses the data plane, OAM, time synchronization, | work encompasses the data plane, OAM, time synchronization, | |||
| management, control, and security aspects. | management, control, and security aspects. | |||
| However, wireless networks create specific challenges. First of all, | However, wireless networks create specific challenges. First of all, | |||
| radio bandwidth is significantly lower than for wired networks. In | radio bandwidth is significantly lower than in wired networks. In | |||
| these conditions, the volume of signaling messages has to be very | these conditions, the volume of signaling messages has to be very | |||
| limited. Even worse, wireless links are lossy: a Layer 2 | limited. Even worse, wireless links are lossy: a Layer 2 | |||
| transmission may or may not be decoded correctly by the receiver, | transmission may or may not be decoded correctly by the receiver, | |||
| depending on a broad set of parameters. Thus, providing high | depending on a broad set of parameters. Thus, providing high | |||
| reliability through wireless segments is particularly challenging. | reliability through wireless segments is particularly challenging. | |||
| Wired networks rely on the concept of _links_. All the devices | Wired networks rely on the concept of _links_. All the devices | |||
| attached to a link receive any transmission. The concept of a link | attached to a link receive any transmission. The concept of a link | |||
| in wireless networks is somewhat different from what many are used to | in wireless networks is somewhat different from what many are used to | |||
| in wireline networks. A receiver may or may not receive a | in wireline networks. A receiver may or may not receive a | |||
| transmission, depending on the presence of a colliding transmission, | transmission, depending on the presence of a colliding transmission, | |||
| the radio channel's quality, and the external interference. Besides, | the radio channel's quality, and the external interference. Besides, | |||
| a wireless transmission is broadcast by nature: any _neighboring_ | a wireless transmission is broadcast by nature: any _neighboring_ | |||
| device may be able to decode it. This document includes detailed | device may be able to decode it. This document includes detailed | |||
| information on what the implications for the OAM features are. | information on the implications for the OAM features. | |||
| Last but not least, radio links present volatile characteristics. If | Last but not least, radio links present volatile characteristics. If | |||
| the wireless networks use an unlicensed band, packet losses are not | the wireless networks use an unlicensed band, packet losses are not | |||
| anymore temporally and spatially independent. Typically, links may | anymore temporally and spatially independent. Typically, links may | |||
| exhibit a very bursty characteristic, where several consecutive | exhibit a very bursty characteristic, where several consecutive | |||
| packets may be dropped, because of e.g. temporary external | packets may be dropped because of, e.g., temporary external | |||
| interference. Thus, providing availability and reliability on top of | interference. Thus, providing availability and reliability on top of | |||
| the wireless infrastructure requires specific Layer 3 mechanisms to | the wireless infrastructure requires specific Layer 3 mechanisms to | |||
| counteract these bursty losses. | counteract these bursty losses. | |||
| Operations, Administration, and Maintenance (OAM) Tools are of | Operations, Administration, and Maintenance (OAM) Tools are of | |||
| primary importance for IP networks [RFC7276]. They define a toolset | primary importance for IP networks [RFC7276]. They define a toolset | |||
| for fault detection, isolation, and performance measurement. | for fault detection, isolation, and performance measurement. | |||
| The primary purpose of this document is to detail the specific | The primary purpose of this document is to detail the specific | |||
| requirements of the OAM features recommended to construct a | requirements of the OAM features recommended to construct a | |||
| skipping to change at page 4, line 21 ¶ | skipping to change at page 4, line 21 ¶ | |||
| 1.1. Terminology | 1.1. Terminology | |||
| In this document, the term OAM will be used according to its | In this document, the term OAM will be used according to its | |||
| definition specified in [RFC6291]. We expect to implement an OAM | definition specified in [RFC6291]. We expect to implement an OAM | |||
| framework in RAW networks to maintain a real-time view of the network | framework in RAW networks to maintain a real-time view of the network | |||
| infrastructure, and its ability to respect the Service Level | infrastructure, and its ability to respect the Service Level | |||
| Objectives (SLO), such as delay and reliability, assigned to each | Objectives (SLO), such as delay and reliability, assigned to each | |||
| data flow. | data flow. | |||
| We re-use here the same terminology as [detnet-oam]: | We re-use here the same terminology as | |||
| [I-D.ietf-detnet-oam-framework]: | ||||
| o OAM entity: a data flow to be monitored for defects and/or its | * OAM entity: a data flow to be monitored for defects and/or its | |||
| performance metrics measured.; | performance metrics measured.; | |||
| o Maintenance End Point (MEP): OAM devices crossed when entering/ | * Test End Point (TEP): OAM devices crossed when entering/exiting | |||
| exiting the network. In RAW, it corresponds mostly to the source | the network. In RAW, it corresponds mostly to the source or | |||
| or destination of a data flow. OAM message can be exchanged | destination of a data flow. OAM message can be exchanged between | |||
| between two MEPs; | two TEPs; | |||
| o Maintenance Intermediate endPoint (MIP): an OAM system along the | * Monitoring endPoint (MonEP): an OAM system along the flow; a MonEP | |||
| flow; a MIP MAY respond to an OAM message generated by the MEP; | MAY respond to an OAM message generated by the TEP; | |||
| o control/management/data plane: the control and management planes | * control/management/data plane: the control and management planes | |||
| are used to configure and control the network (long-term). The | are used to configure and control the network (long-term). The | |||
| data plane takes the individual decision. Relative to a data | data plane takes the individual decision. Relative to a data | |||
| flow, the control and/or management plane can be out-of-band; | flow, the control and/or management plane can be out-of-band; | |||
| o Active measurement methods (as defined in [RFC7799]) modify a | * Active measurement methods (as defined in [RFC7799]) modify a | |||
| normal data flow by inserting novel fields, injecting specially | normal data flow by inserting novel fields, injecting specially | |||
| constructed test packets [RFC2544]). It is critical for the | constructed test packets [RFC2544]). It is critical for the | |||
| quality of information obtained using an active method that | quality of information obtained using an active method that | |||
| generated test packets are in-band with the monitored data flow. | generated test packets are in-band with the monitored data flow. | |||
| In other words, a test packet is required to cross the same | In other words, a test packet is required to cross the same | |||
| network nodes and links and receive the same Quality of Service | network nodes and links and receive the same Quality of Service | |||
| (QoS) treatment as a data packet. Active methods may implement | (QoS) treatment as a data packet. Active methods may implement | |||
| one of these two strategies: | one of these two strategies: | |||
| * In-band: control information follows the same path as the data | - In-band: control information follows the same path as the data | |||
| packets. In other words, a failure in the data plane may | packets. In other words, a failure in the data plane may | |||
| prevent the control information to reach the destination (e.g., | prevent the control information from reaching the destination | |||
| end-device or controller). | (e.g., end-device or controller). | |||
| * out-of-band: control information is sent separately from the | - out-of-band: control information is sent separately from the | |||
| data packets. Thus, the behavior of control vs. data packets | data packets. Thus, the behavior of control vs. data packets | |||
| may differ; | may differ; | |||
| o Passive measurement methods [RFC7799] infer information by | * Passive measurement methods [RFC7799] infer information by | |||
| observing unmodified existing flows. | observing unmodified existing flows. | |||
| We also adopt the following terminology, which is particularly | We also adopt the following terminology, which is particularly | |||
| relevant for RAW segments. | relevant for RAW segments. | |||
| o piggybacking vs. dedicated control packets: control information | * piggybacking vs. dedicated control packets: control information | |||
| may be encapsulated in specific (dedicated) control packets. | may be encapsulated in specific (dedicated) control packets. | |||
| Alternatively, it may be piggybacked in existing data packets, | Alternatively, it may be piggybacked in existing data packets, | |||
| when the MTU is larger than the actual packet length. | when the MTU is larger than the actual packet length. | |||
| Piggybacking makes specifically sense in wireless networks, as the | Piggybacking makes specifically sense in wireless networks, as the | |||
| cost (bandwidth and energy) is not linear with the packet size. | cost (bandwidth and energy) is not linear with the packet size. | |||
| o router-over vs. mesh under: a control packet is either forwarded | * router-over vs. mesh under: a control packet is either forwarded | |||
| directly to the layer-3 next hop (mesh under) or handled hop-by- | directly to the layer-3 next hop (mesh under) or handled hop-by- | |||
| hop by each router. While the latter option consumes more | hop by each router. While the latter option consumes more | |||
| resources, it allows to collect additionnal intermediary | resources, it allows collecting additional intermediary | |||
| information, particularly relevant in wireless networks. | information, particularly relevant in wireless networks. | |||
| o Defect: a temporary change in the network (e.g., a radio link | * Defect: a temporary change in the network (e.g., a radio link | |||
| which is broken due to a mobile obstacle); | which is broken due to a mobile obstacle); | |||
| o Fault: a definite change which may affect the network performance, | * Fault: a definite change which may affect the network performance, | |||
| e.g., a node runs out of energy. | e.g., a node runs out of energy. | |||
| o End-to-end delay: the time between the packet generation and its | * End-to-end delay: the time between the packet generation and its | |||
| reception by the destination. | reception by the destination. | |||
| 1.2. Acronyms | 1.2. Acronyms | |||
| OAM Operations, Administration, and Maintenance | OAM Operations, Administration, and Maintenance | |||
| DetNet Deterministic Networking | DetNet Deterministic Networking | |||
| PSE Path Selection Engine [I-D.pthubert-raw-architecture] | PSE Path Selection Engine [I-D.pthubert-raw-architecture] | |||
| skipping to change at page 5, line 48 ¶ | skipping to change at page 6, line 4 ¶ | |||
| OAM Operations, Administration, and Maintenance | OAM Operations, Administration, and Maintenance | |||
| DetNet Deterministic Networking | DetNet Deterministic Networking | |||
| PSE Path Selection Engine [I-D.pthubert-raw-architecture] | PSE Path Selection Engine [I-D.pthubert-raw-architecture] | |||
| QoS Quality of Service | QoS Quality of Service | |||
| RAW Reliable and Available Wireless | RAW Reliable and Available Wireless | |||
| SLO Service Level Objective | SLO Service Level Objective | |||
| SNMP Simple Network Management Protocol | SNMP Simple Network Management Protocol | |||
| SDN Software-Defined Network | SDN Software-Defined Network | |||
| 1.3. Requirements Language | 1.3. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. Role of OAM in RAW | 2. Role of OAM in RAW | |||
| RAW networks expect to make the communications reliable and | RAW networks expect to make the communications reliable and | |||
| predictable on top of a wireless network infrastructure. Most | predictable over a wireless network infrastructure. Most critical | |||
| critical applications will define an SLO to be required for the data | applications will define an SLO required for the data flows it | |||
| flows it generates. RAW considers network plane protocol elements | generates. RAW considers network plane protocol elements such as OAM | |||
| such as OAM to improve the RAW operation at the service and the | to improve the RAW operation at the service and the forwarding sub- | |||
| forwarding sub-layers. | layers. | |||
| To respect strict guarantees, RAW relies on the Path Selection Engine | To respect strict guarantees, RAW relies on the Path Selection Engine | |||
| (PSE) (as defined in [I-D.pthubert-raw-architecture] to monitor and | (PSE) (as defined in [I-D.pthubert-raw-architecture] to monitor and | |||
| maintain the L3 network. A L2 scheduler may be used to allocate | maintain the L3 network. An L2 scheduler may be used to allocate | |||
| transmission opportunities, based on the radio link characteristics, | transmission opportunities, based on the radio link characteristics, | |||
| SLO of the flows, the number of packets to forward. The PSE exploits | SLO of the flows, the number of packets to forward. The PSE exploits | |||
| the L2 ressources reserved by the scheduler, and organizes the L3 | the L2 resources reserved by the scheduler and organizes the L3 paths | |||
| paths to introduce redundancy, fault tolerance, and create backup | to introduce redundancy, fault tolerance and create backup paths. | |||
| paths. OAM represents the core of the pre-provisioning process by | OAM represents the core of the pre-provisioning process by | |||
| supervising the network. It maintains maintains a global view of the | supervising the network. It maintains a global view of the network | |||
| network resources, to detect defects, faults, over-provisionning, | resources to detect defects, faults, over-provisioning, anomalies. | |||
| anomalies. | ||||
| Fault-tolerance also assumes that multiple paths have to be | Fault tolerance also assumes that multiple paths must be provisioned | |||
| provisioned so that an end-to-end circuit keeps on existing whatever | so that an end-to-end circuit remains operational regardless of the | |||
| the conditions. The Packet Replication and Elimination Function | conditions. The Packet Replication and Elimination Function | |||
| ([PREF-draft]) on a node is typically controlled by the PSE. OAM | ([I-D.thubert-bier-replication-elimination]) on a node is typically | |||
| mechanisms can be used to monitor that PREOF is working correctly on | controlled by the PSE. OAM mechanisms can be used to monitor that | |||
| a node and within the domain. | PREOF is working correctly on a node and within the domain. | |||
| To be energy-efficient, reserving some dedicated out-of-band | To be energy-efficient, out-of-band OAM SHOULD only be used to report | |||
| resources for OAM seems idealistic, and only in-band solutions are | aggregated statistics (e.g., counters, histograms) from the nodes | |||
| considered here. | using, e.g., SNMP or Netconf/Restconf using YANG-based data models. | |||
| The out-of-band OAM flow MAY use a dedicated control and management | ||||
| channel, dedicated for this purpose. | ||||
| RAW supports both proactive and on-demand troubleshooting. | RAW supports both proactive and on-demand troubleshooting. | |||
| Proactively, it is necessary to detect anomalies, to report defects, | Proactively, it is necessary to detect anomalies, report defects, or | |||
| or to reduce over-provisionning if it is not required. However, on- | reduce over-provisioning if it is not required. However, on-demand | |||
| demand may also be required to identify the cause of a specific | may also be required to identify the cause of a specific defect. | |||
| defect. Indeed, some specific faults may only be detected with a | Indeed, some specific faults may only be detected with a global, | |||
| global, detailed view of the network, which is too expensive to | detailed view of the network, which is too expensive to acquire in | |||
| acquire in the normal operating mode. | the normal operating mode. | |||
| The specific characteristics of RAW are discussed below. | The specific characteristics of RAW are discussed below. | |||
| 2.1. Link concept and quality | 2.1. Link concept and quality | |||
| In wireless networks, a _link_ does not exist physically. A device | In wireless networks, a _link_ does not exist physically. A device | |||
| has a set of *neighbors* that correspond to all the devices that have | has a set of *neighbors* that correspond to all the devices that have | |||
| a non null probability of receiving correctly its packets. We make a | a non-null probability of receiving its packets correctly. We make a | |||
| distinction between: | distinction between: | |||
| o point-to-point (p2p) link with one transmitter and one receiver. | * point-to-point (p2p) link with one transmitter and one receiver. | |||
| These links are used to transmit unicast packets. | These links are used to transmit unicast packets. | |||
| o point-to-multipoint (p2m) link associates one transmitter and a | * point-to-multipoint (p2mp) link associates one transmitter and a | |||
| collection of receivers. For instance, broadcast packets assume | collection of receivers. For instance, broadcast packets assume | |||
| the existence of p2m links to avoid duplicating a broadcast packet | the existence of p2mp links to avoid duplicating a broadcast | |||
| to reach each possible radio neighbor. | packet to reach each possible radio neighbor. | |||
| In scheduled radio networks, p2m and p2p links are commonly not | In scheduled radio networks, p2mp and p2p links are commonly not | |||
| scheduled simultaneously to save energy, and/or to reduce the number | scheduled simultaneously to save energy and/or to reduce the number | |||
| of collisions. More precisely, only one part of the neighbors may | of collisions. More precisely, only one part of the neighbors may | |||
| wake-up at a given instant. | wake up at a given instant. | |||
| Anycast are used in p2m links to improve the reliability. A | Anycast is used in p2mp links to improve the reliability. A | |||
| collection of receivers are scheduled to wake-up simutaneously, so | collection of receivers are scheduled to wake up simultaneously, so | |||
| that the transmission fails only if none of the receivers is able to | that the transmission fails only if none of the receivers can decode | |||
| decode the packet. | the packet. | |||
| Each wireless link is associated with a link quality, often measured | Each wireless link is associated with a link quality, often measured | |||
| as the Packet Delivery Ratio (PDR), i.e., the probability that the | as the Packet Delivery Ratio (PDR), i.e., the probability that the | |||
| receiver can decode the packet correctly. It is worth noting that | receiver can decode the packet correctly. It is worth noting that | |||
| this link quality depends on many criteria, such as the level of | this link quality depends on many criteria, such as the level of | |||
| external interference, the presence of concurrent transmissions, or | external interference, the presence of concurrent transmissions, or | |||
| the radio channel state. This link quality is even time-variant. | the radio channel state. This link quality is even time-variant. | |||
| For p2m links, we have consequently a collection of PDR (one value | For p2mp links, consequently, we have a collection of PDR (one value | |||
| per receiver). Other more sophisticated, aggregated metrics exist | per receiver). Other more sophisticated, aggregated metrics exist | |||
| for these p2m links, such as [anycast-property] | for these p2mp links, such as [anycast-property] | |||
| 2.2. Broadcast Transmissions | 2.2. Broadcast Transmissions | |||
| In modern switching networks, the unicast transmission is delivered | The unicast transmission is delivered exclusively to the destination | |||
| uniquely to the destination. Wireless networks are much closer to | in modern switching networks. Wireless networks are much closer to | |||
| the ancient *shared access* networks. Practically, unicast and | the traditional *shared access* networks. Practically, unicast and | |||
| broadcast frames are handled similarly at the physical layer. The | broadcast frames are handled similarly at the physical layer. The | |||
| link layer is just in charge of filtering the frames to discard | link layer is just in charge of filtering the frames to discard | |||
| irrelevant receptions (e.g., different unicast MAC address). | irrelevant receptions (e.g., different unicast MAC addresses). | |||
| However, contrary to wired networks, we cannot be sure that a packet | However, contrary to wired networks, we cannot ensure that a packet | |||
| is received by *all* the devices attached to the Layer 2 segment. It | is received by *all* the devices attached to the Layer 2 segment. It | |||
| depends on the radio channel state between the transmitter(s) and the | depends on the radio channel state between the transmitter(s) and the | |||
| receiver(s). In particular, concurrent transmissions may be possible | receiver(s). In particular, concurrent transmissions may be possible | |||
| or not, depending on the radio conditions (e.g., do the different | or not, depending on the radio conditions (e.g., do the different | |||
| transmitters use a different radio channel or are they sufficiently | transmitters use a different radio channel or are they sufficiently | |||
| spatially separated?) | spatially separated?) | |||
| 2.3. Complex Layer 2 Forwarding | 2.3. Complex Layer 2 Forwarding | |||
| Multiple neighbors may receive a transmission. Thus, anycast Layer 2 | Multiple neighbors may receive a transmission. Thus, anycast Layer 2 | |||
| forwarding helps to maximize the reliability by assigning multiple | forwarding helps to maximize reliability by assigning multiple | |||
| receivers to a single transmission. That way, the packet is lost | receivers to a single transmission. That way, the packet is lost | |||
| only if *none* of the receivers decode it. Practically, it has been | only if *none* of the receivers decode it. Practically, it has been | |||
| proven that different neighbors may exhibit very different radio | proven that different neighbors may exhibit very different radio | |||
| conditions, and that reception independency may hold for some of them | conditions, and that reception independence may hold for some of them | |||
| [anycast-property]. | [anycast-property]. | |||
| 2.4. End-to-end delay | 2.4. End-to-end delay | |||
| In a wireless network, additionnal transmissions opportunities are | In a wireless network, additional transmissions opportunities are | |||
| provisionned to accomodate packet losses. Thus, the end-to-end delay | provisioned to accommodate packet losses. Thus, the end-to-end delay | |||
| consists of: | consists of: | |||
| o Transmission delay, which is fixed and depends mainly on the data | * Transmission delay, which is fixed and depends mainly on the data | |||
| rate, and the presence or absence of an acknowledgement. | rate, and the presence or absence of an acknowledgement. | |||
| o Residence time, corresponds to the buffering delay and depends on | * Residence time, corresponds to the buffering delay and depends on | |||
| the schedule. To account for retransmisisons, the residence time | the schedule. To account for retransmissions, the residence time | |||
| is equal to the difference between the time of last reception from | is equal to the difference between the time of last reception from | |||
| the previous hop (among all the retransmisions) and the time of | the previous hop (among all the retransmissions) and the time of | |||
| emission of the last retransmission. | emission of the last retransmission. | |||
| 3. Operation | 3. Operation | |||
| OAM features will enable RAW with robust operation both for | OAM features will enable RAW with robust operation both for | |||
| forwarding and routing purposes. | forwarding and routing purposes. | |||
| 3.1. Information Collection | 3.1. Information Collection | |||
| The model to exchange information should be the same as for DetNet | The model for exchanging information should be the same as for a | |||
| network, for the sake of inter-operability. YANG may typically | DetNet network to ensure inter-operability. YANG may typically | |||
| fulfill this objective. | fulfill this objective. | |||
| However, RAW networks imply specific constraints (e.g., low | However, RAW networks imply specific constraints (e.g., low | |||
| bandwidth, packet losses, cost of medium access) that may require to | bandwidth, packet losses, cost of medium access) that may require to | |||
| minimize the volume of information to collect. Thus, we discuss in | minimize the volume of information to collect. Thus, we discuss in | |||
| Section 4.2 different ways to collect information, i.e., transfer | Section 4.2 different ways to collect information, i.e., transfer the | |||
| physically the OAM information from the emitter to the receiver. | OAM information physically from the emitter to the receiver. This | |||
| corresponds to passive OAM as defined in [RFC7799] | ||||
| 3.2. Continuity Check | 3.2. Continuity Check | |||
| Similarly to DetNet, we need to verify that the source and the | Similarly to DetNet, we need to verify that the source and the | |||
| destination are connected (at least one valid path exists) | destination are connected (at least one valid path exists) | |||
| 3.3. Connectivity Verification | 3.3. Connectivity Verification | |||
| As in DetNet, we have to verify the absence of misconnection. We | As in DetNet, we have to verify the absence of misconnection. We | |||
| focus here on the RAW specificities. | focus here on the RAW specificities. | |||
| skipping to change at page 9, line 38 ¶ | skipping to change at page 9, line 49 ¶ | |||
| 3.4. Route Tracing | 3.4. Route Tracing | |||
| Wireless networks are broadcast by nature: a radio transmission can | Wireless networks are broadcast by nature: a radio transmission can | |||
| be decoded by any radio neighbor. In multihop wireless networks, | be decoded by any radio neighbor. In multihop wireless networks, | |||
| several paths exist between two endpoints. In hub networks, a device | several paths exist between two endpoints. In hub networks, a device | |||
| may be covered by several Access Points. We should choose the most | may be covered by several Access Points. We should choose the most | |||
| efficient path or AP, concerning specifically the reliability, and | efficient path or AP, concerning specifically the reliability, and | |||
| the delay. | the delay. | |||
| Thus, multipath routing / multi-attachment can be considered to make | Thus, multipath routing / multi-attachment can be viewed as making | |||
| the network fault-tolerant. Even better, we can exploit the | the network more fault-tolerant. Even better, we can exploit the | |||
| broadcast nature of wireless networks to exploit: we may have | broadcast nature of wireless networks: we may have multiple | |||
| multiple Maintenance Intermediate Endpoints (MIP) for each of this | Monitoring Endpoints (MonEP) for each of these kinds of hop. While | |||
| kind of hop. While it may be reasonable in the multi-attachment | it may be reasonable in the multi-attachment case, the complexity | |||
| case, the complexity quickly increases with the path length. Indeed, | quickly increases with the path length. Indeed, each Maintenance | |||
| each Maintenance Intermediate Endpoint has several possible next hops | Intermediate Endpoint has several possible next hops in the | |||
| in the forwarding plane. Thus, all the possible paths between two | forwarding plane. Thus, all the possible paths between two | |||
| maintenance endpoints should be retrieved, which may quickly become | maintenance endpoints should be retrieved, which may quickly become | |||
| intractable if we apply a naive approach. | intractable if we apply a naive approach. | |||
| 3.5. Fault Verification/detection | 3.5. Fault Verification/detection | |||
| Wired networks tend to present stable performances. On the contrary, | Wired networks tend to present stable performances. On the contrary, | |||
| wireless networks are time-variant. We must consequently make a | wireless networks are time-variant. We must consequently make a | |||
| distinction between _normal_ evolutions and malfunction. | distinction between normal evolutions and malfunction. | |||
| 3.6. Fault Isolation/identification | 3.6. Fault Isolation/identification | |||
| The network has isolated and identified the cause of the fault. | The network has isolated and identified the cause of the fault. | |||
| While DetNet already expects to identify malfunctions, some problems | While DetNet already expects to identify malfunctions, some problems | |||
| are specific to wireless networks. We must consequently collect | are specific to wireless networks. We must consequently collect | |||
| metrics and implement algorithms tailored for wireless networking. | metrics and implement algorithms tailored for wireless networking. | |||
| For instance, the decrease in the link quality may be caused by | For instance, the decrease in the link quality may be caused by | |||
| several factors: external interference, obstacles, multipath fading, | several factors: external interference, obstacles, multipath fading, | |||
| mobility. It it fundamental to be able to discriminate the different | mobility. It is fundamental to be able to discriminate the different | |||
| causes to make the right decision. | causes to make the right decision. | |||
| 4. Administration | 4. Administration | |||
| The RAW network has to expose a collection of metrics to support an | The RAW network has to expose a collection of metrics to support an | |||
| operator making proper decisions, including: | operator making proper decisions, including: | |||
| o Packet losses: the time-window average and maximum values of the | * Packet losses: the time-window average and maximum values of the | |||
| number of packet losses have to be measured. Many critical | number of packet losses have to be measured. Many critical | |||
| applications stop to work if a few consecutive packets are | applications stop working if a few consecutive packets are | |||
| dropped; | dropped; | |||
| o Received Signal Strength Indicator (RSSI) is a very common metric | * Received Signal Strength Indicator (RSSI) is a very common metric | |||
| in wireless to denote the link quality. The radio chipset is in | in wireless to denote the link quality. The radio chipset is in | |||
| charge of translating a received signal strength into a normalized | charge of translating a received signal strength into a normalized | |||
| quality indicator; | quality indicator; | |||
| o Delay: the time elapsed between a packet generation / enqueuing | * Delay: the time elapsed between a packet generation / enqueuing | |||
| and its reception by the next hop; | and its reception by the next hop; | |||
| o Buffer occupancy: the number of packets present in the buffer, for | * Buffer occupancy: the number of packets present in the buffer, for | |||
| each of the existing flows. | each of the existing flows. | |||
| o Battery lifetime: the expected remaining battery lifetime of the | * Battery lifetime: the expected remaining battery lifetime of the | |||
| device. Since many RAW devices might be battery powered, this is | device. Since many RAW devices might be battery-powered, this is | |||
| an important metric for an operator to take proper decisions. | an important metric for an operator to make proper decisions. | |||
| o Mobility: if a device is known to be mobile, this might be | * Mobility: if a device is known to be mobile, this might be | |||
| considered by an operator to take proper decisions. | considered by an operator to take proper decisions. | |||
| These metrics should be collected per device, virtual circuit, and | These metrics should be collected per device, virtual circuit, and | |||
| path, as detnet already does. However, we have to face in RAW to a | path, as DetNet already does. However, in RAW, we have to deal with | |||
| finer granularity: | them at a finer granularity: | |||
| o per radio channel to measure, e.g., the level of external | * per radio channel to measure, e.g., the level of external | |||
| interference, and to be able to apply counter-measures (e.g., | interference, and to be able to apply counter-measures (e.g., | |||
| blacklisting). | blacklisting). | |||
| o per physical radio technology / interface if a device has multiple | * per physical radio technology / interface, if a device has | |||
| NIC. | multiple NICs. | |||
| o per link to detect misbehaving link (assymetrical link, | * per link to detect misbehaving link (asymmetrical link, | |||
| fluctuating quality). | fluctuating quality). | |||
| o per resource block: a collision in the schedule is particularly | * per resource block: a collision in the schedule is particularly | |||
| challenging to identify in radio networks with spectrum reuse. In | challenging to identify in radio networks with spectrum reuse. In | |||
| particular, a collision may not be systematic (depending on the | particular, a collision may not be systematic (depending on the | |||
| radio characteristics and the traffic profile). | radio characteristics and the traffic profile). | |||
| 4.1. Worst-case metrics | 4.1. Worst-case metrics | |||
| RAW inherits the same requirements as DetNet: we need to know the | RAW inherits the same requirements as DetNet: we need to know the | |||
| distribution of a collection of metrics. However, wireless networks | distribution of a collection of metrics. However, wireless networks | |||
| are known to be highly variable. Changes may be frequent, and may | are known to be highly variable. Changes may be frequent, and may | |||
| exhibit a periodical pattern. Collecting and analyzing this amount | exhibit a periodical pattern. Collecting and analyzing this amount | |||
| of measurements is challenging. | of measurements is challenging. | |||
| Wireless networks are known to be lossy, and RAW has to implement | Wireless networks are known to be lossy, and RAW has to implement | |||
| strategies to improve reliability on top of unreliable links. | strategies to improve reliability on top of unreliable links. | |||
| Reliability is typically achieved through Automatic Repeat Request | Reliability is typically achieved through Automatic Repeat Request | |||
| (ARQ), and Forward Error Correction (FEC). Since the different flows | (ARQ), and Forward Error Correction (FEC). Since the different flows | |||
| have not the same SLO, RAW must adjust the ARQ and FEC based on the | don't have the same SLO, RAW must adjust the ARQ and FEC based on the | |||
| link and path characteristics. | link and path characteristics. | |||
| 4.2. Efficient data retrieval | 4.2. Efficient measurement retrieval (Passive OAM) | |||
| We have to minimize the number of statistics / measurements to | We have to minimize the number of statistics / measurements to | |||
| exchange: | exchange: | |||
| o energy efficiency: low-power devices have to limit the volume of | * energy efficiency: low-power devices have to limit the volume of | |||
| monitoring information since every bit consumes energy. | monitoring information since every bit consumes energy. | |||
| o bandwidth: wireless networks exhibit a bandwidth significantly | * bandwidth: wireless networks exhibit a bandwidth significantly | |||
| lower than wired, best-effort networks. | lower than wired, best-effort networks. | |||
| o per-packet cost: it is often more expensive to send several | * per-packet cost: it is often more expensive to send several | |||
| packets instead of combining them in a single link-layer frame. | packets instead of combining them in a single link-layer frame. | |||
| In conclusion, we have to take care of power and bandwidth | In conclusion, we have to take care of power and bandwidth | |||
| consumption. The following techniques aim to reduce the cost of such | consumption. The following techniques aim to reduce the cost of such | |||
| maintenance: | maintenance: | |||
| on-path collection: some control information is inserted in the | * on-path collection: some control information is inserted in the | |||
| data packets if they do not fragment the packet (i.e., the MTU is | data packets if they do not fragment the packet (i.e., the MTU is | |||
| not exceeded). Information Elements represent a standardized way | not exceeded). Information Elements represent a standardized way | |||
| to handle such information. IP hop by hop extension headers may | to handle such information. IP hop by hop extension headers may | |||
| help to collect metrics all along the path; | help to collect metrics all along the path; | |||
| flags/fields: we have to set-up flags in the packets to monitor to | * flags/fields: we have to set-up flags in the packets to monitor to | |||
| be able to monitor the forwarding process accurately. A sequence | be able to monitor the forwarding process accurately. A sequence | |||
| number field may help to detect packet losses. Similarly, path | number field may help to detect packet losses. Similarly, path | |||
| inference tools such as [ipath] insert additional information in | inference tools such as [ipath] insert additional information in | |||
| the headers to identify the path followed by a packet a | the headers to identify the path followed by a packet a | |||
| posteriori. | posteriori. | |||
| hierarchical monitoring: localized and centralized mechanisms have | * hierarchical monitoring: localized and centralized mechanisms have | |||
| to be combined together. Typically, a local mechanism should | to be combined together. Typically, a local mechanism should | |||
| contiuously monitor a set of metrics and trigger distant OAM | continuously monitor a set of metrics and trigger remote OAM | |||
| exchances only when a fault is detected (but possibly not | exchanges only when a fault is detected (but possibly not | |||
| identified). For instance, local temporary defects must not | identified). For instance, local temporary defects must not | |||
| trigger expensive OAM transmissions. Besides, the wireless | trigger expensive OAM transmissions. Besides, the wireless | |||
| segments represent often the weakest parts of a path: the volume | segments often represent the weakest parts of a path: the volume | |||
| of control information they produce has to be fixed accordingly. | of control information they produce has to be fixed accordingly. | |||
| 4.3. Reporting OAM packets to the source | Several passive techniques can be combined. For instance, the DetNet | |||
| forwarding sublayer MAY combine In-band Network Telemetry (INT) with | ||||
| P4, iOAM and iPath to compute and report different statistics in the | ||||
| track (e.g., number of link-layer retransmissions, link reliability). | ||||
| TODO: statistics are collected when a packet goes from the source to | 4.3. Reporting OAM packets to the source (Active OAM) | |||
| the destination. However, it has to be also reported by the source. | ||||
| Problem: resource may not be reserved bidirectionnaly. Even worse: | ||||
| the inverse path may not exist. | ||||
| Reporting everything exhaustively to the source may in most cases too | The Test EndPoint will collect measurements from the OAM probes | |||
| exensive. Thus, devices may take local decisions when possible, and | received in the monitored track. However, the aggregated statistics | |||
| receive end-to-end information when possible. | must then be reported to the other Test Endpoint that injected the | |||
| probes. Unfortunately, the monitored track MAY be unidirectional. | ||||
| In this case, the statistics have to be reported out-of-band | ||||
| (through, e.g., a dedicated control or management channel). | ||||
| It is worth noting that Active OAM and Passive OAM techniques are not | ||||
| mutually exclusive. In particular, Active OAM is useful when a | ||||
| statistic cannot be acquired accurately passively. | ||||
| 5. Maintenance | 5. Maintenance | |||
| Maintenance needs to facilitate the maintenance (repairs and | Maintenance needs to facilitate the maintenance (repairs and | |||
| upgrades). In wireless networks, repairs are expected to occur much | upgrades). In wireless networks, repairs are expected to occur much | |||
| more frequently, since the link quality may be highly time-variant. | more frequently, since the link quality may be highly time-variant. | |||
| Thus, maintenance represents a key feature for RAW. | Thus, maintenance represents a key feature for RAW. | |||
| 5.1. Soft transition after reconfiguration | 5.1. Soft transition after reconfiguration | |||
| skipping to change at page 13, line 21 ¶ | skipping to change at page 13, line 32 ¶ | |||
| make a distinction between a metric that changed because of a legal | make a distinction between a metric that changed because of a legal | |||
| network change (e.g., flow redirection) and an unexpected event | network change (e.g., flow redirection) and an unexpected event | |||
| (e.g., a fault). | (e.g., a fault). | |||
| 5.2. Predictive maintenance | 5.2. Predictive maintenance | |||
| RAW needs to implement self-optimization features. While the network | RAW needs to implement self-optimization features. While the network | |||
| is configured to be fault-tolerant, a reconfiguration may be required | is configured to be fault-tolerant, a reconfiguration may be required | |||
| to keep on respecting long-term objectives. Obviously, the network | to keep on respecting long-term objectives. Obviously, the network | |||
| keeps on respecting the SLO after a node's crash, but a | keeps on respecting the SLO after a node's crash, but a | |||
| reconfiguration is required to handle the future faults. In other | reconfiguration is required to handle future faults. In other words, | |||
| words, the reconfiguration delay MUST be strictly smaller than the | the reconfiguration delay MUST be strictly smaller than the inter- | |||
| inter-fault time. | fault time. | |||
| The network must continuously retrieve the state of the network, to | The network must continuously retrieve the state of the network, to | |||
| judge about the relevance of a reconfiguration, quantifying: | judge about the relevance of a reconfiguration, quantifying: | |||
| the cost of the sub-optimality: resources may not be used | * the cost of the sub-optimality: resources may not be used | |||
| optimally (e.g., a better path exists); | optimally (e.g., a better path exists); | |||
| the reconfiguration cost: the controller needs to trigger some | * the reconfiguration cost: the controller needs to trigger some | |||
| reconfigurations. For this transient period, resources may be | reconfigurations. For this transient period, resources may be | |||
| twice reserved, and control packets have to be transmitted. | twice reserved, and control packets have to be transmitted. | |||
| Thus, reconfiguration may only be triggered if the gain is | Thus, reconfiguration may only be triggered if the gain is | |||
| significant. | significant. | |||
| 6. IANA Considerations | 6. Requirements | |||
| This section lists requirements for OAM in a RAW domain: | ||||
| 1. Each Test and Monitoring Endpoint device MUST expose a list of | ||||
| available metrics per track. It MUST at least provide the end- | ||||
| to-end Packet Delivery Ratio, end-to-end latency, and Maximum | ||||
| Consecutive Failures (MCF). | ||||
| 2. PREOF functions MUST guarantee order preservation in the | ||||
| (sub)track. | ||||
| 3. OAM nodes MUST provide aggregated statistics to reduce the volume | ||||
| of traffic for measurements. They MAY send a compressed | ||||
| distribution of measurements, or MIN / MAX values over a time | ||||
| interval. | ||||
| 4. Monitoring Endpoints SHOULD support route tracing with passive | ||||
| OAM techniques. | ||||
| 7. IANA Considerations | ||||
| This document has no actionable requirements for IANA. This section | This document has no actionable requirements for IANA. This section | |||
| can be removed before the publication. | can be removed before the publication. | |||
| 7. Security Considerations | 8. Security Considerations | |||
| This section will be expanded in future versions of the draft. | This section will be expanded in future versions of the draft. | |||
| 8. Acknowledgments | 9. Acknowledgments | |||
| TBD | TBD | |||
| 9. Informative References | 10. Informative References | |||
| [anycast-property] | [anycast-property] | |||
| Teles Hermeto, R., Gallais, A., and F. Theoleyre, "Is | Teles Hermeto, R., Gallais, A., and F. Theoleyre, "Is | |||
| Link-Layer Anycast Scheduling Relevant for IEEE | Link-Layer Anycast Scheduling Relevant for IEEE | |||
| 802.15.4-TSCH Networks?", 2019, | 802.15.4-TSCH Networks?", 2019, | |||
| <https://doi.org/10.1109/LCNSymposium47956.2019.9000679>. | <https://doi.org/10.1109/LCNSymposium47956.2019.9000679>. | |||
| [detnet-oam] | [I-D.ietf-detnet-oam-framework] | |||
| Theoleyre, F., Papadopoulos, G. Z., Mirsky, G., and C. J. | Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos, | |||
| Bernardos, "Operations, Administration and Maintenance | C. J., Varga, B., and J. Farkas, "Framework of Operations, | |||
| (OAM) features for detnet", 2020, | Administration and Maintenance (OAM) for Deterministic | |||
| <https://tools.ietf.org/html/draft-theoleyre-detnet-oam- | Networking (DetNet)", Work in Progress, Internet-Draft, | |||
| support>. | draft-ietf-detnet-oam-framework-05, 14 October 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-detnet- | ||||
| oam-framework-05>. | ||||
| [I-D.pthubert-raw-architecture] | [I-D.pthubert-raw-architecture] | |||
| Thubert, P., Papadopoulos, G. Z., and R. Buddenberg, | Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable | |||
| "Reliable and Available Wireless Architecture/Framework", | and Available Wireless Architecture/Framework", Work in | |||
| draft-pthubert-raw-architecture-05 (work in progress), | Progress, Internet-Draft, draft-pthubert-raw-architecture- | |||
| November 2020. | 09, 7 July 2021, <https://datatracker.ietf.org/doc/html/ | |||
| draft-pthubert-raw-architecture-09>. | ||||
| [I-D.thubert-bier-replication-elimination] | ||||
| Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- | ||||
| TE extensions for Packet Replication and Elimination | ||||
| Function (PREF) and OAM", Work in Progress, Internet- | ||||
| Draft, draft-thubert-bier-replication-elimination-03, 3 | ||||
| March 2018, <https://datatracker.ietf.org/doc/html/draft- | ||||
| thubert-bier-replication-elimination-03>. | ||||
| [ipath] Gao, Y., Dong, W., Chen, C., Bu, J., Wu, W., and X. Liu, | [ipath] Gao, Y., Dong, W., Chen, C., Bu, J., Wu, W., and X. Liu, | |||
| "iPath: path inference in wireless sensor networks.", | "iPath: path inference in wireless sensor networks.", | |||
| 2016, <https://doi.org/10.1109/TNET.2014.2371459>. | 2016, <https://doi.org/10.1109/TNET.2014.2371459>. | |||
| [PREF-draft] | ||||
| Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- | ||||
| TE extensions for Packet Replication and Elimination | ||||
| Function (PREF) and OAM", 2018, | ||||
| <https://tools.ietf.org/html/draft-thubert-bier- | ||||
| replication-elimination>. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for | [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for | |||
| Network Interconnect Devices", RFC 2544, | Network Interconnect Devices", RFC 2544, | |||
| DOI 10.17487/RFC2544, March 1999, | DOI 10.17487/RFC2544, March 1999, | |||
| <https://www.rfc-editor.org/info/rfc2544>. | <https://www.rfc-editor.org/info/rfc2544>. | |||
| skipping to change at page 15, line 30 ¶ | skipping to change at page 16, line 16 ¶ | |||
| "Deterministic Networking Architecture", RFC 8655, | "Deterministic Networking Architecture", RFC 8655, | |||
| DOI 10.17487/RFC8655, October 2019, | DOI 10.17487/RFC8655, October 2019, | |||
| <https://www.rfc-editor.org/info/rfc8655>. | <https://www.rfc-editor.org/info/rfc8655>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Fabrice Theoleyre | Fabrice Theoleyre | |||
| CNRS | CNRS | |||
| Building B | Building B | |||
| 300 boulevard Sebastien Brant - CS 10413 | 300 boulevard Sebastien Brant - CS 10413 | |||
| Illkirch - Strasbourg 67400 | 67400 Illkirch - Strasbourg | |||
| FRANCE | France | |||
| Phone: +33 368 85 45 33 | Phone: +33 368 85 45 33 | |||
| Email: theoleyre@unistra.fr | Email: fabrice.theoleyre@cnrs.fr | |||
| URI: http://www.theoleyre.eu | URI: http://www.theoleyre.eu | |||
| Georgios Z. Papadopoulos | Georgios Z. Papadopoulos | |||
| IMT Atlantique | IMT Atlantique | |||
| Office B00 - 102A | Office B00 - 102A | |||
| 2 Rue de la Chataigneraie | 2 Rue de la Chataigneraie | |||
| Cesson-Sevigne - Rennes 35510 | 35510 Cesson-Sevigne - Rennes | |||
| FRANCE | France | |||
| Phone: +33 299 12 70 04 | Phone: +33 299 12 70 04 | |||
| Email: georgios.papadopoulos@imt-atlantique.fr | Email: georgios.papadopoulos@imt-atlantique.fr | |||
| Greg Mirsky | Greg Mirsky | |||
| ZTE Corp. | Ericsson | |||
| Email: gregimirsky@gmail.com | ||||
| Email: gregory.mirsky@ztetx.com | ||||
| Carlos J. Bernardos | Carlos J. Bernardos | |||
| Universidad Carlos III de Madrid | Universidad Carlos III de Madrid | |||
| Av. Universidad, 30 | Av. Universidad, 30 | |||
| Leganes, Madrid 28911 | 28911 Leganes, Madrid | |||
| Spain | Spain | |||
| Phone: +34 91624 6236 | Phone: +34 91624 6236 | |||
| Email: cjbc@it.uc3m.es | Email: cjbc@it.uc3m.es | |||
| URI: http://www.it.uc3m.es/cjbc/ | URI: http://www.it.uc3m.es/cjbc/ | |||
| End of changes. 102 change blocks. | ||||
| 189 lines changed or deleted | 224 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||