< draft-ietf-detnet-oam-framework-00.txt | draft-ietf-detnet-oam-framework-01.txt > | |||
---|---|---|---|---|
DetNet G. Mirsky | DetNet G. Mirsky | |||
Internet-Draft ZTE Corp. | Internet-Draft ZTE Corp. | |||
Intended status: Standards Track F. Theoleyre | Intended status: Informational F. Theoleyre | |||
Expires: 27 October 2021 CNRS | Expires: 10 November 2021 CNRS | |||
G.Z. Papadopoulos | G.Z. Papadopoulos | |||
IMT Atlantique | IMT Atlantique | |||
CJ. Bernardos | CJ. Bernardos | |||
UC3M | UC3M | |||
25 April 2021 | 9 May 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-00 | draft-ietf-detnet-oam-framework-01 | |||
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 | |||
skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
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 27 October 2021. | This Internet-Draft will expire on 10 November 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 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
extracted from this document must include Simplified BSD License text | extracted from this document must include Simplified BSD License text | |||
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 . . . . . . . . . . . . . . . . . . . . 5 | 2. Role of OAM in DetNet . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. Information Collection . . . . . . . . . . . . . . . . . 5 | 3.1. Information Collection . . . . . . . . . . . . . . . . . 5 | |||
3.2. Continuity Check . . . . . . . . . . . . . . . . . . . . 6 | 3.2. Continuity Check . . . . . . . . . . . . . . . . . . . . 6 | |||
3.3. Connectivity Verification . . . . . . . . . . . . . . . . 6 | 3.3. Connectivity Verification . . . . . . . . . . . . . . . . 6 | |||
3.4. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 6 | 3.4. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.5. Fault Verification/detection . . . . . . . . . . . . . . 6 | 3.5. Fault Verification/detection . . . . . . . . . . . . . . 6 | |||
3.6. Fault Isolation/identification . . . . . . . . . . . . . 7 | 3.6. Fault Localization and Characterization . . . . . . . . . 7 | |||
3.7. Use of Hybrid OAM in DetNet . . . . . . . . . . . . . . . 7 | 3.7. Use of Hybrid OAM in DetNet . . . . . . . . . . . . . . . 7 | |||
4. Administration . . . . . . . . . . . . . . . . . . . . . . . 7 | 4. Administration . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
4.1. Collection of metrics . . . . . . . . . . . . . . . . . . 8 | 4.1. Collection of metrics . . . . . . . . . . . . . . . . . . 8 | |||
4.2. Worst-case metrics . . . . . . . . . . . . . . . . . . . 8 | 4.2. Worst-case metrics . . . . . . . . . . . . . . . . . . . 8 | |||
5. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5.1. Replication / Elimination . . . . . . . . . . . . . . . . 8 | 5.1. Replication / Elimination . . . . . . . . . . . . . . . . 9 | |||
5.2. Resource Reservation . . . . . . . . . . . . . . . . . . 9 | 5.2. Resource Reservation . . . . . . . . . . . . . . . . . . 9 | |||
5.3. Soft transition after reconfiguration . . . . . . . . . . 9 | 5.3. Soft transition after reconfiguration . . . . . . . . . . 10 | |||
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 | 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 11 | 10.2. Informative References . . . . . . . . . . . . . . . . . 12 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
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. Their | 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 | |||
primary importance for IP networks [RFC7276]. DetNet OAM should | primary importance for IP networks [RFC7276]. DetNet OAM should | |||
provide a toolset for fault detection, localization, and performance | provide a toolset for fault detection, localization, and performance | |||
measurement. | measurement. | |||
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 | |||
skipping to change at page 3, line 38 ¶ | skipping to change at page 3, line 38 ¶ | |||
loss ratio, assigned to each data flow. | loss ratio, assigned to each data 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 througout this document as defined | The following terms are used throughout this document as defined | |||
below: | below: | |||
* OAM entity: a data flow to be monitored for defects and/or its | * OAM entity: a data flow to be monitored for defects and/or its | |||
performance metrics measured. | performance metrics measured. | |||
* Maintenance End Point (MEP): OAM systems traversed by a data flow | * Maintenance End Point (MEP): OAM systems traversed by a data flow | |||
when entering/exiting the network. In DetNet, it corresponds with | when entering/exiting the network. In DetNet, it corresponds with | |||
the source and destination of a data flow. OAM messages can be | the source and destination of a data flow. OAM messages can be | |||
exchanged between two MEPs. | exchanged between two MEPs. | |||
* Maintenance Intermediate endPoint (MIP): an OAM system along the | * Maintenance Intermediate endPoint (MIP): an OAM system along the | |||
flow; a MIP MAY respond to an OAM message generated by the MEP. | flow; a MIP MAY respond to an OAM message generated by the MEP. | |||
* 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 data 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 | normal data flow by inserting novel fields, injecting specially | |||
constructed test packets [RFC2544]). It is critical for the | constructed test packets [RFC2544]). | |||
quality of information obtained using an active method that | ||||
generated test packets are in-band with the monitored data flow. | ||||
In other words, a test packet is required to cross the same | ||||
network nodes and links and receive the same Quality of Service | ||||
(QoS) treatment as a data packet. | ||||
* 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 | |||
QoS: Quality of Service | ||||
SNMP: Simple Network Management Protocol | SNMP: Simple Network Management Protocol | |||
SDN: Software Defined Network | SDN: Software Defined Network | |||
<TODO> we need here an exhaustive list, to be completed after the | <TODO> we need here an exhaustive list, to be completed after the | |||
document has evolved. | 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", | |||
skipping to change at page 5, line 14 ¶ | skipping to change at page 4, line 52 ¶ | |||
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 data 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 the SLO. Thus, resources have to be provisioned a | based on their SLO. Thus, resources have to be provisioned a priori | |||
priori for the regular operation of the network. OAM represents the | for the regular operation of the network. Because OAM is an | |||
essential elements of the network operation and necessary for OAM | essential element of the network operation, resources, necessary for | |||
resources that need to be accounted for to maintain the network | OAM, need to be accounted for in addition to DetNet flows. | |||
operational. | ||||
Fault-tolerance also assumes that multiple paths could be provisioned | Fault-tolerance also assumes that multiple paths could be provisioned | |||
so that an end-to-end circuit is maintained by adapting to the | so that an end-to-end circuit is maintained by adapting to the | |||
existing conditions. The central controller/orchestrator typically | existing conditions. The central controller/orchestrator typically | |||
controls the Packet Replication, Elimination, and Ordering Functions | controls the Packet Replication, Elimination, and Ordering Functions | |||
(PREOF) on a node. OAM is expected to support monitoring and | (PREOF) on a node. OAM is expected to support monitoring and | |||
troubleshooting PREOF on a particular node and within the domain. | troubleshooting PREOF on a particular node and within the domain. | |||
Note that PREOF can also be controlled by a set of distributed | Note that PREOF can also be controlled by a set of distributed | |||
controllers, in those scenarios where DetNet solutions involve more | controllers, in those scenarios where DetNet solutions involve more | |||
than one single central controller. | than one single central controller. | |||
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 | ||||
same path, i.e., the connectivity verification has to be conducted | ||||
in-band without impacting the data traffic. Test packets MUST share | ||||
fate with the monitored data traffic without introducing congestion | ||||
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 (SNMP), 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 about the state of the network being | either way, information is collected and sent to the controller. | |||
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 out-of-band or in-band with the data flow. | transported in-band or out-of-band with the data flow. In 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. | ||||
[I-D.ietf-ippm-ioam-data] 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. | ||||
[I-D.ietf-ippm-ioam-direct-export] and | ||||
[I-D.mirsky-ippm-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 | 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 endpoints | |||
A and B. | A and B. | |||
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. | constraints, i.e., the absence of misconnection. The misconnection | |||
error state is entered after several consecutive test packets from | ||||
In particular, resources have to be reserved for a given flow, so | other DetNet flows are received. The definition of the conditions of | |||
they are booked for use without being impacted by other flows. | entry and exit for misconnection error state is outside the scope of | |||
Similarly, the destination does not receive packets from different | this document. | |||
flows through its interface. | ||||
It is worth noting that the test and data packets MUST follow the | ||||
same path, i.e., the connectivity verification has to be conducted | ||||
in-band without impacting the data traffic. Test packets MUST share | ||||
fate with the monitored data traffic without introducing congestion | ||||
in normal network conditions. | ||||
3.4. Route Tracing | 3.4. Route Tracing | |||
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. | specific flow. Also, tracing can be used for the discovery of the | |||
Path Maximum Transmission Unit or location of elements of PREOF for | ||||
the particular route in the DetNet domain. | ||||
DetNet with IP data plane is NOT RECOMMENDED to use multiple paths or | DetNet with IP data plane is NOT RECOMMENDED to use multiple paths or | |||
links, i.e., Equal-Cost Multipath (ECMP) [RFC8939]. As the result, | links, i.e., Equal-Cost Multipath (ECMP) [RFC8939]. As the result, | |||
OAM in IP ECMP environment is outside the scope of this document. | OAM in IP ECMP 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. | |||
skipping to change at page 7, line 10 ¶ | skipping to change at page 7, line 16 ¶ | |||
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 | |||
instance, the end-to-end reliability has decreased significantly, or | instance, the end-to-end reliability has decreased significantly, or | |||
a buffer overflow occurs. | a buffer overflow occurs. | |||
DetNet OAM mechanisms SHOULD allow a fault detection in real time. | DetNet OAM mechanisms SHOULD allow a fault detection in real time. | |||
They MAY, when possible, predict faults based on current network | They MAY, when possible, predict faults based on current network | |||
conditions. They MAY also identify and report the cause of the | conditions. They MAY also identify and report the cause of the | |||
actual/predicted network failure. | actual/predicted network failure. | |||
3.6. Fault Isolation/identification | 3.6. Fault Localization and Characterization | |||
The network has isolated and identified the cause of the fault. For | An ability to localize the network defect and provide its | |||
instance, the replication process behaves not as expected to a | characterization are necessary elements of network operation. | |||
specific intermediary router. | ||||
Fault localization, a process of deducing the location of a | ||||
network failure from a set of observed failure indications, might | ||||
be achieved, for example, 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 | ||||
interleaving sessions monitoring path continuity. | ||||
Fault characterization is 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 | 3.7. Use of Hybrid OAM in DetNet | |||
Hybrid OAM methods are used in performance monitoring and defined in | Hybrid OAM methods are used in performance monitoring and defined in | |||
[RFC7799] as: | [RFC7799] as: | |||
Hybrid Methods are Methods of Measurement that use a combination | Hybrid Methods are Methods of Measurement that use a combination | |||
of Active Methods and Passive Methods. | of Active Methods and Passive Methods. | |||
A hybrid measurement method may produce metrics as close to passive, | A hybrid measurement method may produce metrics as close to passive, | |||
but it still alters something in a data packet even if that is the | but it still alters something in a data packet even if that is the | |||
value of a designated field in the packet encapsulation. One example | value of a designated field in the packet encapsulation. One example | |||
of such a hybrid measurement method is the Alternate Marking method | of such a hybrid measurement method is the Alternate Marking method | |||
(AMM) described in [RFC8321]. One of the advantages of the use of | (AMM) described in [RFC8321]. As with all on-path telemetry methods, | |||
AMM in a DetNet domain with the IP data plane is that the marking is | AMM in a DetNet domain with the IP data plane is natively in-band in | |||
applied to a data flow, thus ensuring that measured metrics are | respect to the monitored DetNet flow. Because the marking is applied | |||
directly applicable to the DetNet flow. | 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 in | ||||
combination with optionally using out-of-band telemetry collection | ||||
for further network analysis. | ||||
4. Administration | 4. Administration | |||
The network SHOULD expose a collection of metrics to support an | The network SHOULD expose a collection of metrics to support an | |||
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 | |||
skipping to change at page 8, line 27 ¶ | skipping to change at page 9, line 7 ¶ | |||
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 | |||
DetNet needs to implement a self-healing and self-optimization | In the face of events that impact the network operation (e.g., link | |||
approach. The controller MUST be able to continuously retrieve the | up/down, node crash/reboot, flows starting and ending), the DetNet | |||
state of the network, to evaluate conditions and trends about the | Controller need to perform repair and re-optimization actions in | |||
relevance of a reconfiguration, quantifying: | order to permanently ensure the SLO of all active flows with minimal | |||
waste of resources The controller MUST be able to continuously | ||||
retrieve the state of the network, to evaluate conditions and trends | ||||
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. | |||
skipping to change at page 9, line 16 ¶ | skipping to change at page 9, line 46 ¶ | |||
// \\// \\// \\ | // \\// \\// \\ | |||
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 QoS criteria associated with a path may degrade, the | Because the quality of service criteria associated with a path may | |||
network has to provision additional resources along the path. We | degrade, the network has to provision additional resources along the | |||
need to provide mechanisms to patch the network configuration. | path. We need to provide mechanisms to patch the network | |||
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 novel resources are reserved | |||
before the ancient ones are released. Some mechanisms have to be | before the ancient ones are released. Some mechanisms have to be | |||
proposed so that packets are forwarded through the novel track only | proposed so that packets are forwarded through the novel track only | |||
when the resources are ready to be used, while maintaining the global | when the resources are ready to be used, while maintaining the global | |||
state consistent (no packet reordering, duplication, etc.) | state consistent (no packet reordering, duplication, etc.) | |||
6. Requirements | 6. Requirements | |||
This section lists requirements for OAM in DetNet domain with MPLS | This section lists requirements for OAM in DetNet domain: | |||
data plane: | ||||
1. It MUST be possible to initiate DetNet OAM session from any | 1. It MUST be possible to initiate DetNet OAM session from any | |||
DetNet node towards another DetNet node(s) within given domain. | DetNet node towards another DetNet node(s) within given domain. | |||
2. It SHOULD be possible to initialize DetNet OAM session from a | 2. It MUST be possible to initialize 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 packets MUST be in-band, i.e., follow precisely the | |||
same path as DetNet data plane traffic. | same path as DetNet data plane traffic. | |||
5. DetNet OAM MUST support unidirectional OAM methods, continuity | 5. DetNet OAM MUST support unidirectional OAM methods, continuity | |||
check, connectivity verification, and performance measurement. | check, connectivity verification, and performance measurement. | |||
skipping to change at page 10, line 17 ¶ | skipping to change at page 10, line 45 ¶ | |||
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., from egress to ingress end point of the OAM | |||
test session. | test session. | |||
7. DetNet OAM MUST support proactive monitoring of a DetNet node | 7. DetNet OAM MUST support proactive monitoring of a DetNet node | |||
availability in the given DetNet domain. | availability in the given DetNet domain. | |||
8. DetNet OAM MUST support Path Maximum Transmission Unit | 8. DetNet OAM MUST support Path Maximum Transmission Unit | |||
discovery. | discovery. | |||
9. DetNet OAM MUST support Remote Defect Indication (RDI) | 9. DetNet OAM MUST support the discovery of PREOF along a route in | |||
the given DetNet domain. | ||||
10. DetNet OAM MUST support Remote Defect Indication (RDI) | ||||
notification to the DetNet node performing continuity checking. | notification to the DetNet node performing continuity checking. | |||
10. DetNet OAM MUST support performance measurement methods. | 11. DetNet OAM MUST support performance measurement methods. | |||
11. DetNet OAM MAY support hybrid performance measurement methods. | 12. DetNet OAM MAY support hybrid performance measurement methods. | |||
12. 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, delay and delay | |||
variation metrics. [RFC6374] provides excellent details on | variation metrics. [RFC6374] provides detailed information on | |||
performance measurement and performance metrics. | performance measurement and performance metrics. | |||
13. DetNet OAM MUST support defect notification mechanism, like | 14. DetNet OAM MUST support defect notification mechanism, like | |||
Alarm Indication Signal. Any DetNet node in the given DetNet | Alarm Indication Signal. Any DetNet node in the given DetNet | |||
domain MAY originate a defect notification addressed to any | domain MAY originate a defect notification addressed to any | |||
subset of nodes within the domain. | subset of nodes within the domain. | |||
14. DetNet OAM MUST support methods to enable survivability of the | 15. DetNet OAM MUST support methods to enable survivability of the | |||
DetNet domain. These recovery methods MAY use protection | DetNet domain. These recovery methods MAY use protection | |||
switching and restoration. | switching and restoration. | |||
15. DetNet OAM MUST support the discovery of Packet Replication, | 16. 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. | |||
16. DetNet OAM MUST support testing of Packet Replication, | 17. 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. | |||
17. DetNet OAM MUST support monitoring any sub-set of paths | 18. DetNet OAM MUST support monitoring levels of resources allocated | |||
for the particular DetNet flow. Such resources include but not | ||||
limited to buffer utilization, scheduler transmission calendar. | ||||
19. 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 | |||
not raise any security concerns or issues in addition to ones common | not raise any security concerns or issues in addition to ones common | |||
to networking and those specific to a DetNet discussed in | to networking and those specific to a DetNet discussed in | |||
[I-D.ietf-detnet-security]. | [I-D.ietf-detnet-security]. | |||
9. Acknowledgments | 9. Acknowledgments | |||
TBD | The authors express their appreciation and gratitude to Pascal | |||
Thubert for the review, insightful questions, and helpful comments. | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[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>. | |||
skipping to change at page 11, line 39 ¶ | skipping to change at page 12, line 28 ¶ | |||
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://tools.ietf.org/html/draft-ietf-detnet-security- | |||
16>. | 16>. | |||
[I-D.ietf-ippm-ioam-data] | ||||
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields | ||||
for In-situ OAM", Work in Progress, Internet-Draft, draft- | ||||
ietf-ippm-ioam-data-12, 21 February 2021, | ||||
<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data- | ||||
12>. | ||||
[I-D.ietf-ippm-ioam-direct-export] | ||||
Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., | ||||
Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ | ||||
OAM Direct Exporting", Work in Progress, Internet-Draft, | ||||
draft-ietf-ippm-ioam-direct-export-03, 17 February 2021, | ||||
<https://tools.ietf.org/html/draft-ietf-ippm-ioam-direct- | ||||
export-03>. | ||||
[I-D.mirsky-ippm-hybrid-two-step] | ||||
Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid | ||||
Two-Step Performance Measurement Method", Work in | ||||
Progress, Internet-Draft, draft-mirsky-ippm-hybrid-two- | ||||
step-09, 30 March 2021, <https://tools.ietf.org/html/ | ||||
draft-mirsky-ippm-hybrid-two-step-09>. | ||||
[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, | |||
<https://www.rfc-editor.org/info/rfc6291>. | <https://www.rfc-editor.org/info/rfc6291>. | |||
End of changes. 39 change blocks. | ||||
77 lines changed or deleted | 135 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/ |