rfc9634.original.xml | rfc9634.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="utf-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<!-- pre-edited by ST 03/14/24 --> | ||||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902 | ||||
" docName="draft-ietf-detnet-ip-oam-13" obsoletes="" updates="" submissionType=" | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902 | |||
IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true | " docName="draft-ietf-detnet-ip-oam-13" number="9634" consensus="true" obsoletes | |||
" version="3"> | ="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3 | |||
<!-- xml2rfc v2v3 conversion 3.6.0 --> | " symRefs="true" sortRefs="true" version="3"> | |||
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> | ||||
<front> | <front> | |||
<title abbrev="OAM for DetNet over IP">Operations, Administration, and Maint | <title abbrev="OAM for DetNet over IP">Operations, Administration, and Maint | |||
enance (OAM) for Deterministic Networks (DetNet) with IP Data Plane</title> | enance (OAM) for Deterministic Networking (DetNet) with the IP Data Plane</title | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-detnet-ip-oam-13"/> | > | |||
<!-- [rfced] We have updated the document title along the lines of | ||||
RFC 9546 and other cited RFCs, which define "DetNet" as | ||||
"Deterministic Networking". Please let us know any concerns. | ||||
Original: | ||||
Operations, Administration, and Maintenance (OAM) for Deterministic | ||||
Networks (DetNet) with IP Data Plane | ||||
Currently: | ||||
Operations, Administration, and Maintenance (OAM) for Deterministic | ||||
Networking (DetNet) with the IP Data Plane --> | ||||
<seriesInfo name="RFC" value="9634"/> | ||||
<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 fullname="Mach(Guoyi) Chen" initials="M." surname="Chen"> | <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen"> | |||
<organization>Huawei</organization> | <organization>Huawei</organization> | |||
<address> | <address> | |||
<postal> | ||||
<street/> | ||||
<city/> | ||||
<code/> | ||||
<country/> | ||||
</postal> | ||||
<email>mach.chen@huawei.com</email> | <email>mach.chen@huawei.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="D" surname="Black" fullname="David Black"> | <author initials="D." surname="Black" fullname="David Black"> | |||
<organization>Dell EMC</organization> | <organization>Dell EMC</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>176 South Street</street> | <street>176 South Street</street> | |||
<city>Hopkinton, MA</city> | <city>Hopkinton</city><region>MA</region> | |||
<code>01748</code> | <code>01748</code> | |||
<country>United States of America</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>david.black@dell.com</email> | <email>david.black@dell.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date year="2024"/> | <date month="August" year="2024"/> | |||
<area>Routing</area> | <area>RTG</area> | |||
<workgroup>DetNet Working Group</workgroup> | <workgroup>detnet</workgroup> | |||
<keyword>Internet-Draft</keyword> | ||||
<keyword>DetNet</keyword> | <keyword>DetNet</keyword> | |||
<keyword>OAM</keyword> | <keyword>OAM</keyword> | |||
<abstract> | <abstract> | |||
<t> | <t> | |||
This document discusses the use of existing IP Operations, | This document discusses the use of existing IP Operations, | |||
Administration, and Maintenance protocols and mechanisms in | Administration, and Maintenance protocols and mechanisms in | |||
Deterministic Networking networks that use the IP data plane. | Deterministic Networking networks that use the IP data plane. | |||
</t> | </t> | |||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section anchor="intro" numbered="true" toc="default"> | <section anchor="intro" numbered="true" toc="default"> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t> | <t> | |||
<xref target="RFC8655" format="default"/> introduces and explains Determinist ic Networks (DetNet) | <xref target="RFC8655" format="default"/> introduces and explains the Determi nistic Networking (DetNet) | |||
architecture. | architecture. | |||
</t> | </t> | |||
<t> | <t> | |||
Operations, Administration, and Maintenance (OAM) protocols are used | Operations, Administration, and Maintenance (OAM) protocols are used | |||
to detect and localize defects in the network as well as to monitor network | to detect and localize defects in the network as well as to monitor network | |||
performance. Some OAM functions (e.g., failure detection), work in | performance. Some OAM functions (e.g., failure detection) work in | |||
the network proactively, while others (e.g., defect localization) are | the network proactively, while others (e.g., defect localization) are | |||
usually performed on-demand. These tasks are achieved by a combination | usually performed on demand. These tasks are achieved by a combination | |||
of active and hybrid OAM methods, as defined in <xref target="RFC7799"/>. | of active and hybrid OAM methods, as defined in <xref target="RFC7799"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
<xref target="I-D.ietf-detnet-oam-framework" format="default"/> lists the OAM | <xref target="RFC9551" format="default"/> lists the OAM functional requiremen | |||
functional requirements | ts | |||
for DetNet, and defines the principles for OAM use within DetNet | for DetNet and defines the principles for OAM use within DetNet | |||
networks utilizing the IP data plane. The functional requirements | networks utilizing the IP data plane. The functional requirements | |||
can be compared against current OAM tools to identify gaps and | can be compared against current OAM tools to identify gaps and | |||
potential enhancements required to enable proactive and on-demand | potential enhancements required to enable proactive and on-demand | |||
path monitoring and service validation. | path monitoring and service validation. | |||
</t> | </t> | |||
<t> | <t> | |||
This document discusses the use of existing IP OAM protocols and mechan isms in | This document discusses the use of existing IP OAM protocols and mechan isms in | |||
DetNet networks that use the IP data plane. | DetNet networks that use the IP data plane. | |||
</t> | </t> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Conventions used in this document</name> | <name>Conventions Used in This Document</name> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Terminology</name> | <name>Terminology</name> | |||
<t> | <t> | |||
The term "DetNet OAM" used in this document interchangeably with longer version | The term "DetNet OAM" as used in this document also means "a set of OAM protocol | |||
"set of OAM protocols, methods and tools for Deterministic Networks". | s, methods, and tools for Deterministic Networking". | |||
</t> | </t> | |||
<t>DetNet: Deterministic Networks</t> | <dl spacing="normal"> | |||
<t>OAM: Operations, Administration, and Maintenance</t> | <dt>DetNet:</dt><dd>Deterministic Networking</dd> | |||
<t>ICMP: Internet Control Message Protocol</t> | <dt>OAM:</dt><dd>Operations, Administration, and Maintenance</dd> | |||
<t>Underlay Network or Underlay Layer: The network that provides | <dt>ICMP:</dt><dd>Internet Control Message Protocol</dd> | |||
connectivity between DetNet nodes. MPLS networks providing LSP | <dt>Underlay Network or Underlay Layer:</dt><dd>The network that provide | |||
s | ||||
connectivity between DetNet nodes. MPLS networks providing Label Switched Pa | ||||
th (LSP) | ||||
connectivity between DetNet nodes are an example of the DetNet IP network und erlay | connectivity between DetNet nodes are an example of the DetNet IP network und erlay | |||
layer.</t> | layer.</dd> | |||
<t>DetNet Node: a node that is an actor in the DetNet domain. DetNet | ||||
<!-- [rfced] Section 2.1: We defined "LSP" as "Label Switched Path" | ||||
per RFC 9546. If this is incorrect, please provide the correct | ||||
definition of "LSP". | ||||
Original: | ||||
MPLS networks providing LSP | ||||
connectivity between DetNet nodes are an example of the DetNet IP | ||||
network underlay layer. | ||||
Currently: | ||||
MPLS networks providing Label | ||||
Switched Path (LSP) connectivity between DetNet nodes are an | ||||
example of the DetNet IP network underlay layer. --> | ||||
<dt>DetNet Node:</dt><dd>A node that is an actor in the DetNet domain. | ||||
DetNet | ||||
domain edge nodes and nodes that perform the Packet Replication and Eliminati on Function within the domain are | domain edge nodes and nodes that perform the Packet Replication and Eliminati on Function within the domain are | |||
examples of a DetNet node.</t> | examples of a DetNet node.</dd> | |||
</section> | ||||
<!-- | <!-- [rfced] Section 2.1: Does "Packet Replication and Elimination | |||
<section numbered="true" toc="default"> | Function" mean "Packet Replication, Elimination, and Ordering | |||
<name>Keywords</name> | Functions" (as used in RFC 9546 and Section 3.3 of this document), | |||
<t> | "Packet Replication Function", "Packet Elimination and Replication | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | Functions", or something else? | |||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", | ||||
"MAY", and "OPTIONAL" in this document are to be interpreted as | Original: | |||
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="R | DetNet | |||
FC8174" format="default"/> | domain edge nodes and nodes that perform the Packet Replication and | |||
when, and only when, they appear in all capitals, as shown here. | Elimination Function within the domain are examples of a DetNet node. --> | |||
</t> | ||||
</dl> | ||||
</section> | </section> | |||
--> | ||||
</section> | </section> | |||
<section anchor="oam-data-plane" numbered="true" toc="default"> | <section anchor="oam-data-plane" numbered="true" toc="default"> | |||
<name>Active OAM for DetNet Networks with the IP Data Plane</name> | <name>Active OAM for DetNet Networks with the IP Data Plane</name> | |||
<t> | <t> | |||
OAM protocols and mechanisms act within the data plane of the particular network ing layer. | OAM protocols and mechanisms act within the data plane of the particular network ing layer. | |||
Thus, it is critical that the data plane encapsulation supports OAM mechanisms a nd enables them to be | Thus, it is critical that the data plane encapsulation support OAM mechanisms an d enable them to be | |||
configured so that DetNet OAM packets follow the same path | configured so that DetNet OAM packets follow the same path | |||
(unidirectional or bidirectional) through the network and receive | (unidirectional or bidirectional) through the network and receive | |||
the same forwarding treatment in the DetNet forwarding sub-layer | the same forwarding treatment in the DetNet forwarding sub-layer | |||
as the DetNet flow being monitored. | as the DetNet flow being monitored. | |||
</t> | </t> | |||
<t> | <t> | |||
The DetNet data plane encapsulation in a transport network with IP encapsulation s is specified | The DetNet data plane encapsulation in a transport network with IP encapsulation s is specified | |||
in Section 6 of <xref target="RFC8939" format="default"/>. | in <xref target="RFC8939" sectionFormat="of" section="6"/>. | |||
For the IP underlay network, DetNet flows are identified | For the IP underlay network, DetNet flows are identified | |||
by the ordered match to the provisioned information set that, among other elemen ts, includes the IP protocol, source port number, | by the ordered match to the provisioned information set that, among other elemen ts, includes the IP protocol type, source port number, and | |||
destination port number. Active IP OAM | destination port number. Active IP OAM | |||
protocols like Bidirectional Forwarding Detection (BFD) <xref target="RFC5880" f | protocols like Bidirectional Forwarding Detection (BFD) <xref target="RFC5880" f | |||
ormat="default"/> or | ormat="default"/> or the | |||
Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762" format | Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762" format | |||
="default"/>, | ="default"/> | |||
use UDP transport and the well-known UDP port numbers as the destination port. | use UDP transport and the well-known UDP port numbers as the destination port. | |||
For BFD, the UDP destination port is specific to the BFD variant, | For BFD, the UDP destination port is specific to the BFD variant, | |||
e.g., Multihop BFD uses port 4784 <xref target="RFC5883"/>. | e.g., multihop BFD uses port 4784 <xref target="RFC5883"/>. | |||
<!-- [rfced] Section 3: This sentence reads oddly, as it seems to | ||||
mix both singular and plural. Should "the well-known UDP port | ||||
numbers" be "the well-known UDP port number", or should "the | ||||
destination port" be "the destination ports"? | ||||
Original: | ||||
Active | ||||
IP OAM protocols like Bidirectional Forwarding Detection (BFD) | ||||
[RFC5880] or Simple Two-way Active Measurement Protocol (STAMP) | ||||
[RFC8762], use UDP transport and the well-known UDP port numbers as | ||||
the destination port. --> | ||||
</t> | </t> | |||
<t> | <t> | |||
Thus a DetNet node must be | Thus, a DetNet node must be | |||
able to associate an IP DetNet flow with the particular test session to ensure t hat test packets experience the | able to associate an IP DetNet flow with the particular test session to ensure t hat test packets experience the | |||
same treatment as the DetNet flow packets. For example, in a network where path selection and DetNet functionality | same treatment as the DetNet flow packets. For example, in a network where path selection and DetNet functionality | |||
are based on 3-tuples (destination and source IP addresses | are based on 3-tuples (destination and source IP addresses | |||
in combination with the Differentiated Services Code Point value) that assoc iation can be achieved | in combination with the Differentiated Services Code Point value), that assoc iation can be achieved | |||
by having the OAM traffic use the same 3-tuple as the monitored | by having the OAM traffic use the same 3-tuple as the monitored | |||
IP DetNet flow. | IP DetNet flow. | |||
In such a scenario, an IP OAM session between the same pair of IP nodes would sh are the network treatment | In such a scenario, an IP OAM session between the same pair of IP nodes would sh are the network treatment | |||
with the monitored IP DetNet flow regardless of whether ICMP, BFD, or STAMP prot ocol is used. | with the monitored IP DetNet flow regardless of whether ICMP, BFD, or STAMP is u sed. | |||
</t> | </t> | |||
<t> | <t> | |||
In IP networks, the majority of on-demand failure detection and localization is achieved through the use | In IP networks, the majority of on-demand failure detection and localization is achieved through the use | |||
of the Internet Control Message Protocol (ICMP), utilizing Echo Request and Echo Reply messages, | of ICMP, utilizing Echo Request and Echo Reply messages, | |||
along with a set of defined error messages such as Destination Unreachable, whic h provide detailed information through assigned code points. | along with a set of defined error messages such as Destination Unreachable, whic h provide detailed information through assigned code points. | |||
<xref target="RFC0792"/> and <xref target="RFC4443"/> define the ICMP for IPv4 a nd IPv6 networks, respectively. | <xref target="RFC0792"/> and <xref target="RFC4443"/> define ICMP for IPv4 and I Pv6 networks, respectively. | |||
To utilize ICMP effectively for these purposes within DetNet, DetNet nodes must establish the association | To utilize ICMP effectively for these purposes within DetNet, DetNet nodes must establish the association | |||
of ICMP traffic between DetNet nodes with IP DetNet traffic. This entails ensuri ng that such | of ICMP traffic between DetNet nodes with IP DetNet traffic. This entails ensuri ng that such | |||
ICMP traffic traverses the same interfaces and receives identical QoS treatment as the monitored DetNet IP flow. | ICMP traffic traverses the same interfaces and receives QoS treatment that is id entical to the monitored DetNet IP flow. | |||
Failure to do so may result in ICMP being unable to detect and localize failures specific to the DetNet IP data plane. | Failure to do so may result in ICMP being unable to detect and localize failures specific to the DetNet IP data plane. | |||
</t> | </t> | |||
<section anchor="native-ip-section" numbered="true" toc="default"> | <section anchor="native-ip-section" numbered="true" toc="default"> | |||
<name>Mapping Active OAM and IP DetNet flows</name> | <name>Mapping Active OAM and IP DetNet Flows</name> | |||
<t> | <t> | |||
IP OAM protocols are used to detect failures (e.g., BFD <xref target="RFC5880"/> ) | IP OAM protocols are used to detect failures (e.g., BFD <xref target="RFC5880"/> ) | |||
and performance degradation (e.g., STAMP <xref target="RFC8762"/>) that affect a n IP DetNet flow. | and performance degradation (e.g., STAMP <xref target="RFC8762"/>) that affect a n IP DetNet flow. | |||
It is essential to ensure that specially constructed OAM packets traverse the sa me set of nodes and links | It is essential to ensure that specially constructed OAM packets traverse the sa me set of nodes and links | |||
and receive the same network QoS treatment as the monitored data flow, e.g., a D etNet flow, for making active OAM useful. | and receive the same network QoS treatment as the monitored data flow, e.g., a D etNet flow, for making active OAM useful. | |||
When the UDP destination port | When the UDP destination port | |||
number used by the OAM protocol is assigned by IANA, then judicious | number used by the OAM protocol is assigned by IANA, judicious | |||
selection of the UDP source port may be able to achieve co-routedness | selection of the UDP source port may help achieve co-routedness | |||
of OAM with the monitored IP DetNet flow in multipath environments, | of OAM with the monitored IP DetNet flow in multipath environments, | |||
e.g., Link Aggregation Group or Equal Cost Multipath, via use of a | e.g., Link Aggregation Group or Equal Cost Multipath, via the use of a | |||
UDP source port value that results in the OAM traffic and the | UDP source port value that results in the OAM traffic and the | |||
monitored IP DetNet flow hashing to the same path based on the packet | monitored IP DetNet flow hashing to the same path based on the packet | |||
header hashes used for path selection. This does assume that forwarding | header hashes used for path selection. This does assume that forwarding | |||
equipment along the multipath makes consistent hashing decisions, which | equipment along the multipath makes consistent hashing decisions, which | |||
might not always be true in a heterogeneous environment. | might not always be true in a heterogeneous environment. | |||
(That also applies to encapsulation techniques described in <xref target="ip-udp | (That also applies to the encapsulation techniques described in | |||
-section"/> and <xref target="detnet-udp-section"/>.) | Sections <xref target="ip-udp-section" format="counter"/> and <xref target= | |||
"detnet-udp-section" format="counter"/>.) | ||||
To ensure the accuracy of OAM results in detecting failures and | To ensure the accuracy of OAM results in detecting failures and | |||
monitoring the performance of IP DetNet, it is essential that test packets not o nly traverse the same path as the monitored IP DetNet flow | monitoring the performance of IP DetNet, it is essential that test packets not o nly traverse the same path as the monitored IP DetNet flow | |||
but also receive the same treatment by the nodes, e.g., shaping, filtering, poli cing, and availability of the pre-allocated resources, | but also receive the same treatment by the nodes, e.g., shaping, filtering, poli cing, and availability of the pre-allocated resources, | |||
as experienced by the IP DetNet packet. That correlation between the particular IP OAM session and the monitored IP DetNet flow | as experienced by the IP DetNet packet. That correlation between the particular IP OAM session and the monitored IP DetNet flow | |||
can be achieved by using DetNet provisioning information (e.g., <xref target="I- | can be achieved by using DetNet provisioning information (e.g., <xref target="RF | |||
D.ietf-detnet-yang"/>). Each IP OAM protocol session | C9633"/>). Each IP OAM protocol session | |||
is presented as a DetNet Application with related service and forwarding sub-lay | is presented as a DetNet application with related service and forwarding sub-lay | |||
ers. The forwarding sub-layer of the IP OAM session | ers. The forwarding sub-layer of the IP OAM session | |||
is identical to the forwarding sub-layer of the monitored IP DetNet flow, except for information | is identical to the forwarding sub-layer of the monitored IP DetNet flow, except for information | |||
in the grouping ip-header, defined in <xref target="I-D.ietf-detnet-yang"/>. | in the "ip-header" grouping item as defined in <xref target="RFC9633"/>. | |||
<!-- | ||||
<!-- [rfced] Section 3.1: We had trouble following what "for making | ||||
active OAM useful" applies to. If the suggested text is not correct, | ||||
please provide clarifying text. | ||||
Original: | ||||
It is essential to ensure that specially constructed | ||||
OAM packets traverse the same set of nodes and links and receive the | ||||
same network QoS treatment as the monitored data flow, e.g., a DetNet | ||||
flow, for making active OAM useful. | ||||
Suggested: | ||||
For active OAM to be useful, it is essential to ensure that | ||||
specially constructed OAM packets traverse the same set of nodes and | ||||
links and receive the same network QoS treatment as the monitored | ||||
data flow, e.g., a DetNet flow. --> | ||||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="ip-udp-section" numbered="true" toc="default"> | <section anchor="ip-udp-section" numbered="true" toc="default"> | |||
<name>Active OAM Using IP-in-UDP Encapsulation</name> | <name>Active OAM Using IP-in-UDP Encapsulation</name> | |||
<t> | <t> | |||
As described above, active IP OAM is realized through several protocols. Some pr otocols use UDP transport, | As described above, active IP OAM is realized through several protocols. Some pr otocols use UDP transport, | |||
while ICMP is a network-layer protocol. The amount of operational work mapping I P OAM protocols | while ICMP is a network-layer protocol. The amount of operational work mapping I P OAM protocols | |||
to the monitored DetNet flow can be reduced by using an IP/UDP tunnel to carry I P test packets (<xref target="RFC2003"/>). | to the monitored DetNet flow can be reduced by using an IP/UDP tunnel to carry I P test packets <xref target="RFC2003"/>. | |||
Then, to ensure that OAM packets traverse the same set of nodes and links, the I P/UDP tunnel | Then, to ensure that OAM packets traverse the same set of nodes and links, the I P/UDP tunnel | |||
must be mapped to the monitored DetNet flow. Note that the DetNet domain for the | must be mapped to the monitored DetNet flow. Note that in such a case, the DetNe | |||
test packet | t domain for the test packet | |||
is seen as a single IP link in such a case. As a result, transit DetNet IP nodes | is seen as a single IP link. As a result, transit DetNet IP nodes cannot be trac | |||
cannot be traced | ed | |||
using the usual traceroute procedure, and a modification of the traceroute may b e required. | using the usual traceroute procedure, and a modification of the traceroute may b e required. | |||
<!-- [rfced] Section 3.2: We couldn't verify this citation, as we | ||||
don't see "test packets" or "test" mentioned in RFC 2003. Would it | ||||
help to rephrase as suggested? | ||||
Original: | ||||
The amount of operational work mapping IP | ||||
OAM protocols to the monitored DetNet flow can be reduced by using an | ||||
IP/UDP tunnel to carry IP test packets ([RFC2003]). | ||||
Suggested (move the citation): | ||||
The amount of operational work mapping IP | ||||
OAM protocols to the monitored DetNet flow can be reduced by using an | ||||
IP/UDP tunnel [RFC2003] to carry IP test packets. --> | ||||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="detnet-udp-section" numbered="true" toc="default"> | <section anchor="detnet-udp-section" numbered="true" toc="default"> | |||
<name>Active OAM Using DetNet-in-UDP Encapsulation</name> | <name>Active OAM Using DetNet-in-UDP Encapsulation</name> | |||
<t> | <t> | |||
Active OAM in IP DetNet can be realized using DetNet-in-UDP encapsulation. | Active OAM in IP DetNet can be realized using DetNet-in-UDP encapsulation. | |||
Using DetNet-in-UDP tunnel between IP DetNet nodes ensures that active OAM tes t packets follow the same path through | Using a DetNet-in-UDP tunnel between IP DetNet nodes ensures that active OAM tes t packets follow the same path through | |||
the network as the monitored IP DetNet flow packets and receive | the network as the monitored IP DetNet flow packets and receive | |||
the same forwarding treatment in the DetNet forwarding sub-layer | the same forwarding treatment in the DetNet forwarding sub-layer | |||
(see Section 4.1.2 of <xref target="RFC8655"/>) as the IP DetNet flow | (see <xref target="RFC8655" sectionFormat="of" section="4.1.2"/>) | |||
as the IP DetNet flow | ||||
being monitored. | being monitored. | |||
</t> | </t> | |||
<t> | <t> | |||
<xref target="I-D.ietf-detnet-mpls-over-ip-preof"/> describes how DetNet with MP | <xref target="RFC9566"/> describes how DetNet with the MPLS-over-UDP/IP data pla | |||
LS over UDP/IP data plane <xref target="RFC9025"/> can be used | ne <xref target="RFC9025"/> can be used | |||
to support Packet Replication, Elimination, and Ordering Functions to potentiall | to support Packet Replication, Elimination, and Ordering Functions (PREOF) to po | |||
y lower packet loss, improve the probability of on-time packet delivery | tentially lower packet loss, improve the probability of on-time packet delivery, | |||
and ensure in-order packet delivery in IP DetNet's service sub-layer. To ensure that an active OAM test packet follows the path of the monitored | and ensure in-order packet delivery in IP DetNet's service sub-layer. To ensure that an active OAM test packet follows the path of the monitored | |||
DetNet flow in the DetNet service sub-layer the encapsulation shown in <xref tar get="ip-detnet-udp-oam"/> is used. | DetNet flow in the DetNet service sub-layer, the encapsulation shown in <xref ta rget="ip-detnet-udp-oam"/> is used. | |||
</t> | </t> | |||
<figure anchor="ip-detnet-udp-oam"> | <figure anchor="ip-detnet-udp-oam"> | |||
<name>DetNet Associated Channel Header Format</name> | <name>DetNet Associated Channel Header Format</name> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | <artwork name="" type="" align="left" alt=""><![CDATA[ +--------- | |||
+---------------------------------+ | ------------------------+ | |||
| | | | | | |||
| DetNet App-Flow | | | DetNet App-Flow | | |||
| (original IP) Packet | | | (original IP) Packet | | |||
| | | | | | |||
+---------------------------------+ <--\ | +---------------------------------+ <--\ | |||
| DetNet ACH | | | | DetNet ACH | | | |||
+---------------------------------+ +--> PREOF capable | +---------------------------------+ +--> PREOF-capable | |||
| Service-ID (S-Label) | | DetNet IP data | | Service-ID (S-Label) | | DetNet IP data | |||
+---------------------------------+ | plane encapsulation | +---------------------------------+ | plane encapsulation | |||
| UDP Header | | | | UDP Header | | | |||
+---------------------------------+ | | +---------------------------------+ | | |||
| IP Header | | | | IP Header | | | |||
+---------------------------------+ <--/ | +---------------------------------+ <--/ | |||
| Data-Link | | | Data-Link | | |||
+---------------------------------+ | +---------------------------------+ | |||
| Physical | | | Physical | | |||
+---------------------------------+ | +---------------------------------+ | |||
skipping to change at line 245 ¶ | skipping to change at line 312 ¶ | |||
| Service-ID (S-Label) | | DetNet IP data | | Service-ID (S-Label) | | DetNet IP data | |||
+---------------------------------+ | plane encapsulation | +---------------------------------+ | plane encapsulation | |||
| UDP Header | | | | UDP Header | | | |||
+---------------------------------+ | | +---------------------------------+ | | |||
| IP Header | | | | IP Header | | | |||
+---------------------------------+ <--/ | +---------------------------------+ <--/ | |||
| Data-Link | | | Data-Link | | |||
+---------------------------------+ | +---------------------------------+ | |||
| Physical | | | Physical | | |||
+---------------------------------+ | +---------------------------------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> | <t> | |||
where: | Where: | |||
</t> | </t> | |||
<ul empty="true"> | <t indent="3">DetNet ACH is the DetNet Associated Channel Header defined | |||
<li>DetNet ACH is the DetNet Associated Channel Header defined in <xref | in <xref target="RFC9546"/>.</t> | |||
target="I-D.ietf-detnet-mpls-oam"/>.</li> | <t indent="3">PREOF if DetNet service sub-layer defined in <xref target= | |||
<li>PREOF - Packet Replication, Elimination, and Ordering Functions if D | "RFC8655"/>.</t> | |||
etNet service sub-layer defined in <xref target="RFC8655"/>.</li> | ||||
</ul> | <!-- [rfced] Section 3.3: This sentence/phrase does not parse; it | |||
appears that some words are missing. If the suggested text is not | ||||
correct, please clarify what "if" refers to. | ||||
Original (the previous entry is included for context): | ||||
DetNet ACH is the DetNet Associated Channel Header defined in | ||||
[I-D.ietf-detnet-mpls-oam]. | ||||
PREOF - Packet Replication, Elimination, and Ordering Functions if | ||||
DetNet service sub-layer defined in [RFC8655]. | ||||
Suggested: | ||||
DetNet ACH is the DetNet Associated Channel Header defined in | ||||
[RFC9546]. | ||||
PREOF is used for the DetNet service sub-layer as defined in | ||||
[RFC8655]. --> | ||||
</section> | </section> | |||
<section anchor="over-gre-section" numbered="true" toc="default"> | <section anchor="over-gre-section" numbered="true" toc="default"> | |||
<name>The Application of Y.1731/G.8013 Using GRE-in-UDP Encapsulation</n ame> | <name>The Application of Y.1731/G.8013 Using GRE-in-UDP Encapsulation</n ame> | |||
<t> | <t> | |||
<xref target="RFC8086" format="default"/> has defined the method of encapsulatin g GRE (Generic Routing Encapsulation) headers | <xref target="RFC8086" format="default"/> has defined the method of encapsulatin g GRE (Generic Routing Encapsulation) headers | |||
in UDP. GRE-in-UDP encapsulation can be used for IP DetNet OAM as it eases the t | in UDP. GRE-in-UDP encapsulation can be used for IP DetNet OAM, as it eases the | |||
ask of mapping an OAM test session | task of mapping an OAM test session | |||
to a particular IP DetNet flow that is identified by N-tuple. Matching a GRE-in- | to a particular IP DetNet flow that is identified by an N-tuple. Matching a GRE- | |||
UDP tunnel to the monitored IP DetNet flow | in-UDP tunnel to the monitored IP DetNet flow | |||
enables the use of Y.1731/G.8013 <xref target="ITU-T.1731" format="default"/> as | enables the use of Y.1731/G.8013 <xref target="ITU.Y1731" format="default"/> as | |||
a comprehensive toolset of OAM. The Protocol Type field | a comprehensive toolset of OAM. The Protocol Type field | |||
in GRE header must be set to 0x8902, assigned by IANA to IEEE 802.1ag Connectivi | in the GRE header must be set to 0x8902, assigned by IANA to the IEEE 802.1ag Co | |||
ty Fault Management (CFM) Protocol / ITU-T Recommendation Y.1731. | nnectivity Fault Management (CFM) protocol / ITU-T Recommendation Y.1731. | |||
Y.1731/G.8013 supports the necessary functions required for IP DetNet OAM, i.e., | Y.1731/G.8013 supports the necessary functions required for IP DetNet OAM, i.e., | |||
continuity check, one-way packet loss and packet delay measurement. | continuity checks, one-way packet loss, and packet delay measurements. | |||
</t> | </t> | |||
</section> | </section> | |||
</section> | </section> | |||
<!-- | ||||
<section anchor="hybrid-oam" title="Use of Hybrid OAM in DetNet"> | ||||
<t>Hybrid OAM methods are used in performance monitoring and defined in <xref ta | ||||
rget="RFC7799"/> as: | ||||
<list> | ||||
<t>Hybrid Methods are Methods of Measurement that use a combination of | ||||
Active Methods and Passive Methods.</t> | ||||
</list> | ||||
A hybrid measurement method may produce metrics as close to passive, | ||||
but it still alters something in a data packet even if that is the value of a | ||||
designated field in the packet encapsulation. One example of such a hybrid me | ||||
asurement method | ||||
is the Alternate Marking method (AMM) described in <xref target="RFC8321"/>. | ||||
One of the advantages | ||||
of the use of AMM in a DetNet domain with the IP data plane is that the marki | ||||
ng is applied to a data flow, | ||||
thus ensuring that measured metrics are directly applicable to the DetNet flo | ||||
w. | ||||
</t> | ||||
</section> | ||||
<section anchor="ip-over-tsn-sec" numbered="true" toc="default"> | <section anchor="ip-over-tsn-sec" numbered="true" toc="default"> | |||
<name>Active OAM for DetNet IP Interworking with OAM of non-IP DetNet doma ins</name> | <name>Active OAM for DetNet IP Interworking with OAM for Non-IP DetNet Domai ns</name> | |||
<t> | <t> | |||
A domain in which IP data plane provides DetNet service could be used | A domain in which the IP data plane provides DetNet service could be used | |||
in conjunction with a TSN and a DetNet domain with MPLS data plane to deliver en | in conjunction with a Time-Sensitive Networking (TSN) network and a DetNet domai | |||
d-to-end service. | n with the MPLS data plane to deliver end-to-end service. | |||
In such scenarios, the ability to detect defects and monitor performance using O AM is essential. | In such scenarios, the ability to detect defects and monitor performance using O AM is essential. | |||
<xref target="I-D.ietf-detnet-mpls-oam" format="default"/> identified two OAM in | <xref target="RFC9546" format="default"/> identifies two OAM interworking models | |||
terworking models - peering and tunneling. | -- peering and tunneling. | |||
Interworking between DetNet domains with IP and MPLS data planes analyzed in Sec | Interworking between DetNet domains with IP and MPLS data planes is analyzed in | |||
tion 4.2 of <xref target="I-D.ietf-detnet-mpls-oam" format="default"/>. | <xref target="RFC9546" sectionFormat="of" section="4.2"/>. | |||
In addition, OAM interworking requirements and recommendations that apply | In addition, OAM interworking requirements and recommendations that apply | |||
between a DetNet Domain with the MPLS dataplane and an adjacent TSN | between a DetNet domain with the MPLS data plane and an adjacent TSN | |||
network also apply between a DetNet domain with the IP dataplane and | network also apply between a DetNet domain with the IP data plane and | |||
an adjacent TSN network. | an adjacent TSN network. | |||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="iana-considerations" numbered="true" toc="default"> | <section anchor="iana-considerations" numbered="true" toc="default"> | |||
<name>IANA Considerations</name> | <name>IANA Considerations</name> | |||
<t> | <t> | |||
This document does not have any requests for IANA allocation. This section can be deleted before the publication of the draft. | This document has no IANA actions. | |||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="security-considerations" numbered="true" toc="default"> | <section anchor="security-considerations" numbered="true" toc="default"> | |||
<name>Security Considerations</name> | <name>Security Considerations</name> | |||
<t> | <t> | |||
This document describes the applicability of the existing Fault Management an d | This document describes the applicability of the existing Fault Management an d | |||
Performance Monitoring IP OAM protocols. | Performance Monitoring IP OAM protocols. | |||
It does not raise any security concerns or issues in addition to ones common to networking or | It does not raise any security concerns or issues in addition to those common to networking or | |||
already documented in <xref target="RFC0792"/>, <xref target="RFC4443"/>, <xr ef target="RFC5880"/>, | already documented in <xref target="RFC0792"/>, <xref target="RFC4443"/>, <xr ef target="RFC5880"/>, | |||
and <xref target="RFC8762"/> for the referenced DetNet and OAM protocols. | and <xref target="RFC8762"/> for the referenced DetNet and OAM protocols. | |||
</t> | </t> | |||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<!-- References split into informative and normative --> | ||||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references> | <references> | |||
<name>Normative References</name> | <name>Normative References</name> | |||
<!-- | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0 | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | 792.xml"/> | |||
FC.2119.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | 443.xml"/> | |||
FC.8174.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | |||
--> | 086.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.8 | |||
FC.0792.xml"/> | 655.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
FC.4443.xml"/> | <!-- draft-ietf-detnet-mpls-oam-15 (RFC 9546; published) --> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | |||
FC.8086.xml"/> | 546.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.8 | |||
FC.8655.xml"/> | 939.xml"/> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-de | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | |||
tnet-mpls-oam.xml"/> | 025.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.2 | |||
FC.8939.xml"/> | 003.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
FC.9025.xml"/> | <!-- draft-ietf-detnet-yang (RFC YYY1) | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | Note: Title updated per YANG Doctors; should be OK. In AUTH48 as of 8/19/24 | |||
FC.2003.xml"/> | --> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf- | <reference anchor="RFC9633" target="https://www.rfc-editor.org/info/rfc9633"> | |||
detnet-yang.xml"/> | <front> | |||
<!-- | <title>Deterministic Networking (DetNet) YANG Data Model</title> | |||
<?rfc include="reference.RFC.6310"?> | <author initials="X." surname="Geng" fullname="Xuesong Geng"> | |||
<?rfc include="reference.RFC.7023"?> | <organization>Huawei Technologies</organization> | |||
<?rfc include="reference.I-D.ietf-detnet-ip-over-mpls"?> | </author> | |||
<?rfc include="reference.I-D.ietf-detnet-ip-over-tsn"?> | <author initials="Y." surname="Ryoo" fullname="Yeoncheol Ryoo"> | |||
--> | <organization>ETRI</organization> | |||
</author> | ||||
<author initials="D." surname="Fedyk" fullname="Don Fedyk"> | ||||
<organization>LabN Consulting, L.L.C.</organization> | ||||
</author> | ||||
<author initials="R." surname="Rahman" fullname="Reshad Rahman"> | ||||
<organization>Equinix</organization> | ||||
</author> | ||||
<author initials="Z." surname="Li" fullname="Zhenqiang Li"> | ||||
<organization>China Mobile</organization> | ||||
</author> | ||||
<date month="August" year="2024" /> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9633"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9633"/> | ||||
</reference> | ||||
</references> | </references> | |||
<references> | <references> | |||
<name>Informational References</name> | <name>Informative References</name> | |||
<reference anchor="ITU-T.1731"> | ||||
<reference anchor="ITU.Y1731"> | ||||
<front> | <front> | |||
<title>Operations, administration and maintenance (OAM) functions an d mechanisms for Ethernet-based networks</title> | <title>Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks</title> | |||
<author> | <author> | |||
<organization>ITU-T</organization> | <organization>ITU-T</organization> | |||
</author> | </author> | |||
<date month="August" year="2015"/> | <date month="June" year="2023"/> | |||
</front> | </front> | |||
<seriesInfo name="ITU-T" value="G.8013/Y.1731"/> | <seriesInfo name="ITU-T Recommendation" value="G.8013/Y.1731"/> | |||
</reference> | </reference> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
FC.7799.xml"/> | <!-- [rfced] References: The August 2015 version of this | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | specification is marked "Superseded" on | |||
FC.8762.xml"/> | <https://www.itu.int/rec/T-REC-G.8013/en>. As the citation in | |||
<!-- <?rfc include="reference.RFC.8321"?> --> | Section 3.4 appears to be general in nature, we updated this listing | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5 | per RFC 9546 accordingly. Please let us know any concerns. | |||
880.xml"/> | ||||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5 | Original: | |||
883.xml"/> | [ITU-T.1731] | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-de | ITU-T, "Operations, administration and maintenance (OAM) | |||
tnet-oam-framework.xml"/> | functions and mechanisms for Ethernet-based networks", | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-det | ITU-T G.8013/Y.1731, August 2015. | |||
net-mpls-over-ip-preof.xml"/> | ||||
Currently: | ||||
[ITU.Y1731] | ||||
ITU-T, "Operation, administration and maintenance (OAM) | ||||
functions and mechanisms for Ethernet-based networks", | ||||
ITU-T Recommendation G.8013/Y.1731, June 2023. --> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
799.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
762.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58 | ||||
80.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58 | ||||
83.xml"/> | ||||
<!-- draft-ietf-detnet-oam-framework (RFC 9551; published) --> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95 | ||||
51.xml"/> | ||||
<!-- ietf-detnet-mpls-over-ip-preof (RFC 9566; published) --> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95 | ||||
66.xml"/> | ||||
</references> | </references> | |||
</references> | </references> | |||
</back> | </back> | |||
<!-- [rfced] Please review the "Inclusive Language" portion of the | ||||
online Style Guide at | ||||
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, | ||||
and let us know if any changes are needed. | ||||
Note that our script did not flag any words in particular, but this | ||||
should still be reviewed as a best practice. --> | ||||
</rfc> | </rfc> | |||
End of changes. 63 change blocks. | ||||
194 lines changed or deleted | 306 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |