]> Huawei

China hongyi.huang@huawei.com

Huawei

China zhangli344@huawei.com

Huawei

China zhoutianran@huawei.com

Routing Area detnet Working Group DetNet This document provides a method of realizing remote defect indication for DetNet OAM. It takes advantage of and extends BFD to explicitly indicate DetNet-specific defects.

Introduction Deterministic Networking (DetNet) provides reliable service for data flows with extremely low packet loss rates and bounded end-to-end delivery by dedicating network resources such as link bandwidth and buffer space to DetNet flows within a network domain. It operates at the IP layer and can deliver service over lower-layer technologies such as MPLS. With DetNet capabilities enabled in all network nodes, DetNet Quality of Service (QoS) requirements can be met as it provides. Extremely high QoS leaves little space for possible defects alongside the whole DetNet. Therefore, it's of great significance to achieve accurate and timely on-path defect detection and dissemination in order to support service validation and fault localization. Such requirements are listed in DetNet OAM as well. This document's primary purpose is to provide a generic method to achieve Remote Defect Indication (RDI), which disseminates defects between nodes within DetNet domain. This document focuses on how to explicitly notify remote nodes of detected DetNet-specific defects. Many techniques used to detect the defects can be borrowed from non-DetNet OAM tools and they are outside the scope of this document. Bidirectional Forwarding Detection (BFD) is commonly used for RDI. This document specifies an extension of BFD to support generic notification of DetNet-specific defects with low latency.

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.

Terminology The abbreviations used in this document are: BFD: Bidirectional Forwarding Detection DetNet: Deterministic Networking IFIT: In-situ Flow Information Telemetry OAM: Operation, Administration, and Maintenance POF: Packet Ordering Function PREOF: Packet Replication, Elimination and Ordering Function QoS: Quality of Service RDI: Remote Defect Indication SLO: Service Level Objective

Requirements for DetNet RDI DetNet defines three main QoS in : bounded end-to-end latency, strict packet loss ratio and upper bound of out-of-order packet delivery, which are not mandatory in traditional IP network. To mitigate any performance degradation of DetNet flows, DetNet is supposed to observe and report the violation of Service Level Objectives (SLO) before the network has deviated from expected behavior. Additionally, DetNet OAM has explicitly required RDI support for DetNet forwarding sub-layer, which facilitates the failure localization and characterization. Corresponding to the QoS of DetNet, three key indicators of defects are proposed to accurately reflect DetNet serviceability as listed below.

Packet Latency IP network does not provide any guarantee of latency, leaving the considerations in higher layer (e.g., transport layer). What's worse, its best-effort delivery could induce congestion, which, consequently, increases the latency. For example, heavy and bursty flows traversing IP network could increase packet latency to great extent. Contrary to that, deterministic bounded end-to-end latency is one of the key commitments of DetNet. If the latency is detected to be exceeding the threshold along the network path, DetNet is considered kind of faulty. In this case, DetNet ingress nodes should be notified by egress nodes as soon as possible in order to protect DetNet data flows and provide correct and guaranteed service.

Packet Loss On one hand, packet loss may occur in DetNet, similar to IP network, since DetNet does not operate on loss-free underlay network. On the other hand, DetNet utilizes packet replication and elimination to achieve service protection, which aims to mitigate or eliminate packet loss due to equipment failures. Therefore, packet loss in DetNet could imply the violation of DetNet QoS and thus, DetNet nodes should detect the packet loss timely and accurately. Existing methods of loss detection used in non-DetNet OAM are not sensitive enough to fulfill the requirements of DetNet QoS. For example, BFD reports packet loss based on multiple (e.g., 3) consecutive lost probing packets. Although IFIT performs more accurate detection based on data traffic instead of probing traffic, it still requires a generic method of failure notification for packet loss in DetNet.

Packet Misorder While IP network does not preserve the order of packets within flows, DetNet strictly examines the property of order-preserving to realize the basic Packet Replication, Elimination and Ordering Functions (PREOF) so as to serve loss-free data flows, in case that end system(s) of the flow cannot tolerate out-of-order delivery. Although DetNet applies Packet Ordering Function (POF) to preserve packet order, exceeded buffer or extreme circumstances could induce out-of-order delivery yet. This should be identified as failure and disseminated to DetNet ingress nodes in some way.

