BFD Working Group G. Mirsky
Internet-Draft X. Min
Intended status: Standards Track ZTE Corp.
Expires: September 6, 2019 March 5, 2019

Extended Bidirectional Forwarding Detection


This document describes a mechanism to extend the capabilities of Bidirectional Forwarding Detection (BFD). These extensions enable BFD to measure performance metrics like packet loss and packet delay.

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

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 September 6, 2019.

Copyright Notice

Copyright (c) 2019 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 ( 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

[RFC5880] provided the base specification of Bidirectional Detection (BFD) as the light-weight mechanism to monitor a path continuity between two systems and detect a failure in the data-plane. Since its introduction, BFD became has been broadly deployed. There was a number of attempts to introduce new capabilities in the protocol, some more successful than others. One of the significant obstacles to extending BFD capabilities may be seen in the compact format of the BFD control message. This document introduces an extended BFD control message and describes the use of the new format for new BFD capabilities.

2. Conventions used in this document

2.1. Terminology

BFD: Bidirectional Forwarding Detection

G-ACh Generic Associated Channel

MTU Maximum Transmission Unit

PMTUD Path MTU Discovery

p2p: Point-to-Point

TLV Type, Length, Value

2.2. 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.

3. Extended BFD Control Message

    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
   |                                                               |
   |                      BFD Control Message                      |
   |                                                               |
   |                        Guard Word                             |
   |                                                               |
   ~                            TLVs                               ~
   |                                                               |

Figure 1: Extended BFD Control Message Format

If an extended BFD control message encapsulated in IP/UDP, the value of the Total Length in the IP header includes the length of the extended BFD control message while the value of the Length field of the BFD control message equals the value as defined in [RFC5880]. If an extended BFD control message to be used over Generic Associated Channel (G-ACh), e.g., [RFC6428] new code point for G-ACh may be allocated.

    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
   |             Type              |           Length              |
   ~                            Value                              ~

Figure 2: General Type-Length-Value Encoding

Figure 2 displays the generic TLV format. A TLV MAY include sub-TLVs that have the same format as presented in Figure 2.

TLVs may be included within other TLVs, in which case the former TLVs are referred to as sub-TLVs. Sub-TLVs have independent types.

3.1. Theory of Operation

A BFD system, also referred to as a node in this document, that supports extended BFD first MUST discover whether other nodes in the given BFD session support the extended BFD. The node MUST send extended BFD control message initiating the Poll sequence as defined in [RFC5880]. If the remote system fails to respond with the extended BFD control message and the Final flag set, then the initiator node MUST conclude that the BFD peer does not support the use of the extended BFD control messages.

    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
   |      Type  = Capability       |           Length              |
   |                         Capability                          ...

Figure 3: Capability TLV Format

The first extended BFD control message SHOULD include the Capability TLV that lists capabilities that may be used at some time during the lifetime of the BFD session. The format of the Capability TLV is presented in Figure 3.

    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
   | L | D |M|                       Reserved                    ...

Figure 4: Capability Encoding Format

Figure 4 presents defined in this document the capabilities that use the extended BFD control message:

The remote BFD node that supports this specification MUST respond to the Capability TLV with the extended BFD control message that includes the Capability TLV listing capabilities the responder supports. The responder MUST set the Final flag in the extended BFD control message

3.2. Performance Measurement with Extended BFD Control Message

Loss measurement, delay measurement, and loss/delay measurement messages can be used in the extended BFD control message to support one-way and round-trip measurements. All the messages are encapsulated as TLVs with Type values allocated by IANA, Section 4.

To perform one-way loss and/or delay measurement the BFD node MAY periodically transmit the extended BFD message with the appropriate TLV in Asynchronous mode. To perform synthetic loss measurement the sender MUST monotonically increment the counter of transmitted test packets. Also, direct-mode loss measurement, as described in [RFC6374], is supported.

For the one-way measurement the sender MAY use the Performance Metric TLV (presented in Figure 5) to obtain the measurement report from the receiver.

    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
   |   Type  = Performance Metric  |           Length              |
   |                                                               |
   ~                       Metric Sub-TLVs                         ~
   |                                                               |

Figure 5: Performance Metric TLV Format

To measure the round-trip loss and/or delay metrics the BFD node transmits the extended BFD control message with the appropriate TLV with the Poll flag set. Before the transmission of the extended BFD control message, the receiver MUST clear the Poll flag and set the Final flag.

4. IANA Considerations

IANA is requested to create the Extended BFD Message Types registry. All code points in the range 1 through 32759 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 32760 through 65279 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code points are allocated according to Table 1:

Extended BFD Type Registry
Value Description Reference
0 Reserved This document
1- 32767 Mandatory TLV, unassigned IETF Review
32768 - 65279 Optional TLV, unassigned First Come First Served
65280 - 65519 Experimental This document
65520 - 65534 Private Use This document
65535 Reserved This document

This document defines the following new values in Extended BFD Type registry:

Extended BFD Types
Value Description Reference
TBA1 Extra Padding This document
TBA2 Capability This document
TBA3 Loss Measurement This document
TBA4 Delay Measurement This document
TBA5 Loss and Delay Measurement This document
TBA6 Performance Metric This document

5. Security Considerations

This document does not introduce new security aspects but inherits all security considerations from [RFC5880], [RFC6428], and [RFC6374].

6. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011.
[RFC6428] Allan, D., Swallow, G. and J. Drake, "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011.
[RFC8126] Cotton, M., Leiba, B. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

Appendix A. Acknowledgements


Authors' Addresses

Greg Mirsky ZTE Corp. EMail:
Xiao Min ZTE Corp. EMail: