rfc9634.original | rfc9634.txt | |||
---|---|---|---|---|
DetNet Working Group G. Mirsky | Internet Engineering Task Force (IETF) G. Mirsky | |||
Internet-Draft Ericsson | Request for Comments: 9634 Ericsson | |||
Intended status: Informational M. Chen | Category: Informational M. Chen | |||
Expires: 17 August 2024 Huawei | ISSN: 2070-1721 Huawei | |||
D. Black | D. Black | |||
Dell EMC | Dell EMC | |||
14 February 2024 | August 2024 | |||
Operations, Administration, and Maintenance (OAM) for Deterministic | Operations, Administration, and Maintenance (OAM) for Deterministic | |||
Networks (DetNet) with IP Data Plane | Networking (DetNet) with the IP Data Plane | |||
draft-ietf-detnet-ip-oam-13 | ||||
Abstract | Abstract | |||
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. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||
approved by the IESG are candidates for any level of Internet | ||||
Standard; see Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on 17 August 2024. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc9634. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction | |||
2. Conventions used in this document . . . . . . . . . . . . . . 3 | 2. Conventions Used in This Document | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Terminology | |||
3. Active OAM for DetNet Networks with the IP Data Plane . . . . 3 | 3. Active OAM for DetNet Networks with the IP Data Plane | |||
3.1. Mapping Active OAM and IP DetNet flows . . . . . . . . . 4 | 3.1. Mapping Active OAM and IP DetNet Flows | |||
3.2. Active OAM Using IP-in-UDP Encapsulation . . . . . . . . 5 | 3.2. Active OAM Using IP-in-UDP Encapsulation | |||
3.3. Active OAM Using DetNet-in-UDP Encapsulation . . . . . . 5 | 3.3. Active OAM Using DetNet-in-UDP Encapsulation | |||
3.4. The Application of Y.1731/G.8013 Using GRE-in-UDP | 3.4. The Application of Y.1731/G.8013 Using GRE-in-UDP | |||
Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 | Encapsulation | |||
4. Active OAM for DetNet IP Interworking with OAM of non-IP DetNet | 4. Active OAM for DetNet IP Interworking with OAM for Non-IP | |||
domains . . . . . . . . . . . . . . . . . . . . . . . . . 7 | DetNet Domains | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 5. IANA Considerations | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 6. Security Considerations | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 7. References | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 | 7.1. Normative References | |||
7.2. Informational References . . . . . . . . . . . . . . . . 8 | 7.2. Informative References | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
[RFC8655] introduces and explains Deterministic Networks (DetNet) | [RFC8655] introduces and explains the Deterministic Networking | |||
architecture. | (DetNet) architecture. | |||
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 | to detect and localize defects in the network as well as to monitor | |||
network performance. Some OAM functions (e.g., failure detection), | network performance. Some OAM functions (e.g., failure detection) | |||
work in the network proactively, while others (e.g., defect | work in the network proactively, while others (e.g., defect | |||
localization) are usually performed on-demand. These tasks are | localization) are usually performed on demand. These tasks are | |||
achieved by a combination of active and hybrid OAM methods, as | achieved by a combination of active and hybrid OAM methods, as | |||
defined in [RFC7799]. | defined in [RFC7799]. | |||
[I-D.ietf-detnet-oam-framework] lists the OAM functional requirements | [RFC9551] lists the OAM functional requirements for DetNet and | |||
for DetNet, and defines the principles for OAM use within DetNet | defines the principles for OAM use within DetNet networks utilizing | |||
networks utilizing the IP data plane. The functional requirements | the IP data plane. The functional requirements can be compared | |||
can be compared against current OAM tools to identify gaps and | against current OAM tools to identify gaps and potential enhancements | |||
potential enhancements required to enable proactive and on-demand | required to enable proactive and on-demand path monitoring and | |||
path monitoring and service validation. | service validation. | |||
This document discusses the use of existing IP OAM protocols and | This document discusses the use of existing IP OAM protocols and | |||
mechanisms in DetNet networks that use the IP data plane. | mechanisms in DetNet networks that use the IP data plane. | |||
2. Conventions used in this document | 2. Conventions Used in This Document | |||
2.1. Terminology | 2.1. Terminology | |||
The term "DetNet OAM" used in this document interchangeably with | The term "DetNet OAM" as used in this document means "a set of OAM | |||
longer version "set of OAM protocols, methods and tools for | protocols, methods, and tools for Deterministic Networking". | |||
Deterministic Networks". | ||||
DetNet: Deterministic Networks | DetNet: Deterministic Networking | |||
OAM: Operations, Administration, and Maintenance | OAM: Operations, Administration, and Maintenance | |||
ICMP: Internet Control Message Protocol | ICMP: Internet Control Message Protocol | |||
Underlay Network or Underlay Layer: The network that provides | Underlay Network or Underlay Layer: The network that provides | |||
connectivity between DetNet nodes. MPLS networks providing LSP | connectivity between DetNet nodes. MPLS networks providing Label | |||
connectivity between DetNet nodes are an example of the DetNet IP | Switched Path (LSP) connectivity between DetNet nodes are an | |||
network underlay layer. | example of the DetNet IP network underlay layer. | |||
DetNet Node: a node that is an actor in the DetNet domain. DetNet | DetNet Node: A node that is an actor in the DetNet domain. DetNet | |||
domain edge nodes and nodes that perform the Packet Replication and | domain edge nodes and nodes that perform the Packet Replication, | |||
Elimination Function within the domain are examples of a DetNet node. | Elimination, and Ordering Functions within the domain are examples | |||
of a DetNet node. | ||||
3. Active OAM for DetNet Networks with the IP Data Plane | 3. Active OAM for DetNet Networks with the IP Data Plane | |||
OAM protocols and mechanisms act within the data plane of the | OAM protocols and mechanisms act within the data plane of the | |||
particular networking layer. Thus, it is critical that the data | particular networking layer. Thus, it is critical that the data | |||
plane encapsulation supports OAM mechanisms and enables them to be | plane encapsulation support OAM mechanisms and 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 the | (unidirectional or bidirectional) through the network and receive the | |||
same forwarding treatment in the DetNet forwarding sub-layer as the | same forwarding treatment in the DetNet forwarding sub-layer as the | |||
DetNet flow being monitored. | DetNet flow being monitored. | |||
The DetNet data plane encapsulation in a transport network with IP | The DetNet data plane encapsulation in a transport network with IP | |||
encapsulations is specified in Section 6 of [RFC8939]. For the IP | encapsulations is specified in Section 6 of [RFC8939]. For the IP | |||
underlay network, DetNet flows are identified by the ordered match to | underlay network, DetNet flows are identified by the ordered match to | |||
the provisioned information set that, among other elements, includes | the provisioned information set that, among other elements, includes | |||
the IP protocol, source port number, destination port number. Active | the IP protocol type, source port number, and destination port | |||
IP OAM protocols like Bidirectional Forwarding Detection (BFD) | number. Active IP OAM protocols like Bidirectional Forwarding | |||
[RFC5880] or Simple Two-way Active Measurement Protocol (STAMP) | Detection (BFD) [RFC5880] or the Simple Two-way Active Measurement | |||
[RFC8762], use UDP transport and the well-known UDP port numbers as | Protocol (STAMP) [RFC8762] use UDP transport and the well-known UDP | |||
the destination port. For BFD, the UDP destination port is specific | port numbers as the respective destination ports. For BFD, the UDP | |||
to the BFD variant, e.g., Multihop BFD uses port 4784 [RFC5883]. | destination port is specific to the BFD variant, e.g., multihop BFD | |||
uses port 4784 [RFC5883]. | ||||
Thus a DetNet node must be able to associate an IP DetNet flow with | Thus, a DetNet node must be able to associate an IP DetNet flow with | |||
the particular test session to ensure that test packets experience | the particular test session to ensure that test packets experience | |||
the same treatment as the DetNet flow packets. For example, in a | the same treatment as the DetNet flow packets. For example, in a | |||
network where path selection and DetNet functionality are based on | network where path selection and DetNet functionality are based on | |||
3-tuples (destination and source IP addresses in combination with the | 3-tuples (destination and source IP addresses in combination with the | |||
Differentiated Services Code Point value) that association can be | Differentiated Services Code Point value), that association can be | |||
achieved by having the OAM traffic use the same 3-tuple as the | achieved by having the OAM traffic use the same 3-tuple as the | |||
monitored IP DetNet flow. In such a scenario, an IP OAM session | monitored IP DetNet flow. In such a scenario, an IP OAM session | |||
between the same pair of IP nodes would share the network treatment | between the same pair of IP nodes would share the network treatment | |||
with the monitored IP DetNet flow regardless of whether ICMP, BFD, or | with the monitored IP DetNet flow regardless of whether ICMP, BFD, or | |||
STAMP protocol is used. | STAMP is used. | |||
In IP networks, the majority of on-demand failure detection and | In IP networks, the majority of on-demand failure detection and | |||
localization is achieved through the use of the Internet Control | localization is achieved through the use of ICMP, utilizing Echo | |||
Message Protocol (ICMP), utilizing Echo Request and Echo Reply | Request and Echo Reply messages, along with a set of defined error | |||
messages, along with a set of defined error messages such as | messages such as Destination Unreachable, which provide detailed | |||
Destination Unreachable, which provide detailed information through | information through assigned code points. [RFC0792] and [RFC4443] | |||
assigned code points. [RFC0792] and [RFC4443] define the ICMP for | define ICMP for IPv4 and IPv6 networks, respectively. To utilize | |||
IPv4 and IPv6 networks, respectively. To utilize ICMP effectively | ICMP effectively for these purposes within DetNet, DetNet nodes must | |||
for these purposes within DetNet, DetNet nodes must establish the | establish the association of ICMP traffic between DetNet nodes with | |||
association of ICMP traffic between DetNet nodes with IP DetNet | IP DetNet traffic. This entails ensuring that such ICMP traffic | |||
traffic. This entails ensuring that such ICMP traffic traverses the | traverses the same interfaces and receives QoS treatment that is | |||
same interfaces and receives identical QoS treatment as the monitored | identical to the monitored DetNet IP flow. Failure to do so may | |||
DetNet IP flow. Failure to do so may result in ICMP being unable to | result in ICMP being unable to detect and localize failures specific | |||
detect and localize failures specific to the DetNet IP data plane. | to the DetNet IP data plane. | |||
3.1. Mapping Active OAM and IP DetNet flows | 3.1. Mapping Active OAM and IP DetNet Flows | |||
IP OAM protocols are used to detect failures (e.g., BFD [RFC5880]) | IP OAM protocols are used to detect failures (e.g., BFD [RFC5880]) | |||
and performance degradation (e.g., STAMP [RFC8762]) that affect an IP | and performance degradation (e.g., STAMP [RFC8762]) that affect an IP | |||
DetNet flow. It is essential to ensure that specially constructed | DetNet flow. For active OAM to be useful, it is essential to ensure | |||
OAM packets traverse the same set of nodes and links and receive the | that specially constructed OAM packets traverse the same set of nodes | |||
same network QoS treatment as the monitored data flow, e.g., a DetNet | and links and receive the same network QoS treatment as the monitored | |||
flow, for making active OAM useful. When the UDP destination port | data flow, e.g., a DetNet flow. When the UDP destination port number | |||
number used by the OAM protocol is assigned by IANA, then judicious | used by the OAM protocol is assigned by IANA, judicious selection of | |||
selection of the UDP source port may be able to achieve co-routedness | the UDP source port may help achieve co-routedness of OAM with the | |||
of OAM with the monitored IP DetNet flow in multipath environments, | monitored IP DetNet flow in multipath environments, e.g., Link | |||
e.g., Link Aggregation Group or Equal Cost Multipath, via use of a | Aggregation Group or Equal Cost Multipath, via the use of a UDP | |||
UDP source port value that results in the OAM traffic and the | source port value that results in the OAM traffic and the monitored | |||
monitored IP DetNet flow hashing to the same path based on the packet | IP DetNet flow hashing to the same path based on the packet header | |||
header hashes used for path selection. This does assume that | hashes used for path selection. This does assume that forwarding | |||
forwarding equipment along the multipath makes consistent hashing | equipment along the multipath makes consistent hashing decisions, | |||
decisions, which might not always be true in a heterogeneous | which might not always be true in a heterogeneous environment. (That | |||
environment. (That also applies to encapsulation techniques | also applies to the encapsulation techniques described in | |||
described in Section 3.2 and Section 3.3.) To ensure the accuracy of | Sections 3.2 and 3.3.) To ensure the accuracy of OAM results in | |||
OAM results in detecting failures and monitoring the performance of | detecting failures and monitoring the performance of IP DetNet, it is | |||
IP DetNet, it is essential that test packets not only traverse the | essential that test packets not only traverse the same path as the | |||
same path as the monitored IP DetNet flow but also receive the same | monitored IP DetNet flow but also receive the same treatment by the | |||
treatment by the nodes, e.g., shaping, filtering, policing, and | nodes, e.g., shaping, filtering, policing, and availability of the | |||
availability of the pre-allocated resources, as experienced by the IP | pre-allocated resources, as experienced by the IP DetNet packet. | |||
DetNet packet. That correlation between the particular IP OAM | That correlation between the particular IP OAM session and the | |||
session and the monitored IP DetNet flow can be achieved by using | monitored IP DetNet flow can be achieved by using DetNet provisioning | |||
DetNet provisioning information (e.g., [I-D.ietf-detnet-yang]). Each | information (e.g., [RFC9633]). Each IP OAM protocol session is | |||
IP OAM protocol session is presented as a DetNet Application with | presented as a DetNet application with related service and forwarding | |||
related service and forwarding sub-layers. The forwarding sub-layer | sub-layers. The forwarding sub-layer of the IP OAM session is | |||
of the IP OAM session is identical to the forwarding sub-layer of the | identical to the forwarding sub-layer of the monitored IP DetNet | |||
monitored IP DetNet flow, except for information in the grouping ip- | flow, except for information in the "ip-header" grouping item as | |||
header, defined in [I-D.ietf-detnet-yang]. | defined in [RFC9633]. | |||
3.2. Active OAM Using IP-in-UDP Encapsulation | 3.2. Active OAM Using IP-in-UDP Encapsulation | |||
As described above, active IP OAM is realized through several | As described above, active IP OAM is realized through several | |||
protocols. Some protocols use UDP transport, while ICMP is a | protocols. Some protocols use UDP transport, while ICMP is a | |||
network-layer protocol. The amount of operational work mapping IP | network-layer protocol. The amount of operational work mapping IP | |||
OAM protocols to the monitored DetNet flow can be reduced by using an | OAM protocols to the monitored DetNet flow can be reduced by using an | |||
IP/UDP tunnel to carry IP test packets ([RFC2003]). Then, to ensure | IP/UDP tunnel [RFC2003] to carry IP test packets. Then, to ensure | |||
that OAM packets traverse the same set of nodes and links, the IP/UDP | that OAM packets traverse the same set of nodes and links, the IP/UDP | |||
tunnel must be mapped to the monitored DetNet flow. Note that the | tunnel must be mapped to the monitored DetNet flow. Note that in | |||
DetNet domain for the test packet is seen as a single IP link in such | such a case, the DetNet domain for the test packet is seen as a | |||
a case. As a result, transit DetNet IP nodes cannot be traced using | single IP link. As a result, transit DetNet IP nodes cannot be | |||
the usual traceroute procedure, and a modification of the traceroute | traced using the usual traceroute procedure, and a modification of | |||
may be required. | the traceroute may be required. | |||
3.3. Active OAM Using DetNet-in-UDP Encapsulation | 3.3. Active OAM Using DetNet-in-UDP Encapsulation | |||
Active OAM in IP DetNet can be realized using DetNet-in-UDP | Active OAM in IP DetNet can be realized using DetNet-in-UDP | |||
encapsulation. Using DetNet-in-UDP tunnel between IP DetNet nodes | encapsulation. Using a DetNet-in-UDP tunnel between IP DetNet nodes | |||
ensures that active OAM test packets follow the same path through the | ensures that active OAM test packets follow the same path through the | |||
network as the monitored IP DetNet flow packets and receive the same | network as the monitored IP DetNet flow packets and receive the same | |||
forwarding treatment in the DetNet forwarding sub-layer (see | forwarding treatment in the DetNet forwarding sub-layer (see | |||
Section 4.1.2 of [RFC8655]) as the IP DetNet flow being monitored. | Section 4.1.2 of [RFC8655]) as the IP DetNet flow being monitored. | |||
[I-D.ietf-detnet-mpls-over-ip-preof] describes how DetNet with MPLS | [RFC9566] describes how DetNet with the MPLS-over-UDP/IP data plane | |||
over UDP/IP data plane [RFC9025] can be used to support Packet | [RFC9025] can be used to support Packet Replication, Elimination, and | |||
Replication, Elimination, and Ordering Functions to potentially lower | Ordering Functions (PREOF) to potentially lower packet loss, improve | |||
packet loss, improve the probability of on-time packet delivery and | the probability of on-time packet delivery, and ensure in-order | |||
ensure in-order packet delivery in IP DetNet's service sub-layer. To | packet delivery in IP DetNet's service sub-layer. To ensure that an | |||
ensure that an active OAM test packet follows the path of the | active OAM test packet follows the path of the monitored DetNet flow | |||
monitored DetNet flow in the DetNet service sub-layer the | in the DetNet service sub-layer, the encapsulation shown in Figure 1 | |||
encapsulation shown in Figure 1 is used. | is used. | |||
+---------------------------------+ | +---------------------------------+ | |||
| | | | | | |||
| 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 | | |||
+---------------------------------+ | +---------------------------------+ | |||
Figure 1: DetNet Associated Channel Header Format | Figure 1: DetNet Associated Channel Header Format | |||
where: | * DetNet ACH - the DetNet Associated Channel Header as defined in | |||
[RFC9546]. | ||||
DetNet ACH is the DetNet Associated Channel Header defined in | ||||
[I-D.ietf-detnet-mpls-oam]. | ||||
PREOF - Packet Replication, Elimination, and Ordering Functions if | * PREOF - Packet Replication, Elimination, and Ordering Functions | |||
DetNet service sub-layer defined in [RFC8655]. | used in the DetNet service sub-layer as defined in [RFC8655]. | |||
3.4. The Application of Y.1731/G.8013 Using GRE-in-UDP Encapsulation | 3.4. The Application of Y.1731/G.8013 Using GRE-in-UDP Encapsulation | |||
[RFC8086] has defined the method of encapsulating GRE (Generic | [RFC8086] has defined the method of encapsulating GRE (Generic | |||
Routing Encapsulation) headers in UDP. GRE-in-UDP encapsulation can | Routing Encapsulation) headers in UDP. GRE-in-UDP encapsulation can | |||
be used for IP DetNet OAM as it eases the task of mapping an OAM test | be used for IP DetNet OAM, as it eases the task of mapping an OAM | |||
session to a particular IP DetNet flow that is identified by N-tuple. | test session to a particular IP DetNet flow that is identified by an | |||
Matching a GRE-in-UDP tunnel to the monitored IP DetNet flow enables | N-tuple. Matching a GRE-in-UDP tunnel to the monitored IP DetNet | |||
the use of Y.1731/G.8013 [ITU-T.1731] as a comprehensive toolset of | flow enables the use of Y.1731/G.8013 [ITU.Y1731] as a comprehensive | |||
OAM. The Protocol Type field in GRE header must be set to 0x8902, | toolset of OAM. The Protocol Type field in the GRE header must be | |||
assigned by IANA to IEEE 802.1ag Connectivity Fault Management (CFM) | set to 0x8902, assigned by IANA to the IEEE 802.1ag Connectivity | |||
Protocol / ITU-T Recommendation Y.1731. Y.1731/G.8013 supports the | Fault Management (CFM) protocol / ITU-T Recommendation Y.1731. | |||
necessary functions required for IP DetNet OAM, i.e., continuity | Y.1731/G.8013 supports the necessary functions required for IP DetNet | |||
check, one-way packet loss and packet delay measurement. | OAM, i.e., continuity checks, one-way packet loss, and packet delay | |||
measurements. | ||||
4. Active OAM for DetNet IP Interworking with OAM of non-IP DetNet | 4. Active OAM for DetNet IP Interworking with OAM for Non-IP DetNet | |||
domains | Domains | |||
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 | |||
in conjunction with a TSN and a DetNet domain with MPLS data plane to | used in conjunction with a Time-Sensitive Networking (TSN) network | |||
deliver end-to-end service. In such scenarios, the ability to detect | and a DetNet domain with the MPLS data plane to deliver end-to-end | |||
defects and monitor performance using OAM is essential. | service. In such scenarios, the ability to detect defects and | |||
[I-D.ietf-detnet-mpls-oam] identified two OAM interworking models - | monitor performance using OAM is essential. [RFC9546] identifies two | |||
peering and tunneling. Interworking between DetNet domains with IP | OAM interworking models -- peering and tunneling. Interworking | |||
and MPLS data planes analyzed in Section 4.2 of | between DetNet domains with IP and MPLS data planes is analyzed in | |||
[I-D.ietf-detnet-mpls-oam]. In addition, OAM interworking | Section 4.2 of [RFC9546]. In addition, OAM interworking requirements | |||
requirements and recommendations that apply between a DetNet Domain | and recommendations that apply between a DetNet domain with the MPLS | |||
with the MPLS dataplane and an adjacent TSN network also apply | data plane and an adjacent TSN network also apply between a DetNet | |||
between a DetNet domain with the IP dataplane and an adjacent TSN | domain with the IP data plane and an adjacent TSN network. | |||
network. | ||||
5. IANA Considerations | 5. IANA Considerations | |||
This document does not have any requests for IANA allocation. This | This document has no IANA actions. | |||
section can be deleted before the publication of the draft. | ||||
6. Security Considerations | 6. Security Considerations | |||
This document describes the applicability of the existing Fault | This document describes the applicability of the existing Fault | |||
Management and Performance Monitoring IP OAM protocols. It does not | Management and Performance Monitoring IP OAM protocols. It does not | |||
raise any security concerns or issues in addition to ones common to | raise any security concerns or issues in addition to those common to | |||
networking or already documented in [RFC0792], [RFC4443], [RFC5880], | networking or already documented in [RFC0792], [RFC4443], [RFC5880], | |||
and [RFC8762] for the referenced DetNet and OAM protocols. | and [RFC8762] for the referenced DetNet and OAM protocols. | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[I-D.ietf-detnet-mpls-oam] | ||||
Mirsky, G., Chen, M., and B. Varga, "Operations, | ||||
Administration and Maintenance (OAM) for Deterministic | ||||
Networks (DetNet) with MPLS Data Plane", Work in Progress, | ||||
Internet-Draft, draft-ietf-detnet-mpls-oam-15, 12 January | ||||
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- | ||||
detnet-mpls-oam-15>. | ||||
[I-D.ietf-detnet-yang] | ||||
Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, | ||||
"Deterministic Networking (DetNet) YANG Model", Work in | ||||
Progress, Internet-Draft, draft-ietf-detnet-yang-19, 25 | ||||
January 2024, <https://datatracker.ietf.org/doc/html/ | ||||
draft-ietf-detnet-yang-19>. | ||||
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | |||
RFC 792, DOI 10.17487/RFC0792, September 1981, | RFC 792, DOI 10.17487/RFC0792, September 1981, | |||
<https://www.rfc-editor.org/info/rfc792>. | <https://www.rfc-editor.org/info/rfc792>. | |||
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, | [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, | |||
DOI 10.17487/RFC2003, October 1996, | DOI 10.17487/RFC2003, October 1996, | |||
<https://www.rfc-editor.org/info/rfc2003>. | <https://www.rfc-editor.org/info/rfc2003>. | |||
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet | [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet | |||
Control Message Protocol (ICMPv6) for the Internet | Control Message Protocol (ICMPv6) for the Internet | |||
skipping to change at page 8, line 38 ¶ | skipping to change at line 335 ¶ | |||
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. | [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. | |||
Bryant, "Deterministic Networking (DetNet) Data Plane: | Bryant, "Deterministic Networking (DetNet) Data Plane: | |||
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, | IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, | |||
<https://www.rfc-editor.org/info/rfc8939>. | <https://www.rfc-editor.org/info/rfc8939>. | |||
[RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. | [RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. | |||
Bryant, "Deterministic Networking (DetNet) Data Plane: | Bryant, "Deterministic Networking (DetNet) Data Plane: | |||
MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April | MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April | |||
2021, <https://www.rfc-editor.org/info/rfc9025>. | 2021, <https://www.rfc-editor.org/info/rfc9025>. | |||
7.2. Informational References | [RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations, | |||
Administration, and Maintenance (OAM) for Deterministic | ||||
Networking (DetNet) with the MPLS Data Plane", RFC 9546, | ||||
DOI 10.17487/RFC9546, February 2024, | ||||
<https://www.rfc-editor.org/info/rfc9546>. | ||||
[I-D.ietf-detnet-mpls-over-ip-preof] | [RFC9633] Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, | |||
Varga, B., Farkas, J., and A. G. Malis, "Deterministic | "Deterministic Networking (DetNet) YANG Data Model", | |||
Networking (DetNet): DetNet PREOF via MPLS over UDP/IP", | RFC 9633, DOI 10.17487/RFC9633, August 2024, | |||
Work in Progress, Internet-Draft, draft-ietf-detnet-mpls- | <https://www.rfc-editor.org/info/rfc9633>. | |||
over-ip-preof-09, 8 February 2024, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-detnet- | ||||
mpls-over-ip-preof-09>. | ||||
[I-D.ietf-detnet-oam-framework] | 7.2. Informative References | |||
Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos, | ||||
C. J., Varga, B., and J. Farkas, "Framework of Operations, | ||||
Administration and Maintenance (OAM) for Deterministic | ||||
Networking (DetNet)", Work in Progress, Internet-Draft, | ||||
draft-ietf-detnet-oam-framework-11, 8 January 2024, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-detnet- | ||||
oam-framework-11>. | ||||
[ITU-T.1731] | [ITU.Y1731] | |||
ITU-T, "Operations, administration and maintenance (OAM) | ITU-T, "Operation, administration and maintenance (OAM) | |||
functions and mechanisms for Ethernet-based networks", | functions and mechanisms for Ethernet-based networks", | |||
ITU-T G.8013/Y.1731, August 2015. | ITU-T Recommendation G.8013/Y.1731, June 2023. | |||
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | |||
<https://www.rfc-editor.org/info/rfc5880>. | <https://www.rfc-editor.org/info/rfc5880>. | |||
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, | (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, | |||
June 2010, <https://www.rfc-editor.org/info/rfc5883>. | June 2010, <https://www.rfc-editor.org/info/rfc5883>. | |||
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | |||
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | |||
May 2016, <https://www.rfc-editor.org/info/rfc7799>. | May 2016, <https://www.rfc-editor.org/info/rfc7799>. | |||
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple | [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple | |||
Two-Way Active Measurement Protocol", RFC 8762, | Two-Way Active Measurement Protocol", RFC 8762, | |||
DOI 10.17487/RFC8762, March 2020, | DOI 10.17487/RFC8762, March 2020, | |||
<https://www.rfc-editor.org/info/rfc8762>. | <https://www.rfc-editor.org/info/rfc8762>. | |||
[RFC9551] Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos, | ||||
CJ., Varga, B., and J. Farkas, "Framework of Operations, | ||||
Administration, and Maintenance (OAM) for Deterministic | ||||
Networking (DetNet)", RFC 9551, DOI 10.17487/RFC9551, | ||||
March 2024, <https://www.rfc-editor.org/info/rfc9551>. | ||||
[RFC9566] Varga, B., Farkas, J., and A. Malis, "Deterministic | ||||
Networking (DetNet) Packet Replication, Elimination, and | ||||
Ordering Functions (PREOF) via MPLS over UDP/IP", | ||||
RFC 9566, DOI 10.17487/RFC9566, April 2024, | ||||
<https://www.rfc-editor.org/info/rfc9566>. | ||||
Authors' Addresses | Authors' Addresses | |||
Greg Mirsky | Greg Mirsky | |||
Ericsson | Ericsson | |||
Email: gregimirsky@gmail.com | Email: gregimirsky@gmail.com | |||
Mach(Guoyi) Chen | Mach(Guoyi) Chen | |||
Huawei | Huawei | |||
Email: mach.chen@huawei.com | Email: mach.chen@huawei.com | |||
David Black | David Black | |||
Dell EMC | Dell EMC | |||
176 South Street | 176 South Street | |||
Hopkinton, MA, 01748 | Hopkinton, MA 01748 | |||
United States of America | United States of America | |||
Email: david.black@dell.com | Email: david.black@dell.com | |||
End of changes. 48 change blocks. | ||||
200 lines changed or deleted | 188 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |