doc: Add RFC documents

1 files changed, 403 insertions, 0 deletions

diff --git a/doc/rfc/rfc9634.txt b/doc/rfc/rfc9634.txt
new file mode 100644
index 0000000..5f74248
--- /dev/null
+++ b/doc/rfc/rfc9634.txt
@@ -0,0 +1,403 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         G. Mirsky
+Request for Comments: 9634                                      Ericsson
+Category: Informational                                          M. Chen
+ISSN: 2070-1721                                                   Huawei
+                                                                D. Black
+                                                                Dell EMC
+                                                            October 2024
+
+
+  Operations, Administration, and Maintenance (OAM) for Deterministic
+               Networking (DetNet) with the IP Data Plane
+
+Abstract
+
+   This document discusses the use of existing IP Operations,
+   Administration, and Maintenance protocols and mechanisms in
+   Deterministic Networking networks that use the IP data plane.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   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.
+
+   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 (c) 2024 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Conventions Used in This Document
+     2.1.  Terminology
+   3.  Active OAM for DetNet Networks with the IP Data Plane
+     3.1.  Mapping Active OAM and IP DetNet Flows
+     3.2.  Active OAM Using IP-in-UDP Encapsulation
+     3.3.  Active OAM Using DetNet-in-UDP Encapsulation
+     3.4.  The Application of Y.1731/G.8013 Using GRE-in-UDP
+           Encapsulation
+   4.  Active OAM for DetNet IP Interworking with OAM for Non-IP
+           DetNet Domains
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Authors' Addresses
+
+1.  Introduction
+
+   [RFC8655] introduces and explains the Deterministic Networking
+   (DetNet) architecture.
+
+   Operations, Administration, and Maintenance (OAM) protocols are used
+   to detect and localize defects in the network as well as to monitor
+   network performance.  Some OAM functions (e.g., failure detection)
+   work in the network proactively, while others (e.g., defect
+   localization) are usually performed on demand.  These tasks are
+   achieved by a combination of active and hybrid OAM methods, as
+   defined in [RFC7799].
+
+   [RFC9551] lists the OAM functional requirements for DetNet and
+   defines the principles for OAM use within DetNet networks utilizing
+   the IP data plane.  The functional requirements can be compared
+   against current OAM tools to identify gaps and potential enhancements
+   required to enable proactive and on-demand path monitoring and
+   service validation.
+
+   This document discusses the use of existing IP OAM protocols and
+   mechanisms in DetNet networks that use the IP data plane.
+
+2.  Conventions Used in This Document
+
+2.1.  Terminology
+
+   The term "DetNet OAM" as used in this document means "a set of OAM
+   protocols, methods, and tools for Deterministic Networking".
+
+   DetNet:  Deterministic Networking
+
+   OAM:  Operations, Administration, and Maintenance
+
+   ICMP:  Internet Control Message Protocol
+
+   Underlay Network or Underlay Layer:  The network that provides
+      connectivity between DetNet nodes.  MPLS networks providing Label
+      Switched Path (LSP) connectivity between DetNet nodes are an
+      example of the DetNet IP network underlay layer.
+
+   DetNet Node:  A node that is an actor in the DetNet domain.  DetNet
+      domain edge nodes and nodes that perform the Packet Replication,
+      Elimination, and Ordering Functions within the domain are examples
+      of a DetNet node.
+
+3.  Active OAM for DetNet Networks with the IP Data Plane
+
+   OAM protocols and mechanisms act within the data plane of the
+   particular networking layer.  Thus, it is critical that the data
+   plane encapsulation support OAM mechanisms and enable them to be
+   configured so that DetNet OAM packets follow the same path
+   (unidirectional or bidirectional) through the network and receive the
+   same forwarding treatment in the DetNet forwarding sub-layer as the
+   DetNet flow being monitored.
+
+   The DetNet data plane encapsulation in a transport network with IP
+   encapsulations is specified in Section 6 of [RFC8939].  For the IP
+   underlay network, DetNet flows are identified by the ordered match to
+   the provisioned information set that, among other elements, includes
+   the IP protocol type, source port number, and destination port
+   number.  Active IP OAM protocols like Bidirectional Forwarding
+   Detection (BFD) [RFC5880] or the Simple Two-way Active Measurement
+   Protocol (STAMP) [RFC8762] use UDP transport and the well-known UDP
+   port numbers as the respective destination ports.  For BFD, the UDP
+   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
+   the particular test session to ensure that test packets experience
+   the 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 in combination with the
+   Differentiated Services Code Point value), that association can be
+   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
+   between the same pair of IP nodes would share the network treatment
+   with the monitored IP DetNet flow regardless of whether ICMP, BFD, or
+   STAMP is used.
+
+   In IP networks, the majority of on-demand failure detection and
+   localization is achieved through the use of ICMP, utilizing Echo
+   Request and Echo Reply messages, along with a set of defined error
+   messages such as Destination Unreachable, which provide detailed
+   information through assigned code points.  [RFC0792] and [RFC4443]
+   define ICMP for IPv4 and IPv6 networks, respectively.  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 ensuring that such ICMP traffic
+   traverses the same interfaces and receives QoS treatment that is
+   identical 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.
+
+3.1.  Mapping Active OAM and IP DetNet Flows
+
+   IP OAM protocols are used to detect failures (e.g., BFD [RFC5880])
+   and performance degradation (e.g., STAMP [RFC8762]) that affect an IP
+   DetNet flow.  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.  When the UDP destination port number
+   used by the OAM protocol is assigned by IANA, judicious selection of
+   the UDP source port may help achieve co-routedness of OAM with the
+   monitored IP DetNet flow in multipath environments, 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 monitored
+   IP DetNet flow hashing to the same path based on the packet header
+   hashes used for path selection.  This does assume that forwarding
+   equipment along the multipath makes consistent hashing decisions,
+   which might not always be true in a heterogeneous environment.  (That
+   also applies to the encapsulation techniques described in
+   Sections 3.2 and 3.3.)  To ensure the accuracy of OAM results in
+   detecting failures and monitoring the performance of IP DetNet, it is
+   essential that test packets not only traverse the same path as the
+   monitored IP DetNet flow but also receive the same treatment by the
+   nodes, e.g., shaping, filtering, policing, 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 can be achieved by using DetNet provisioning
+   information (e.g., [RFC9633]).  Each IP OAM protocol session is
+   presented as a DetNet application with related service and forwarding
+   sub-layers.  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 in the "ip-header" grouping item as
+   defined in [RFC9633].
+
+3.2.  Active OAM Using IP-in-UDP Encapsulation
+
+   As described above, active IP OAM is realized through several
+   protocols.  Some protocols use UDP transport, while ICMP is a
+   network-layer protocol.  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.  Then, to ensure
+   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 in
+   such a case, the DetNet domain for the test packet is seen as a
+   single IP link.  As a result, transit DetNet IP nodes cannot be
+   traced using the usual traceroute procedure, and a modification of
+   the traceroute may be required.
+
+3.3.  Active OAM Using DetNet-in-UDP Encapsulation
+
+   Active OAM in IP DetNet can be realized using DetNet-in-UDP
+   encapsulation.  Using a DetNet-in-UDP tunnel between IP DetNet nodes
+   ensures that active OAM test packets follow the same path through the
+   network as the monitored IP DetNet flow packets and receive the same
+   forwarding treatment in the DetNet forwarding sub-layer (see
+   Section 4.1.2 of [RFC8655]) as the IP DetNet flow being monitored.
+
+   [RFC9566] describes how DetNet with the MPLS-over-UDP/IP data plane
+   [RFC9025] can be used to support Packet Replication, Elimination, and
+   Ordering Functions (PREOF) to potentially 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 DetNet flow
+   in the DetNet service sub-layer, the encapsulation shown in Figure 1
+   is used.
+
+         +---------------------------------+
+         |                                 |
+         |         DetNet App-Flow         |
+         |       (original IP) Packet      |
+         |                                 |
+         +---------------------------------+ <--\
+         |            DetNet ACH           |    |
+         +---------------------------------+    +--> PREOF-capable
+         |       Service-ID (S-Label)      |    |    DetNet IP data
+         +---------------------------------+    |    plane encapsulation
+         |            UDP Header           |    |
+         +---------------------------------+    |
+         |            IP Header            |    |
+         +---------------------------------+ <--/
+         |            Data-Link            |
+         +---------------------------------+
+         |             Physical            |
+         +---------------------------------+
+
+             Figure 1: DetNet Associated Channel Header Format
+
+   *  DetNet ACH - the DetNet Associated Channel Header as defined in
+      [RFC9546].
+
+   *  PREOF - Packet Replication, Elimination, and Ordering Functions
+      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
+
+   [RFC8086] has defined the method of encapsulating GRE (Generic
+   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 session to a particular IP DetNet flow that is identified by an
+   N-tuple.  Matching a GRE-in-UDP tunnel to the monitored IP DetNet
+   flow enables the use of Y.1731/G.8013 [ITU.Y1731] as a comprehensive
+   toolset of OAM.  The Protocol Type field in the GRE header must be
+   set to 0x8902, assigned by IANA to the IEEE 802.1ag Connectivity
+   Fault Management (CFM) protocol / ITU-T Recommendation Y.1731.
+   Y.1731/G.8013 supports the necessary functions required for IP DetNet
+   OAM, i.e., continuity checks, one-way packet loss, and packet delay
+   measurements.
+
+4.  Active OAM for DetNet IP Interworking with OAM for Non-IP DetNet
+    Domains
+
+   A domain in which the IP data plane provides DetNet service could be
+   used in conjunction with a Time-Sensitive Networking (TSN) network
+   and a DetNet domain with the MPLS data plane to deliver end-to-end
+   service.  In such scenarios, the ability to detect defects and
+   monitor performance using OAM is essential.  [RFC9546] identifies two
+   OAM interworking models -- peering and tunneling.  Interworking
+   between DetNet domains with IP and MPLS data planes is analyzed in
+   Section 4.2 of [RFC9546].  In addition, OAM interworking requirements
+   and recommendations that apply between a DetNet domain with the MPLS
+   data plane and an adjacent TSN network also apply between a DetNet
+   domain with the IP data plane and an adjacent TSN network.
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  Security Considerations
+
+   This document describes the applicability of the existing Fault
+   Management and Performance Monitoring IP OAM protocols.  It does not
+   raise any security concerns or issues in addition to those common to
+   networking or already documented in [RFC0792], [RFC4443], [RFC5880],
+   and [RFC8762] for the referenced DetNet and OAM protocols.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
+              RFC 792, DOI 10.17487/RFC0792, September 1981,
+              <https://www.rfc-editor.org/info/rfc792>.
+
+   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
+              DOI 10.17487/RFC2003, October 1996,
+              <https://www.rfc-editor.org/info/rfc2003>.
+
+   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+              Control Message Protocol (ICMPv6) for the Internet
+              Protocol Version 6 (IPv6) Specification", STD 89,
+              RFC 4443, DOI 10.17487/RFC4443, March 2006,
+              <https://www.rfc-editor.org/info/rfc4443>.
+
+   [RFC8086]  Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
+              in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
+              March 2017, <https://www.rfc-editor.org/info/rfc8086>.
+
+   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
+              "Deterministic Networking Architecture", RFC 8655,
+              DOI 10.17487/RFC8655, October 2019,
+              <https://www.rfc-editor.org/info/rfc8655>.
+
+   [RFC8939]  Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
+              Bryant, "Deterministic Networking (DetNet) Data Plane:
+              IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
+              <https://www.rfc-editor.org/info/rfc8939>.
+
+   [RFC9025]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
+              Bryant, "Deterministic Networking (DetNet) Data Plane:
+              MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April
+              2021, <https://www.rfc-editor.org/info/rfc9025>.
+
+   [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>.
+
+   [RFC9633]  Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li,
+              "Deterministic Networking (DetNet) YANG Data Model",
+              RFC 9633, DOI 10.17487/RFC9633, October 2024,
+              <https://www.rfc-editor.org/info/rfc9633>.
+
+7.2.  Informative References
+
+   [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.
+
+   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
+              <https://www.rfc-editor.org/info/rfc5880>.
+
+   [RFC5883]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
+              June 2010, <https://www.rfc-editor.org/info/rfc5883>.
+
+   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
+              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
+              May 2016, <https://www.rfc-editor.org/info/rfc7799>.
+
+   [RFC8762]  Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
+              Two-Way Active Measurement Protocol", RFC 8762,
+              DOI 10.17487/RFC8762, March 2020,
+              <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
+
+   Greg Mirsky
+   Ericsson
+   Email: gregimirsky@gmail.com
+
+
+   Mach(Guoyi) Chen
+   Huawei
+   Email: mach.chen@huawei.com
+
+
+   David Black
+   Dell EMC
+   176 South Street
+   Hopkinton, MA 01748
+   United States of America
+   Email: david.black@dell.com