| rfc9551.original.xml | rfc9551.xml | |||
|---|---|---|---|---|
| <?xml version="1.0" encoding="utf-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
| <!-- xml2rfc v2v3 conversion 3.6.0 --> | ||||
| <!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
| <!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
| <!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
| <!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
| <!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
| ]> | ]> | |||
| <?rfc toc="yes"?> | ||||
| <?rfc tocompact="yes"?> | ||||
| <?rfc tocdepth="3"?> | ||||
| <?rfc tocindent="yes"?> | ||||
| <?rfc symrefs="yes"?> | ||||
| <?rfc sortrefs="yes"?> | ||||
| <?rfc comments="yes"?> | ||||
| <?rfc inline="yes"?> | ||||
| <?rfc compact="no"?> | ||||
| <?rfc subcompact="no"?> | ||||
| <?rfc authorship="yes"?> | ||||
| <?rfc tocappendix="yes"?> | ||||
| <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902 | ||||
| " docName="draft-ietf-detnet-oam-framework-11" obsoletes="" updates="" submissio | ||||
| nType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRef | ||||
| s="true" version="3"> | ||||
| <!-- xml2rfc v2v3 conversion 3.6.0 --> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" | |||
| category="info" | ||||
| ipr="trust200902" | ||||
| docName="draft-ietf-detnet-oam-framework-11" | ||||
| number="9551" | ||||
| consensus="true" | ||||
| obsoletes="" | ||||
| updates="" | ||||
| submissionType="IETF" | ||||
| xml:lang="en" | ||||
| tocInclude="true" | ||||
| tocDepth="3" | ||||
| symRefs="true" | ||||
| sortRefs="true" | ||||
| version="3"> | ||||
| <front> | <front> | |||
| <title abbrev="Framework of OAM for DetNet">Framework of Operations, Adminis | <title abbrev="Framework of OAM for DetNet">Framework of Operations, Adminis | |||
| tration and Maintenance (OAM) for Deterministic Networking (DetNet)</title> | tration, and Maintenance (OAM) for Deterministic Networking (DetNet)</title> | |||
| <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-oam-framework-11" | <seriesInfo name="RFC" value="9551"/> | |||
| /> | ||||
| <author initials="G." surname="Mirsky" fullname="Greg Mirsky"> | <author initials="G." surname="Mirsky" fullname="Greg Mirsky"> | |||
| <organization>Ericsson</organization> | <organization>Ericsson</organization> | |||
| <address> | <address> | |||
| <email>gregimirsky@gmail.com</email> | <email>gregimirsky@gmail.com</email> | |||
| </address> | </address> | |||
| </author> | </author> | |||
| <author initials="F." surname="Theoleyre" fullname="Fabrice Theoleyre"> | <author initials="F." surname="Theoleyre" fullname="Fabrice Theoleyre"> | |||
| <organization>CNRS</organization> | <organization>CNRS</organization> | |||
| <address> | <address> | |||
| <postal> | <postal> | |||
| <extaddr>ICube Lab, Pole API</extaddr> | ||||
| <street>300 boulevard Sebastien Brant - CS 10413</street> | <street>300 boulevard Sebastien Brant - CS 10413</street> | |||
| <city>Illkirch - Strasbourg</city> | <city>Illkirch - Strasbourg</city> | |||
| <code>67400</code> | <code>67400</code> | |||
| <country>FRANCE</country> | <country>France</country> | |||
| </postal> | </postal> | |||
| <phone>+33 368 85 45 33</phone> | <phone>+33 368 85 45 33</phone> | |||
| <email>fabrice.theoleyre@cnrs.fr</email> | <email>fabrice.theoleyre@cnrs.fr</email> | |||
| <uri>https://fabrice.theoleyre.cnrs.fr/</uri> | <uri>https://fabrice.theoleyre.cnrs.fr/</uri> | |||
| </address> | </address> | |||
| </author> | </author> | |||
| <author initials="G.Z." surname="Papadopoulos" fullname="Georgios Z. Papadop | ||||
| oulos"> | <author initials="G." surname="Papadopoulos" fullname="Georgios Papadopoulos | |||
| "> | ||||
| <organization>IMT Atlantique</organization> | <organization>IMT Atlantique</organization> | |||
| <address> | <address> | |||
| <postal> | <postal> | |||
| <street>Office B00 - 102A</street> | <street>Office B00 - 102A</street> | |||
| <street>2 Rue de la Châtaigneraie</street> | <street>2 Rue de la Châtaigneraie</street> | |||
| <city>Cesson-Sévigné - Rennes</city> | <city>Cesson-Sévigné - Rennes</city> | |||
| <code>35510</code> | <code>35510</code> | |||
| <country>FRANCE</country> | <country>France</country> | |||
| </postal> | </postal> | |||
| <phone>+33 299 12 70 04</phone> | <phone>+33 299 12 70 04</phone> | |||
| <email>georgios.papadopoulos@imt-atlantique.fr</email> | <email>georgios.papadopoulos@imt-atlantique.fr</email> | |||
| </address> | </address> | |||
| </author> | </author> | |||
| <author initials="CJ." surname="Bernardos" fullname="Carlos J. Bernardos"> | <author initials="CJ." surname="Bernardos" fullname="Carlos J. Bernardos"> | |||
| <organization abbrev="UC3M"> | <organization abbrev="UC3M"> | |||
| Universidad Carlos III de Madrid | Universidad Carlos III de Madrid | |||
| </organization> | </organization> | |||
| <address> | <address> | |||
| skipping to change at line 104 ¶ | skipping to change at line 111 ¶ | |||
| <postal> | <postal> | |||
| <street>Magyar Tudosok krt. 11.</street> | <street>Magyar Tudosok krt. 11.</street> | |||
| <city>Budapest</city> | <city>Budapest</city> | |||
| <country>Hungary</country> | <country>Hungary</country> | |||
| <code>1117</code> | <code>1117</code> | |||
| </postal> | </postal> | |||
| <email>janos.farkas@ericsson.com</email> | <email>janos.farkas@ericsson.com</email> | |||
| </address> | </address> | |||
| </author> | </author> | |||
| <date/> | <date year="2024" month="March"/> | |||
| <area>RTG</area> | ||||
| <workgroup>DetNet</workgroup> | <workgroup>DetNet</workgroup> | |||
| <abstract> | <abstract> | |||
| <t> | <t>Deterministic Networking (DetNet), as defined in RFC 8655, aims to | |||
| Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide b | provide bounded end-to-end latency on top of the network infrastructure, | |||
| ounded end-to-end latency | comprising both Layer 2 bridged and Layer 3 routed segments. This | |||
| on top of the network infrastructure, comprising both Layer 2 bridged an | document's primary purpose is to detail the specific requirements of the | |||
| d Layer 3 routed segments. | Operations, Administration, and Maintenance (OAM) recommended to maintain | |||
| This document's primary purpose is to detail the specific requirements of the Op | a deterministic network. The document will be used in future work that | |||
| eration, Administration, and Maintenance (OAM) recommended to maintain a | defines the applicability of and extension of OAM protocols for a | |||
| deterministic network. The document will be used in future work that defines | deterministic network. With the implementation of the OAM framework in | |||
| the applicability of and extension of OAM protocols for a deterministic network. | DetNet, an operator will have a real-time view of the network | |||
| With the implementation of the OAM framework in DetNet, an operator will have | infrastructure regarding the network's ability to respect the Service | |||
| a real-time | Level Objective (SLO), such as packet delay, delay variation, and packet-l | |||
| view of the network infrastructure regarding the network's ability to res | oss | |||
| pect the Service Level | ratio, assigned to each DetNet flow. | |||
| Objective, such as packet delay, delay variation, and packet loss rati | ||||
| o, assigned to each DetNet flow. | ||||
| </t> | </t> | |||
| </abstract> | </abstract> | |||
| </front> | </front> | |||
| <middle> | <middle> | |||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Introduction</name> | <name>Introduction</name> | |||
| <t> | <t> | |||
| Deterministic Networking (DetNet) <xref target="RFC8655" format="default "/> has proposed to provide a bounded end-to-end latency | Deterministic Networking (DetNet) <xref target="RFC8655" format="default "/> has proposed to provide a bounded end-to-end latency | |||
| on top of the network infrastructure, comprising both Layer 2 bridged an d Layer 3 routed segments. | on top of the network infrastructure, comprising both Layer 2 bridged an d Layer 3 routed segments. | |||
| That work encompasses the data plane, OAM, time synchronization, managem ent, control, and security aspects. | That work encompasses the data plane, OAM, time synchronization, managem ent, control, and security aspects. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| Operations, Administration, and Maintenance (OAM) Tools are of primary i mportance | Operations, Administration, and Maintenance (OAM) tools are of primary i mportance | |||
| for IP networks <xref target="RFC7276" format="default"/>. | for IP networks <xref target="RFC7276" format="default"/>. | |||
| DetNet OAM should provide a toolset for fault detection, localization, a nd performance measurement. | DetNet OAM should provide a toolset for fault detection, localization, a nd performance measurement. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| This document's primary purpose is to detail the specific requirements o f the OAM features recommended to maintain a | This document's primary purpose is to detail the specific requirements o f the OAM features recommended to maintain a | |||
| deterministic/reliable network. | deterministic/reliable network. Specifically, it investigates the requir | |||
| Specifically, it investigates the requirements for a deterministic netwo | ements for a deterministic | |||
| rk, supporting critical flows. | network that supports critical flows. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| In this document, the term OAM will be used according to its definition s | In this document, the term "OAM" will be used according to its definition | |||
| pecified | specified | |||
| in <xref target="RFC6291" format="default"/>. | in <xref target="RFC6291" format="default"/>. DetNet is expected to imple | |||
| DetNet expects to implement an OAM framework to maintain a real-time | ment an OAM framework to maintain a real-time | |||
| view of the network infrastructure, and its ability to respect the Servic e Level | view of the network infrastructure, and its ability to respect the Servic e Level | |||
| Objectives (SLOs), such as in-order packet delivery, packet delay, del | Objectives (SLOs), such as in-order packet delivery, packet delay, del | |||
| ay variation, and packet loss ratio, assigned to each DetNet flow. | ay variation, and packet-loss ratio, assigned to each DetNet flow. | |||
| </t> | ||||
| <t> | ||||
| This document lists the functional requirements toward OAM for a DetNet doma | ||||
| in. | ||||
| The list can further be used for gap analysis of available OAM tools to ident | ||||
| ify | ||||
| possible enhancements of existing or whether new OAM tools are required to | ||||
| support proactive and on-demand path monitoring and service validation. | ||||
| </t> | </t> | |||
| <t>This document lists the OAM functional requirements for a DetNet domain | ||||
| . | ||||
| The list can further be used for gap analysis of available OAM tools to iden | ||||
| tify:</t> | ||||
| <ul><li>possible enhancements of existing tools, or</li> | ||||
| <li>whether new OAM tools are required to | ||||
| support proactive and on-demand path monitoring and service validation.</li>< | ||||
| /ul> | ||||
| <section anchor="define-sec" numbered="true" toc="default"> | <section anchor="define-sec" numbered="true" toc="default"> | |||
| <name>Definitions</name> | <name>Definitions</name> | |||
| <t> | <t> | |||
| This document uses definitions, particularly of a DetNet flow, provi ded in Section 2.1 of <xref target="RFC8655"/>. | This document uses definitions, particularly of a DetNet flow, provi ded in <xref target="RFC8655" sectionFormat="of" section="2.1"/>. | |||
| The following terms are used throughout this document as defined bel ow: | The following terms are used throughout this document as defined bel ow: | |||
| </t> | </t> | |||
| <ul spacing="normal"> | <dl spacing="normal"> | |||
| <li> | <dt> | |||
| DetNet OAM domain: a DetNet network used by the monitored De | DetNet OAM domain:</dt><dd>a DetNet network used by the moni | |||
| tNet flow. A DetNet OAM domain | tored DetNet flow. A DetNet OAM domain | |||
| (also referred to in this document as "OAM domain") may have | (also referred to in this document as "OAM domain") may have | |||
| MEPs on its edge and MIPs within. | Maintenance End Points (MEPs) on its edge and Maintenance Intermediate Points ( | |||
| </li> | MIPs) within. | |||
| <li> | </dd> | |||
| DetNet OAM instance: a function that monitors a DetNet flow | ||||
| for defects and/or measures its performance metrics. Within this document, | <dt>DetNet OAM instance:</dt><dd>a function that monitors a | |||
| a shorter version, OAM instance, is used interchangeably. | DetNet flow for defects and/or measures its performance metrics. Within this doc | |||
| </li> | ument, | |||
| <li> | the shorter version "OAM instance" is used interchangeably. | |||
| Maintenance End Point (MEP): an OAM instance that is capable | </dd> | |||
| of generating OAM test packets | ||||
| <dt>Maintenance End Point (MEP):</dt><dd>an OAM instance that | ||||
| is capable of generating OAM test packets | ||||
| in the particular sub-layer of the DetNet OAM domain. | in the particular sub-layer of the DetNet OAM domain. | |||
| </li> | </dd> | |||
| <li> | ||||
| Maintenance Intermediate Point (MIP): an OAM instance along t | <dt>Maintenance Intermediate Point (MIP):</dt><dd>an OAM inst | |||
| he DetNet flow in the particular sub-layer of the DetNet OAM domain. | ance along the DetNet flow in the particular sub-layer of the DetNet OAM domain | |||
| An active MIP MUST respond to an OAM message generated by the MEP at its sub-lay | . | |||
| er of the same DetNet OAM domain. | An active MIP <bcp14>MUST</bcp14> respond to an OAM message generated by the MEP | |||
| </li> | at its sub-layer of the same DetNet OAM domain. | |||
| <li> | </dd> | |||
| Control and management plane: the control and management planes a | <dt>Control and management plane:</dt><dd>the control and management p | |||
| re used to configure and control the network. | lanes are used to configure and control the network. | |||
| Relative to a DetNet flow, the control and/or management plane ca | Relative to a DetNet flow, the control and/or management plane ca | |||
| n be out-of-band. | n be out of band. | |||
| </li> | </dd> | |||
| <li> | <dt>Active measurement methods:</dt><dd>(as defined in <xref target="R | |||
| Active measurement methods (as defined in <xref target="RFC7799" | FC7799" format="default"/>) | |||
| format="default"/>) | these methods modify a DetNet flow by injecting specially cons | |||
| modify a DetNet flow by injecting specially constructed test p | tructed test packets <xref target="RFC2544" format="default"/>. | |||
| ackets <xref target="RFC2544" format="default"/>). | </dd> | |||
| </li> | <dt>Passive measurement methods:</dt> <dd>(as defined in <xref target= | |||
| <li>Passive measurement methods <xref target="RFC7799" format="default | "RFC7799" format="default"/>) these methods infer information by observing unmod | |||
| "/> infer information by observing unmodified existing flows.</li> | ified existing flows.</dd> | |||
| <li>Hybrid measurement methods <xref target="RFC7799" format="default" | <dt>Hybrid measurement methods:</dt><dd>(as defined in <xref target="R | |||
| /> is the combination of elements of both active and passive measurement methods | FC7799" format="default"/>) the combination of elements of both active and passi | |||
| .</li> | ve measurement methods.</dd> | |||
| <li> | <dt>In-band OAM:</dt><dd>an active OAM method that is in band within t | |||
| In-band OAM is an active OAM that is in-band within the monitored | he monitored | |||
| DetNet OAM domain when it traverses the same set of links and interfaces | DetNet OAM domain when it traverses the same set of links and | |||
| receiving the same QoS and Packet Replication, Elimination, and Ordering F | interfaces receiving the same QoS and Packet Replication, | |||
| unctions | Elimination, and Ordering Functions (PREOF) treatment as the | |||
| (PREOF) treatment as the monitored DetNet flow. | monitored DetNet flow.</dd> | |||
| </li> | <dt>Out-of-band OAM:</dt><dd>an active OAM method whose path through the DetNet | |||
| <li> | domain may not be topologically identical to the | |||
| Out-of-band OAM is an active OAM whose path through the DetNet domain is not | path of the monitored DetNet flow, its test packets may receive different QoS | |||
| topologically identical to the | and/or PREOF treatment, or both. | |||
| path of the monitored DetNet flow, or its test packets receive different QoS | </dd> | |||
| and/or PREOF treatment, or both. | <dt>On-path telemetry:</dt><dd>on-path telemetry can be realized as a hybr | |||
| </li> | id OAM method. The origination of the telemetry information | |||
| <li> | is inherently in band as packets in a DetNet flow are used as triggers. Co | |||
| On-path telemetry can be realized as a hybrid OAM method. The origination | llection of the on-path telemetry information | |||
| of the telemetry information | ||||
| is inherently in-band as packets in a DetNet flow are used as triggers. Co | ||||
| llection of the on-path telemetry information | ||||
| can be performed using in-band or out-of-band OAM methods. | can be performed using in-band or out-of-band OAM methods. | |||
| </li> | </dd> | |||
| </ul> | </dl> | |||
| </section> | </section> | |||
| <section anchor="acronyms-sec" numbered="true" toc="default"> | ||||
| <name>Abbreviations</name> | ||||
| <t>OAM: Operations, Administration, and Maintenance</t | ||||
| > | ||||
| <t>DetNet: Deterministic Networking</t> | ||||
| <t>PREOF: Packet Replication, Elimination and Ordering Func | ||||
| tions</t> | ||||
| <t>SLO: Service Level Objective</t> | ||||
| </section> | ||||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Requirements Language</name> | <name>Requirements Language</name> | |||
| <t> | <t> | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | |||
| NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", | "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14> | |||
| "MAY", and "OPTIONAL" in this document are to be interpreted as | ", | |||
| described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="R | "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", | |||
| FC8174" format="default"/> | "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
| when, and only when, they appear in all capitals, as shown here. | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | |||
| The requirements language is used in <xref target="define-sec"/>, <xref targe | be | |||
| t="req-list"/>, | interpreted as described in BCP 14 <xref target="RFC2119"/> <xref | |||
| target="RFC8174"/> when, and only when, they appear in all capitals, as | ||||
| shown here. | ||||
| The requirements language is used in Sections <xref target="define-sec" forma | ||||
| t="counter"/> and <xref target="req-list" format="counter"/>, | ||||
| and applies to the implementations of DetNet OAM. | and applies to the implementations of DetNet OAM. | |||
| </t> | </t> | |||
| </section> | </section> | |||
| </section> | </section> | |||
| <!-- INTEREST OF OAM --> | ||||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Role of OAM in DetNet</name> | <name>Role of OAM in DetNet</name> | |||
| <t> | <t> | |||
| DetNet networks expect to provide communications with predictable low | DetNet networks are expected to provide communications with predictable l | |||
| packet delay, packet loss, and packet misordering. Most critical applications wi | ow packet delay, packet loss, and packet misordering. Most critical application | |||
| ll define | s will define | |||
| a set of SLOs to be required for the DetNet flows it generates. | a set of SLOs to be required for the DetNet flows they generate. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| To respect strict guarantees, DetNet can use an orchestrator able to | To respect strict guarantees, DetNet can use an orchestrator able to | |||
| monitor and maintain the network. Typically, a Software-Defined | monitor and maintain the network. Typically, a Software-Defined | |||
| Network controller places DetNet flows in the deployed network | Network (SDN) controller places DetNet flows in the deployed network | |||
| based on their SLOs. Thus, resources have to be provisioned a | based on their SLOs. Thus, resources have to be provisioned a | |||
| priori for the regular operation of the network. | priori for the regular operation of the network. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| Most of the existing OAM tools can be used in DetNet networks, | Most of the existing OAM tools can be used in DetNet networks, | |||
| but they can only cover some aspects of deterministic networking. | but they can only cover some aspects of deterministic networking. | |||
| Fulfilling strict guarantees is essential for DetNet flows, | Fulfilling strict guarantees is essential for DetNet flows, | |||
| resulting in new DetNet-specific functionalities that must be covered with OAM. | resulting in new DetNet-specific functionalities that must be covered with OAM. | |||
| Filling these gaps is inevitable and needs accurate consideration of | Filling these gaps is inevitable and needs accurate consideration of | |||
| DetNet specifics. Similar to DetNet flows, their OAM also needs careful | DetNet specifics. Similar to DetNet flows, their OAM also needs careful | |||
| end-to-end engineering. | end-to-end engineering. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| For example, appropriate placing of MEPs along the path of a DetNet flow is | For example, appropriate placing of MEPs along the path of a DetNet flow is | |||
| not always a trivial task and may require proper design, together with the | not always a trivial task and may require proper design together with the | |||
| design of the service component of a given DetNet flow. | design of the service component of a given DetNet flow. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| There are several DetNet-specific challenges for OAM. Bounded network | There are several DetNet-specific challenges for OAM. Bounded network | |||
| characteristics (e.g., delay, loss) are inseparable service parameters; | characteristics (e.g., delay, loss) are inseparable service parameters; | |||
| therefore, Performance Monitoring OAM is a key topic for DetNet. OAM tools are n eeded to monitor each | therefore, Performance Monitoring (PM) OAM is a key topic for DetNet. OAM tools are needed to monitor each | |||
| SLO without impacting the DetNet flow characteristics. A further challenge | SLO without impacting the DetNet flow characteristics. A further challenge | |||
| is strict resource allocation. Resources used by OAM must be considered | is strict resource allocation. Resources used by OAM must be considered | |||
| and allocated to avoid disturbing DetNet flows. | and allocated to avoid disturbing DetNet flows. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| The DetNet Working Group has defined two sub-layers: | The DetNet Working Group has defined two sub-layers: | |||
| </t> | </t> | |||
| <ul empty="true" spacing="normal"> | <ul empty="true" spacing="normal"> | |||
| <li> | <li> | |||
| DetNet service sub-layer, at which a DetNet service (e.g., service | The DetNet service sub-layer at which a DetNet service (e.g., service | |||
| protection) is provided. | protection) is provided. | |||
| </li> | </li> | |||
| <li> | <li> | |||
| DetNet forwarding sub-layer, which | The DetNet forwarding sub-layer, which | |||
| optionally provides resource allocation for DetNet flows over paths | optionally provides resource allocation for DetNet flows over paths | |||
| provided by the underlying network. | provided by the underlying network. | |||
| </li> | </li> | |||
| </ul> | </ul> | |||
| <t> | <t> | |||
| OAM mechanisms exist for the | OAM mechanisms exist for the | |||
| DetNet forwarding sub-layer, but the service | DetNet forwarding sub-layer, but the service | |||
| sub-layer requires new OAM procedures. These new OAM functions | sub-layer requires new OAM procedures. These new OAM functions | |||
| must allow, for example, to recognize/discover DetNet relay | must allow, for example, recognizing/discovering DetNet relay | |||
| nodes, to get information about their configuration, and to | nodes, getting information about their configuration, and | |||
| check their operation or status. | checking their operation or status. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| DetNet service sub-layer functions use a sequence number for PREOF. That creates | DetNet service sub-layer functions use a sequence number for PREOF, which create s | |||
| a challenge for inserting OAM packets in the DetNet flow. | a challenge for inserting OAM packets in the DetNet flow. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| Fault tolerance also assumes that multiple paths could be provisioned | Fault tolerance also assumes that multiple paths could be provisioned | |||
| to maintain an end-to-end circuit by adapting to the existing conditions. | to maintain an end-to-end circuit by adapting to the existing conditions. | |||
| The DetNet Controller Plane, e.g., central controller/orchestrator, controls the PREOF on a node. OAM is expected to support monitoring and | The DetNet Controller Plane, e.g., central controller/orchestrator, controls the PREOF on a node. OAM is expected to support monitoring and | |||
| troubleshooting PREOF on a particular node and within the domain. | troubleshooting PREOF on a particular node and within the domain. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| Note that a distributed architecture of the DetNet Control Plane can also contro l PREOF | Note that a distributed architecture of the DetNet Control Plane can also contro l PREOF | |||
| in those scenarios where DetNet solutions involve more than one single central c ontroller. | in those scenarios where DetNet solutions involve more than one single central c ontroller. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| The DetNet forwarding sub-layer is based on preexisting technologies and has | The DetNet forwarding sub-layer is based on preexisting technologies and has | |||
| much better coverage regarding OAM. However, the forwarding sub-layer | much better coverage regarding OAM. However, the forwarding sub-layer | |||
| is terminated at DetNet relay nodes, so the end-to-end OAM state of forwarding | is terminated at DetNet relay nodes, so the end-to-end OAM state of forwarding | |||
| may be created only based on the status of multiple forwarding sub-layer segment s | may be created only based on the status of multiple forwarding sub-layer segment s | |||
| serving a given DetNet flow (e.g., in case of DetNet MPLS, there may be | serving a given DetNet flow (e.g., in case of DetNet MPLS, there may be | |||
| no end-to-end LSP below the DetNet Pseudowire). | no end-to-end LSP below the DetNet pseudowire). | |||
| </t> | </t> | |||
| <!-- | ||||
| <t> | ||||
| It is undwerstood that the existing OAM tools broadly used in networks can | ||||
| be used in DetNet domains. | ||||
| At the same time, it is expected that addressiing specific DetNet use case | ||||
| , for example, | ||||
| PREOF, will require extensions to the existing OAM protocols. | ||||
| </t> | ||||
| --> | ||||
| </section> | </section> | |||
| <!-- OPERATION --> | ||||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Operation</name> | <name>Operation</name> | |||
| <t> | <t> | |||
| OAM features will enable DetNet with robust operation both for forwarding and routing | OAM features will enable DetNet with robust operation both for forwarding and routing | |||
| purposes. | purposes. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| It is worth noting that the test and data packets are exp ected to follow the same | It is worth noting that the test and data packets are exp ected to follow the same | |||
| path, i.e., connectivity verification has to be conducted in-band wi thout | path, i.e., connectivity verification has to be conducted in band wi thout | |||
| impacting data traffic. | impacting data traffic. | |||
| It is expected that test packets share fate with the monitored data traffic | It is expected that test packets share fate with the monitored data traffic | |||
| without introducing congestion in normal network conditions. | without introducing congestion in normal network conditions. | |||
| </t> | </t> | |||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Information Collection</name> | <name>Information Collection</name> | |||
| <t> | <t> | |||
| Information about the state of the network can be collected using several mechanisms. Some protocols, | Information about the state of the network can be collected using several mechanisms. Some protocols, | |||
| e.g., Simple Network Management Protocol, polls for updated data. | e.g., the Simple Network Management Protocol (SNMP), poll for upda ted data. | |||
| Other protocols, such as YANG-Push <xref target="RFC8641"/>, can b e used | Other protocols, such as YANG-Push <xref target="RFC8641"/>, can b e used | |||
| to set up subscriptions for the data defined in the YANG data mode ls | to set up subscriptions for the data defined in the YANG data mode ls | |||
| to be published periodically or when the underlying data changes. | to be published periodically or when the underlying data changes. | |||
| In either way, information is collected and sent using the DetNet Controller Plane. | Either way, information is collected and sent using the DetNet Con troller Plane. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| Also, we can characterize methods of transporting OAM information relative to the path of data. | Also, we can characterize methods of transporting OAM information relative to the path of data. | |||
| For instance, OAM information may be transported in-band or out-o | For instance, OAM information may be transported in band or out o | |||
| f-band relative to the DetNet flow. | f band relative to the DetNet flow. | |||
| In case of the former, the telemetry information uses resources a | In the case of the former, the telemetry information uses resourc | |||
| llocated for the monitored DetNet flow. | es allocated for the monitored DetNet flow. | |||
| If an in-band method of transporting telemetry is used, the amoun t of generated information needs | If an in-band method of transporting telemetry is used, the amoun t of generated information needs | |||
| to be carefully analyzed, and additional resources must be reserv ed. <xref target="RFC9197"/> defines the in-band | to be carefully analyzed, and additional resources must be reserv ed. <xref target="RFC9197"/> defines the in-band | |||
| transport mechanism where telemetry information is collected in t he data packet on which information is generated. | transport mechanism where telemetry information is collected in t he data packet on which information is generated. | |||
| Two tracing methods are described - end-to-end, i.e., from the in | Two tracing methods are described:</t> | |||
| gress and egress nodes, | <ul> | |||
| and hop-by-hop, i.e., like end-to-end with additional information | <li>end-to-end, i.e., from the ingress and egress nodes, | |||
| from transit nodes. | and</li> | |||
| <xref target="RFC9326"/> and <xref target="I-D.mirsky-ippm-hybrid | <li>hop-by-hop, i.e., like end-to-end with additional information from | |||
| -two-step"/> are examples of out-of-band | transit nodes.</li></ul> | |||
| <t><xref target="RFC9326"/> and <xref target="I-D.ietf-ippm-hybri | ||||
| d-two-step"/> are examples of out-of-band | ||||
| telemetry transport. In the former case, information is transport ed by each node traversed | telemetry transport. In the former case, information is transport ed by each node traversed | |||
| by the data packet of the monitored DetNet flow in a specially co nstructed packet. In the latter, | by the data packet of the monitored DetNet flow in a specially co nstructed packet. In the latter, | |||
| information is collected in a sequence of follow-up packets that traverse the same path as the data packet of the monitored DetNet flow. | information is collected in a sequence of follow-up packets that traverse the same path as the data packet of the monitored DetNet flow. | |||
| In both methods, transport of the telemetry can avoid using resou rces allocated for the DetNet domain. | In both methods, transport of the telemetry can avoid using resou rces allocated for the DetNet domain. | |||
| </t> | </t> | |||
| </section> | </section> | |||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Continuity Check</name> | <name>Continuity Check</name> | |||
| <t> | <t> | |||
| Continuity check is used to monitor the continuity of a p ath, i.e., | A continuity check is used to monitor the continuity of a path, i.e., | |||
| that there exists a way to deliver packets between | that there exists a way to deliver packets between | |||
| MEP A and MEP B. The continuity check detects a network failure in o | MEP A and MEP B. The continuity check detects a network failure in o | |||
| ne direction, | ne direction: | |||
| from the MEP transmitting test packets to the remote egress MEP. Con | from the MEP transmitting test packets to the remote egress MEP. The | |||
| tinuity check in a DetNet OAM domain | continuity check in a DetNet OAM domain | |||
| monitors the DetNet forwarding sub-layer and thus is not affected | monitors the DetNet forwarding sub-layer; thus, it is not affected | |||
| by a PREOF that operates at the DetNet service sub-layer (<xref targe | by a PREOF that operates at the DetNet service sub-layer (<xref targe | |||
| t="RFC8655"/>. | t="RFC8655"/>). | |||
| </t> | </t> | |||
| </section> | </section> | |||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Connectivity Verification</name> | <name>Connectivity Verification</name> | |||
| <t> | <t> | |||
| In addition to the Continuity Check, DetNet solutions have to verify connectivity. | In addition to the Continuity Check, DetNet solutions have to verify connectivity. | |||
| This verification considers an additional constraint, i.e, the absen ce of | This verification considers an additional constraint: the absence of | |||
| misconnection. The misconnection error state is entered after severa l consecutive test packets | misconnection. The misconnection error state is entered after severa l consecutive test packets | |||
| from other DetNet flows are received. The definition of the conditio ns for entry and exit of a misconnection | from other DetNet flows are received. The definition of the conditio ns for entry and exit of a misconnection | |||
| error state is outside the scope of this document. Connectivity veri fication in a DetNet OAM domain | error state is outside the scope of this document. Connectivity veri fication in a DetNet OAM domain | |||
| monitors the DetNet forwarding sub-layer and thus is not affected | monitors the DetNet forwarding sub-layer; thus, it is not affected | |||
| by PREOF that operates at the DetNet service sub-layer (<xref target= | by PREOF that operates at the DetNet service sub-layer (<xref target= | |||
| "RFC8655"/>. | "RFC8655"/>). | |||
| </t> | </t> | |||
| </section> | </section> | |||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Route Tracing</name> | <name>Route Tracing</name> | |||
| <t> | <t> | |||
| Ping and traceroute are two ubiquitous tools that help lo calize and characterize a failure in the network | Ping and traceroute are two ubiquitous tools that help lo calize and characterize a failure in the network | |||
| using an echo request/reply mechanism. | using an echo request/reply mechanism. | |||
| They help to identify a subset of the routers in the path . | They help to identify a subset of the routers in the path . | |||
| However, to be predictable, resources are reserved per fl ow in DetNet. | However, to be predictable, resources are reserved per fl ow in DetNet. | |||
| Thus, DetNet needs to define route tracing tools able to trace the route for a | Thus, DetNet needs to define route tracing tools able to trace the route for a | |||
| specific flow. Also, tracing can be used for the discover y of the Path Maximum Transmission Unit or location of elements of PREOF | specific flow. Also, tracing can be used for the discover y of the Path Maximum Transmission Unit (PMTU) or location of elements of PREOF | |||
| for the particular route in the DetNet domain. | for the particular route in the DetNet domain. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| DetNet is not expected to use Equal-Cost Multipath (ECMP) <xref target="RFC8939" format="default"/>. | DetNet is not expected to use Equal-Cost Multipath (ECMP) <xref target="RFC8939" format="default"/>. | |||
| As the result, DetNet OAM in an ECMP environment is outsi de the scope of this document. | As a result, DetNet OAM in an ECMP environment is outside the scope of this document. | |||
| </t> | </t> | |||
| </section> | </section> | |||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Fault Verification/Detection</name> | <name>Fault Verification/Detection</name> | |||
| <t> | <t> | |||
| DetNet expects to operate fault-tolerant networks. | DetNet expects to operate fault-tolerant networks. | |||
| Thus, mechanisms able to detect faults before they impact network performance are needed. | Thus, mechanisms able to detect faults before they impact network performance are needed. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| The network has to detect when a fault has occurred, i.e., the ne twork has deviated | The network has to detect when a fault has occurred, i.e., the ne twork has deviated | |||
| from its expected behavior. Fault detection can be based on proacti ve OAM protocols | from its expected behavior. Fault detection can be based on proacti ve OAM protocols | |||
| like continuity check or on-demand methods like ping. | like continuity check or on-demand methods like ping. | |||
| While the network must report an alarm, the cause may not be iden tified | While the network must report an alarm, the cause may not be iden tified | |||
| precisely. | precisely. | |||
| Examples of such alarms are significant degradation of the end-to -end reliability, or a | Examples of such alarms are significant degradation of the end-to -end reliability or when a | |||
| buffer overflow occurs. | buffer overflow occurs. | |||
| </t> | </t> | |||
| </section> | </section> | |||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Fault Localization and Characterization</name> | <name>Fault Localization and Characterization</name> | |||
| <t> | <t> | |||
| An ability to localize a network defect and provide its character | The ability to localize a network defect and provide its characte | |||
| ization are necessary elements of network operation. | rization are necessary elements of network operation. | |||
| </t> | </t> | |||
| <ul empty="true" spacing="normal"> | ||||
| <li>Fault localization, a process of deducing the location of a networ | <dl spacing="normal"> | |||
| k failure from a set of observed failure indications, | <dt>Fault localization:</dt><dd>a process of deducing the location of | |||
| might be achieved, for example, by tracing the route of the DetNe | a network failure from a set of observed failure indications. | |||
| t flow in which the network failure was detected. | For example, this might be achieved by tracing the route of the D | |||
| Another method of fault localization can correlate reports of fai | etNet flow in which the network failure was detected. | |||
| lures from a set of interleaved sessions monitoring path continuity.</li> | Another method of fault localization can correlate reports of fai | |||
| <li> | lures from a set of interleaved sessions monitoring path continuity.</dd> | |||
| Fault characterization is a process of identifying the root cause of t | <dt>Fault characterization:</dt><dd>a process of identifying the | |||
| he problem. For instance, misconfiguration or malfunction of PREOF elements | root cause of the problem. For instance, misconfiguration or malfunction of PREO | |||
| F elements | ||||
| can be the cause of erroneous packet | can be the cause of erroneous packet | |||
| replication or extra packets being flooded in the DetNet domain. | replication or extra packets being flooded in the DetNet domain. | |||
| </li> | </dd> | |||
| </ul> | </dl> | |||
| </section> | </section> | |||
| <section anchor="hybrid-oam" numbered="true" toc="default"> | <section anchor="hybrid-oam" numbered="true" toc="default"> | |||
| <name>Use of Hybrid OAM in DetNet</name> | <name>Use of Hybrid OAM in DetNet</name> | |||
| <t>Hybrid OAM methods are used in performance monitoring and defined in <xref target="RFC7799" format="default"/> as: | <t>Hybrid OAM methods are used in performance monitoring and defined in <xref target="RFC7799" format="default"/> as follows: | |||
| </t> | </t> | |||
| <ul empty="true" spacing="normal"> | <blockquote> | |||
| <li>Hybrid Methods are Methods of Measurement that use a combination o | <t>Hybrid Methods are Methods of Measurement that use a combination of | |||
| f | Active Methods and Passive Methods.</t> | |||
| Active Methods and Passive Methods.</li> | </blockquote> | |||
| </ul> | ||||
| <t> | <t> | |||
| A hybrid measurement method can produce metrics as close to measured using a pas sive measurement method. | A hybrid measurement method can produce metrics as close to measured using a pas sive measurement method. | |||
| The passive methods measure metrics closest to the network's actual conditions. A hybrid method, | The passive methods measure metrics closest to the network's actual conditions. A hybrid method, | |||
| even if it alters something in a data packet, even if that is as little as the v alue of a designated field in the packet encapsulation, | even if it alters something in a data packet, even if that is as little as the v alue of a designated field in the packet encapsulation, | |||
| is considered an approximation of a passive measurement method. | is considered an approximation of a passive measurement method. | |||
| One example of such a hybrid measurement method | One example of such a hybrid measurement method | |||
| is the Alternate Marking method (AMM) described in <xref target="RFC9341" for | is the Alternate-Marking Method (AMM) described in <xref target="RFC9341" for | |||
| mat="default"/>. | mat="default"/>. | |||
| As with all on-path telemetry methods, AMM in a DetNet domain with the IP dat | As with all on-path telemetry methods, AMM in a DetNet domain with the IP dat | |||
| a plane is natively in-band | a plane is, by design, in band | |||
| with respect to the monitored DetNet flow. Because the marking is applied to a data flow, | with respect to the monitored DetNet flow. Because the marking is applied to a data flow, | |||
| measured metrics are directly applicable to the DetNet flow. AMM minimizes the additional load on | measured metrics are directly applicable to the DetNet flow. AMM minimizes the additional load on | |||
| the DetNet domain by using nodal collection and computation of performance met | the DetNet domain by using nodal collection and computation of performance met | |||
| rics in combination with | rics optionally in combination with | |||
| optionally using out-of-band telemetry collection for further network analysis | using out-of-band telemetry collection for further network analysis. | |||
| . | ||||
| </t> | </t> | |||
| </section> | </section> | |||
| </section> | </section> | |||
| <!-- ADMINISTRATION --> | ||||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Administration</name> | <name>Administration</name> | |||
| <t> | <t> | |||
| The ability to expose a collection of metrics to support an operator's dec ision-making is essential. | The ability to expose a collection of metrics to support an operator's dec ision-making is essential. | |||
| The following performance metrics are useful: | The following performance metrics are useful: | |||
| </t> | </t> | |||
| <ul spacing="normal"> | <dl> | |||
| <li> | <dt>Queuing Delay:</dt><dd>the time elapsed between enqueuing a packet a | |||
| Queuing Delay: the time elapsed between enqueuing a packet and its t | nd its transmission to the next hop. | |||
| ransmission to the next hop. | </dd> | |||
| </li> | <dt>Buffer occupancy:</dt><dd>the number of packets present in the buffe | |||
| <li> | r for each of the existing flows. | |||
| Buffer occupancy: the number of packets present in the buffer, for e | </dd> | |||
| ach of the existing flows. | <dt>Per DetNet flow:</dt><dd>a metric reflecting end-to-end performance | |||
| </li> | for a given flow. | |||
| <li> | ||||
| Per DetNet flow, a metric reflecting end-to-end performance for a gi | ||||
| ven flow. | ||||
| Each of the paths has to be isolated in a multipath routing environm ent. | Each of the paths has to be isolated in a multipath routing environm ent. | |||
| </li> | </dd> | |||
| <li> | <dt>Per-path:</dt><dd>detection of a misbehaving path or paths when mult | |||
| Per path, detection of misbehaving path(s) when multiple paths are u | iple paths are used for the service protection. | |||
| sed for the service protection. | </dd> | |||
| </li> | <dt>Per-device:</dt><dd>detection of a misbehaving device. | |||
| <li> | </dd> | |||
| Per device, detection of a misbehaving device. | </dl> | |||
| </li> | ||||
| </ul> | ||||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Collection of metrics</name> | <name>Collection of Metrics</name> | |||
| <t> | <t> | |||
| It is important to optimize the volume and frequency of statistics/ measurement collection, | It is important to optimize the volume and frequency of statistics/ measurement collection, | |||
| whether the mechanisms are distributed, centralized, or both. Perio dic and | whether the mechanisms are distributed, centralized, or both. Perio dic and | |||
| event-triggered collection information characterizing the state of a network is | event-triggered collection information characterizing the state of a network is | |||
| an example of mechanisms to achieve the optimization. | an example of mechanisms to achieve the optimization. | |||
| </t> | </t> | |||
| </section> | </section> | |||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Worst-case metrics</name> | <name>Worst-Case Metrics</name> | |||
| <t> | <t> | |||
| DetNet aims to enable real-time communications on top of a heterogeneou s multi-hop architecture. | DetNet aims to enable real-time communications on top of a heterogeneou s multi-hop architecture. | |||
| To make correct decisions, the DetNet Controller Plane <xref target="RF C8655"/> needs timely information | To make correct decisions, the DetNet Controller Plane <xref target="RF C8655"/> needs timely information | |||
| about packet losses/delays for each flow, and each hop of the paths. | about packet losses/delays for each flow and each hop of the paths. | |||
| In other words, just the average end-to-end statistics are not enough. | In other words, just the average end-to-end statistics are not enough. | |||
| The collected information must be sufficient to allow a system to predi ct the worst-case scenario. | The collected information must be sufficient to allow a system to predi ct the worst-case scenario. | |||
| </t> | </t> | |||
| </section> | </section> | |||
| </section> | </section> | |||
| <!-- MAINTENANCE --> | ||||
| <!-- speak about predictive maintenance? --> | ||||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Maintenance</name> | <name>Maintenance</name> | |||
| <t> | <t> | |||
| Service protection (provided by the DetNet Service sub-layer) is designed to mitigate simple network failures more rapidly | Service protection (provided by the DetNet Service sub-layer) is designed to mitigate simple network failures more rapidly | |||
| than the expected response time of the DetNet Controller Plane. | than the expected response time of the DetNet Controller Plane. | |||
| In the face of events that impact network operation (e.g., link up/down, | In the face of events that impact network operation (e.g., link up/down, | |||
| device crash/reboot, flows starting and ending), the DetNet Controller | device crash/reboot, flows starting and ending), the DetNet Controller | |||
| Plane needs to perform | Plane needs to perform | |||
| repair and re-optimization actions in order to permanently ensure | repair and reoptimization actions in order to permanently ensure | |||
| SLOs of all active flows with minimal waste of resources. | SLOs of all active flows with minimal waste of resources. | |||
| The Controller Plane is expected to be able to continuously retrieve th e state of the network, | The Controller Plane is expected to be able to continuously retrieve th e state of the network, | |||
| to evaluate conditions and trends about the relevance of a reconfigurat ion, quantifying: | to evaluate conditions and trends about the relevance of a reconfigurat ion, quantifying the following: | |||
| </t> | </t> | |||
| <ul spacing="normal"> | <dl spacing="normal"> | |||
| <li> the cost of the sub-optimality: resources may not be used optimally | <dt>the cost of the suboptimality:</dt><dd>resources may not be used opt | |||
| (i.e., a better path exists). | imally (i.e., a better path exists). | |||
| </li> | </dd> | |||
| <li> | <dt>the reconfiguration cost:</dt><dd>the DetNet Controller Plane needs | |||
| the reconfiguration cost: the DetNet Controller Plane needs an ab | an ability to trigger some reconfigurations. | |||
| ility to trigger some reconfigurations. | ||||
| For this transient period, resources may be twice reserved, and c ontrol packets have to be transmitted. | For this transient period, resources may be twice reserved, and c ontrol packets have to be transmitted. | |||
| </li> | </dd> | |||
| </ul> | </dl> | |||
| <t> | <t> | |||
| Thus, reconfiguration may only be triggered if the gain is significant. | Thus, reconfiguration may only be triggered if the gain is significant. | |||
| </t> | </t> | |||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Replication / Elimination</name> | <name>Replication/Elimination</name> | |||
| <t> | <t> | |||
| When multiple paths are reserved between two MEPs, | When multiple paths are reserved between two MEPs, | |||
| packet replication may be used to introduce redundancy and alleviate transmiss ion errors and collisions. | packet replication may be used to introduce redundancy and alleviate transmiss ion errors and collisions. | |||
| For instance, in <xref target="fig_replication" format="default"/> , the source device S transmits | For instance, in <xref target="fig_replication" format="default"/> , the source device S transmits | |||
| a packet to devices A and B to reach the destination node R. | a packet to devices A and B to reach the destination node R. | |||
| </t> | </t> | |||
| <figure anchor="fig_replication"> | <figure anchor="fig_replication"> | |||
| <name>Packet Replication and Elimination Functions</name> | <name>Packet Replication and Elimination Functions</name> | |||
| <artwork align="center" name="" type="" alt=""><![CDATA[ | <artwork align="center" name="" type="" alt=""><![CDATA[ | |||
| skipping to change at line 549 ¶ | skipping to change at line 536 ¶ | |||
| ===> (A) => (C) => (E) === | ===> (A) => (C) => (E) === | |||
| // \\// \\// \\ | // \\// \\// \\ | |||
| source (S) //\\ //\\ (R) (root) | source (S) //\\ //\\ (R) (root) | |||
| \\ // \\ // \\ // | \\ // \\ // \\ // | |||
| ===> (B) => (D) => (F) === | ===> (B) => (D) => (F) === | |||
| ]]></artwork> | ]]></artwork> | |||
| </figure> | </figure> | |||
| </section> | </section> | |||
| <section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
| <name>Resource Reservation</name> | <name>Resource Reservation</name> | |||
| <t> | <t>Because the quality of service associated with a path may degrade, th | |||
| e network has | ||||
| Because the quality of service criteria associated with a path may d | ||||
| egrade, the network has | ||||
| to provision additional resources along the path. | to provision additional resources along the path. | |||
| </t> | </t> | |||
| </section> | </section> | |||
| </section> | </section> | |||
| <section anchor="req-list" numbered="true" toc="default"> | <section anchor="req-list" numbered="true" toc="default"> | |||
| <name>Requirements</name> | <name>Requirements</name> | |||
| <t> | <t> | |||
| According to <xref target="RFC8655"/>, DetNet functionality is divided int o forwarding and service sub-layers. | According to <xref target="RFC8655"/>, DetNet functionality is divided int o forwarding and service sub-layers. | |||
| The DetNet forwarding sub-layer includes DetNet transit nodes and may allo cate resources for a DetNet flow over paths provided by the underlay network. | The DetNet forwarding sub-layer includes DetNet transit nodes and may allo cate resources for a DetNet flow over paths provided by the underlay network. | |||
| The DetNet service sub-layer includes DetNet relay nodes and provides a De tNet service (e.g., service protection). | The DetNet service sub-layer includes DetNet relay nodes and provides a De tNet service (e.g., service protection). | |||
| This section lists general requirements for DetNet OAM as well as requirements in each of the DetNet sub-layers of a DetNet domain. | This section lists general requirements for DetNet OAM as well as requirements in each of the DetNet sub-layers of a DetNet domain. | |||
| </t> | </t> | |||
| <ol spacing="normal" type="1"> | <ol spacing="normal" type="1"> | |||
| <li> | <li> | |||
| It MUST be possible to initiate a DetNet OAM session from a MEP locate | It <bcp14>MUST</bcp14> be possible to initiate a DetNet OAM session fr | |||
| d at a | om a MEP located at a | |||
| DetNet node towards MEP(s) downstream from that DetNet node | DetNet node towards a MEP or MEPs downstream from that DetNet node | |||
| within the given domain at a particular DetNet sub-layer. | within the given domain at a particular DetNet sub-layer. | |||
| </li> | </li> | |||
| <li> | <li> | |||
| It MUST be possible to initiate a DetNet OAM session from using any of DetNet Controller Plane solutions, e.g., centralized controller. | It <bcp14>MUST</bcp14> be possible to initiate a DetNet OAM session using any of the DetNet Controller Plane solutions, e.g., a centralized controller. | |||
| </li> | </li> | |||
| <li> | <li> | |||
| DetNet OAM MUST support proactive OAM monitoring and measurement methods. | DetNet OAM <bcp14>MUST</bcp14> support proactive OAM monitoring and measuremen t methods. | |||
| </li> | </li> | |||
| <li> | <li> | |||
| DetNet OAM MUST support on-demand OAM monitoring and measurement methods. | DetNet OAM <bcp14>MUST</bcp14> support on-demand OAM monitoring and measuremen | |||
| </li> | t methods. | |||
| <li> | ||||
| DetNet OAM MUST support unidirectional OAM methods, continuity check, | ||||
| connectivity verification, and performance measurement. | ||||
| </li> | </li> | |||
| <!-- | ||||
| <li> | <li> | |||
| DetNet OAM methods MAY combine in-band monitoring or measurement in the forwar | DetNet OAM <bcp14>MUST</bcp14> support unidirectional OAM methods, continuity | |||
| d direction and out-of-band | checks, | |||
| notification in the reverse direction, i.e., towards the ingress MEP. | connectivity verification, and performance measurements. | |||
| </li> | </li> | |||
| --> | ||||
| <li> | <li> | |||
| DetNet OAM MUST support bi-directional DetNet flows, | DetNet OAM <bcp14>MUST</bcp14> support bidirectional DetNet flows, | |||
| but is not required to support bi-directional OAM methods for bi-directional | but it is not required to support bidirectional OAM methods for bidirectiona | |||
| DetNet flows. | l DetNet flows. | |||
| DetNet OAM test packets used for monitoring and measurements | DetNet OAM test packets used for monitoring and measurements | |||
| of a bi-directional DetNet flow MUST be in-band in both directions. | of a bidirectional DetNet flow <bcp14>MUST</bcp14> be in band in both direct ions. | |||
| </li> | </li> | |||
| <li> | <li> | |||
| DetNet OAM MUST support proactive monitoring of a DetNet device reachability for a given DetNet flow. | DetNet OAM <bcp14>MUST</bcp14> support proactive monitoring of a DetNet device's reachability for a given DetNet flow. | |||
| </li> | </li> | |||
| <li> | <li> | |||
| DetNet OAM MUST support hybrid performance measurement methods. | DetNet OAM <bcp14>MUST</bcp14> support hybrid performance measurement methods. | |||
| </li> | </li> | |||
| <li> | <li> | |||
| Calculated performance metrics MUST include but are not limited to throughput, p | Calculated performance metrics <bcp14>MUST</bcp14> include, but are not limited | |||
| acket loss, out of order, | to, throughput, packet-loss, out-of-order, | |||
| delay, and delay variation metrics. <xref target="RFC6374" format="default"/> pr | delay, and delay-variation metrics. <xref target="RFC6374" format="default"/> pr | |||
| ovides detailed information on performance | ovides detailed information on performance | |||
| measurement and performance metrics. | measurement and performance metrics. | |||
| </li> | </li> | |||
| </ol> | </ol> | |||
| <section anchor="req-on-dfs-oam" title="For the DetNet Forwarding Sub-la yer"> | <section anchor="req-on-dfs-oam" title="For the DetNet Forwarding Sub-la yer"> | |||
| <t>DetNet OAM <bcp14>MUST</bcp14> support:</t> | ||||
| <ol spacing="normal" type="1"> | <ol spacing="normal" type="1"> | |||
| <li> | <li>PMTU discovery. | |||
| DetNet OAM MUST support Path Maximum Transmission Unit discovery. | ||||
| </li> | </li> | |||
| <li> | <li>Remote Defect Indication (RDI) notification to the DetNet OAM instan | |||
| DetNet OAM MUST support Remote Defect Indication notification to the DetNet OAM | ce | |||
| instance | ||||
| performing continuity checking. | performing continuity checking. | |||
| </li> | </li> | |||
| <li> | <li>the monitoring of levels of resources allocated for a particular D | |||
| DetNet OAM MUST support monitoring levels of resources allocated for a particu | etNet flow. | |||
| lar DetNet flow. | Such resources include, but are not limited to, buffer utilization and schedul | |||
| Such resources include but are not limited to buffer utilization and scheduler | er transmission calendar. | |||
| transmission calendar. | ||||
| </li> | </li> | |||
| <li> | <li>the monitoring of any subset of paths traversed through the DetNet d | |||
| DetNet OAM MUST support monitoring any subset of paths traversed through the D | omain by a DetNet flow. | |||
| etNet domain by a DetNet flow. | ||||
| </li> | </li> | |||
| </ol> | </ol> | |||
| </section> | </section> | |||
| <section anchor="req-on-dss-oam" title="For the DetNet Service Sub-layer"> | <section anchor="req-on-dss-oam" title="For the DetNet Service Sub-layer"> | |||
| <t> | <t> | |||
| The OAM functions for the DetNet service sub-layer allow, for example, t | The OAM functions for the DetNet service sub-layer allow, for example, t | |||
| o | he | |||
| recognize/discover DetNet relay nodes, to get information about their | recognizing/discovery of DetNet relay nodes, the gathering of informatio | |||
| configuration, and to check their operation or status. | n about their | |||
| configuration, and the checking of their operation or status. | ||||
| </t> | </t> | |||
| <t> | <t> | |||
| The requirements on OAM for a DetNet relay node are: | The requirements on OAM for a DetNet relay node are that DetNet OAM <bcp14> MUST</bcp14>: | |||
| </t> | </t> | |||
| <ol spacing="normal" type="1"> | <ol spacing="normal" type="1"> | |||
| <li>DetNet OAM MUST provide OAM functions for the DetNet service sub-la | <li>provide OAM functions for the DetNet service sub-layer. </li> | |||
| yer. </li> | <li>support the discovery of DetNet relay nodes in a DetNet network. | |||
| <li> | ||||
| DetNet OAM MUST support the discovery of DetNet relay nodes in a DetNet | ||||
| network. | ||||
| </li> | </li> | |||
| <li> | <li>support the discovery of PREOF locations in the domain. | |||
| DetNet OAM MUST support the discovery of PREOF locations in the domain. | ||||
| </li> | </li> | |||
| <li> | <li>support the collection of information specific to the DetNet servic | |||
| DetNet OAM MUST support the collection of the DetNet service sub-layer | e sub-layer | |||
| specific | (configuration/operation/status) from DetNet relay nodes. | |||
| (configuration/operation/status) information from DetNet relay nodes. | ||||
| </li> | </li> | |||
| <li> | <li>support exercising functionality of PREOF in the domain. | |||
| DetNet OAM MUST support excercising functionality of PREOF in t | ||||
| he domain. | ||||
| </li> | </li> | |||
| <li>DetNet OAM MUST work for DetNet data planes - MPLS and IP. < | <li>work for DetNet data planes: MPLS and IP. </li> | |||
| /li> | <li>support a defect notification mechanism, like Alarm Indicatio | |||
| <li> | n Signal. | |||
| DetNet OAM MUST support a defect notification mechanism, like Alarm Indication S | ||||
| ignal. | ||||
| Any DetNet relay node providing service for a given DetNet flow | Any DetNet relay node providing service for a given DetNet flow | |||
| MAY originate a defect notification addressed to any subset of DetNet relay node s along that flow. | <bcp14>MAY</bcp14> originate a defect notification addressed to any subset of De tNet relay nodes along that flow. | |||
| </li> | </li> | |||
| <li> | <li>be able to measure metrics (e.g. delay) inside a collection of OAM sessi | |||
| DetNet OAM MUST be able to measure metrics (e.g. delay) inside a collection of O | ons, specially for complex DetNet flows, with PREOF features. | |||
| AM sessions, specially for complex DetNet flows, with PREOF features. | ||||
| </li> | </li> | |||
| </ol> | </ol> | |||
| </section> <!-- end of service sub-layer requirements --> | </section> | |||
| </section> | </section> | |||
| <section anchor="iana-consider" numbered="true" toc="default"> | <section anchor="iana-consider" numbered="true" toc="default"> | |||
| <name>IANA Considerations</name> | <name>IANA Considerations</name> | |||
| <t>This document has no actionable requirements for IANA. This section can | ||||
| be removed before publication.</t> | <t>This document has no IANA actions.</t> | |||
| </section> | </section> | |||
| <section anchor="security" numbered="true" toc="default"> | <section anchor="security" numbered="true" toc="default"> | |||
| <name>Security Considerations</name> | <name>Security Considerations</name> | |||
| <t> | <t> | |||
| This document lists the OAM requirements for a DetNet domain | This document lists the OAM requirements for a DetNet domain | |||
| and does not raise any security concerns or issues in addition to ones common to networking and | and does not raise any security concerns or issues in addition to ones common to networking and | |||
| those specific to DetNet discussed in Section 9 of <xref target="RFC9055" for | those specific to DetNet that are discussed in <xref target="RFC9055" section | |||
| mat="default"/>. | Format="of" section="9"/>. | |||
| Furthermore, the analysis of OAM security concerns in Section 6 of <xref t | Furthermore, the analysis of OAM security concerns in <xref target="RFC727 | |||
| arget="RFC7276"/> | 6" sectionFormat="of" section="6"/> | |||
| also applies to DetNet OAM, including the use of OAM for network reconnais sance.</t> | also applies to DetNet OAM, including the use of OAM for network reconnais sance.</t> | |||
| </section> | </section> | |||
| <section anchor="privacy" numbered="true" toc="default"> | <section anchor="privacy" numbered="true" toc="default"> | |||
| <name>Privacy Considerations</name> | <name>Privacy Considerations</name> | |||
| <t> | <t> | |||
| Privacy considerations of DetNet discussed in Section 13 of <xref target="RFC9 055" format="default"/> | Privacy considerations of DetNet discussed in <xref target="RFC9055" sectionFo rmat="of" section="13"/> | |||
| are also applicable to DetNet OAM. If any privacy mechanism is used for the mo nitored DetNet flow, then | are also applicable to DetNet OAM. If any privacy mechanism is used for the mo nitored DetNet flow, then | |||
| the same privacy method MUST be applied to the active DetNet OAM used to monit | the same privacy method <bcp14>MUST</bcp14> be applied to the active DetNet OA | |||
| or the flow. | M used to monitor the flow. | |||
| </t> | ||||
| </section> | ||||
| <section numbered="true" toc="default"> | ||||
| <name>Acknowledgments</name> | ||||
| <t> | ||||
| The authors express their appreciation and gratitude to Pascal Thubert f | ||||
| or the review, insightful questions, and helpful comments. | ||||
| </t> | </t> | |||
| </section> | </section> | |||
| </middle> | </middle> | |||
| <back> | <back> | |||
| <displayreference target="I-D.ietf-ippm-hybrid-two-step" to="HYBRID-TWO-STEP"/ | ||||
| > | ||||
| <references> | <references> | |||
| <name>References</name> | <name>References</name> | |||
| <references> | <references> | |||
| <name>Normative References</name> | <name>Normative References</name> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
| FC.2119.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21 | |||
| <!-- Key words for use in RFCs to Indicate Requirement Levels --> | 19.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8 | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81 | |||
| 174.xml"/> | 74.xml"/> | |||
| <!-- Ambiguity of Uppercase vs Lowercase --> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86 | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/ref | 55.xml"/> | |||
| erence.RFC.8655.xml"/> | ||||
| <!-- Deterministic Networking Architecture --> | ||||
| </references> | </references> | |||
| <references> | <references> | |||
| <name>Informative References</name> | <name>Informative References</name> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
| FC.6291.xml"/> | ||||
| <!-- OAM definition --> | ||||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
| FC.7276.xml"/> | ||||
| <!-- An Overview of Operations, Administration, and Maintenance (OAM) To | ||||
| ols --> | ||||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62 | |||
| FC.7799.xml"/> | 91.xml"/> | |||
| <!-- passive / active methods --> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.72 | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | 76.xml"/> | |||
| FC.2544.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77 | |||
| <!-- test packets --> | 99.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.25 | |||
| FC.8939.xml"/> | 44.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89 | |||
| FC.6374.xml"/> | 39.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.63 | |||
| FC.9055.xml"/> | 74.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90 | |||
| FC.8641.xml"/> | 55.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86 | |||
| FC.9197.xml"/> | 41.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91 | |||
| .RFC.9326.xml"/> | 97.xml"/> | |||
| <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-mirs | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93 | |||
| ky-ippm-hybrid-two-step.xml"/> | 26.xml"/> | |||
| <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | ||||
| .ietf-ippm-hybrid-two-step.xml"/> | ||||
| <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
| 341.xml"/> | ||||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9341.xml"/> | ||||
| </references> | </references> | |||
| </references> | </references> | |||
| <section numbered="false" toc="default"> | ||||
| <name>Acknowledgments</name> | ||||
| <t> | ||||
| The authors express their appreciation and gratitude to <contact fullna | ||||
| me="Pascal Thubert"/> for the review, insightful questions, and helpful comments | ||||
| . | ||||
| </t> | ||||
| </section> | ||||
| </back> | </back> | |||
| </rfc> | </rfc> | |||
| End of changes. 105 change blocks. | ||||
| 392 lines changed or deleted | 354 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||