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