diff options
Diffstat (limited to 'doc/rfc/rfc9551.txt')
| -rw-r--r-- | doc/rfc/rfc9551.txt | 755 |
1 files changed, 755 insertions, 0 deletions
diff --git a/doc/rfc/rfc9551.txt b/doc/rfc/rfc9551.txt new file mode 100644 index 0000000..98eb00b --- /dev/null +++ b/doc/rfc/rfc9551.txt @@ -0,0 +1,755 @@ + + + + +Internet Engineering Task Force (IETF) G. Mirsky +Request for Comments: 9551 Ericsson +Category: Informational F. Theoleyre +ISSN: 2070-1721 CNRS + G. Papadopoulos + IMT Atlantique + CJ. Bernardos + UC3M + B. Varga + J. Farkas + Ericsson + March 2024 + + + Framework of Operations, Administration, and Maintenance (OAM) for + Deterministic Networking (DetNet) + +Abstract + + Deterministic Networking (DetNet), as defined in RFC 8655, aims to + provide bounded end-to-end latency on top of the network + infrastructure, comprising both Layer 2 bridged and Layer 3 routed + segments. This document's primary purpose is to detail the specific + requirements of the Operations, Administration, and Maintenance (OAM) + recommended to maintain a deterministic network. The document will + be used in future work that defines the applicability of and + extension of OAM protocols for a deterministic network. With the + implementation of the OAM framework in DetNet, an operator will have + a real-time view of the network infrastructure regarding the + network's ability to respect the Service Level Objective (SLO), such + as packet delay, delay variation, and packet-loss ratio, assigned to + each DetNet flow. + +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/rfc9551. + +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 + 1.1. Definitions + 1.2. Requirements Language + 2. Role of OAM in DetNet + 3. Operation + 3.1. Information Collection + 3.2. Continuity Check + 3.3. Connectivity Verification + 3.4. Route Tracing + 3.5. Fault Verification/Detection + 3.6. Fault Localization and Characterization + 3.7. Use of Hybrid OAM in DetNet + 4. Administration + 4.1. Collection of Metrics + 4.2. Worst-Case Metrics + 5. Maintenance + 5.1. Replication/Elimination + 5.2. Resource Reservation + 6. Requirements + 6.1. For the DetNet Forwarding Sub-layer + 6.2. For the DetNet Service Sub-layer + 7. IANA Considerations + 8. Security Considerations + 9. Privacy Considerations + 10. References + 10.1. Normative References + 10.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + Deterministic Networking (DetNet) [RFC8655] has proposed to provide a + bounded end-to-end latency on top of the network infrastructure, + comprising both Layer 2 bridged and Layer 3 routed segments. That + work encompasses the data plane, OAM, time synchronization, + management, control, and security aspects. + + Operations, Administration, and Maintenance (OAM) tools are of + primary importance for IP networks [RFC7276]. DetNet OAM should + provide a toolset for fault detection, localization, and performance + measurement. + + This document's primary purpose is to detail the specific + requirements of the OAM features recommended to maintain a + deterministic/reliable network. Specifically, it investigates the + requirements for a deterministic network that supports critical + flows. + + In this document, the term "OAM" will be used according to its + definition specified in [RFC6291]. DetNet is expected to implement + an OAM framework to maintain a real-time view of the network + infrastructure, and its ability to respect the Service Level + Objectives (SLOs), such as in-order packet delivery, packet delay, + delay variation, and packet-loss ratio, assigned to each DetNet flow. + + This document lists the OAM functional requirements for a DetNet + domain. The list can further be used for gap analysis of available + OAM tools to identify: + + * possible enhancements of existing tools, or + + * whether new OAM tools are required to support proactive and on- + demand path monitoring and service validation. + +1.1. Definitions + + This document uses definitions, particularly of a DetNet flow, + provided in Section 2.1 of [RFC8655]. The following terms are used + throughout this document as defined below: + + DetNet OAM domain: a DetNet network used by the monitored DetNet + flow. A DetNet OAM domain (also referred to in this document as + "OAM domain") may have Maintenance End Points (MEPs) on its edge + and Maintenance Intermediate Points (MIPs) within. + + DetNet OAM instance: a function that monitors a DetNet flow for + defects and/or measures its performance metrics. Within this + document, the shorter version "OAM instance" is used + interchangeably. + + Maintenance End Point (MEP): an OAM instance that is capable of + generating OAM test packets in the particular sub-layer of the + DetNet OAM domain. + + Maintenance Intermediate Point (MIP): an OAM instance along the + DetNet flow in the particular sub-layer of the DetNet OAM domain. + An active MIP MUST respond to an OAM message generated by the MEP + at its sub-layer of the same DetNet OAM domain. + + Control and management plane: the control and management planes are + used to configure and control the network. Relative to a DetNet + flow, the control and/or management plane can be out of band. + + Active measurement methods: (as defined in [RFC7799]) these methods + modify a DetNet flow by injecting specially constructed test + packets [RFC2544]. + + Passive measurement methods: (as defined in [RFC7799]) these methods + infer information by observing unmodified existing flows. + + Hybrid measurement methods: (as defined in [RFC7799]) the + combination of elements of both active and passive measurement + methods. + + In-band OAM: an active OAM method that is in band within the + monitored DetNet OAM domain when it traverses the same set of + links and interfaces receiving the same QoS and Packet + Replication, Elimination, and Ordering Functions (PREOF) treatment + as the monitored DetNet flow. + + Out-of-band OAM: an active OAM method whose path through the DetNet + domain may not be topologically identical to the path of the + monitored DetNet flow, its test packets may receive different QoS + and/or PREOF treatment, or both. + + On-path telemetry: on-path telemetry can be realized as a hybrid OAM + method. The origination of the telemetry information is + inherently in band as packets in a DetNet flow are used as + triggers. Collection of the on-path telemetry information can be + performed using in-band or out-of-band OAM methods. + +1.2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. The requirements language is used in + Sections 1.1 and 6, and applies to the implementations of DetNet OAM. + +2. Role of OAM in DetNet + + DetNet networks are expected to provide communications with + predictable low packet delay, packet loss, and packet misordering. + Most critical applications will define a set of SLOs to be required + for the DetNet flows they generate. + + To respect strict guarantees, DetNet can use an orchestrator able to + monitor and maintain the network. Typically, a Software-Defined + Network (SDN) controller places DetNet flows in the deployed network + based on their SLOs. Thus, resources have to be provisioned a priori + for the regular operation of the network. + + Most of the existing OAM tools can be used in DetNet networks, but + they can only cover some aspects of deterministic networking. + Fulfilling strict guarantees is essential for DetNet flows, resulting + in new DetNet-specific functionalities that must be covered with OAM. + Filling these gaps is inevitable and needs accurate consideration of + DetNet specifics. Similar to DetNet flows, their OAM also needs + careful end-to-end engineering. + + For example, appropriate placing of MEPs along the path of a DetNet + flow is not always a trivial task and may require proper design + together with the design of the service component of a given DetNet + flow. + + There are several DetNet-specific challenges for OAM. Bounded + network characteristics (e.g., delay, loss) are inseparable service + parameters; therefore, Performance Monitoring (PM) OAM is a key topic + for DetNet. OAM tools are needed to monitor each SLO without + impacting the DetNet flow characteristics. A further challenge is + strict resource allocation. Resources used by OAM must be considered + and allocated to avoid disturbing DetNet flows. + + The DetNet Working Group has defined two sub-layers: + + The DetNet service sub-layer at which a DetNet service (e.g., + service protection) is provided. + + The DetNet forwarding sub-layer, which optionally provides + resource allocation for DetNet flows over paths provided by the + underlying network. + + OAM mechanisms exist for the DetNet forwarding sub-layer, but the + service sub-layer requires new OAM procedures. These new OAM + functions must allow, for example, recognizing/discovering DetNet + relay nodes, getting information about their configuration, and + checking their operation or status. + + DetNet service sub-layer functions use a sequence number for PREOF, + which creates a challenge for inserting OAM packets in the DetNet + flow. + + Fault tolerance also assumes that multiple paths could be provisioned + to maintain an end-to-end circuit by adapting to the existing + conditions. The DetNet Controller Plane, e.g., central controller/ + orchestrator, controls the PREOF on a node. OAM is expected to + support monitoring and troubleshooting PREOF on a particular node and + within the domain. + + Note that a distributed architecture of the DetNet Control Plane can + also control PREOF in those scenarios where DetNet solutions involve + more than one single central controller. + + The DetNet forwarding sub-layer is based on preexisting technologies + and has much better coverage regarding OAM. However, the forwarding + sub-layer is terminated at DetNet relay nodes, so the end-to-end OAM + state of forwarding may be created only based on the status of + multiple forwarding sub-layer segments serving a given DetNet flow + (e.g., in case of DetNet MPLS, there may be no end-to-end LSP below + the DetNet pseudowire). + +3. Operation + + OAM features will enable DetNet with robust operation both for + forwarding and routing purposes. + + It is worth noting that the test and data packets are expected to + follow the same path, i.e., connectivity verification has to be + conducted in band without impacting data traffic. It is expected + that test packets share fate with the monitored data traffic without + introducing congestion in normal network conditions. + +3.1. Information Collection + + Information about the state of the network can be collected using + several mechanisms. Some protocols, e.g., the Simple Network + Management Protocol (SNMP), poll for updated data. Other protocols, + such as YANG-Push [RFC8641], can be used to set up subscriptions for + the data defined in the YANG data models to be published periodically + or when the underlying data changes. Either way, information is + collected and sent using the DetNet Controller Plane. + + Also, we can characterize methods of transporting OAM information + relative to the path of data. For instance, OAM information may be + transported in band or out of band relative to the DetNet flow. In + the case of the former, the telemetry information uses resources + allocated for the monitored DetNet flow. If an in-band method of + transporting telemetry is used, the amount of generated information + needs to be carefully analyzed, and additional resources must be + reserved. [RFC9197] defines the in-band transport mechanism where + telemetry information is collected in the data packet on which + information is generated. Two tracing methods are described: + + * end-to-end, i.e., from the ingress and egress nodes, and + + * hop-by-hop, i.e., like end-to-end with additional information from + transit nodes. + + [RFC9326] and [HYBRID-TWO-STEP] are examples of out-of-band telemetry + transport. In the former case, information is transported by each + node traversed by the data packet of the monitored DetNet flow in a + specially constructed packet. In the latter, information is + collected in a sequence of follow-up packets that traverse the same + path as the data packet of the monitored DetNet flow. In both + methods, transport of the telemetry can avoid using resources + allocated for the DetNet domain. + +3.2. Continuity Check + + A continuity check is used to monitor the continuity of a path, i.e., + that there exists a way to deliver packets between MEP A and MEP B. + The continuity check detects a network failure in one direction: from + the MEP transmitting test packets to the remote egress MEP. The + continuity check in a DetNet OAM domain monitors the DetNet + forwarding sub-layer; thus, it is not affected by a PREOF that + operates at the DetNet service sub-layer ([RFC8655]). + +3.3. Connectivity Verification + + In addition to the Continuity Check, DetNet solutions have to verify + connectivity. This verification considers an additional constraint: + the absence of misconnection. The misconnection error state is + entered after several consecutive test packets from other DetNet + flows are received. The definition of the conditions for entry and + exit of a misconnection error state is outside the scope of this + document. Connectivity verification in a DetNet OAM domain monitors + the DetNet forwarding sub-layer; thus, it is not affected by PREOF + that operates at the DetNet service sub-layer ([RFC8655]). + +3.4. Route Tracing + + Ping and traceroute are two ubiquitous tools that help localize and + characterize a failure in the network using an echo request/reply + mechanism. They help to identify a subset of the routers in the + path. However, to be predictable, resources are reserved per flow in + DetNet. Thus, DetNet needs to define route tracing tools able to + trace the route for a specific flow. Also, tracing can be used for + the discovery of the Path Maximum Transmission Unit (PMTU) or + location of elements of PREOF for the particular route in the DetNet + domain. + + DetNet is not expected to use Equal-Cost Multipath (ECMP) [RFC8939]. + As a result, DetNet OAM in an ECMP environment is outside the scope + of this document. + +3.5. Fault Verification/Detection + + DetNet expects to operate fault-tolerant networks. Thus, mechanisms + able to detect faults before they impact network performance are + needed. + + The network has to detect when a fault has occurred, i.e., the + network has deviated from its expected behavior. Fault detection can + be based on proactive OAM protocols like continuity check or on- + demand methods like ping. While the network must report an alarm, + the cause may not be identified precisely. Examples of such alarms + are significant degradation of the end-to-end reliability or when a + buffer overflow occurs. + +3.6. Fault Localization and Characterization + + The ability to localize a network defect and provide its + characterization are necessary elements of network operation. + + Fault localization: a process of deducing the location of a network + failure from a set of observed failure indications. For example, + this might be achieved by tracing the route of the DetNet flow in + which the network failure was detected. Another method of fault + localization can correlate reports of failures from a set of + interleaved sessions monitoring path continuity. + + Fault characterization: a process of identifying the root cause of + the problem. For instance, misconfiguration or malfunction of + PREOF elements can be the cause of erroneous packet replication or + extra packets being flooded in the DetNet domain. + +3.7. Use of Hybrid OAM in DetNet + + Hybrid OAM methods are used in performance monitoring and defined in + [RFC7799] as follows: + + | Hybrid Methods are Methods of Measurement that use a combination + | of Active Methods and Passive Methods. + + A hybrid measurement method can produce metrics as close to measured + using a passive measurement method. The passive methods measure + metrics closest to the network's actual conditions. A hybrid method, + even if it alters something in a data packet, even if that is as + little as the value of a designated field in the packet + encapsulation, is considered an approximation of a passive + measurement method. One example of such a hybrid measurement method + is the Alternate-Marking Method (AMM) described in [RFC9341]. As + with all on-path telemetry methods, AMM in a DetNet domain with the + IP data plane is, by design, in band with respect to the monitored + DetNet flow. Because the marking is applied to a data flow, measured + metrics are directly applicable to the DetNet flow. AMM minimizes + the additional load on the DetNet domain by using nodal collection + and computation of performance metrics optionally in combination with + using out-of-band telemetry collection for further network analysis. + +4. Administration + + The ability to expose a collection of metrics to support an + operator's decision-making is essential. The following performance + metrics are useful: + + Queuing Delay: the time elapsed between enqueuing a packet and its + transmission to the next hop. + + Buffer occupancy: the number of packets present in the buffer for + each of the existing flows. + + Per DetNet flow: a metric reflecting end-to-end performance for a + given flow. Each of the paths has to be isolated in a multipath + routing environment. + + Per-path: detection of a misbehaving path or paths when multiple + paths are used for the service protection. + + Per-device: detection of a misbehaving device. + +4.1. Collection of Metrics + + It is important to optimize the volume and frequency of statistics/ + measurement collection, whether the mechanisms are distributed, + centralized, or both. Periodic and event-triggered collection + information characterizing the state of a network is an example of + mechanisms to achieve the optimization. + +4.2. Worst-Case Metrics + + DetNet aims to enable real-time communications on top of a + heterogeneous multi-hop architecture. To make correct decisions, the + DetNet Controller Plane [RFC8655] needs timely information about + packet losses/delays for each flow and each hop of the paths. In + other words, just the average end-to-end statistics are not enough. + The collected information must be sufficient to allow a system to + predict the worst-case scenario. + +5. Maintenance + + Service protection (provided by the DetNet Service sub-layer) is + designed to mitigate simple network failures more rapidly than the + expected response time of the DetNet Controller Plane. In the face + of events that impact network operation (e.g., link up/down, device + crash/reboot, flows starting and ending), the DetNet Controller Plane + needs to perform repair and reoptimization actions in order to + permanently ensure SLOs of all active flows with minimal waste of + resources. The Controller Plane is expected to be able to + continuously retrieve the state of the network, to evaluate + conditions and trends about the relevance of a reconfiguration, + quantifying the following: + + the cost of the suboptimality: resources may not be used optimally + (i.e., a better path exists). + + the reconfiguration cost: the DetNet Controller Plane needs an + ability to trigger some reconfigurations. For this transient + period, resources may be twice reserved, and control packets have + to be transmitted. + + Thus, reconfiguration may only be triggered if the gain is + significant. + +5.1. Replication/Elimination + + When multiple paths are reserved between two MEPs, packet replication + may be used to introduce redundancy and alleviate transmission errors + and collisions. For instance, in Figure 1, the source device S + transmits a packet to devices A and B to reach the destination node + R. + + + ===> (A) => (C) => (E) === + // \\// \\// \\ + source (S) //\\ //\\ (R) (root) + \\ // \\ // \\ // + ===> (B) => (D) => (F) === + + Figure 1: Packet Replication and Elimination Functions + +5.2. Resource Reservation + + Because the quality of service associated with a path may degrade, + the network has to provision additional resources along the path. + +6. Requirements + + According to [RFC8655], DetNet functionality is divided into + forwarding and service sub-layers. The DetNet forwarding sub-layer + includes DetNet transit nodes and may allocate resources for a DetNet + flow over paths provided by the underlay network. The DetNet service + sub-layer includes DetNet relay nodes and provides a DetNet service + (e.g., service protection). This section lists general requirements + for DetNet OAM as well as requirements in each of the DetNet sub- + layers of a DetNet domain. + + 1. It MUST be possible to initiate a DetNet OAM session from a MEP + located at a DetNet node towards a MEP or MEPs downstream from + that DetNet node within the given domain at a particular DetNet + sub-layer. + + 2. It MUST be possible to initiate a DetNet OAM session using any of + the DetNet Controller Plane solutions, e.g., a centralized + controller. + + 3. DetNet OAM MUST support proactive OAM monitoring and measurement + methods. + + 4. DetNet OAM MUST support on-demand OAM monitoring and measurement + methods. + + 5. DetNet OAM MUST support unidirectional OAM methods, continuity + checks, connectivity verification, and performance measurements. + + 6. DetNet OAM MUST support bidirectional DetNet flows, but it is not + required to support bidirectional OAM methods for bidirectional + DetNet flows. DetNet OAM test packets used for monitoring and + measurements of a bidirectional DetNet flow MUST be in band in + both directions. + + 7. DetNet OAM MUST support proactive monitoring of a DetNet device's + reachability for a given DetNet flow. + + 8. DetNet OAM MUST support hybrid performance measurement methods. + + 9. Calculated performance metrics MUST include, but are not limited + to, throughput, packet-loss, out-of-order, delay, and delay- + variation metrics. [RFC6374] provides detailed information on + performance measurement and performance metrics. + +6.1. For the DetNet Forwarding Sub-layer + + DetNet OAM MUST support: + + 1. PMTU discovery. + + 2. Remote Defect Indication (RDI) notification to the DetNet OAM + instance performing continuity checking. + + 3. the monitoring of levels of resources allocated for a particular + DetNet flow. Such resources include, but are not limited to, + buffer utilization and scheduler transmission calendar. + + 4. the monitoring of any subset of paths traversed through the + DetNet domain by a DetNet flow. + +6.2. For the DetNet Service Sub-layer + + The OAM functions for the DetNet service sub-layer allow, for + example, the recognizing/discovery of DetNet relay nodes, the + gathering of information about their configuration, and the checking + of their operation or status. + + The requirements on OAM for a DetNet relay node are that DetNet OAM + MUST: + + 1. provide OAM functions for the DetNet service sub-layer. + + 2. support the discovery of DetNet relay nodes in a DetNet network. + + 3. support the discovery of PREOF locations in the domain. + + 4. support the collection of information specific to the DetNet + service sub-layer (configuration/operation/status) from DetNet + relay nodes. + + 5. support exercising functionality of PREOF in the domain. + + 6. work for DetNet data planes: MPLS and IP. + + 7. support a defect notification mechanism, like Alarm Indication + Signal. Any DetNet relay node providing service for a given + DetNet flow MAY originate a defect notification addressed to any + subset of DetNet relay nodes along that flow. + + 8. be able to measure metrics (e.g. delay) inside a collection of + OAM sessions, specially for complex DetNet flows, with PREOF + features. + +7. IANA Considerations + + This document has no IANA actions. + +8. Security Considerations + + This document lists the OAM requirements for a DetNet domain and does + not raise any security concerns or issues in addition to ones common + to networking and those specific to DetNet that are discussed in + Section 9 of [RFC9055]. Furthermore, the analysis of OAM security + concerns in Section 6 of [RFC7276] also applies to DetNet OAM, + including the use of OAM for network reconnaissance. + +9. Privacy Considerations + + Privacy considerations of DetNet discussed in Section 13 of [RFC9055] + are also applicable to DetNet OAM. If any privacy mechanism is used + for the monitored DetNet flow, then the same privacy method MUST be + applied to the active DetNet OAM used to monitor the flow. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [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>. + +10.2. Informative References + + [HYBRID-TWO-STEP] + Mirsky, G., Lingqiang, W., Zhui, G., Song, H., and P. + Thubert, "Hybrid Two-Step Performance Measurement Method", + Work in Progress, Internet-Draft, draft-ietf-ippm-hybrid- + two-step-00, 4 October 2023, + <https://datatracker.ietf.org/doc/html/draft-ietf-ippm- + hybrid-two-step-00>. + + [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for + Network Interconnect Devices", RFC 2544, + DOI 10.17487/RFC2544, March 1999, + <https://www.rfc-editor.org/info/rfc2544>. + + [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, + D., and S. Mansfield, "Guidelines for the Use of the "OAM" + Acronym in the IETF", BCP 161, RFC 6291, + DOI 10.17487/RFC6291, June 2011, + <https://www.rfc-editor.org/info/rfc6291>. + + [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay + Measurement for MPLS Networks", RFC 6374, + DOI 10.17487/RFC6374, September 2011, + <https://www.rfc-editor.org/info/rfc6374>. + + [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. + Weingarten, "An Overview of Operations, Administration, + and Maintenance (OAM) Tools", RFC 7276, + DOI 10.17487/RFC7276, June 2014, + <https://www.rfc-editor.org/info/rfc7276>. + + [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>. + + [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications + for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, + September 2019, <https://www.rfc-editor.org/info/rfc8641>. + + [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>. + + [RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, + "Deterministic Networking (DetNet) Security + Considerations", RFC 9055, DOI 10.17487/RFC9055, June + 2021, <https://www.rfc-editor.org/info/rfc9055>. + + [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, + Ed., "Data Fields for In Situ Operations, Administration, + and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, + May 2022, <https://www.rfc-editor.org/info/rfc9197>. + + [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. + Mizrahi, "In Situ Operations, Administration, and + Maintenance (IOAM) Direct Exporting", RFC 9326, + DOI 10.17487/RFC9326, November 2022, + <https://www.rfc-editor.org/info/rfc9326>. + + [RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T., + and T. Zhou, "Alternate-Marking Method", RFC 9341, + DOI 10.17487/RFC9341, December 2022, + <https://www.rfc-editor.org/info/rfc9341>. + +Acknowledgments + + The authors express their appreciation and gratitude to Pascal + Thubert for the review, insightful questions, and helpful comments. + +Authors' Addresses + + Greg Mirsky + Ericsson + Email: gregimirsky@gmail.com + + + Fabrice Theoleyre + CNRS + ICube Lab, Pole API + 300 boulevard Sebastien Brant - CS 10413 + 67400 Illkirch - Strasbourg + France + Phone: +33 368 85 45 33 + Email: fabrice.theoleyre@cnrs.fr + URI: https://fabrice.theoleyre.cnrs.fr/ + + + Georgios Papadopoulos + IMT Atlantique + Office B00 - 102A + 2 Rue de la Châtaigneraie + 35510 Cesson-Sévigné - Rennes + France + Phone: +33 299 12 70 04 + Email: georgios.papadopoulos@imt-atlantique.fr + + + Carlos J. Bernardos + Universidad Carlos III de Madrid + Av. Universidad, 30 + 28911 Leganes, Madrid + Spain + Phone: +34 91624 6236 + Email: cjbc@it.uc3m.es + URI: http://www.it.uc3m.es/cjbc/ + + + Balazs Varga + Ericsson + Budapest + Magyar Tudosok krt. 11. + 1117 + Hungary + Email: balazs.a.varga@ericsson.com + + + Janos Farkas + Ericsson + Budapest + Magyar Tudosok krt. 11. + 1117 + Hungary + Email: janos.farkas@ericsson.com |