| Internet-Draft | BFD Extension for DetNet Remote Defect I | October 2022 |
| Huang, et al. | Expires 27 April 2023 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 April 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Deterministic Networking (DetNet) [RFC8655] 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 [I-D.ietf-detnet-oam-framework] 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)[RFC5880] is commonly used for RDI. This document specifies an extension of BFD to support generic notification of DetNet-specific defects with low latency.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The 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¶
DetNet defines three main QoS in [RFC8655]: 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 [I-D.ietf-detnet-oam-framework] 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.¶
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.¶
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 [I-D.song-opsawg-ifit-framework] 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.¶
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.¶
As per [I-D.ietf-detnet-oam-framework], 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.¶
BFD [RFC5880] 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.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BFD control packet contains a field namely diagnostic ("Diag" in Figure 1) to provide the information of local failures to remote nodes to determine the root cause. As per [RFC5880], values from 0 to 8 have been specified as certain indicators and values from 9-31 are reserved for further use. [RFC6428] 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 Section 2), and thereby realize RDI in DetNet OAM.¶
This document appends three value-name pairs (see Table 1) to the existing "BFD Diagnostic Codes", where the exact values SHOULD be assigned by IANA.¶
| 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 maximun 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.¶
+---------------------------------+ | BFD Control Packet | +---------------------------------+ <--+ | UDP Header | | +---------------------------------+ +--> IP Encapsulation | IP Header | | +---------------------------------+ <--/ | Data-Link | +---------------------------------+ | Physical | +---------------------------------+
+---------------------------------+ | BFD Control Packet | +---------------------------------+ <--\ | DetNet Associated Channel Header| | +---------------------------------+ +--> MPLS Encapsulation | S-Label | | +---------------------------------+ | | [ F-Label(s) ] | | +---------------------------------+ <--/ | Data-Link | +---------------------------------+ | Physical | +---------------------------------+
IANA is requested to make the assignment from the "Bidirectional Forwarding Detection (BFD) Parameters" registry, "BFD Diagnostic Codes" subregistry as follows.¶
| 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 |
This specification inherits the security considerations from [RFC5880] and does not raise any additional security issues beyond those.¶
TBD.¶