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. |