Summary As per , many legacy OAM tools used in IP network apply in DetNet as well. However, existing protocol (i.e., BFD) for RDI in non-DetNet networks does not define the above DetNet-specific defect indicators, which could neglect and proliferate the failures. In such cases, the above OAM requirements of DetNet may not be fulfilled.

DetNet RDI Method

Introduction of BFD and Rationale of Extension BFD is implemented mainly in forwarding plane to detect and report failures on top of any data protocol. The format of mandatory section of a BFD control packet is shown as below.

The Format of Mandatory Section of BFD Control Packet

The BFD control packet contains a field namely diagnostic ("Diag" in ) to provide the information of local failures to remote nodes to determine the root cause. As per , values from 0 to 8 have been specified as certain indicators and values from 9-31 are reserved for further use. encodes a diagnostic code of '9' to indicate mis-connectivity defect for MPLS-TP. Similarly, DetNet OAM can utilize the reserved values to record and disseminate several important DetNet-specific defects as listed above (see ), and thereby realize RDI in DetNet OAM.

BFD Extension This document appends three value-name pairs (see ) to the existing "BFD Diagnostic Codes", where the exact values SHOULD be assigned by IANA. Appended Value-Name Pairs to "BFD Diagnostic Codes"

Value	BFD Diagnostic Code Name
TBD1	Packet_Misorder_Ratio_Limit_Reached
TBD2	Packet_Latency_Limit_Reached
TBD3	Packet_Loss_Ratio_Limit_Reached

When the measured ratio of out-of-order packets reaches the limit, BFD control packets is sent with encoding the diagnostic code as TBD1. Similarly, if the measured packet latency exceeds the maximum threshold, the diagnostic code SHOULD be encoded with TBD2. If the measured ratio of packet loss reaches the limit, the diagnostic code SHOULD be encoded with TBD3.

Applicability

IP Encapsulation

DetNet RDI Packet Encapsulation in UDP/IP IP Encapsulation | IP Header | | +---------------------------------+ <--/ | Data-Link | +---------------------------------+ | Physical | +---------------------------------+ ]]>

MPLS Encapsulation

DetNet RDI Packet Encapsulation in MPLS MPLS Encapsulation | S-Label | | +---------------------------------+ | | [ F-Label(s) ] | | +---------------------------------+ <--/ | Data-Link | +---------------------------------+ | Physical | +---------------------------------+ ]]>

IANA Considerations

BFD Diagnostic Codes IANA is requested to make the assignment from the "Bidirectional Forwarding Detection (BFD) Parameters" registry, "BFD Diagnostic Codes" subregistry as follows. Requested Assignment from the "BFD Diagnostic Codes" Subregistry

Value	Name	Reference
TBD1	Packet_Misorder_Ratio_Limit_Reached	This document
TBD2	Packet_Latency_Limit_Reached	This document
TBD3	Packet_Loss_Ratio_Limit_Reached	This document

Security Considerations This specification inherits the security considerations from and does not raise any additional security issues beyond those.

References Normative References This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK] 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. 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. 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. Informative References Ericsson CNRS IMT Atlantique Universidad Carlos III de Madrid Ericsson Ericsson 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 Operation, 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, such as packet delay, delay variation, and packet loss ratio, assigned to each DetNet flow. Futurewei China Mobile China Telecom LG U+ SK Telecom As network scale increases and network operation becomes more sophisticated, existing Operation, Administration, and Maintenance (OAM) methods are no longer sufficient to meet the monitoring and measurement requirements. Emerging data-plane on-path telemetry techniques, such as IOAM and AltMrk, which provide high-precision flow insight and issue notifications in real time can supplement existing proactive and reactive methods that run in active and passive modes. They enable quality of experience for users and applications, and identification of network faults and deficiencies. This document describes a reference framework, named as In-situ Flow Information Telemetry, for the on-path telemetry techniques. The high-level framework outlines the system architecture for applying the on-path telemetry techniques to collect and correlate performance measurement information from the network. It identifies the components that coordinate existing protocol tools and telemetry mechanisms, and addresses deployment challenges for flow-oriented on- path telemetry techniques, especially in carrier networks. The document is a guide for system designers applying the referenced techniques. It is also intended to motivate further work to enhance the OAM ecosystem. Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM). Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, or Section. This document specifies specific extensions to Bidirectional Forwarding Detection (BFD) and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. [STANDARDS-TRACK]

Acknowledgements TBD.