Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) Ericsson
gregimirsky@gmail.com
CNRS
ICube Lab, Pole API 300 boulevard Sebastien Brant - CS 10413 Illkirch - Strasbourg 67400 France +33 368 85 45 33 fabrice.theoleyre@cnrs.fr https://fabrice.theoleyre.cnrs.fr/
IMT Atlantique
Office B00 - 102A 2 Rue de la Châtaigneraie Cesson-Sévigné - Rennes 35510 France +33 299 12 70 04 georgios.papadopoulos@imt-atlantique.fr
Universidad Carlos III de Madrid
Av. Universidad, 30 Leganes, Madrid 28911 Spain +34 91624 6236 cjbc@it.uc3m.es http://www.it.uc3m.es/cjbc/
Ericsson
Magyar Tudosok krt. 11. Budapest Hungary 1117 balazs.a.varga@ericsson.com
Ericsson
Magyar Tudosok krt. 11. Budapest Hungary 1117 janos.farkas@ericsson.com
RTG DetNet 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 .
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 () 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
  • .  Introduction
    • .  Definitions
    • .  Requirements Language
  • .  Role of OAM in DetNet
  • .  Operation
    • .  Information Collection
    • .  Continuity Check
    • .  Connectivity Verification
    • .  Route Tracing
    • .  Fault Verification/Detection
    • .  Fault Localization and Characterization
    • .  Use of Hybrid OAM in DetNet
  • .  Administration
    • .  Collection of Metrics
    • .  Worst-Case Metrics
  • .  Maintenance
    • .  Replication/Elimination
    • .  Resource Reservation
  • .  Requirements
    • .  For the DetNet Forwarding Sub-layer
    • .  For the DetNet Service Sub-layer
  • .  IANA Considerations
  • .  Security Considerations
  • .  Privacy Considerations
  • . References
    • .  Normative References
    • .  Informative References
  • Acknowledgments
  • Authors' Addresses
Introduction Deterministic Networking (DetNet) 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 . 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 . 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.
Definitions This document uses definitions, particularly of a DetNet flow, provided in . 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 ) these methods modify a DetNet flow by injecting specially constructed test packets .
Passive measurement methods:
(as defined in ) these methods infer information by observing unmodified existing flows.
Hybrid measurement methods:
(as defined in ) 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.
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 when, and only when, they appear in all capitals, as shown here. The requirements language is used in Sections and , and applies to the implementations of DetNet OAM.
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).
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.
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 , 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. 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.
and 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.
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 ().
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 ().
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) . As a result, DetNet OAM in an ECMP environment is outside the scope of this document.
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.
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.
Use of Hybrid OAM in DetNet Hybrid OAM methods are used in performance monitoring and defined in 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 . 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.
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.
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.
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 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.
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.
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 , the source device S transmits a packet to devices A and B to reach the destination node R.
Packet Replication and Elimination Functions ===> (A) => (C) => (E) === // \\// \\// \\ source (S) //\\ //\\ (R) (root) \\ // \\ // \\ // ===> (B) => (D) => (F) ===
Resource Reservation Because the quality of service associated with a path may degrade, the network has to provision additional resources along the path.
Requirements According to , 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. provides detailed information on performance measurement and performance metrics.
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.
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.
IANA Considerations This document has no IANA actions.
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 . Furthermore, the analysis of OAM security concerns in also applies to DetNet OAM, including the use of OAM for network reconnaissance.
Privacy Considerations Privacy considerations of DetNet discussed in 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.
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Deterministic Networking Architecture This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1. Informative References Hybrid Two-Step Performance Measurement Method Ericsson ZTE Corporation ZTE Corporation Futurewei Technologies Cisco Systems, Inc Development of, and advancements in, automation of network operations brought new requirements for measurement methodology. Among them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. This document introduces a new hybrid measurement method, referred to as hybrid two-step, as it separates the act of measuring and/or calculating the performance metric from the act of collecting and transporting network state. Work in Progress Benchmarking Methodology for Network Interconnect Devices This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community. Guidelines for the Use of the "OAM" Acronym in the IETF At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again. This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice. Packet Loss and Delay Measurement for MPLS Networks Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK] An Overview of Operations, Administration, and Maintenance (OAM) Tools Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary. Active and Passive Metrics and Methods (with Hybrid Types In-Between) This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge. Subscription to YANG Notifications for Datastore Updates This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. Deterministic Networking (DetNet) Data Plane: IP This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938). Deterministic Networking (DetNet) Security Considerations A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e., "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties. This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection. This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents. Data Fields for In Situ Operations, Administration, and Maintenance (IOAM) In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAM Direct Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document. Alternate-Marking Method This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321.
Acknowledgments The authors express their appreciation and gratitude to for the review, insightful questions, and helpful comments.
Authors' Addresses Ericsson
gregimirsky@gmail.com
CNRS
ICube Lab, Pole API 300 boulevard Sebastien Brant - CS 10413 Illkirch - Strasbourg 67400 France +33 368 85 45 33 fabrice.theoleyre@cnrs.fr https://fabrice.theoleyre.cnrs.fr/
IMT Atlantique
Office B00 - 102A 2 Rue de la Châtaigneraie Cesson-Sévigné - Rennes 35510 France +33 299 12 70 04 georgios.papadopoulos@imt-atlantique.fr
Universidad Carlos III de Madrid
Av. Universidad, 30 Leganes, Madrid 28911 Spain +34 91624 6236 cjbc@it.uc3m.es http://www.it.uc3m.es/cjbc/
Ericsson
Magyar Tudosok krt. 11. Budapest Hungary 1117 balazs.a.varga@ericsson.com
Ericsson
Magyar Tudosok krt. 11. Budapest Hungary 1117 janos.farkas@ericsson.com