BFD Extension for DetNet Remote Defect Indication (RDI)
draft-huang-detnet-rdi-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Hongyi Huang , Li Zhang , Tianran Zhou | ||
| Last updated | 2024-02-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-huang-detnet-rdi-01
detnet Working Group H. Huang
Internet-Draft L. Zhang
Intended status: Standards Track T. Zhou
Expires: 24 August 2024 Huawei
21 February 2024
BFD Extension for DetNet Remote Defect Indication (RDI)
draft-huang-detnet-rdi-01
Abstract
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.
Status of This Memo
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 24 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (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.
Huang, et al. Expires 24 August 2024 [Page 1]
Internet-Draft BFD Extension DetNet RDI February 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements for DetNet RDI . . . . . . . . . . . . . . . . . 4
2.1. Packet Latency . . . . . . . . . . . . . . . . . . . . . 4
2.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Packet Misorder . . . . . . . . . . . . . . . . . . . . . 5
2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. DetNet RDI Method . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Introduction of BFD and Rationale of Extension . . . . . 5
3.2. BFD Extension . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. IP Encapsulation . . . . . . . . . . . . . . . . . . . . 6
4.2. MPLS Encapsulation . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. BFD Diagnostic Codes . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
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.
Huang, et al. Expires 24 August 2024 [Page 2]
Internet-Draft BFD Extension DetNet RDI February 2024
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.
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. 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
Huang, et al. Expires 24 August 2024 [Page 3]
Internet-Draft BFD Extension DetNet RDI February 2024
2. Requirements for DetNet RDI
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.
2.1. 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.
2.2. 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 [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.
Huang, et al. Expires 24 August 2024 [Page 4]
Internet-Draft BFD Extension DetNet RDI February 2024
2.3. 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.
2.4. Summary
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.
3. DetNet RDI Method
3.1. Introduction of BFD and Rationale of Extension
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Format of Mandatory Section of BFD Control Packet
Huang, et al. Expires 24 August 2024 [Page 5]
Internet-Draft BFD Extension DetNet RDI February 2024
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.
3.2. BFD Extension
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 |
+-------+-------------------------------------+
Table 1: Appended Value-Name Pairs to "BFD
Diagnostic Codes"
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.
4. Applicability
4.1. IP Encapsulation
Huang, et al. Expires 24 August 2024 [Page 6]
Internet-Draft BFD Extension DetNet RDI February 2024
+---------------------------------+
| BFD Control Packet |
+---------------------------------+ <--+
| UDP Header | |
+---------------------------------+ +--> IP Encapsulation
| IP Header | |
+---------------------------------+ <--/
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Figure 2: DetNet RDI Packet Encapsulation in UDP/IP
4.2. MPLS Encapsulation
+---------------------------------+
| BFD Control Packet |
+---------------------------------+ <--\
| DetNet Associated Channel Header| |
+---------------------------------+ +--> MPLS Encapsulation
| S-Label | |
+---------------------------------+ |
| [ F-Label(s) ] | |
+---------------------------------+ <--/
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Figure 3: DetNet RDI Packet Encapsulation in MPLS
5. IANA Considerations
5.1. BFD Diagnostic Codes
IANA is requested to make the assignment from the "Bidirectional
Forwarding Detection (BFD) Parameters" registry, "BFD Diagnostic
Codes" subregistry as follows.
Huang, et al. Expires 24 August 2024 [Page 7]
Internet-Draft BFD Extension DetNet RDI February 2024
+=======+=====================================+===============+
| 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 |
+-------+-------------------------------------+---------------+
Table 2: Requested Assignment from the "BFD Diagnostic
Codes" Subregistry
6. Security Considerations
This specification inherits the security considerations from
[RFC5880] and does not raise any additional security issues beyond
those.
7. References
7.1. Normative References
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[I-D.ietf-detnet-oam-framework]
Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos,
C. J., Varga, B., and J. Farkas, "Framework of Operations,
Administration and Maintenance (OAM) for Deterministic
Networking (DetNet)", Work in Progress, Internet-Draft,
Huang, et al. Expires 24 August 2024 [Page 8]
Internet-Draft BFD Extension DetNet RDI February 2024
draft-ietf-detnet-oam-framework-11, 8 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
oam-framework-11>.
[I-D.song-opsawg-ifit-framework]
Song, H., Qin, F., Chen, H., Jin, J., and J. Shin,
"Framework for In-situ Flow Information Telemetry", Work
in Progress, Internet-Draft, draft-song-opsawg-ifit-
framework-21, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-song-opsawg-
ifit-framework-21>.
[RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed.,
"Proactive Connectivity Verification, Continuity Check,
and Remote Defect Indication for the MPLS Transport
Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011,
<https://www.rfc-editor.org/info/rfc6428>.
Acknowledgements
TBD.
Authors' Addresses
Hongyi Huang
Huawei
China
Email: hongyi.huang@huawei.com
Li Zhang
Huawei
China
Email: zhangli344@huawei.com
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
Huang, et al. Expires 24 August 2024 [Page 9]