Bidirectional Forwarding Detection (BFD) for Multihop Paths
RFC 5883
|
| Document |
Type |
|
RFC - Proposed Standard
(June 2010; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5883 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Ross Callon
|
|
Send notices to |
|
(None)
|
Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5883 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010
Bidirectional Forwarding Detection (BFD) for Multihop Paths
Abstract
This document describes the use of the Bidirectional Forwarding
Detection (BFD) protocol over multihop paths, including
unidirectional links.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5883.
Copyright Notice
Copyright (c) 2010 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
(http://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 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.
Katz & Ward Standards Track [Page 1]
RFC 5883 BFD for Multihop Paths June 2010
1. Introduction
The Bidirectional Forwarding Detection (BFD) protocol [BFD] defines a
method for liveness detection of arbitrary paths between systems.
The BFD one-hop specification [BFD-1HOP] describes how to use BFD
across single hops of IPv4 and IPv6.
BFD can also be useful on arbitrary paths between systems, which may
span multiple network hops and follow unpredictable paths.
Furthermore, a pair of systems may have multiple paths between them
that may overlap. This document describes methods for using BFD in
such scenarios.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].
2. Applicability
Please note that BFD is intended as an Operations, Administration,
and Maintenance (OAM) mechanism for connectivity check and connection
verification. It is applicable for network-based services (e.g.
router-to-router, subscriber-to-gateway, LSP/circuit endpoints, and
service appliance failure detection). In these scenarios it is
required that the operator correctly provision the rates at which BFD
is transmitted to avoid congestion (e.g link, I/O, CPU) and false
failure detection. It is not applicable for application-to-
application failure detection across the Internet because it does not
have sufficient capability to do necessary congestion detection and
avoidance and therefore cannot prevent congestion collapse. Host-to-
host or application-to-application deployment across the Internet
will require the encapsulation of BFD within a transport that
provides "TCP-friendly" [TFRC] behavior.
3. Issues
There are three primary issues in the use of BFD for multihop paths.
The first is security and spoofing; [BFD-1HOP] describes a
lightweight method of avoiding spoofing by requiring a Time to Live
(TTL)/Hop Limit of 255 on both transmit and receive, but this
obviously does not work across multiple hops. The utilization of BFD
authentication addresses this issue.
The second, more subtle, issue is that of demultiplexing multiple BFD
sessions between the same pair of systems to the proper BFD session.
In particular, the first BFD packet received for a session may carry
Katz & Ward Standards Track [Page 2]
RFC 5883 BFD for Multihop Paths June 2010
a Your Discriminator value of zero, resulting in ambiguity as to
which session the packet should be associated. Once the
Show full document text