draft-ietf-detnet-oam-framework-01.txt   draft-ietf-detnet-oam-framework-02.txt 
DetNet G. Mirsky DetNet G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Intended status: Informational F. Theoleyre Intended status: Informational F. Theoleyre
Expires: 20 November 2021 CNRS Expires: 29 December 2021 CNRS
G.Z. Papadopoulos G.Z. Papadopoulos
IMT Atlantique IMT Atlantique
CJ. Bernardos CJ. Bernardos
UC3M UC3M
19 May 2021 27 June 2021
Framework of Operations, Administration and Maintenance (OAM) for Framework of Operations, Administration and Maintenance (OAM) for
Deterministic Networking (DetNet) Deterministic Networking (DetNet)
draft-ietf-detnet-oam-framework-01 draft-ietf-detnet-oam-framework-02
Abstract Abstract
Deterministic Networking (DetNet), as defined in RFC 8655, is aimed Deterministic Networking (DetNet), as defined in RFC 8655, is aimed
to provide a bounded end-to-end latency on top of the network to provide a bounded end-to-end latency on top of the network
infrastructure, comprising both Layer 2 bridged and Layer 3 routed infrastructure, comprising both Layer 2 bridged and Layer 3 routed
segments. This document's primary purpose is to detail the specific segments. This document's primary purpose is to detail the specific
requirements of the Operation, Administration, and Maintenance (OAM) requirements of the Operation, Administration, and Maintenance (OAM)
recommended to maintain a deterministic network. With the recommended to maintain a deterministic network. With the
implementation of the OAM framework in DetNet, an operator will have implementation of the OAM framework in DetNet, an operator will have
a real-time view of the network infrastructure regarding the a real-time view of the network infrastructure regarding the
network's ability to respect the Service Level Objective, such as network's ability to respect the Service Level Objective, such as
packet delay, delay variation, and packet loss ratio, assigned to packet delay, delay variation, and packet loss ratio, assigned to
each data flow. each DetNet flow.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 November 2021. This Internet-Draft will expire on 29 December 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 26 skipping to change at page 2, line 26
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Role of OAM in DetNet . . . . . . . . . . . . . . . . . . . . 4 2. Role of OAM in DetNet . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Information Collection . . . . . . . . . . . . . . . . . 5 3.1. Information Collection . . . . . . . . . . . . . . . . . 6
3.2. Continuity Check . . . . . . . . . . . . . . . . . . . . 6 3.2. Continuity Check . . . . . . . . . . . . . . . . . . . . 7
3.3. Connectivity Verification . . . . . . . . . . . . . . . . 6 3.3. Connectivity Verification . . . . . . . . . . . . . . . . 7
3.4. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Fault Verification/detection . . . . . . . . . . . . . . 6 3.5. Fault Verification/detection . . . . . . . . . . . . . . 8
3.6. Fault Localization and Characterization . . . . . . . . . 7 3.6. Fault Localization and Characterization . . . . . . . . . 8
3.7. Use of Hybrid OAM in DetNet . . . . . . . . . . . . . . . 7 3.7. Use of Hybrid OAM in DetNet . . . . . . . . . . . . . . . 8
4. Administration . . . . . . . . . . . . . . . . . . . . . . . 8 4. Administration . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Collection of metrics . . . . . . . . . . . . . . . . . . 8 4.1. Collection of metrics . . . . . . . . . . . . . . . . . . 9
4.2. Worst-case metrics . . . . . . . . . . . . . . . . . . . 8 4.2. Worst-case metrics . . . . . . . . . . . . . . . . . . . 9
5. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Replication / Elimination . . . . . . . . . . . . . . . . 9 5.1. Replication / Elimination . . . . . . . . . . . . . . . . 10
5.2. Resource Reservation . . . . . . . . . . . . . . . . . . 9 5.2. Resource Reservation . . . . . . . . . . . . . . . . . . 10
5.3. Soft transition after reconfiguration . . . . . . . . . . 10 5.3. Soft transition after reconfiguration . . . . . . . . . . 11
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Deterministic Networking (DetNet) [RFC8655] has proposed to provide a Deterministic Networking (DetNet) [RFC8655] has proposed to provide a
bounded end-to-end latency on top of the network infrastructure, bounded end-to-end latency on top of the network infrastructure,
comprising both Layer 2 bridged and Layer 3 routed segments. That comprising both Layer 2 bridged and Layer 3 routed segments. That
work encompasses the data plane, OAM, time synchronization, work encompasses the data plane, OAM, time synchronization,
management, control, and security aspects. management, control, and security aspects.
Operations, Administration, and Maintenance (OAM) Tools are of Operations, Administration, and Maintenance (OAM) Tools are of
skipping to change at page 3, line 27 skipping to change at page 3, line 27
This document's primary purpose is to detail the specific This document's primary purpose is to detail the specific
requirements of the OAM features recommended to maintain a requirements of the OAM features recommended to maintain a
deterministic/reliable network. Specifically, it investigates the deterministic/reliable network. Specifically, it investigates the
requirements for a deterministic network, supporting critical flows. requirements for a deterministic network, supporting critical flows.
In this document, the term OAM will be used according to its In this document, the term OAM will be used according to its
definition specified in [RFC6291]. DetNet expects to implement an definition specified in [RFC6291]. DetNet expects to implement an
OAM framework to maintain a real-time view of the network OAM framework to maintain a real-time view of the network
infrastructure, and its ability to respect the Service Level infrastructure, and its ability to respect the Service Level
Objectives (SLO), such as packet delay, delay variation, and packet Objectives (SLO), such as in-order packet delivery, packet delay,
loss ratio, assigned to each data flow. delay variation, and packet loss ratio, assigned to each DetNet flow.
This document lists the functional requirements toward OAM for DetNet This document lists the functional requirements toward OAM for DetNet
domain. The list can further be used for gap analysis of available domain. The list can further be used for gap analysis of available
OAM tools to identify possible enhancements of existing or whether OAM tools to identify possible enhancements of existing or whether
new OAM tools are required to support proactive and on-demand path new OAM tools are required to support proactive and on-demand path
monitoring and service validation. monitoring and service validation.
1.1. Terminology 1.1. Terminology
The following terms are used throughout this document as defined This document uses definitions, particularly of a DetNet flow,
below: provided in Section 2.1 [RFC8655]. The following terms are used
throughout this document as defined below:
* OAM entity: a data flow to be monitored for defects and/or its * DetNet OAM domain: a DetNet network used by the monitored DetNet
performance metrics measured. flow. A DetNet OAM domain (also referred to in this document as
"OAM domain") may have MEPs on its edge and MIPs within.
* Maintenance End Point (MEP): OAM systems traversed by a data flow * DetNet OAM instance: a function that monitors a DetNet flow for
when entering/exiting the network. In DetNet, it corresponds with defects and/or measures its performance metrics. Within this
the source and destination of a data flow. OAM messages can be document, a shorter version, OAM instance, is used
exchanged between two MEPs. interchangeably.
* Maintenance Intermediate endPoint (MIP): an OAM system along the * Maintenance End Point (MEP): an OAM instance that is capable of
flow; a MIP MAY respond to an OAM message generated by the MEP. generating OAM test packets in the particular sub-layer of the
DetNet OAM domain.
* Maintenance Intermediate endPoint (MIP): an OAM instance along the
DetNet flow in the particular sub-layer of the DetNet OAM domain.
A MIP MAY 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 * Control and management plane: the control and management planes
are used to configure and control the network (long-term). are used to configure and control the network (long-term).
Relative to a data flow, the control and/or management plane can Relative to a DetNet flow, the control and/or management plane can
be out-of-band. be out-of-band.
* Active measurement methods (as defined in [RFC7799]) modify a * Active measurement methods (as defined in [RFC7799]) modify a
normal data flow by inserting novel fields, injecting specially DetNet flow by inserting novel fields, injecting specially
constructed test packets [RFC2544]). constructed test packets [RFC2544]).
* Passive measurement methods [RFC7799] infer information by * Passive measurement methods [RFC7799] infer information by
observing unmodified existing flows. observing unmodified existing flows.
* Hybrid measurement methods [RFC7799] is the combination of * Hybrid measurement methods [RFC7799] is the combination of
elements of both active and passive measurement methods. elements of both active and passive measurement methods.
1.2. Acronyms 1.2. Acronyms
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
DetNet: Deterministic Networking DetNet: Deterministic Networking
SLO: Service Level Objective SLO: Service Level Objective
SNMP: Simple Network Management Protocol
SDN: Software Defined Network
<TODO> we need here an exhaustive list, to be completed after the
document has evolved.
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Role of OAM in DetNet 2. Role of OAM in DetNet
DetNet networks expect to provide communications with predictable low DetNet networks expect to provide communications with predictable low
packet delay and packet loss. Most critical applications will define packet delay and packet loss. Most critical applications will define
an SLO to be required for the data flows it generates. an SLO to be required for the DetNet flows it generates.
To respect strict guarantees, DetNet can use an orchestrator able to To respect strict guarantees, DetNet can use an orchestrator able to
monitor and maintain the network. Typically, a Software-Defined monitor and maintain the network. Typically, a Software-Defined
Network (SDN) controller places DetNet flows in the deployed network Network (SDN) controller places DetNet flows in the deployed network
based on their SLO. Thus, resources have to be provisioned a priori based on their SLO. Thus, resources have to be provisioned a priori
for the regular operation of the network. Because OAM is an for the regular operation of the network. OAM represents the
essential element of the network operation, resources, necessary for essential elements of the network operation and necessary for OAM
OAM, need to be accounted for in addition to DetNet flows. resources that need to be accounted for to maintain the network
operational.
Fault-tolerance also assumes that multiple paths could be provisioned Many legacy OAM tools can be used in DetNet networks, but they are
so that an end-to-end circuit is maintained by adapting to the not able to cover all the aspects of deterministic networking.
existing conditions. The central controller/orchestrator typically Fulfilling strict guarantees is essential for DetNet flows, resulting
controls the Packet Replication, Elimination, and Ordering Functions in new DetNet specific functionalities that must be covered with OAM.
(PREOF) on a node. OAM is expected to support monitoring and Filling these gaps is inevitable and needs accurate consideration of
troubleshooting PREOF on a particular node and within the domain. DetNet specifics. Similar to DetNet flows itself, their OAM needs
careful end-to-end engineering as well.
Note that PREOF can also be controlled by a set of distributed For example, appropriate placing of MEPs along the path of a DetNet
controllers, in those scenarios where DetNet solutions involve more flow is not always a trivial task and may require proper design
than one single central controller. 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, PM is a key topic for DetNet. OAM tools are
needed to prove the SLO without impacting the DetNet flow
characteristics. A further challenge is the strict resource
allocation. Resources used by OAM must be considered and allocated
to avoid disturbing DetNet flow(s).
The DetNet Working Group has defined two sub-layers: (1) DetNet
service sub-layer, at which a DetNet service (e.g., service
protection) is provided and (2) 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, nonetheless, OAM for the service sub-
layer requires new OAM procedures. These new OAM functions must
allow, for example, to recognize/discover DetNet relay nodes, to get
information about their configuration, and to check their operation
or status.
DetNet service sub-layer functions using a sequence number. That
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 central controller/orchestrator typically controls
the Packet Replication, Elimination, and Ordering Functions (PREOF)
on a node. OAM is expected to support monitoring and troubleshooting
PREOF on a particular node and within the domain.
Note that distributed controllers can also control PREOF in those
scenarios where DetNet solutions involve more than one single central
controller.
DetNet forwarding sub-layer is based on legacy technologies and has a
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 PW).
3. Operation 3. Operation
OAM features will enable DetNet with robust operation both for OAM features will enable DetNet with robust operation both for
forwarding and routing purposes. forwarding and routing purposes.
It is worth noting that the test and data packets MUST follow the It is worth noting that the test and data packets MUST follow the
same path, i.e., the connectivity verification has to be conducted same path, i.e., the connectivity verification has to be conducted
in-band without impacting the data traffic. Test packets MUST share in-band without impacting the data traffic. Test packets MUST share
fate with the monitored data traffic without introducing congestion fate with the monitored data traffic without introducing congestion
in normal network conditions. in normal network conditions.
3.1. Information Collection 3.1. Information Collection
Information about the state of the network can be collected using Information about the state of the network can be collected using
several mechanisms. Some protocols, e.g., Simple Network Management several mechanisms. Some protocols, e.g., Simple Network Management
Protocol (SNMP), send queries. Others, e.g., YANG-based data models, Protocol, send queries. Others, e.g., YANG-based data models,
generate notifications based on the publish-subscribe method. In generate notifications based on the publish-subscribe method. In
either way, information is collected and sent to the controller. either way, information is collected and sent to the controller.
Also, we can characterize methods of transporting OAM information Also, we can characterize methods of transporting OAM information
relative to the path of data. For instance, OAM information may be relative to the path of data. For instance, OAM information may be
transported in-band or out-of-band with the data flow. In case of transported in-band or out-of-band relative to the DetNet flow. In
the former, the telemetry information uses resources allocated for case of the former, the telemetry information uses resources
the monitored DetNet flow. If an in-band method of transporting allocated for the monitored DetNet flow. If an in-band method of
telemetry is used, the amount of generated information needs to be transporting telemetry is used, the amount of generated information
carefully analyzed, and additional resources must be reserved. needs to be carefully analyzed, and additional resources must be
[I-D.ietf-ippm-ioam-data] defines the in-band transport mechanism reserved. [I-D.ietf-ippm-ioam-data] defines the in-band transport
where telemetry information is collected in the data packet on which mechanism where telemetry information is collected in the data packet
information is generated. Two tracing methods are described - end- on which information is generated. Two tracing methods are described
to-end, i.e., from the ingress and egress nodes, and hop-by-hop, - end-to-end, i.e., from the ingress and egress nodes, and hop-by-
i.e., like end-to-end with additional information from transit nodes. hop, i.e., like end-to-end with additional information from transit
[I-D.ietf-ippm-ioam-direct-export] and nodes. [I-D.ietf-ippm-ioam-direct-export] and
[I-D.mirsky-ippm-hybrid-two-step] are examples of out-of-band [I-D.mirsky-ippm-hybrid-two-step] are examples of out-of-band
telemetry transport. In the former case, information is transported telemetry transport. In the former case, information is transported
by each node traversed by the data packet of the monitored DetNet by each node traversed by the data packet of the monitored DetNet
flow in a specially constructed packet. In the latter, information flow in a specially constructed packet. In the latter, information
is collected in a sequence of follow-up packets that traverse the 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 same path as the data packet of the monitored DetNet flow. In both
methods, transport of the telemetry can avoid using resources methods, transport of the telemetry can avoid using resources
allocated for the DetNet domain. allocated for the DetNet domain.
3.2. Continuity Check 3.2. Continuity Check
Continuity check is used to monitor the continuity of a path, i.e., Continuity check is used to monitor the continuity of a path, i.e.,
that there exists a way to deliver the packets between two endpoints that there exists a way to deliver the packets between two MEP A and
A and B. MEP B. The continuity check detects a network failure in one
direction, from the MEP transmitting test packets to the remote
egress MEP.
3.3. Connectivity Verification 3.3. Connectivity Verification
In addition to the Continuity Check, DetNet solutions have to verify In addition to the Continuity Check, DetNet solutions have to verify
the connectivity. This verification considers additional the connectivity. This verification considers additional
constraints, i.e., the absence of misconnection. The misconnection constraints, i.e., the absence of misconnection. The misconnection
error state is entered after several consecutive test packets from error state is entered after several consecutive test packets from
other DetNet flows are received. The definition of the conditions of other DetNet flows are received. The definition of the conditions of
entry and exit for misconnection error state is outside the scope of entry and exit for misconnection error state is outside the scope of
this document. this document.
skipping to change at page 6, line 39 skipping to change at page 7, line 45
Ping and traceroute are two ubiquitous tools that help localize and Ping and traceroute are two ubiquitous tools that help localize and
characterize a failure in the network. They help to identify a characterize a failure in the network. They help to identify a
subset of the list of routers in the route. However, to be subset of the list of routers in the route. However, to be
predictable, resources are reserved per flow in DetNet. Thus, DetNet predictable, resources are reserved per flow in DetNet. Thus, DetNet
needs to define route tracing tools able to track the route for a needs to define route tracing tools able to track the route for a
specific flow. Also, tracing can be used for the discovery of the specific flow. Also, tracing can be used for the discovery of the
Path Maximum Transmission Unit or location of elements of PREOF for Path Maximum Transmission Unit or location of elements of PREOF for
the particular route in the DetNet domain. the particular route in the DetNet domain.
DetNet with IP data plane is NOT RECOMMENDED to use multiple paths or DetNet is NOT RECOMMENDED to use multiple paths or links, i.e.,
links, i.e., Equal-Cost Multipath (ECMP) [RFC8939]. As the result, Equal-Cost Multipath (ECMP) [RFC8939]. As the result, OAM in ECMP
OAM in IP ECMP environment is outside the scope of this document. environment is outside the scope of this document.
3.5. Fault Verification/detection 3.5. Fault Verification/detection
DetNet expects to operate fault-tolerant networks. Thus, mechanisms DetNet expects to operate fault-tolerant networks. Thus, mechanisms
able to detect faults before they impact the network performance are able to detect faults before they impact the network performance are
needed. needed.
The network has to detect when a fault occurred, i.e., the network The network has to detect when a fault occurred, i.e., the network
has deviated from its expected behavior. While the network must has deviated from its expected behavior. While the network must
report an alarm, the cause may not be identified precisely. For report an alarm, the cause may not be identified precisely. For
skipping to change at page 8, line 18 skipping to change at page 9, line 24
operator making proper decisions, including: operator making proper decisions, including:
* Queuing Delay: the time elapsed between a packet enqueued and its * Queuing Delay: the time elapsed between a packet enqueued and its
transmission to the next hop. transmission to the next hop.
* Buffer occupancy: the number of packets present in the buffer, for * Buffer occupancy: the number of packets present in the buffer, for
each of the existing flows. each of the existing flows.
The following metrics SHOULD be collected: The following metrics SHOULD be collected:
* per virtual circuit to measure the end-to-end performance for a * per a DetNet flow to measure the end-to-end performance for a
given flow. Each of the paths has to be isolated in multipath given flow. Each of the paths has to be isolated in multipath
routing strategies. routing strategies.
* per path to detect misbehaving path when multiple paths are * per path to detect misbehaving path when multiple paths are
applied. applied.
* per device to detect misbehaving node, when it relays the packets * per device to detect misbehaving device, when it relays the
of several flows. packets of several flows.
4.1. Collection of metrics 4.1. Collection of metrics
DetNet OAM SHOULD optimize the number of statistics / measurements to DetNet OAM SHOULD optimize the number of statistics / measurements to
collected, frequency of collecting. Distributed and centralized collected, frequency of collecting. Distributed and centralized
mechanisms MAY be used in combination. Periodic and event-triggered mechanisms MAY be used in combination. Periodic and event-triggered
collection information characterizing the state of a network MAY be collection information characterizing the state of a network MAY be
used. used.
4.2. Worst-case metrics 4.2. Worst-case metrics
skipping to change at page 9, line 8 skipping to change at page 10, line 8
DetNet aims to enable real-time communications on top of a DetNet aims to enable real-time communications on top of a
heterogeneous multi-hop architecture. To make correct decisions, the heterogeneous multi-hop architecture. To make correct decisions, the
controller needs to know the distribution of packet losses/delays for controller needs to know the distribution of packet losses/delays for
each flow, and each hop of the paths. In other words, the average each flow, and each hop of the paths. In other words, the average
end-to-end statistics are not enough. The collected information must end-to-end statistics are not enough. The collected information must
be sufficient to allow the controller to predict the worst-case. be sufficient to allow the controller to predict the worst-case.
5. Maintenance 5. Maintenance
In the face of events that impact the network operation (e.g., link In the face of events that impact the network operation (e.g., link
up/down, node crash/reboot, flows starting and ending), the DetNet up/down, device crash/reboot, flows starting and ending), the DetNet
Controller need to perform repair and re-optimization actions in Controller need to perform repair and re-optimization actions in
order to permanently ensure the SLO of all active flows with minimal order to permanently ensure the SLO of all active flows with minimal
waste of resources The controller MUST be able to continuously waste of resources The controller MUST be able to continuously
retrieve the state of the network, to evaluate conditions and trends retrieve the state of the network, to evaluate conditions and trends
about the relevance of a reconfiguration, quantifying: about the relevance of a reconfiguration, quantifying:
the cost of the sub-optimality: resources may not be used the cost of the sub-optimality: resources may not be used
optimally (e.g., a better path exists). optimally (e.g., a better path exists).
the reconfiguration cost: the controller needs to trigger some the reconfiguration cost: the controller needs to trigger some
reconfigurations. For this transient period, resources may be reconfigurations. For this transient period, resources may be
twice reserved, and control packets have to be transmitted. twice reserved, and control packets have to be transmitted.
Thus, reconfiguration may only be triggered if the gain is Thus, reconfiguration may only be triggered if the gain is
significant. significant.
5.1. Replication / Elimination 5.1. Replication / Elimination
When multiple paths are reserved between two maintenance endpoints, When multiple paths are reserved between two MEPs, packet replication
packet replication may be used to introduce redundancy and alleviate may be used to introduce redundancy and alleviate transmission errors
transmission errors and collisions. For instance, in Figure 1, the and collisions. For instance, in Figure 1, the source device S is
source node S is transmitting the packet to both parents, nodes A and transmitting the packet to both parents, devices A and B. Each MEP
B. Each maintenance endpoint will decide to trigger the packet will decide to trigger the packet replication, elimination or the
replication, elimination or the ordering process when a set of ordering process when a set of metrics passes a threshold value.
metrics passes a threshold value.
===> (A) => (C) => (E) === ===> (A) => (C) => (E) ===
// \\// \\// \\ // \\// \\// \\
source (S) //\\ //\\ (R) (root) source (S) //\\ //\\ (R) (root)
\\ // \\ // \\ // \\ // \\ // \\ //
===> (B) => (D) => (F) === ===> (B) => (D) => (F) ===
Figure 1: Packet Replication: S transmits twice the same data Figure 1: Packet Replication: S transmits twice the same data
packet, to DP(A) and AP (B). packet, to DP(A) and AP (B).
5.2. Resource Reservation 5.2. Resource Reservation
Because the quality of service criteria associated with a path may Because the quality of service criteria associated with a path may
degrade, the network has to provision additional resources along the degrade, the network has to provision additional resources along the
path. We need to provide mechanisms to patch the network path. We need to provide mechanisms to patch the network
configuration. configuration.
5.3. Soft transition after reconfiguration 5.3. Soft transition after reconfiguration
Since DetNet expects to support real-time flows, DetNet OAM MUST Since DetNet expects to support real-time flows, DetNet OAM MUST
support soft-reconfiguration, where the novel resources are reserved support soft-reconfiguration, where the the additional resources are
before the ancient ones are released. Some mechanisms have to be reserved before the those previously reserved but not in use are
proposed so that packets are forwarded through the novel track only released. Some mechanisms have to be proposed so that packets are
when the resources are ready to be used, while maintaining the global forwarded through the novel track only when the resources are ready
state consistent (no packet reordering, duplication, etc.) to be used, while maintaining the global state consistent (no packet
reordering, duplication, etc.)
6. Requirements 6. Requirements
This section lists requirements for OAM in DetNet domain: This section lists requirements for OAM in a DetNet domain:
1. It MUST be possible to initiate DetNet OAM session from any 1. It MUST be possible to initiate a DetNet OAM session from a MEP
DetNet node towards another DetNet node(s) within given domain. located at a DetNet node towards downstream MEP(s) within the
given domain at a particular DetNet sub-layer. [Ed.note: FT: A
MEP may be inside the detnet domain: for instance, for PREOF, an
OAM session may be maintained between any pair of replicator /
eliminator / egress / ingress.]
2. It MUST be possible to initialize DetNet OAM session from a 2. It MUST be possible to initialize a DetNet OAM session from a
centralized controller. centralized controller.
3. DetNet OAM MUST support proactive and on-demand OAM monitoring 3. DetNet OAM MUST support proactive and on-demand OAM monitoring
and measurement methods. and measurement methods.
4. DetNet OAM packets MUST be in-band, i.e., follow precisely the 4. DetNet OAM MUST support unidirectional OAM methods, continuity
same path as DetNet data plane traffic.
5. DetNet OAM MUST support unidirectional OAM methods, continuity
check, connectivity verification, and performance measurement. check, connectivity verification, and performance measurement.
6. DetNet OAM MUST support bi-directional OAM methods. Such OAM 5. OAM methods MAY combine in-band monitoring or measurement in the
methods MAY combine in-band monitoring or measurement in the
forward direction and out-of-bound notification in the reverse forward direction and out-of-bound notification in the reverse
direction, i.e., from egress to ingress end point of the OAM direction, i.e., towards the ingress MEP.
test session.
7. DetNet OAM MUST support proactive monitoring of a DetNet node 6. DetNet OAM MUST support bi-directional DetNet flows.
availability in the given DetNet domain.
8. DetNet OAM MUST support Path Maximum Transmission Unit 7. DetNet OAM MAY support bi-directional OAM methods for
bidirectional DetNet flows. OAM test packets used for
monitoring and measurements MUST be in-band in both directions.
8. DetNet OAM MUST support proactive monitoring of a DetNet device
reachability for a given DetNet flow.
9. DetNet OAM MUST support Path Maximum Transmission Unit
discovery. discovery.
9. DetNet OAM MUST support the discovery of PREOF along a route in 10. DetNet OAM MUST support the discovery of PREOF along a route in
the given DetNet domain. the given DetNet domain.
10. DetNet OAM MUST support Remote Defect Indication (RDI) 11. DetNet OAM MUST support Remote Defect Indication (RDI)
notification to the DetNet node performing continuity checking. notification to the DetNet OAM instance performing continuity
checking.
11. DetNet OAM MUST support performance measurement methods.
12. DetNet OAM MAY support hybrid performance measurement methods. 12. DetNet OAM MAY support hybrid performance measurement methods.
13. DetNet OAM MUST support unidirectional performance measurement 13. DetNet OAM MUST support unidirectional performance measurement
methods. Calculated performance metrics MUST include but are methods. Calculated performance metrics MUST include but are
not limited to throughput, packet loss, delay and delay not limited to throughput, packet loss, out of order, delay and
variation metrics. [RFC6374] provides detailed information on delay variation metrics. [RFC6374] provides detailed
performance measurement and performance metrics. information on performance measurement and performance metrics.
14. DetNet OAM MUST support defect notification mechanism, like 14. DetNet OAM MUST be able to measure metrics (e.g. delay) inside a
Alarm Indication Signal. Any DetNet node in the given DetNet collection of OAM sessions, specially for complex DetNet flows,
domain MAY originate a defect notification addressed to any with PREOF features.
subset of nodes within the domain.
15. DetNet OAM MUST support methods to enable survivability of the 15. DetNet OAM MUST support defect notification mechanism, like
Alarm Indication Signal. Any DetNet device within the given
DetNet flow MAY originate a defect notification addressed to any
subset of DetNet devices within that flow.
16. DetNet OAM MUST support methods to enable availability of the
DetNet domain. These recovery methods MAY use protection DetNet domain. These recovery methods MAY use protection
switching and restoration. switching and restoration.
16. DetNet OAM MUST support the discovery of Packet Replication, 17. DetNet OAM MUST support the discovery of Packet Replication,
Elimination, and Order preservation sub-functions locations in Elimination, and Order preservation sub-functions locations in
the domain. the domain.
17. DetNet OAM MUST support testing of Packet Replication, 18. DetNet OAM MUST support testing of Packet Replication,
Elimination, and Order preservation sub-functions in the domain. Elimination, and Order preservation sub-functions in the domain.
18. DetNet OAM MUST support monitoring levels of resources allocated 19. DetNet OAM MUST support monitoring levels of resources allocated
for the particular DetNet flow. Such resources include but not for the particular DetNet flow. Such resources include but not
limited to buffer utilization, scheduler transmission calendar. limited to buffer utilization, scheduler transmission calendar.
19. DetNet OAM MUST support monitoring any sub-set of paths 20. DetNet OAM MUST support monitoring any sub-set of paths
traversed through the DetNet domain by the DetNet flow. traversed through the DetNet domain by the DetNet flow.
7. IANA Considerations 7. IANA Considerations
This document has no actionable requirements for IANA. This section This document has no actionable requirements for IANA. This section
can be removed before the publication. can be removed before the publication.
8. Security Considerations 8. Security Considerations
This document lists the OAM requirements for a DetNet domain and does This document lists the OAM requirements for a DetNet domain and does
skipping to change at page 12, line 18 skipping to change at page 13, line 30
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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 10.2. Informative References
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Grossman, E., Mizrahi, T., and A. J. Hacker, Grossman, E., Mizrahi, T., and A. J. Hacker,
"Deterministic Networking (DetNet) Security "Deterministic Networking (DetNet) Security
Considerations", Work in Progress, Internet-Draft, draft- Considerations", Work in Progress, Internet-Draft, draft-
ietf-detnet-security-16, 2 March 2021, ietf-detnet-security-16, 2 March 2021,
<https://tools.ietf.org/html/draft-ietf-detnet-security- <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
16>. security-16>.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", Work in Progress, Internet-Draft, draft- for In-situ OAM", Work in Progress, Internet-Draft, draft-
ietf-ippm-ioam-data-12, 21 February 2021, ietf-ippm-ioam-data-14, 24 June 2021,
<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data- <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
12>. ioam-data-14>.
[I-D.ietf-ippm-ioam-direct-export] [I-D.ietf-ippm-ioam-direct-export]
Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,
Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ
OAM Direct Exporting", Work in Progress, Internet-Draft, OAM Direct Exporting", Work in Progress, Internet-Draft,
draft-ietf-ippm-ioam-direct-export-03, 17 February 2021, draft-ietf-ippm-ioam-direct-export-03, 17 February 2021,
<https://tools.ietf.org/html/draft-ietf-ippm-ioam-direct- <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
export-03>. ioam-direct-export-03>.
[I-D.mirsky-ippm-hybrid-two-step] [I-D.mirsky-ippm-hybrid-two-step]
Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid
Two-Step Performance Measurement Method", Work in Two-Step Performance Measurement Method", Work in
Progress, Internet-Draft, draft-mirsky-ippm-hybrid-two- Progress, Internet-Draft, draft-mirsky-ippm-hybrid-two-
step-10, 17 May 2021, <https://tools.ietf.org/html/draft- step-10, 17 May 2021,
mirsky-ippm-hybrid-two-step-10>. <https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-
hybrid-two-step-10>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, Network Interconnect Devices", RFC 2544,
DOI 10.17487/RFC2544, March 1999, DOI 10.17487/RFC2544, March 1999,
<https://www.rfc-editor.org/info/rfc2544>. <https://www.rfc-editor.org/info/rfc2544>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM" D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011, DOI 10.17487/RFC6291, June 2011,
skipping to change at page 13, line 37 skipping to change at page 15, line 5
[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>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid "Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[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. [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>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
 End of changes. 50 change blocks. 
141 lines changed or deleted 197 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/