draft-ietf-bfd-base-11.txt   rfc5880.txt 
Network Working Group D. Katz Internet Engineering Task Force (IETF) D. Katz
Internet Draft Juniper Networks Request for Comments: 5880 D. Ward
Intended status: Proposed Standard D. Ward Category: Standards Track Juniper Networks
Juniper Networks ISSN: 2070-1721 June 2010
Expires: July, 2010 January 14, 2010
Bidirectional Forwarding Detection Bidirectional Forwarding Detection (BFD)
draft-ietf-bfd-base-11.txt
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the This document describes a protocol intended to detect faults in the
provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
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."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/1id-abstracts.html (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.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5880.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Abstract
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.
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].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions Used in This Document ..........................4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 2. Design ..........................................................4
3.1 Addressing and Session Establishment . . . . . . . . . . . 6 3. Protocol Overview ...............................................5
3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 6 3.1. Addressing and Session Establishment .......................5
4. BFD Control Packet Format . . . . . . . . . . . . . . . . . . 7 3.2. Operating Modes ............................................5
4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7 4. BFD Control Packet Format .......................................7
4.2 Simple Password Authentication Section Format . . . . . 12 4.1. Generic BFD Control Packet Format ..........................7
4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 4.2. Simple Password Authentication Section Format .............11
Section Format . . . . . . . . . . . . . . . . . . . . . 13 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication
4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format ............................................11
Section Format . . . . . . . . . . . . . . . . . . . . . 14 4.4. Keyed SHA1 and Meticulous Keyed SHA1
5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 15 Authentication Section Format .............................13
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 16 5. BFD Echo Packet Format .........................................14
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Elements of Procedure ..........................................14
6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 17 6.1. Overview ..................................................14
6.3 Demultiplexing and the Discriminator Fields . . . . . . 19 6.2. BFD State Machine .........................................16
6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 20 6.3. Demultiplexing and the Discriminator Fields ...............17
6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 20 6.4. The Echo Function and Asymmetry ...........................18
6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 21 6.5. The Poll Sequence .........................................19
6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 22 6.6. Demand Mode ...............................................19
6.7.1 Enabling and Disabling Authentication . . . . . . 23 6.7. Authentication ............................................21
6.7.2 Simple Password Authentication . . . . . . . . . . 24 6.7.1. Enabling and Disabling Authentication ..............21
6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 25 6.7.2. Simple Password Authentication .....................22
6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 26 6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication ..23
6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 28 6.7.4. Keyed SHA1 and Meticulous Keyed SHA1
6.8.1 State Variables . . . . . . . . . . . . . . . . . 29 Authentication .....................................25
6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 32 6.8. Functional Specifics ......................................27
6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 32 6.8.1. State Variables ....................................27
6.8.4 Calculating the Detection Time . . . . . . . . . . 34 6.8.2. Timer Negotiation ..................................30
6.8.5 Detecting Failures with the Echo Function . . . . 35 6.8.3. Timer Manipulation .................................31
6.8.6 Reception of BFD Control Packets . . . . . . . . . 35 6.8.4. Calculating the Detection Time .....................32
6.8.7 Transmitting BFD Control Packets . . . . . . . . . 38 6.8.5. Detecting Failures with the Echo Function ..........33
6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 41 6.8.6. Reception of BFD Control Packets ...................33
6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 41 6.8.7. Transmitting BFD Control Packets ...................36
6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 42 6.8.8. Reception of BFD Echo Packets ......................39
6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 42 6.8.9. Transmission of BFD Echo Packets ...................39
6.8.12 Detect Multiplier Change . . . . . . . . . . . . 42 6.8.10. Min Rx Interval Change ............................40
6.8.13 Enabling or Disabling the Echo Function . . . . . 42 6.8.11. Min Tx Interval Change ............................40
6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 42 6.8.12. Detect Multiplier Change ..........................40
6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 43 6.8.13. Enabling or Disabling The Echo Function ...........40
6.8.16 Administrative Control . . . . . . . . . . . . . 43 6.8.14. Enabling or Disabling Demand Mode .................40
6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43 6.8.15. Forwarding Plane Reset ............................41
6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 44 6.8.16. Administrative Control ............................41
7. Operational Considerations . . . . . . . . . . . . . . . . . 45 6.8.17. Concatenated Paths ................................41
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46 6.8.18. Holding Down Sessions .............................42
9. Security Considerations . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . 49
10.1 Normative References . . . . . . . . . . . . . . . . . 49
10.2 Informative References . . . . . . . . . . . . . . . . 49
Backward Compatibility (Non-Normative) . . . . . . . . . . . . 49
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 51
Changes from the previous draft . . . . . . . . . . . . . . . . 51
1. Introduction 7. Operational Considerations .....................................43
8. IANA Considerations ............................................44
9. Security Considerations ........................................45
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................47
Appendix A. Backward Compatibility (Non-Normative) ................48
Appendix B. Contributors ..........................................48
Appendix C. Acknowledgments .......................................49
1. Introduction
An increasingly important feature of networking equipment is the An increasingly important feature of networking equipment is the
rapid detection of communication failures between adjacent systems, rapid detection of communication failures between adjacent systems,
in order to more quickly establish alternative paths. Detection can in order to more quickly establish alternative paths. Detection can
come fairly quickly in certain circumstances when data link hardware come fairly quickly in certain circumstances when data link hardware
comes into play (such as SONET alarms.) However, there are media comes into play (such as Synchronous Optical Network (SONET) alarms).
that do not provide this kind of signaling (such as Ethernet), and However, there are media that do not provide this kind of signaling
some media may not detect certain kinds of failures in the path, for (such as Ethernet), and some media may not detect certain kinds of
example, failing interfaces or forwarding engine components. failures in the path, for example, failing interfaces or forwarding
engine components.
Networks use relatively slow "Hello" mechanisms, usually in routing Networks use relatively slow "Hello" mechanisms, usually in routing
protocols, to detect failures when there is no hardware signaling to protocols, to detect failures when there is no hardware signaling to
help out. The time to detect failures ("Detection Times") available help out. The time to detect failures ("Detection Times") available
in the existing protocols are no better than a second, which is far in the existing protocols are no better than a second, which is far
too long for some applications and represents a great deal of lost too long for some applications and represents a great deal of lost
data at gigabit rates. Furthermore, routing protocol Hellos are of data at gigabit rates. Furthermore, routing protocol Hellos are of
no help when those routing protocols are not in use, and the no help when those routing protocols are not in use, and the
semantics of detection are subtly different--they detect a failure in semantics of detection are subtly different -- they detect a failure
the path between the two routing protocol engines. in the path between the two routing protocol engines.
The goal of BFD is to provide low-overhead, short-duration detection The goal of Bidirectional Forwarding Detection (BFD) is to provide
of failures in the path between adjacent forwarding engines, low-overhead, short-duration detection of failures in the path
including the interfaces, data link(s), and to the extent possible between adjacent forwarding engines, including the interfaces, data
the forwarding engines themselves. link(s), and, to the extent possible, the forwarding engines
themselves.
An additional goal is to provide a single mechanism that can be used An additional goal is to provide a single mechanism that can be used
for liveness detection over any media, at any protocol layer, with a for liveness detection over any media, at any protocol layer, with a
wide range of Detection Times and overhead, to avoid a proliferation wide range of Detection Times and overhead, to avoid a proliferation
of different methods. of different methods.
This document specifies the details of the base protocol. The use of This document specifies the details of the base protocol. The use of
some mechanisms are application dependent and are specified in a some mechanisms are application dependent and are specified in a
separate series of application documents. These issues are so noted. separate series of application documents. These issues are so noted.
Note that many of the exact mechanisms are implementation dependent Note that many of the exact mechanisms are implementation dependent
and will not affect interoperability, and are thus outside the scope and will not affect interoperability, and are thus outside the scope
of this specification. Those issues are so noted. of this specification. Those issues are so noted.
2. Design 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. Design
BFD is designed to detect failures in communication with a forwarding BFD is designed to detect failures in communication with a forwarding
plane next hop. It is intended to be implemented in some component plane next hop. It is intended to be implemented in some component
of the forwarding engine of a system, in cases where the forwarding of the forwarding engine of a system, in cases where the forwarding
and control engines are separated. This not only binds the protocol and control engines are separated. This not only binds the protocol
more to the forwarding plane, but decouples the protocol from the more to the forwarding plane, but decouples the protocol from the
fate of the routing protocol engine, making it useful in concert with fate of the routing protocol engine, making it useful in concert with
various "graceful restart" mechanisms for those protocols. BFD may various "graceful restart" mechanisms for those protocols. BFD may
also be implemented in the control engine, though doing so may also be implemented in the control engine, though doing so may
preclude the detection of some kinds of failures. preclude the detection of some kinds of failures.
skipping to change at page 4, line 46 skipping to change at page 4, line 37
BFD operates on top of any data protocol (network layer, link layer, BFD operates on top of any data protocol (network layer, link layer,
tunnels, etc.) being forwarded between two systems. It is always tunnels, etc.) being forwarded between two systems. It is always
run in a unicast, point-to-point mode. BFD packets are carried as run in a unicast, point-to-point mode. BFD packets are carried as
the payload of whatever encapsulating protocol is appropriate for the the payload of whatever encapsulating protocol is appropriate for the
medium and network. BFD may be running at multiple layers in a medium and network. BFD may be running at multiple layers in a
system. The context of the operation of any particular BFD session system. The context of the operation of any particular BFD session
is bound to its encapsulation. is bound to its encapsulation.
BFD can provide failure detection on any kind of path between BFD can provide failure detection on any kind of path between
systems, including direct physical links, virtual circuits, tunnels, systems, including direct physical links, virtual circuits, tunnels,
MPLS LSPs, multihop routed paths, and unidirectional links (so long MPLS Label Switched Paths (LSPs), multihop routed paths, and
as there is some return path, of course.) Multiple BFD sessions can unidirectional links (so long as there is some return path, of
be established between the same pair of systems when multiple paths course). Multiple BFD sessions can be established between the same
between them are present in at least one direction, even if a lesser pair of systems when multiple paths between them are present in at
number of paths are available in the other direction (multiple least one direction, even if a lesser number of paths are available
parallel unidirectional links or MPLS LSPs, for example.) in the other direction (multiple parallel unidirectional links or
MPLS LSPs, for example).
The BFD state machine implements a three-way handshake, both when The BFD state machine implements a three-way handshake, both when
establishing a BFD session and when tearing it down for any reason, establishing a BFD session and when tearing it down for any reason,
to ensure that both systems are aware of the state change. to ensure that both systems are aware of the state change.
BFD can be abstracted as a simple service. The service primitives BFD can be abstracted as a simple service. The service primitives
provided by BFD are to create, destroy, and modify a session, given provided by BFD are to create, destroy, and modify a session, given
the destination address and other parameters. BFD in return provides the destination address and other parameters. BFD in return provides
a signal to its clients indicating when the BFD session goes up or a signal to its clients indicating when the BFD session goes up or
down. down.
3. Protocol Overview 3. Protocol Overview
BFD is a simple hello protocol that in many respects is similar to BFD is a simple Hello protocol that, in many respects, is similar to
the detection components of well-known routing protocols. A pair of the detection components of well-known routing protocols. A pair of
systems transmit BFD packets periodically over each path between the systems transmit BFD packets periodically over each path between the
two systems, and if a system stops receiving BFD packets for long two systems, and if a system stops receiving BFD packets for long
enough, some component in that particular bidirectional path to the enough, some component in that particular bidirectional path to the
neighboring system is assumed to have failed. Under some conditions, neighboring system is assumed to have failed. Under some conditions,
systems may negotiate to not send periodic BFD packets in order to systems may negotiate not to send periodic BFD packets in order to
reduce overhead. reduce overhead.
A path is only declared to be operational when two-way communication A path is only declared to be operational when two-way communication
has been established between systems, though this does not preclude has been established between systems, though this does not preclude
the use of unidirectional links. the use of unidirectional links.
A separate BFD session is created for each communications path and A separate BFD session is created for each communications path and
data protocol in use between two systems. data protocol in use between two systems.
Each system estimates how quickly it can send and receive BFD packets Each system estimates how quickly it can send and receive BFD packets
in order to come to an agreement with its neighbor about how rapidly in order to come to an agreement with its neighbor about how rapidly
detection of failure will take place. These estimates can be detection of failure will take place. These estimates can be
modified in real time in order to adapt to unusual situations. This modified in real time in order to adapt to unusual situations. This
design also allows for fast systems on a shared medium with a slow design also allows for fast systems on a shared medium with a slow
system to be able to more rapidly detect failures between the fast system to be able to more rapidly detect failures between the fast
systems while allowing the slow system to participate to the best of systems while allowing the slow system to participate to the best of
its ability. its ability.
3.1. Addressing and Session Establishment 3.1. Addressing and Session Establishment
A BFD session is established based on the needs of the application A BFD session is established based on the needs of the application
that will be making use of it. It is up to the application to that will be making use of it. It is up to the application to
determine the need for BFD, and the addresses to use--there is no determine the need for BFD, and the addresses to use -- there is no
discovery mechanism in BFD. For example, an OSPF [OSPF] discovery mechanism in BFD. For example, an OSPF [OSPF]
implementation may request a BFD session to be established to a implementation may request a BFD session to be established to a
neighbor discovered using the OSPF Hello protocol. neighbor discovered using the OSPF Hello protocol.
3.2. Operating Modes 3.2. Operating Modes
BFD has two operating modes which may be selected, as well as an BFD has two operating modes that may be selected, as well as an
additional function that can be used in combination with the two additional function that can be used in combination with the two
modes. modes.
The primary mode is known as Asynchronous mode. In this mode, the The primary mode is known as Asynchronous mode. In this mode, the
systems periodically send BFD Control packets to one another, and if systems periodically send BFD Control packets to one another, and if
a number of those packets in a row are not received by the other a number of those packets in a row are not received by the other
system, the session is declared to be down. system, the session is declared to be down.
The second mode is known as Demand mode. In this mode, it is assumed The second mode is known as Demand mode. In this mode, it is assumed
that a system has an independent way of verifying that it has that a system has an independent way of verifying that it has
skipping to change at page 6, line 39 skipping to change at page 6, line 24
packets, except when the system feels the need to verify connectivity packets, except when the system feels the need to verify connectivity
explicitly, in which case a short sequence of BFD Control packets is explicitly, in which case a short sequence of BFD Control packets is
exchanged, and then the far system quiesces. Demand mode may operate exchanged, and then the far system quiesces. Demand mode may operate
independently in each direction, or simultaneously. independently in each direction, or simultaneously.
An adjunct to both modes is the Echo function. When the Echo An adjunct to both modes is the Echo function. When the Echo
function is active, a stream of BFD Echo packets is transmitted in function is active, a stream of BFD Echo packets is transmitted in
such a way as to have the other system loop them back through its such a way as to have the other system loop them back through its
forwarding path. If a number of packets of the echoed data stream forwarding path. If a number of packets of the echoed data stream
are not received, the session is declared to be down. The Echo are not received, the session is declared to be down. The Echo
function may be used with either Asynchronous or Demand modes. Since function may be used with either Asynchronous or Demand mode. Since
the Echo function is handling the task of detection, the rate of the Echo function is handling the task of detection, the rate of
periodic transmission of Control packets may be reduced (in the case periodic transmission of Control packets may be reduced (in the case
of Asynchronous mode) or eliminated completely (in the case of Demand of Asynchronous mode) or eliminated completely (in the case of Demand
mode.) mode).
Pure asynchronous mode is advantageous in that it requires half as Pure Asynchronous mode is advantageous in that it requires half as
many packets to achieve a particular Detection Time as does the Echo many packets to achieve a particular Detection Time as does the Echo
function. It is also used when the Echo function cannot be supported function. It is also used when the Echo function cannot be supported
for some reason. for some reason.
The Echo function has the advantage of truly testing only the The Echo function has the advantage of truly testing only the
forwarding path on the remote system. This may reduce round-trip forwarding path on the remote system. This may reduce round-trip
jitter and thus allow more aggressive Detection Times, as well as jitter and thus allow more aggressive Detection Times, as well as
potentially detecting some classes of failure that might not potentially detecting some classes of failure that might not
otherwise be detected. otherwise be detected.
skipping to change at page 7, line 19 skipping to change at page 7, line 4
is enabled in a particular direction only when the system that loops is enabled in a particular direction only when the system that loops
the Echo packets back signals that it will allow it, and when the the Echo packets back signals that it will allow it, and when the
system that sends the Echo packets decides it wishes to. system that sends the Echo packets decides it wishes to.
Demand mode is useful in situations where the overhead of a periodic Demand mode is useful in situations where the overhead of a periodic
protocol might prove onerous, such as a system with a very large protocol might prove onerous, such as a system with a very large
number of BFD sessions. It is also useful when the Echo function is number of BFD sessions. It is also useful when the Echo function is
being used symmetrically. Demand mode has the disadvantage that being used symmetrically. Demand mode has the disadvantage that
Detection Times are essentially driven by the heuristics of the Detection Times are essentially driven by the heuristics of the
system implementation and are not known to the BFD protocol. Demand system implementation and are not known to the BFD protocol. Demand
mode may not be used when the path round trip time is greater than mode may not be used when the path round-trip time is greater than
the desired Detection Time, or the protocol will fail to work the desired Detection Time, or the protocol will fail to work
properly. See section 6.6 for more details. properly. See section 6.6 for more details.
4. BFD Control Packet Format 4. BFD Control Packet Format
4.1. Generic BFD Control Packet Format 4.1. Generic BFD Control Packet Format
BFD Control packets are sent in an encapsulation appropriate to the BFD Control packets are sent in an encapsulation appropriate to the
environment. The specific encapsulation is outside of the scope of environment. The specific encapsulation is outside of the scope of
this specification. See the appropriate application document for this specification. See the appropriate application document for
encapsulation details. encapsulation details.
The BFD Control packet has a Mandatory Section and an optional The BFD Control packet has a Mandatory Section and an optional
Authentication Section. The format of the Authentication Section, if Authentication Section. The format of the Authentication Section, if
present, is dependent on the type of authentication in use. present, is dependent on the type of authentication in use.
The Mandatory Section of a BFD Control packet has the following The Mandatory Section of a BFD Control packet has the following
format: format:
0 1 2 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 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 | |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Discriminator | | My Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator | | Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval | | Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval | | Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval | | Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An optional Authentication Section MAY be present: An optional Authentication Section MAY be present:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Authentication Data... | | Auth Type | Auth Len | Authentication Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (Vers) Version (Vers)
The version number of the protocol. This document defines The version number of the protocol. This document defines
protocol version 1. protocol version 1.
Diagnostic (Diag) Diagnostic (Diag)
A diagnostic code specifying the local system's reason for the A diagnostic code specifying the local system's reason for the
last change in session state. Values are: last change in session state. Values are:
0 -- No Diagnostic 0 -- No Diagnostic
1 -- Control Detection Time Expired 1 -- Control Detection Time Expired
2 -- Echo Function Failed 2 -- Echo Function Failed
3 -- Neighbor Signaled Session Down 3 -- Neighbor Signaled Session Down
4 -- Forwarding Plane Reset 4 -- Forwarding Plane Reset
5 -- Path Down 5 -- Path Down
6 -- Concatenated Path Down 6 -- Concatenated Path Down
7 -- Administratively Down 7 -- Administratively Down
8 -- Reverse Concatenated Path Down 8 -- Reverse Concatenated Path Down
9-31 -- Reserved for future use 9-31 -- Reserved for future use
This field allows remote systems to determine the reason that the This field allows remote systems to determine the reason that the
previous session failed, for example. previous session failed, for example.
State (Sta) State (Sta)
The current BFD session state as seen by the transmitting system. The current BFD session state as seen by the transmitting system.
Values are: Values are:
0 -- AdminDown 0 -- AdminDown
1 -- Down 1 -- Down
2 -- Init 2 -- Init
3 -- Up 3 -- Up
Poll (P) Poll (P)
If set, the transmitting system is requesting verification of If set, the transmitting system is requesting verification of
connectivity, or of a parameter change, and is expecting a packet connectivity, or of a parameter change, and is expecting a packet
with the Final (F) bit in reply. If clear, the transmitting with the Final (F) bit in reply. If clear, the transmitting
system is not requesting verification. system is not requesting verification.
Final (F) Final (F)
If set, the transmitting system is responding to a received BFD If set, the transmitting system is responding to a received BFD
Control packet that had the Poll (P) bit set. If clear, the Control packet that had the Poll (P) bit set. If clear, the
transmitting system is not responding to a Poll. transmitting system is not responding to a Poll.
Control Plane Independent (C) Control Plane Independent (C)
If set, the transmitting system's BFD implementation does not If set, the transmitting system's BFD implementation does not
share fate with its control plane (in other words, BFD is share fate with its control plane (in other words, BFD is
implemented in the forwarding plane and can continue to function implemented in the forwarding plane and can continue to function
through disruptions in the control plane.) If clear, the through disruptions in the control plane). If clear, the
transmitting system's BFD implementation shares fate with its transmitting system's BFD implementation shares fate with its
control plane. control plane.
The use of this bit is application dependent and is outside the The use of this bit is application dependent and is outside the
scope of this specification. See specific application scope of this specification. See specific application
specifications for details. specifications for details.
Authentication Present (A) Authentication Present (A)
If set, the Authentication Section is present and the session is If set, the Authentication Section is present and the session is
to be authenticated (see section 6.7 for details). to be authenticated (see section 6.7 for details).
Demand (D) Demand (D)
If set, Demand mode is active in the transmitting system (the If set, Demand mode is active in the transmitting system (the
system wishes to operate in Demand mode, knows that the session is system wishes to operate in Demand mode, knows that the session is
up in both directions, and is directing the remote system to cease Up in both directions, and is directing the remote system to cease
the periodic transmission of BFD Control packets.) If clear, the periodic transmission of BFD Control packets). If clear,
Demand mode is not active in the transmitting system. Demand mode is not active in the transmitting system.
Multipoint (M) Multipoint (M)
This bit is reserved for future point-to-multipoint extensions to This bit is reserved for future point-to-multipoint extensions to
BFD. It MUST be zero on both transmit and receipt. BFD. It MUST be zero on both transmit and receipt.
Detect Mult Detect Mult
Detection time multiplier. The negotiated transmit interval, Detection time multiplier. The negotiated transmit interval,
skipping to change at page 11, line 45 skipping to change at page 10, line 39
BFD Echo packets that this system is capable of supporting, less BFD Echo packets that this system is capable of supporting, less
any jitter applied by the sender (see section 6.8.9). If this any jitter applied by the sender (see section 6.8.9). If this
value is zero, the transmitting system does not support the value is zero, the transmitting system does not support the
receipt of BFD Echo packets. receipt of BFD Echo packets.
Auth Type Auth Type
The authentication type in use, if the Authentication Present (A) The authentication type in use, if the Authentication Present (A)
bit is set. bit is set.
0 - Reserved 0 - Reserved
1 - Simple Password 1 - Simple Password
2 - Keyed MD5 2 - Keyed MD5
3 - Meticulous Keyed MD5 3 - Meticulous Keyed MD5
4 - Keyed SHA1 4 - Keyed SHA1
5 - Meticulous Keyed SHA1 5 - Meticulous Keyed SHA1
6-255 - Reserved for future use 6-255 - Reserved for future use
Auth Len Auth Len
The length, in bytes, of the authentication section, including the The length, in bytes, of the authentication section, including the
Auth Type and Auth Len fields. Auth Type and Auth Len fields.
4.2. Simple Password Authentication Section Format 4.2. Simple Password Authentication Section Format
If the Authentication Present (A) bit is set in the header, and the If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 1 (Simple Password), the Authentication Type field contains 1 (Simple Password), the
Authentication Section has the following format: Authentication Section has the following format:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Password... | | Auth Type | Auth Len | Auth Key ID | Password... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type Auth Type
The Authentication Type, which in this case is 1 (Simple The Authentication Type, which in this case is 1 (Simple
Password.) Password).
Auth Len Auth Len
The length of the Authentication Section, in bytes. For Simple The length of the Authentication Section, in bytes. For Simple
Password authentication, the length is equal to the password Password authentication, the length is equal to the password
length plus three. length plus three.
Auth Key ID Auth Key ID
The authentication key ID in use for this packet. This allows The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously. multiple keys to be active simultaneously.
Password Password
The simple password in use on this session. The password is a The simple password in use on this session. The password is a
binary string, and MUST be from 1 to 16 bytes in length. The binary string, and MUST be from 1 to 16 bytes in length. The
password MUST be encoded and configured according to section password MUST be encoded and configured according to section
6.7.2. 6.7.2.
4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format
The use of MD5-based authentication is strongly discouraged. The use of MD5-based authentication is strongly discouraged.
However, it is documented here for compatibility with existing However, it is documented here for compatibility with existing
implementations. implementations.
If the Authentication Present (A) bit is set in the header, and the If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous
Keyed MD5), the Authentication Section has the following format: Keyed MD5), the Authentication Section has the following format:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved | | Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Digest... | | Auth Key/Digest... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type Auth Type
The Authentication Type, which in this case is 2 (Keyed MD5) or 3 The Authentication Type, which in this case is 2 (Keyed MD5) or 3
(Meticulous Keyed MD5). (Meticulous Keyed MD5).
Auth Len Auth Len
The length of the Authentication Section, in bytes. For Keyed MD5 The length of the Authentication Section, in bytes. For Keyed MD5
and Meticulous Keyed MD5 authentication, the length is 24. and Meticulous Keyed MD5 authentication, the length is 24.
skipping to change at page 14, line 11 skipping to change at page 12, line 38
The authentication key ID in use for this packet. This allows The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously. multiple keys to be active simultaneously.
Reserved Reserved
This byte MUST be set to zero on transmit, and ignored on receipt. This byte MUST be set to zero on transmit, and ignored on receipt.
Sequence Number Sequence Number
The Sequence Number for this packet. For Keyed MD5 The sequence number for this packet. For Keyed MD5
Authentication, this value is incremented occasionally. For Authentication, this value is incremented occasionally. For
Meticulous Keyed MD5 Authentication, this value is incremented for Meticulous Keyed MD5 Authentication, this value is incremented for
each successive packet transmitted for a session. This provides each successive packet transmitted for a session. This provides
protection against replay attacks. protection against replay attacks.
Auth Key/Digest Auth Key/Digest
This field carries the 16 byte MD5 digest for the packet. When This field carries the 16-byte MD5 digest for the packet. When
the digest is calculated, the shared MD5 key is stored in this the digest is calculated, the shared MD5 key is stored in this
field, padded to 16 bytes with trailing zero bytes if needed. The field, padded to 16 bytes with trailing zero bytes if needed. The
shared key MUST be encoded and configured to section 6.7.3. shared key MUST be encoded and configured to section 6.7.3.
4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format
If the Authentication Present (A) bit is set in the header, and the If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous
Keyed SHA1), the Authentication Section has the following format: Keyed SHA1), the Authentication Section has the following format:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved | | Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Hash... | | Auth Key/Hash... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type Auth Type
The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 The Authentication Type, which in this case is 4 (Keyed SHA1) or 5
(Meticulous Keyed SHA1). (Meticulous Keyed SHA1).
Auth Len Auth Len
The length of the Authentication Section, in bytes. For Keyed The length of the Authentication Section, in bytes. For Keyed
SHA1 and Meticulous Keyed SHA1 authentication, the length is 28. SHA1 and Meticulous Keyed SHA1 authentication, the length is 28.
Auth Key ID Auth Key ID
The authentication key ID in use for this packet. This allows The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously. multiple keys to be active simultaneously.
Reserved Reserved
This byte MUST be set to zero on transmit, and ignored on receipt. This byte MUST be set to zero on transmit and ignored on receipt.
Sequence Number Sequence Number
The Sequence Number for this packet. For Keyed SHA1 The sequence number for this packet. For Keyed SHA1
Authentication, this value is incremented occasionally. For Authentication, this value is incremented occasionally. For
Meticulous Keyed SHA1 Authentication, this value is incremented Meticulous Keyed SHA1 Authentication, this value is incremented
for each successive packet transmitted for a session. This for each successive packet transmitted for a session. This
provides protection against replay attacks. provides protection against replay attacks.
Auth Key/Hash Auth Key/Hash
This field carries the 20 byte SHA1 hash for the packet. When the This field carries the 20-byte SHA1 hash for the packet. When the
hash is calculated, the shared SHA1 key is stored in this field, hash is calculated, the shared SHA1 key is stored in this field,
padded to a length of 20 bytes with trailing zero bytes if needed. padded to a length of 20 bytes with trailing zero bytes if needed.
The shared key MUST be encoded and configured to section 6.7.4. The shared key MUST be encoded and configured to section 6.7.4.
5. BFD Echo Packet Format 5. BFD Echo Packet Format
BFD Echo packets are sent in an encapsulation appropriate to the BFD Echo packets are sent in an encapsulation appropriate to the
environment. See the appropriate application documents for the environment. See the appropriate application documents for the
specifics of particular environments. specifics of particular environments.
The payload of a BFD Echo packet is a local matter, since only the The payload of a BFD Echo packet is a local matter, since only the
sending system ever processes the content. The only requirement is sending system ever processes the content. The only requirement is
that sufficient information is included to demultiplex the received that sufficient information is included to demultiplex the received
packet to the correct BFD session after it is looped back to the packet to the correct BFD session after it is looped back to the
sender. The contents are otherwise outside the scope of this sender. The contents are otherwise outside the scope of this
specification. specification.
Some form of authentication SHOULD be included, since Echo packets Some form of authentication SHOULD be included, since Echo packets
may be spoofed. may be spoofed.
6. Elements of Procedure 6. Elements of Procedure
This section discusses the normative requirements of the protocol in This section discusses the normative requirements of the protocol in
order to achieve interoperability. It is important for implementors order to achieve interoperability. It is important for implementors
to enforce only the requirements specified in this section, as to enforce only the requirements specified in this section, as
misguided pedantry has been proven by experience to adversely affect misguided pedantry has been proven by experience to affect
interoperability. interoperability adversely.
Remember that all references of the form "bfd.Xx" refer to internal Remember that all references of the form "bfd.Xx" refer to internal
state variables (defined in section 6.8.1), whereas all references to state variables (defined in section 6.8.1), whereas all references to
"the Xxx field" refer to fields in the protocol packets themselves "the Xxx field" refer to fields in the protocol packets themselves
(defined in section 4). (defined in section 4).
6.1. Overview 6.1. Overview
A system may take either an Active role or a Passive role in session A system may take either an Active role or a Passive role in session
initialization. A system taking the Active role MUST send BFD initialization. A system taking the Active role MUST send BFD
Control packets for a particular session, regardless of whether it Control packets for a particular session, regardless of whether it
has received any BFD packets for that session. A system taking the has received any BFD packets for that session. A system taking the
Passive role MUST NOT begin sending BFD packets for a particular Passive role MUST NOT begin sending BFD packets for a particular
session until it has received a BFD packet for that session, and thus session until it has received a BFD packet for that session, and thus
has learned the remote system's discriminator value. At least one has learned the remote system's discriminator value. At least one
system MUST take the Active role (possibly both.) The role that a system MUST take the Active role (possibly both). The role that a
system takes is specific to the application of BFD, and is outside system takes is specific to the application of BFD, and is outside
the scope of this specification. the scope of this specification.
A session begins with the periodic, slow transmission of BFD Control A session begins with the periodic, slow transmission of BFD Control
packets. When bidirectional communication is achieved, the BFD packets. When bidirectional communication is achieved, the BFD
session comes Up. session becomes Up.
Once the BFD session is Up, a system can choose to start the Echo Once the BFD session is Up, a system can choose to start the Echo
function if it desires to and the other system signals that it will function if it desires and the other system signals that it will
allow it. The rate of transmission of Control packets is typically allow it. The rate of transmission of Control packets is typically
kept low when the Echo function is active. kept low when the Echo function is active.
If the Echo function is not active, the transmission rate of Control If the Echo function is not active, the transmission rate of Control
packets may be increased to a level necessary to achieve the packets may be increased to a level necessary to achieve the
Detection Time requirements for the session. Detection Time requirements for the session.
Once the session is up, a system may signal that it has entered Once the session is Up, a system may signal that it has entered
Demand mode, and the transmission of BFD Control packets by the Demand mode, and the transmission of BFD Control packets by the
remote system ceases. Other means of implying connectivity are used remote system ceases. Other means of implying connectivity are used
to keep the session alive. If either system wishes to verify to keep the session alive. If either system wishes to verify
bidirectional connectivity, it can initiate a short exchange of BFD bidirectional connectivity, it can initiate a short exchange of BFD
Control packets (a "Poll Sequence"; see section 6.5) to do so. Control packets (a "Poll Sequence"; see section 6.5) to do so.
If Demand mode is not active, and no Control packets are received in If Demand mode is not active, and no Control packets are received in
the calculated Detection Time (see section 6.8.4), the session is the calculated Detection Time (see section 6.8.4), the session is
declared Down. This is signaled to the remote end via the State declared Down. This is signaled to the remote end via the State
(Sta) field in outgoing packets. (Sta) field in outgoing packets.
If sufficient Echo packets are lost, the session is declared down in If sufficient Echo packets are lost, the session is declared Down in
the same manner. See section 6.8.5. the same manner. See section 6.8.5.
If Demand mode is active and no appropriate Control packets are If Demand mode is active and no appropriate Control packets are
received in response to a Poll Sequence, the session is declared down received in response to a Poll Sequence, the session is declared Down
in the same manner. See section 6.6. in the same manner. See section 6.6.
If the session goes down, the transmission of Echo packets (if any) If the session goes Down, the transmission of Echo packets (if any)
ceases, and the transmission of Control packets goes back to the slow ceases, and the transmission of Control packets goes back to the slow
rate. rate.
Once a session has been declared down, it cannot come back up until Once a session has been declared Down, it cannot come back up until
the remote end first signals that it is down (by leaving the Up the remote end first signals that it is down (by leaving the Up
state), thus implementing a three-way handshake. state), thus implementing a three-way handshake.
A session MAY be kept administratively down by entering the AdminDown A session MAY be kept administratively down by entering the AdminDown
state and sending an explanatory diagnostic code in the Diagnostic state and sending an explanatory diagnostic code in the Diagnostic
field. field.
6.2. BFD State Machine 6.2. BFD State Machine
The BFD state machine is quite straightforward. There are three The BFD state machine is quite straightforward. There are three
states through which a session normally proceeds, two for states through which a session normally proceeds: two for
establishing a session (Init and Up) and one for tearing down a establishing a session (Init and Up) and one for tearing down a
session (Down.) This allows a three-way handshake for both session session (Down). This allows a three-way handshake for both session
establishment and session teardown (assuring that both systems are establishment and session teardown (assuring that both systems are
aware of all session state changes.) A fourth state (AdminDown) aware of all session state changes). A fourth state (AdminDown)
exists so that a session can be administratively put down exists so that a session can be administratively put down
indefinitely. indefinitely.
Each system communicates its session state in the State (Sta) field Each system communicates its session state in the State (Sta) field
in the BFD Control packet, and that received state in combination in the BFD Control packet, and that received state, in combination
with the local session state drives the state machine. with the local session state, drives the state machine.
Down state means that the session is down (or has just been created.) Down state means that the session is down (or has just been created).
A session remains in Down state until the remote system indicates A session remains in Down state until the remote system indicates
that it agrees that the session is down by sending a BFD Control that it agrees that the session is down by sending a BFD Control
packet with the State field set to anything other than Up. If that packet with the State field set to anything other than Up. If that
packet signals Down state, the session advances to Init state; if packet signals Down state, the session advances to Init state; if
that packet signals Init state, the session advances to Up state. that packet signals Init state, the session advances to Up state.
Semantically, Down state indicates that the forwarding path is Semantically, Down state indicates that the forwarding path is
unavailable, and that appropriate actions should be taken by the unavailable, and that appropriate actions should be taken by the
applications monitoring the state of the BFD session. A system MAY applications monitoring the state of the BFD session. A system MAY
hold a session in Down state indefinitely (by simply refusing to hold a session in Down state indefinitely (by simply refusing to
advance the session state.) This may be done for operational or advance the session state). This may be done for operational or
administrative reasons, among others. administrative reasons, among others.
Init state means that the remote system is communicating, and the Init state means that the remote system is communicating, and the
local system desires to bring the session up, but the remote system local system desires to bring the session up, but the remote system
does not yet realize it. A session will remain in Init state until does not yet realize it. A session will remain in Init state until
either a BFD Control Packet is received that is signaling Init or Up either a BFD Control Packet is received that is signaling Init or Up
state (in which case the session advances to Up state) or until the state (in which case the session advances to Up state) or the
Detection Time expires, meaning that communication with the remote Detection Time expires, meaning that communication with the remote
system has been lost (in which case the session advances to Down system has been lost (in which case the session advances to Down
state.) state).
Up state means that the BFD session has successfully been Up state means that the BFD session has successfully been
established, and implies that connectivity between the systems is established, and implies that connectivity between the systems is
working. The session will remain in the Up state until either working. The session will remain in the Up state until either
connectivity fails, or the session is taken down administratively. connectivity fails or the session is taken down administratively. If
If either the remote system signals Down state, or the Detection Time either the remote system signals Down state or the Detection Time
expires, the session advances to Down state. expires, the session advances to Down state.
AdminDown state means that the session is being held administratively AdminDown state means that the session is being held administratively
down. This causes the remote system to enter Down state, and remain down. This causes the remote system to enter Down state, and remain
there until the local system exits AdminDown state. AdminDown state there until the local system exits AdminDown state. AdminDown state
has no semantic implications for the availability of the forwarding has no semantic implications for the availability of the forwarding
path. path.
The following diagram provides an overview of the state machine. The following diagram provides an overview of the state machine.
Transitions involving AdminDown state are deleted for clarity (but Transitions involving AdminDown state are deleted for clarity (but
are fully specified in sections 6.8.6 and 6.8.16.) The notation on are fully specified in sections 6.8.6 and 6.8.16). The notation on
each arc represents the state of the remote system (as received in each arc represents the state of the remote system (as received in
the State field in the BFD Control packet) or indicates the the State field in the BFD Control packet) or indicates the
expiration of the Detection Timer. expiration of the Detection Timer.
+--+ +--+
| | UP, ADMIN DOWN, TIMER | | UP, ADMIN DOWN, TIMER
| V | V
DOWN +------+ INIT DOWN +------+ INIT
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| | ADMIN DOWN,| | | | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| | | |ADMIN DOWN, DOWN,| |
| |TIMER TIMER| | | |TIMER TIMER| |
V | | V V | | V
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+ +--->| | INIT, UP | |<---+
+------+ +------+ +------+ +------+
6.3. Demultiplexing and the Discriminator Fields 6.3. Demultiplexing and the Discriminator Fields
Since multiple BFD sessions may be running between two systems, there Since multiple BFD sessions may be running between two systems, there
needs to be a mechanism for demultiplexing received BFD packets to needs to be a mechanism for demultiplexing received BFD packets to
the proper session. the proper session.
Each system MUST choose an opaque discriminator value that identifies Each system MUST choose an opaque discriminator value that identifies
each session, and which MUST be unique among all BFD sessions on the each session, and which MUST be unique among all BFD sessions on the
system. The local discriminator is sent in the My Discriminator system. The local discriminator is sent in the My Discriminator
field in the BFD Control packet, and is echoed back in the Your field in the BFD Control packet, and is echoed back in the Your
Discriminator field of packets sent from the remote end. Discriminator field of packets sent from the remote end.
Once the remote end echoes back the local discriminator, all further Once the remote end echoes back the local discriminator, all further
received packets are demultiplexed based on the Your Discriminator received packets are demultiplexed based on the Your Discriminator
field only (which means that, among other things, the source address field only (which means that, among other things, the source address
field can change or the interface over which the packets are received field can change or the interface over which the packets are received
can change, but the packets will still be associated with the proper can change, but the packets will still be associated with the proper
session.) session).
The method of demultiplexing the initial packets (in which Your The method of demultiplexing the initial packets (in which Your
Discriminator is zero) is application-dependent, and is thus outside Discriminator is zero) is application dependent, and is thus outside
the scope of this specification. the scope of this specification.
Note that it is permissible for a system to change its discriminator Note that it is permissible for a system to change its discriminator
during a session without affecting the session state, since only that during a session without affecting the session state, since only that
system uses its discriminator for demultiplexing purposes (by having system uses its discriminator for demultiplexing purposes (by having
the other system reflect it back.) The implications on an the other system reflect it back). The implications on an
implementation for changing the discriminator value is outside the implementation for changing the discriminator value is outside the
scope of this specification. scope of this specification.
6.4. The Echo Function and Asymmetry 6.4. The Echo Function and Asymmetry
The Echo function can be run independently in each direction between The Echo function can be run independently in each direction between
a pair of systems. For whatever reason, a system may advertise that a pair of systems. For whatever reason, a system may advertise that
it is willing to receive (and loop back) Echo packets, but may not it is willing to receive (and loop back) Echo packets, but may not
wish to ever send any. The fact that a system is sending Echo wish to ever send any. The fact that a system is sending Echo
packets is not directly signaled to the system looping them back. packets is not directly signaled to the system looping them back.
When a system is using the Echo function, it is advantageous to When a system is using the Echo function, it is advantageous to
choose a sedate reception rate for Control packets, since liveness choose a sedate reception rate for Control packets, since liveness
detection is being handled by the Echo packets. This can be detection is being handled by the Echo packets. This can be
controlled by manipulating the Required Min RX Interval field (see controlled by manipulating the Required Min RX Interval field (see
section 6.8.3.) section 6.8.3).
If the Echo function is only being run in one direction, the system If the Echo function is only being run in one direction, the system
not running the Echo function will more likely wish to receive fairly not running the Echo function will more likely wish to receive fairly
rapid Control packets in order to achieve its desired Detection Time. rapid Control packets in order to achieve its desired Detection Time.
Since BFD allows independent transmission rates in each direction, Since BFD allows independent transmission rates in each direction,
this is easily accomplished. this is easily accomplished.
A system SHOULD otherwise advertise the lowest value of Required Min A system SHOULD otherwise advertise the lowest value of Required Min
RX Interval and Required Min Echo RX Interval that it can under the RX Interval and Required Min Echo RX Interval that it can under the
circumstances, to give the other system more freedom in choosing its circumstances, to give the other system more freedom in choosing its
transmission rate. Note that a system is committing to be able to transmission rate. Note that a system is committing to be able to
receive both streams of packets at the rate it advertises, so this receive both streams of packets at the rate it advertises, so this
should be taken into account when choosing the values to advertise. should be taken into account when choosing the values to advertise.
6.5. The Poll Sequence 6.5. The Poll Sequence
A Poll Sequence is an exchange of BFD Control packets that is used in A Poll Sequence is an exchange of BFD Control packets that is used in
some circumstances to ensure that the remote system is aware of some circumstances to ensure that the remote system is aware of
parameter changes. It is also used in Demand mode (see section 6.6) parameter changes. It is also used in Demand mode (see section 6.6)
to validate bidirectional connectivity. to validate bidirectional connectivity.
A Poll Sequence consists of a system sending periodic BFD Control A Poll Sequence consists of a system sending periodic BFD Control
packets with the Poll (P) bit set. When the other system receives a packets with the Poll (P) bit set. When the other system receives a
Poll, it immediately transmits a BFD Control packet with the Final Poll, it immediately transmits a BFD Control packet with the Final
(F) bit set, independent of any periodic BFD Control packets it may (F) bit set, independent of any periodic BFD Control packets it may
skipping to change at page 21, line 12 skipping to change at page 19, line 29
Poll bit cleared. A BFD Control packet MUST NOT have both the Poll Poll bit cleared. A BFD Control packet MUST NOT have both the Poll
(P) and Final (F) bits set. (P) and Final (F) bits set.
If periodic BFD Control packets are already being sent (the remote If periodic BFD Control packets are already being sent (the remote
system is not in Demand mode), the Poll Sequence MUST be performed by system is not in Demand mode), the Poll Sequence MUST be performed by
setting the Poll (P) bit on those scheduled periodic transmissions; setting the Poll (P) bit on those scheduled periodic transmissions;
additional packets MUST NOT be sent. additional packets MUST NOT be sent.
After a Poll Sequence is terminated, the system requesting the Poll After a Poll Sequence is terminated, the system requesting the Poll
Sequence will cease the periodic transmission of BFD Control packets Sequence will cease the periodic transmission of BFD Control packets
if the remote end is in Demand mode; otherwise it will return to the if the remote end is in Demand mode; otherwise, it will return to the
periodic transmission of BFD Control packets with the Poll (P) bit periodic transmission of BFD Control packets with the Poll (P) bit
clear. clear.
Typically, the entire sequence consists of a single packet in each Typically, the entire sequence consists of a single packet in each
direction, though packet losses or relatively long packet latencies direction, though packet losses or relatively long packet latencies
may result in multiple Poll packets to be sent before the sequence may result in multiple Poll packets to be sent before the sequence
terminates. terminates.
6.6. Demand Mode 6.6. Demand Mode
Demand mode is requested independently in each direction by virtue of Demand mode is requested independently in each direction by virtue of
a system setting the Demand (D) bit in its BFD Control packets. The a system setting the Demand (D) bit in its BFD Control packets. The
system receiving the Demand bit ceases the periodic transmission of system receiving the Demand bit ceases the periodic transmission of
BFD Control packets. If both systems are operating in Demand mode, BFD Control packets. If both systems are operating in Demand mode,
no periodic BFD Control packets will flow in either direction. no periodic BFD Control packets will flow in either direction.
Demand mode requires that some other mechanism is used to imply Demand mode requires that some other mechanism is used to imply
continuing connectivity between the two systems. The mechanism used continuing connectivity between the two systems. The mechanism used
does not have to be the same in both directions, and is outside of does not have to be the same in both directions, and is outside of
the scope of this specification. One possible mechanism is the the scope of this specification. One possible mechanism is the
receipt of traffic from the remote system; another is the use of the receipt of traffic from the remote system; another is the use of the
Echo function. Echo function.
When a system in Demand mode wishes to verify bidirectional When a system in Demand mode wishes to verify bidirectional
connectivity, it initiates a Poll Sequence (see section 6.5). If no connectivity, it initiates a Poll Sequence (see section 6.5). If no
response is received to a Poll, the Poll is repeated until the response is received to a Poll, the Poll is repeated until the
Detection Time expires, at which point the session is declared to be Detection Time expires, at which point the session is declared to be
down. Note that if Demand mode is operating only on the local Down. Note that if Demand mode is operating only on the local
system, the Poll Sequence is performed by simply setting the Poll (P) system, the Poll Sequence is performed by simply setting the Poll (P)
bit in regular periodic BFD Control packets, as required by section bit in regular periodic BFD Control packets, as required by section
6.5. 6.5.
The Detection Time in Demand mode is calculated differently than in The Detection Time in Demand mode is calculated differently than in
Asynchronous mode; it is based on the transmit rate of the local Asynchronous mode; it is based on the transmit rate of the local
system, rather than the transmit rate of the remote system. This system, rather than the transmit rate of the remote system. This
ensures that the Poll Sequence mechanism works properly. See section ensures that the Poll Sequence mechanism works properly. See section
6.8.4 for more details. 6.8.4 for more details.
Note that the Poll mechanism will always fail unless the negotiated Note that the Poll mechanism will always fail unless the negotiated
Detection Time is greater than the round trip time between the two Detection Time is greater than the round-trip time between the two
systems. Enforcement of this constraint is outside the scope of this systems. Enforcement of this constraint is outside the scope of this
specification. specification.
Demand mode MAY be enabled or disabled at any time, independently in Demand mode MAY be enabled or disabled at any time, independently in
each direction, by setting or clearing the Demand (D) bit in the BFD each direction, by setting or clearing the Demand (D) bit in the BFD
Control packet, without affecting the BFD session state. Note that Control packet, without affecting the BFD session state. Note that
the Demand bit MUST NOT be set unless both systems perceive the the Demand bit MUST NOT be set unless both systems perceive the
session to be Up (the local system thinks the session is Up, and the session to be Up (the local system thinks the session is Up, and the
remote system last reported Up state in the State (Sta) field of the remote system last reported Up state in the State (Sta) field of the
BFD Control packet.) BFD Control packet).
When the transmitted value of the Demand (D) bit is to be changed, When the transmitted value of the Demand (D) bit is to be changed,
the transmitting system MUST initiate a Poll Sequence in conjunction the transmitting system MUST initiate a Poll Sequence in conjunction
with changing the bit in order to ensure that both systems are aware with changing the bit in order to ensure that both systems are aware
of the change. of the change.
If Demand mode is active on either or both systems, a Poll Sequence If Demand mode is active on either or both systems, a Poll Sequence
MUST be initiated whenever the contents of the next BFD Control MUST be initiated whenever the contents of the next BFD Control
packet to be sent would be different than the contents of the packet to be sent would be different than the contents of the
previous packet, with the exception of the Poll (P) and Final (F) previous packet, with the exception of the Poll (P) and Final (F)
skipping to change at page 22, line 38 skipping to change at page 21, line 8
Because the underlying detection mechanism is unspecified, and may Because the underlying detection mechanism is unspecified, and may
differ between the two systems, the overall Detection Time differ between the two systems, the overall Detection Time
characteristics of the path will not be fully known to either system. characteristics of the path will not be fully known to either system.
The total Detection Time for a particular system is the sum of the The total Detection Time for a particular system is the sum of the
time prior to the initiation of the Poll Sequence, plus the time prior to the initiation of the Poll Sequence, plus the
calculated Detection Time. calculated Detection Time.
Note that if Demand mode is enabled in only one direction, continuous Note that if Demand mode is enabled in only one direction, continuous
bidirectional connectivity verification is lost (only connectivity in bidirectional connectivity verification is lost (only connectivity in
the direction from the system in Demand mode to the other system will the direction from the system in Demand mode to the other system will
be verified.) Resolving the issue of one system requesting Demand be verified). Resolving the issue of one system requesting Demand
mode while the other requires continuous bidirectional connectivity mode while the other requires continuous bidirectional connectivity
verification is outside the scope of this specification. verification is outside the scope of this specification.
6.7. Authentication 6.7. Authentication
An optional Authentication Section MAY be present in the BFD Control An optional Authentication Section MAY be present in the BFD Control
packet. In its generic form, the purpose of the Authentication packet. In its generic form, the purpose of the Authentication
Section is to carry all necessary information, based on the Section is to carry all necessary information, based on the
authentication type in use, to allow the receiving system to authentication type in use, to allow the receiving system to
determine the validity of the received packet. The exact mechanism determine the validity of the received packet. The exact mechanism
depends on the authentication type in use, but in general the depends on the authentication type in use, but in general the
transmitting system will put information in the Authentication transmitting system will put information in the Authentication
Section that vouches for the packet's validity, and the receiving Section that vouches for the packet's validity, and the receiving
system will examine the Authentication Section and either accept the system will examine the Authentication Section and either accept the
packet for further processing, or discard it. packet for further processing or discard it.
The same authentication type, and any keys or other necessary The same authentication type, and any keys or other necessary
information, obviously must be in use by the two systems. The information, obviously must be in use by the two systems. The
negotiation of authentication type, key exchange, etc. are all negotiation of authentication type, key exchange, etc., are all
outside the scope of this specification and are expected to be outside the scope of this specification and are expected to be
performed by means outside of the protocol. performed by means outside of the protocol.
Note that in the subsections below, to "accept" a packet means only Note that in the subsections below, to "accept" a packet means only
that the packet has passed authentication; it may in fact be that the packet has passed authentication; it may in fact be
discarded for other reasons as described in the general packet discarded for other reasons as described in the general packet
reception rules described in section 6.8.6. reception rules described in section 6.8.6.
Implementations supporting authentication MUST support both types of Implementations supporting authentication MUST support both types of
SHA1 authentication. Other forms of authentication are optional. SHA1 authentication. Other forms of authentication are optional.
6.7.1. Enabling and Disabling Authentication 6.7.1. Enabling and Disabling Authentication
It may be desirable to enable or disable authentication on a session It may be desirable to enable or disable authentication on a session
without disturbing the session state. The exact mechanism for doing without disturbing the session state. The exact mechanism for doing
so is outside the scope of this specification. However, it is useful so is outside the scope of this specification. However, it is useful
to point out some issues in supporting this mechanism. to point out some issues in supporting this mechanism.
In a simple implementation, a BFD session will fail when In a simple implementation, a BFD session will fail when
authentication is either turned on or turned off, because the packet authentication is either turned on or turned off, because the packet
acceptance rules essentially require the local and remote machines to acceptance rules essentially require the local and remote machines to
do so in a more or less synchronized fashion (within the Detection do so in a more or less synchronized fashion (within the Detection
Time)--a packet with authentication will only be accepted if Time) -- a packet with authentication will only be accepted if
authentication is "in use" (and likewise packets without authentication is "in use" (and likewise packets without
authentication. authentication).
One possible approach is to build an implementation such that One possible approach is to build an implementation such that
authentication is configured, but not considered "in use" until the authentication is configured, but not considered "in use" until the
first packet containing a matching authentication section is received first packet containing a matching authentication section is received
(providing the necessary synchronization.) Likewise, authentication (providing the necessary synchronization). Likewise, authentication
could be configured off, but still considered "in use" until the could be configured off, but still considered "in use" until the
receipt of the first packet without the authentication section. receipt of the first packet without the authentication section.
In order to avoid security risks, implementations using this method In order to avoid security risks, implementations using this method
SHOULD only allow the authentication state to be changed at most once SHOULD only allow the authentication state to be changed at most once
without some form of intervention (so that authentication cannot be without some form of intervention (so that authentication cannot be
turned on and off repeatedly simply based on the receipt of BFD turned on and off repeatedly simply based on the receipt of BFD
Control packets from remote systems.) Unless it is desired to enable Control packets from remote systems). Unless it is desired to enable
or disable authentication, an implementation SHOULD NOT allow the or disable authentication, an implementation SHOULD NOT allow the
authentication state to change based on the receipt of BFD Control authentication state to change based on the receipt of BFD Control
packets. packets.
6.7.2. Simple Password Authentication 6.7.2. Simple Password Authentication
The most straightforward (and weakest) form of authentication is The most straightforward (and weakest) form of authentication is
Simple Password Authentication. In this method of authentication, Simple Password Authentication. In this method of authentication,
one or more Passwords (with corresponding Key IDs) are configured in one or more Passwords (with corresponding Key IDs) are configured in
each system and one of these Password/ID pairs is carried in each BFD each system and one of these Password/ID pairs is carried in each BFD
Control packet. The receiving system accepts the packet if the Control packet. The receiving system accepts the packet if the
Password and Key ID matches one of the Password/ID pairs configured Password and Key ID matches one of the Password/ID pairs configured
in that system. in that system.
Transmission Using Simple Password Authentication Transmission Using Simple Password Authentication
The currently selected password and Key ID for the session MUST be The currently selected password and Key ID for the session MUST be
stored in the Authentication Section of each outgoing BFD Control stored in the Authentication Section of each outgoing BFD Control
packet. The Auth Type field MUST be set to 1 (Simple Password.) packet. The Auth Type field MUST be set to 1 (Simple Password).
The Auth Len field MUST be set to the proper length (4 to 19 The Auth Len field MUST be set to the proper length (4 to 19
bytes). bytes).
The password is a binary string, and MUST be 1 to 16 bytes in The password is a binary string, and MUST be 1 to 16 bytes in
length. For interoperability, the management interface by which length. For interoperability, the management interface by which
the password is configured MUST accept ASCII strings, and SHOULD the password is configured MUST accept ASCII strings, and SHOULD
also allow for the configuration of any arbitrary binary string in also allow for the configuration of any arbitrary binary string in
hexadecimal form. Other configuration methods MAY be supported. hexadecimal form. Other configuration methods MAY be supported.
Reception Using Simple Password Authentication Reception Using Simple Password Authentication
If the received BFD Control packet does not contain an If the received BFD Control packet does not contain an
Authentication Section, or the Auth Type is not 1 (Simple Authentication Section, or the Auth Type is not 1 (Simple
Password), then the received packet MUST be discarded. Password), then the received packet MUST be discarded.
If the Auth Key ID field does not match the ID of a configured If the Auth Key ID field does not match the ID of a configured
password, the received packet MUST be discarded. password, the received packet MUST be discarded.
If the Auth Len field is not equal to the length of the password If the Auth Len field is not equal to the length of the password
selected by the Key ID, plus three, the packet MUST be discarded. selected by the key ID, plus three, the packet MUST be discarded.
If the Password field does not match the password selected by the If the Password field does not match the password selected by the
Key ID, the packet MUST be discarded. key ID, the packet MUST be discarded.
Otherwise, the packet MUST be accepted. Otherwise, the packet MUST be accepted.
6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication 6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication
The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are
very similar to those used in other protocols. In these methods of very similar to those used in other protocols. In these methods of
authentication, one or more secret keys (with corresponding Key IDs) authentication, one or more secret keys (with corresponding key IDs)
are configured in each system. One of the Keys is included in an MD5 are configured in each system. One of the keys is included in an MD5
[MD5] digest calculated over the outgoing BFD Control packet, but the [MD5] digest calculated over the outgoing BFD Control packet, but the
Key itself is not carried in the packet. To help avoid replay Key itself is not carried in the packet. To help avoid replay
attacks, a sequence number is also carried in each packet. For Keyed attacks, a sequence number is also carried in each packet. For Keyed
MD5, the sequence number is occasionally incremented. For Meticulous MD5, the sequence number is occasionally incremented. For Meticulous
Keyed MD5, the sequence number is incremented on every packet. Keyed MD5, the sequence number is incremented on every packet.
The receiving system accepts the packet if the Key ID matches one of The receiving system accepts the packet if the key ID matches one of
the configured Keys, an MD5 digest including the selected key matches the configured Keys, an MD5 digest including the selected key matches
that carried in the packet, and if the sequence number is greater that carried in the packet, and the sequence number is greater than
than or equal to the last sequence number received (for Keyed MD5), or equal to the last sequence number received (for Keyed MD5), or
or strictly greater than the last sequence number received (for strictly greater than the last sequence number received (for
Meticulous Keyed MD5.) Meticulous Keyed MD5).
Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication
The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous
Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key Keyed MD5). The Auth Len field MUST be set to 24. The Auth Key
ID field MUST be set to the ID of the current authentication key. ID field MUST be set to the ID of the current authentication key.
The Sequence Number field MUST be set to bfd.XmitAuthSeq. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
The authentication key value is a binary string of up to 16 bytes, The authentication key value is a binary string of up to 16 bytes,
and MUST be placed into the Auth Key/Digest field, padded with and MUST be placed into the Auth Key/Digest field, padded with
trailing zero bytes as necessary. For interoperability, the trailing zero bytes as necessary. For interoperability, the
management interface by which the key is configured MUST accept management interface by which the key is configured MUST accept
ASCII strings, and SHOULD also allow for the configuration of any ASCII strings, and SHOULD also allow for the configuration of any
arbitrary binary string in hexadecimal form. Other configuration arbitrary binary string in hexadecimal form. Other configuration
methods MAY be supported. methods MAY be supported.
An MD5 digest MUST be calculated over the entire BFD control An MD5 digest MUST be calculated over the entire BFD Control
packet. The resulting digest MUST be stored in the Auth packet. The resulting digest MUST be stored in the Auth
Key/Digest field prior to transmission (replacing the secret key, Key/Digest field prior to transmission (replacing the secret key,
which MUST NOT be carried in the packet.) which MUST NOT be carried in the packet).
For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular
fashion (when treated as an unsigned 32 bit value.) fashion (when treated as an unsigned 32-bit value).
bfd.XmitAuthSeq SHOULD be incremented when the session state bfd.XmitAuthSeq SHOULD be incremented when the session state
changes, or when the transmitted BFD Control packet carries changes, or when the transmitted BFD Control packet carries
different contents than the previously transmitted packet. The different contents than the previously transmitted packet. The
decision as to when to increment bfd.XmitAuthSeq is outside the decision as to when to increment bfd.XmitAuthSeq is outside the
scope of this specification. See the section entitled "Security scope of this specification. See the section titled "Security
Considerations" below for a discussion. Considerations" below for a discussion.
For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a
circular fashion (when treated as an unsigned 32 bit value.) circular fashion (when treated as an unsigned 32-bit value).
Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication
If the received BFD Control packet does not contain an If the received BFD Control packet does not contain an
Authentication Section, or the Auth Type is not correct (2 for Authentication Section, or the Auth Type is not correct (2 for
Keyed MD5, or 3 for Meticulous Keyed MD5), then the received Keyed MD5 or 3 for Meticulous Keyed MD5), then the received packet
packet MUST be discarded. MUST be discarded.
If the Auth Key ID field does not match the ID of a configured If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded. authentication key, the received packet MUST be discarded.
If the Auth Len field is not equal to 24, the packet MUST be If the Auth Len field is not equal to 24, the packet MUST be
discarded. discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Keyed MD5, if the Sequence Number lies outside of the range of Keyed MD5, if the sequence number lies outside of the range of
bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32 bit circular number space), the received treated as an unsigned 32-bit circular number space), the received
packet MUST be discarded. For Meticulous Keyed MD5, if the packet MUST be discarded. For Meticulous Keyed MD5, if the
Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to sequence number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32 bit circular number space, the received packet MUST be unsigned 32-bit circular number space) the received packet MUST be
discarded. discarded.
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, bfd.RcvAuthSeq MUST be set to the value of the received 1, and bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field. Sequence Number field.
Replace the contents of the Auth Key/Digest field with the Replace the contents of the Auth Key/Digest field with the
authentication key selected by the received Auth Key ID field. If authentication key selected by the received Auth Key ID field. If
the MD5 digest of the entire BFD Control packet is equal to the the MD5 digest of the entire BFD Control packet is equal to the
received value of the Auth Key/Digest field, the received packet received value of the Auth Key/Digest field, the received packet
MUST be accepted. Otherwise (the digest does not match the Auth MUST be accepted. Otherwise (the digest does not match the Auth
Key/Digest field) the received packet MUST be discarded. Key/Digest field), the received packet MUST be discarded.
6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication 6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication
The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms
are very similar to those used in other protocols. In these methods are very similar to those used in other protocols. In these methods
of authentication, one or more secret keys (with corresponding Key of authentication, one or more secret keys (with corresponding key
IDs) are configured in each system. One of the Keys is included in a IDs) are configured in each system. One of the keys is included in a
SHA1 [SHA1] hash calculated over the outgoing BFD Control packet, but SHA1 [SHA1] hash calculated over the outgoing BFD Control packet, but
the Key itself is not carried in the packet. To help avoid replay the key itself is not carried in the packet. To help avoid replay
attacks, a sequence number is also carried in each packet. For Keyed attacks, a sequence number is also carried in each packet. For Keyed
SHA1, the sequence number is occasionally incremented. For SHA1, the sequence number is occasionally incremented. For
Meticulous Keyed SHA1, the sequence number is incremented on every Meticulous Keyed SHA1, the sequence number is incremented on every
packet. packet.
The receiving system accepts the packet if the Key ID matches one of The receiving system accepts the packet if the key ID matches one of
the configured Keys, a SHA1 hash including the selected key matches the configured keys, a SHA1 hash including the selected key matches
that carried in the packet, and if the sequence number is greater that carried in the packet, and if the sequence number is greater
than or equal to the last sequence number received (for Keyed SHA1), than or equal to the last sequence number received (for Keyed SHA1),
or strictly greater than the last sequence number received (for or strictly greater than the last sequence number received (for
Meticulous Keyed SHA1.) Meticulous Keyed SHA1).
Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 Transmission Using Keyed SHA1 and Meticulous Keyed SHA1
Authentication Authentication
The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous
Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key Keyed SHA1). The Auth Len field MUST be set to 28. The Auth Key
ID field MUST be set to the ID of the current authentication key. ID field MUST be set to the ID of the current authentication key.
The Sequence Number field MUST be set to bfd.XmitAuthSeq. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
The authentication key value is a binary string of up to 20 bytes, The authentication key value is a binary string of up to 20 bytes,
and MUST be placed into the Auth Key/Hash field, padding with and MUST be placed into the Auth Key/Hash field, padding with
trailing zero bytes as necessary. For interoperability, the trailing zero bytes as necessary. For interoperability, the
management interface by which the key is configured MUST accept management interface by which the key is configured MUST accept
ASCII strings, and SHOULD also allow for the configuration of any ASCII strings, and SHOULD also allow for the configuration of any
arbitrary binary string in hexadecimal form. Other configuration arbitrary binary string in hexadecimal form. Other configuration
methods MAY be supported. methods MAY be supported.
A SHA1 hash MUST be calculated over the entire BFD control packet. A SHA1 hash MUST be calculated over the entire BFD control packet.
The resulting hash MUST be stored in the Auth Key/Hash field prior The resulting hash MUST be stored in the Auth Key/Hash field prior
to transmission (replacing the secret key, which MUST NOT be to transmission (replacing the secret key, which MUST NOT be
carried in the packet.) carried in the packet).
For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular
fashion (when treated as an unsigned 32 bit value.) fashion (when treated as an unsigned 32-bit value).
bfd.XmitAuthSeq SHOULD be incremented when the session state bfd.XmitAuthSeq SHOULD be incremented when the session state
changes, or when the transmitted BFD Control packet carries changes, or when the transmitted BFD Control packet carries
different contents than the previously transmitted packet. The different contents than the previously transmitted packet. The
decision as to when to increment bfd.XmitAuthSeq is outside the decision as to when to increment bfd.XmitAuthSeq is outside the
scope of this specification. See the section entitled "Security scope of this specification. See the section titled "Security
Considerations" below for a discussion. Considerations" below for a discussion.
For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in
a circular fashion (when treated as an unsigned 32 bit value.) a circular fashion (when treated as an unsigned 32-bit value).
Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication
If the received BFD Control packet does not contain an If the received BFD Control packet does not contain an
Authentication Section, or the Auth Type is not correct (4 for Authentication Section, or the Auth Type is not correct (4 for
Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received Keyed SHA1 or 5 for Meticulous Keyed SHA1), then the received
packet MUST be discarded. packet MUST be discarded.
If the Auth Key ID field does not match the ID of a configured If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded. authentication key, the received packet MUST be discarded.
If the Auth Len field is not equal to 28, the packet MUST be If the Auth Len field is not equal to 28, the packet MUST be
discarded. discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Keyed SHA1, if the Sequence Number lies outside of the range of Keyed SHA1, if the sequence number lies outside of the range of
bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32 bit circular number space), the received treated as an unsigned 32-bit circular number space), the received
packet MUST be discarded. For Meticulous Keyed SHA1, if the packet MUST be discarded. For Meticulous Keyed SHA1, if the
Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to sequence number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32 bit circular number space, the received packet MUST be unsigned 32-bit circular number space, the received packet MUST be
discarded. discarded.
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, bfd.RcvAuthSeq MUST be set to the value of the received 1, bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field, and the received packet MUST be accepted. Sequence Number field, and the received packet MUST be accepted.
Replace the contents of the Auth Key/Hash field with the Replace the contents of the Auth Key/Hash field with the
authentication key selected by the received Auth Key ID field. If authentication key selected by the received Auth Key ID field. If
the SHA1 hash of the entire BFD Control packet is equal to the the SHA1 hash of the entire BFD Control packet is equal to the
received value of the Auth Key/Hash field, the received packet received value of the Auth Key/Hash field, the received packet
MUST be accepted. Otherwise (the hash does not match the Auth MUST be accepted. Otherwise (the hash does not match the Auth
Key/Hash field) the received packet MUST be discarded. Key/Hash field), the received packet MUST be discarded.
6.8. Functional Specifics 6.8. Functional Specifics
The following section of this specification is normative. The means The following section of this specification is normative. The means
by which this specification is achieved is outside the scope of this by which this specification is achieved is outside the scope of this
specification. specification.
When a system is said to have "the Echo function active," it means When a system is said to have "the Echo function active" it means
that the system is sending BFD Echo packets, implying that the that the system is sending BFD Echo packets, implying that the
session is Up and the other system has signaled its willingness to session is Up and the other system has signaled its willingness to
loop back Echo packets. loop back Echo packets.
When the local system is said to have "Demand mode active," it means When the local system is said to have "Demand mode active," it means
that bfd.DemandMode is 1 in the local system (see section 6.8.1), the that bfd.DemandMode is 1 in the local system (see section 6.8.1), the
session is Up, and the remote system is signaling that the session is session is Up, and the remote system is signaling that the session is
in state Up. in state Up.
When the remote system is said to have "Demand mode active," it means When the remote system is said to have "Demand mode active," it means
that bfd.RemoteDemandMode is 1 (the remote system set the Demand (D) that bfd.RemoteDemandMode is 1 (the remote system set the Demand (D)
bit in the last received BFD Control packet), the session is Up, and bit in the last received BFD Control packet), the session is Up, and
the remote system is signaling that the session is in state Up. the remote system is signaling that the session is in state Up.
6.8.1. State Variables 6.8.1. State Variables
A minimum amount of information about a session needs to be tracked A minimum amount of information about a session needs to be tracked
in order to achieve the elements of procedure described here. The in order to achieve the elements of procedure described here. The
following is a set of state variables that are helpful in describing following is a set of state variables that are helpful in describing
the mechanisms of BFD. Any means of tracking this state may be used the mechanisms of BFD. Any means of tracking this state may be used
so long as the protocol behaves as described. so long as the protocol behaves as described.
When the text refers to initializing a state variable, this takes When the text refers to initializing a state variable, this takes
place only at the time that the session (and the corresponding state place only at the time that the session (and the corresponding state
variables) is created. The state variables are subsequently variables) is created. The state variables are subsequently
skipping to change at page 29, line 41 skipping to change at page 28, line 10
preserve session state longer than this. The preservation or preserve session state longer than this. The preservation or
destruction of session state when no BFD Control packets for this destruction of session state when no BFD Control packets for this
session have been received from the remote system is outside the session have been received from the remote system is outside the
scope of this specification. scope of this specification.
All state variables in this specification are of the form "bfd.Xx" All state variables in this specification are of the form "bfd.Xx"
and should not be confused with fields carried in the protocol and should not be confused with fields carried in the protocol
packets, which are always spelled out to match the names in section packets, which are always spelled out to match the names in section
4. 4.
bfd.SessionState bfd.SessionState
The perceived state of the session (Init, Up, Down, or The perceived state of the session (Init, Up, Down, or AdminDown).
AdminDown.) The exact action taken when the session state The exact action taken when the session state changes is outside
changes is outside the scope of this specification, though it the scope of this specification, though it is expected that this
is expected that this state change (particularly to and from Up state change (particularly, to and from Up state) is reported to
state) is reported to other components of the system. This other components of the system. This variable MUST be initialized
variable MUST be initialized to Down. to Down.
bfd.RemoteSessionState bfd.RemoteSessionState
The session state last reported by the remote system in the The session state last reported by the remote system in the State
State (Sta) field of the BFD Control packet. This variable (Sta) field of the BFD Control packet. This variable MUST be
MUST be initialized to Down. initialized to Down.
bfd.LocalDiscr bfd.LocalDiscr
The local discriminator for this BFD session, used to uniquely The local discriminator for this BFD session, used to uniquely
identify it. It MUST be unique across all BFD sessions on this identify it. It MUST be unique across all BFD sessions on this
system, and nonzero. It SHOULD be set to a random (but still system, and nonzero. It SHOULD be set to a random (but still
unique) value to improve security. The value is otherwise unique) value to improve security. The value is otherwise outside
outside the scope of this specification. the scope of this specification.
bfd.RemoteDiscr bfd.RemoteDiscr
The remote discriminator for this BFD session. This is the The remote discriminator for this BFD session. This is the
discriminator chosen by the remote system, and is totally discriminator chosen by the remote system, and is totally opaque
opaque to the local system. This MUST be initialized to zero. to the local system. This MUST be initialized to zero. If a
If a period of a Detection Time passes without the receipt of a period of a Detection Time passes without the receipt of a valid,
valid, authenticated BFD packet from the remote system, this authenticated BFD packet from the remote system, this variable
variable MUST be set to zero. MUST be set to zero.
bfd.LocalDiag bfd.LocalDiag
The diagnostic code specifying the reason for the most recent The diagnostic code specifying the reason for the most recent
change in the local session state. This MUST be initialized to change in the local session state. This MUST be initialized to
zero (No Diagnostic.) zero (No Diagnostic).
bfd.DesiredMinTxInterval bfd.DesiredMinTxInterval
The minimum interval, in microseconds, between transmitted BFD The minimum interval, in microseconds, between transmitted BFD
Control packets that this system would like to use at the Control packets that this system would like to use at the current
current time, less any jitter applied (see section 6.8.2). The time, less any jitter applied (see section 6.8.2). The actual
actual interval is negotiated between the two systems. This interval is negotiated between the two systems. This MUST be
MUST be initialized to a value of at least one second initialized to a value of at least one second (1,000,000
(1,000,000 microseconds) according to the rules described in microseconds) according to the rules described in section 6.8.3.
section 6.8.3. The setting of this variable is otherwise The setting of this variable is otherwise outside the scope of
outside the scope of this specification. this specification.
bfd.RequiredMinRxInterval bfd.RequiredMinRxInterval
The minimum interval, in microseconds, between received BFD The minimum interval, in microseconds, between received BFD
Control packets that this system requires, less any jitter Control packets that this system requires, less any jitter applied
applied by the sender (see section 6.8.2). The setting of this by the sender (see section 6.8.2). The setting of this variable
variable is outside the scope of this specification. A value is outside the scope of this specification. A value of zero means
of zero means that this system does not want to receive any that this system does not want to receive any periodic BFD Control
periodic BFD Control packets. See section 6.8.18 for details. packets. See section 6.8.18 for details.
bfd.RemoteMinRxInterval bfd.RemoteMinRxInterval
The last value of Required Min RX Interval received from the The last value of Required Min RX Interval received from the
remote system in a BFD Control packet. This variable MUST be remote system in a BFD Control packet. This variable MUST be
initialized to 1. initialized to 1.
bfd.DemandMode bfd.DemandMode
Set to 1 if the local system wishes to use Demand mode, or 0 if Set to 1 if the local system wishes to use Demand mode, or 0 if
not. not.
bfd.RemoteDemandMode bfd.RemoteDemandMode
Set to 1 if the remote system wishes to use Demand mode, or 0 Set to 1 if the remote system wishes to use Demand mode, or 0 if
if not. This is the value of the Demand (D) bit in the last not. This is the value of the Demand (D) bit in the last received
received BFD Control packet. This variable MUST be initialized BFD Control packet. This variable MUST be initialized to zero.
to zero.
bfd.DetectMult bfd.DetectMult
The desired Detection Time multiplier for BFD Control packets The desired Detection Time multiplier for BFD Control packets on
on the local system. The negotiated Control packet the local system. The negotiated Control packet transmission
transmission interval, multiplied by this variable, will be the interval, multiplied by this variable, will be the Detection Time
Detection Time for this session (as seen by the remote system.) for this session (as seen by the remote system). This variable
This variable MUST be a nonzero integer, and is otherwise MUST be a nonzero integer, and is otherwise outside the scope of
outside the scope of this specification. See section 6.8.4 for this specification. See section 6.8.4 for further information.
further information.
bfd.AuthType bfd.AuthType
The authentication type in use for this session, as defined in The authentication type in use for this session, as defined in
section 4.1, or zero if no authentication is in use. section 4.1, or zero if no authentication is in use.
bfd.RcvAuthSeq bfd.RcvAuthSeq
A 32 bit unsigned integer containing the last sequence number A 32-bit unsigned integer containing the last sequence number for
for keyed MD5 or SHA1 authentication that was received. The Keyed MD5 or SHA1 Authentication that was received. The initial
initial value is unimportant. value is unimportant.
bfd.XmitAuthSeq bfd.XmitAuthSeq
A 32 bit unsigned integer containing the next sequence number A 32-bit unsigned integer containing the next sequence number for
for keyed MD5 or SHA1 authentication to be transmitted. This Keyed MD5 or SHA1 Authentication to be transmitted. This variable
variable MUST be initialized to a random 32 bit value. MUST be initialized to a random 32-bit value.
bfd.AuthSeqKnown bfd.AuthSeqKnown
Set to 1 if the next sequence number for keyed MD5 or SHA1 Set to 1 if the next sequence number for Keyed MD5 or SHA1
authentication expected to be received is known, or 0 if it is authentication expected to be received is known, or 0 if it is not
not known. This variable MUST be initialized to zero. known. This variable MUST be initialized to zero.
This variable MUST be set to zero after no packets have been This variable MUST be set to zero after no packets have been
received on this session for at least twice the Detection Time. received on this session for at least twice the Detection Time.
This ensures that the sequence number can be resynchronized if This ensures that the sequence number can be resynchronized if the
the remote system restarts. remote system restarts.
6.8.2. Timer Negotiation 6.8.2. Timer Negotiation
The time values used to determine BFD packet transmission intervals The time values used to determine BFD packet transmission intervals
and the session Detection Time are continuously negotiated, and thus and the session Detection Time are continuously negotiated, and thus
may be changed at any time. The negotiation and time values are may be changed at any time. The negotiation and time values are
independent in each direction for each session. independent in each direction for each session.
Each system reports in the BFD Control packet how rapidly it would Each system reports in the BFD Control packet how rapidly it would
like to transmit BFD packets, as well as how rapidly it is prepared like to transmit BFD packets, as well as how rapidly it is prepared
to receive them. This allows either system to unilaterally determine to receive them. This allows either system to unilaterally determine
the maximum packet rate (minimum interval) in both directions. the maximum packet rate (minimum interval) in both directions.
See section 6.8.7 for the details of packet transmission timing and See section 6.8.7 for the details of packet transmission timing and
negotiation. negotiation.
6.8.3. Timer Manipulation 6.8.3. Timer Manipulation
The time values used to determine BFD packet transmission intervals The time values used to determine BFD packet transmission intervals
and the session Detection Time may be modified at any time without and the session Detection Time may be modified at any time without
affecting the state of the session. When the timer parameters are affecting the state of the session. When the timer parameters are
changed for any reason, the requirements of this section apply. changed for any reason, the requirements of this section apply.
If either bfd.DesiredMinTxInterval is changed or If either bfd.DesiredMinTxInterval is changed or
bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
initiated (see section 6.5). If the timing is such that a system initiated (see section 6.5). If the timing is such that a system
receiving a Poll Sequence wishes to change the parameters described receiving a Poll Sequence wishes to change the parameters described
skipping to change at page 33, line 29 skipping to change at page 31, line 36
If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,
the previous value of bfd.RequiredMinRxInterval MUST be used when the previous value of bfd.RequiredMinRxInterval MUST be used when
calculating the Detection Time for the remote system until the Poll calculating the Detection Time for the remote system until the Poll
Sequence described above has terminated. This is to ensure that the Sequence described above has terminated. This is to ensure that the
remote system is transmitting packets at the higher rate (and those remote system is transmitting packets at the higher rate (and those
packets are being received) prior to the Detection Time being packets are being received) prior to the Detection Time being
reduced. reduced.
When bfd.SessionState is not Up, the system MUST set When bfd.SessionState is not Up, the system MUST set
bfd.DesiredMinTxInterval to a value of not less than one second bfd.DesiredMinTxInterval to a value of not less than one second
(1,000,000 microseconds.) This is intended to ensure that the (1,000,000 microseconds). This is intended to ensure that the
bandwidth consumed by BFD sessions that are not Up is negligible, bandwidth consumed by BFD sessions that are not Up is negligible,
particularly in the case where a neighbor may not be running BFD. particularly in the case where a neighbor may not be running BFD.
If the local system reduces its transmit interval due to If the local system reduces its transmit interval due to
bfd.RemoteMinRxInterval being reduced (the remote system has bfd.RemoteMinRxInterval being reduced (the remote system has
advertised a reduced value in Required Min RX Interval), and the advertised a reduced value in Required Min RX Interval), and the
remote system is not in Demand mode, the local system MUST honor the remote system is not in Demand mode, the local system MUST honor the
new interval immediately. In other words, the local system cannot new interval immediately. In other words, the local system cannot
wait longer than the new interval between the previous packet wait longer than the new interval between the previous packet
transmission and the next one. If this interval has already passed transmission and the next one. If this interval has already passed
since the last transmission (because the new interval is since the last transmission (because the new interval is
significantly shorter), the local system MUST send the next periodic significantly shorter), the local system MUST send the next periodic
BFD Control packet as soon as practicable. BFD Control packet as soon as practicable.
When the Echo function is active, a system SHOULD set When the Echo function is active, a system SHOULD set
bfd.RequiredMinRxInterval to a value of not less than one second bfd.RequiredMinRxInterval to a value of not less than one second
(1,000,000 microseconds.) This is intended to keep received BFD (1,000,000 microseconds). This is intended to keep received BFD
Control traffic at a negligible level, since the actual detection Control traffic at a negligible level, since the actual detection
function is being performed using BFD Echo packets. function is being performed using BFD Echo packets.
In any case other than those explicitly called out above, timing In any case other than those explicitly called out above, timing
parameter changes MUST be effected immediately (changing the parameter changes MUST be effected immediately (changing the
transmission rate and/or the Detection Time). transmission rate and/or the Detection Time).
Note that the Poll Sequence mechanism is ambiguous if more than one Note that the Poll Sequence mechanism is ambiguous if more than one
parameter change is made that would require its use, and those parameter change is made that would require its use, and those
multiple changes are spread across multiple packets (since the multiple changes are spread across multiple packets (since the
semantics of the returning Final are unclear.) Therefore, if semantics of the returning Final are unclear). Therefore, if
multiple changes are made that require the use of a Poll Sequence, multiple changes are made that require the use of a Poll Sequence,
there are three choices: 1) they MUST be communicated in a single there are three choices: 1) they MUST be communicated in a single BFD
BFD Control packet (so the semantics of the Final reply are clear), Control packet (so the semantics of the Final reply are clear), or 2)
or 2) sufficient time must have transpired since the Poll Sequence sufficient time must have transpired since the Poll Sequence was
was completed to disambiguate the situation (at least a round trip completed to disambiguate the situation (at least a round trip time
time since the last Poll was transmitted) prior to the initiation of since the last Poll was transmitted) prior to the initiation of
another Poll Sequence, or 3) an additional BFD Control packet with another Poll Sequence, or 3) an additional BFD Control packet with
the Final (F) bit *clear* MUST be received after the Poll Sequence the Final (F) bit *clear* MUST be received after the Poll Sequence
has completed prior to the initiation of another Poll Sequence (this has completed prior to the initiation of another Poll Sequence (this
option is not available when Demand mode is active.) option is not available when Demand mode is active).
6.8.4. Calculating the Detection Time 6.8.4. Calculating the Detection Time
The Detection Time (the period of time without receiving BFD packets The Detection Time (the period of time without receiving BFD packets
after which the session is determined to have failed) is not carried after which the session is determined to have failed) is not carried
explicitly in the protocol. Rather, it is calculated independently explicitly in the protocol. Rather, it is calculated independently
in each direction by the receiving system based on the negotiated in each direction by the receiving system based on the negotiated
transmit interval and the detection multiplier. Note that there may transmit interval and the detection multiplier. Note that there may
be different Detection Times in each direction. be different Detection Times in each direction.
The calculation of the Detection Time is slightly different when in The calculation of the Detection Time is slightly different when in
Demand mode versus Asynchronous mode. Demand mode versus Asynchronous mode.
In Asynchronous mode, the Detection Time calculated in the local In Asynchronous mode, the Detection Time calculated in the local
system is equal to the value of Detect Mult received from the remote system is equal to the value of Detect Mult received from the remote
system, multiplied by the agreed transmit interval of the remote system, multiplied by the agreed transmit interval of the remote
system (the greater of bfd.RequiredMinRxInterval and the last system (the greater of bfd.RequiredMinRxInterval and the last
received Desired Min TX Interval.) The Detect Mult value is (roughly received Desired Min TX Interval). The Detect Mult value is (roughly
speaking, due to jitter) the number of packets that have to be missed speaking, due to jitter) the number of packets that have to be missed
in a row to declare the session to be down. in a row to declare the session to be down.
If Demand mode is not active, and a period of time equal to the If Demand mode is not active, and a period of time equal to the
Detection Time passes without receiving a BFD Control packet from the Detection Time passes without receiving a BFD Control packet from the
remote system, and bfd.SessionState is Init or Up, the session has remote system, and bfd.SessionState is Init or Up, the session has
gone down--the local system MUST set bfd.SessionState to Down and gone down -- the local system MUST set bfd.SessionState to Down and
bfd.LocalDiag to 1 (Control Detection Time Expired.) bfd.LocalDiag to 1 (Control Detection Time Expired).
In Demand mode, the Detection Time calculated in the local system is In Demand mode, the Detection Time calculated in the local system is
equal to bfd.DetectMult, multiplied by the agreed transmit interval equal to bfd.DetectMult, multiplied by the agreed transmit interval
of the local system (the greater of bfd.DesiredMinTxInterval and of the local system (the greater of bfd.DesiredMinTxInterval and
bfd.RemoteMinRxInterval.) bfd.DetectMult is (roughly speaking, due bfd.RemoteMinRxInterval). bfd.DetectMult is (roughly speaking, due
to jitter) the number of packets that have to be missed in a row to to jitter) the number of packets that have to be missed in a row to
declare the session to be down. declare the session to be down.
If Demand mode is active, and a period of time equal to the Detection If Demand mode is active, and a period of time equal to the Detection
Time passes after the initiation of a Poll Sequence (the transmission Time passes after the initiation of a Poll Sequence (the transmission
of the first BFD Control packet with the Poll bit set), the session of the first BFD Control packet with the Poll bit set), the session
has gone down--the local system MUST set bfd.SessionState to Down, has gone down -- the local system MUST set bfd.SessionState to Down,
and bfd.LocalDiag to 1 (Control Detection Time Expired.) and bfd.LocalDiag to 1 (Control Detection Time Expired).
(Note that a packet is considered to have been received, for the (Note that a packet is considered to have been received, for the
purposes of Detection Time expiration, only if it has not been purposes of Detection Time expiration, only if it has not been
"discarded" according to the rules of section 6.8.6.) "discarded" according to the rules of section 6.8.6).
6.8.5. Detecting Failures with the Echo Function 6.8.5. Detecting Failures with the Echo Function
When the Echo function is active and a sufficient number of Echo When the Echo function is active and a sufficient number of Echo
packets have not arrived as they should, the session has gone packets have not arrived as they should, the session has gone down --
down--the local system MUST set bfd.SessionState to Down, and the local system MUST set bfd.SessionState to Down and bfd.LocalDiag
bfd.LocalDiag to 2 (Echo Function Failed.) to 2 (Echo Function Failed).
The means by which the Echo function failures are detected is outside The means by which the Echo function failures are detected is outside
of the scope of this specification. Any means which will detect a of the scope of this specification. Any means that will detect a
communication failure is acceptable. communication failure are acceptable.
6.8.6. Reception of BFD Control Packets 6.8.6. Reception of BFD Control Packets
When a BFD Control packet is received, the following procedure MUST When a BFD Control packet is received, the following procedure MUST
be followed, in the order specified. If the packet is discarded be followed, in the order specified. If the packet is discarded
according to these rules, processing of the packet MUST cease at that according to these rules, processing of the packet MUST cease at that
point. point.
If the version number is not correct (1), the packet MUST be If the version number is not correct (1), the packet MUST be
discarded. discarded.
If the Length field is less than the minimum correct value (24 if If the Length field is less than the minimum correct value (24 if
skipping to change at page 36, line 16 skipping to change at page 34, line 27
select the session with which this BFD packet is associated. If select the session with which this BFD packet is associated. If
no session is found, the packet MUST be discarded. no session is found, the packet MUST be discarded.
If the Your Discriminator field is zero and the State field is not If the Your Discriminator field is zero and the State field is not
Down or AdminDown, the packet MUST be discarded. Down or AdminDown, the packet MUST be discarded.
If the Your Discriminator field is zero, the session MUST be If the Your Discriminator field is zero, the session MUST be
selected based on some combination of other fields, possibly selected based on some combination of other fields, possibly
including source addressing information, the My Discriminator including source addressing information, the My Discriminator
field, and the interface over which the packet was received. The field, and the interface over which the packet was received. The
exact method of selection is application-specific and is thus exact method of selection is application specific and is thus
outside the scope of this specification. If a matching session is outside the scope of this specification. If a matching session is
not found, a new session MAY be created, or the packet MAY be not found, a new session MAY be created, or the packet MAY be
discarded. This choice is outside the scope of this discarded. This choice is outside the scope of this
specification. specification.
If the A bit is set and no authentication is in use (bfd.AuthType If the A bit is set and no authentication is in use (bfd.AuthType
is zero), the packet MUST be discarded. is zero), the packet MUST be discarded.
If the A bit is clear and authentication is in use (bfd.AuthType If the A bit is clear and authentication is in use (bfd.AuthType
is nonzero), the packet MUST be discarded. is nonzero), the packet MUST be discarded.
If the A bit is set, the packet MUST be authenticated under the If the A bit is set, the packet MUST be authenticated under the
rules of section 6.7, based on the authentication type in use rules of section 6.7, based on the authentication type in use
(bfd.AuthType.) This may cause the packet to be discarded. (bfd.AuthType). This may cause the packet to be discarded.
Set bfd.RemoteDiscr to the value of My Discriminator. Set bfd.RemoteDiscr to the value of My Discriminator.
Set bfd.RemoteState to the value of the State (Sta) field. Set bfd.RemoteState to the value of the State (Sta) field.
Set bfd.RemoteDemandMode to the value of the Demand (D) bit. Set bfd.RemoteDemandMode to the value of the Demand (D) bit.
Set bfd.RemoteMinRxInterval to the value of Required Min RX Set bfd.RemoteMinRxInterval to the value of Required Min RX
Interval. Interval.
skipping to change at page 37, line 26 skipping to change at page 35, line 40
Set bfd.SessionState to Init Set bfd.SessionState to Init
Else if received State is Init Else if received State is Init
Set bfd.SessionState to Up Set bfd.SessionState to Up
Else if bfd.SessionState is Init Else if bfd.SessionState is Init
If received State is Init or Up If received State is Init or Up
Set bfd.SessionState to Up Set bfd.SessionState to Up
Else (bfd.SessionState is Up) Else (bfd.SessionState is Up)
If received State is Down If received State is Down
Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.LocalDiag to 3 (Neighbor signaled
session down)
Set bfd.SessionState to Down Set bfd.SessionState to Down
Check to see if Demand mode should become active or not (see Check to see if Demand mode should become active or not (see
section 6.6). section 6.6).
If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and
bfd.RemoteSessionState is Up, Demand mode is active on the remote bfd.RemoteSessionState is Up, Demand mode is active on the remote
system and the local system MUST cease the periodic transmission system and the local system MUST cease the periodic transmission
of BFD Control packets (see section 6.8.7.) of BFD Control packets (see section 6.8.7).
If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or
bfd.RemoteSessionState is not Up, Demand mode is not active on the bfd.RemoteSessionState is not Up, Demand mode is not active on the
remote system and the local system MUST send periodic BFD Control remote system and the local system MUST send periodic BFD Control
packets (see section 6.8.7.) packets (see section 6.8.7).
If the Poll (P) bit is set, send a BFD Control packet to the If the Poll (P) bit is set, send a BFD Control packet to the
remote system with the Poll (P) bit clear, and the Final (F) bit remote system with the Poll (P) bit clear, and the Final (F) bit
set (see section 6.8.7.) set (see section 6.8.7).
If the packet was not discarded, it has been received for purposes If the packet was not discarded, it has been received for purposes
of the Detection Time expiration rules in section 6.8.4. of the Detection Time expiration rules in section 6.8.4.
6.8.7. Transmitting BFD Control Packets 6.8.7. Transmitting BFD Control Packets
With the exceptions listed in the remainder of this section, a system With the exceptions listed in the remainder of this section, a system
MUST NOT transmit BFD Control packets at an interval less than the MUST NOT transmit BFD Control packets at an interval less than the
larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less
applied jitter (see below). In other words, the system reporting the applied jitter (see below). In other words, the system reporting the
slower rate determines the transmission rate. slower rate determines the transmission rate.
The periodic transmission of BFD Control packets MUST be jittered on The periodic transmission of BFD Control packets MUST be jittered on
a per-packet basis by up to 25%, that is, the interval MUST be a per-packet basis by up to 25%, that is, the interval MUST be
reduced by a random value of 0 to 25%, in order to avoid self- reduced by a random value of 0 to 25%, in order to avoid self-
skipping to change at page 39, line 43 skipping to change at page 38, line 14
Final (F) Final (F)
Set to 1 if the local system is responding to a Control packet Set to 1 if the local system is responding to a Control packet
received with the Poll (P) bit set, or 0 if not. received with the Poll (P) bit set, or 0 if not.
Control Plane Independent (C) Control Plane Independent (C)
Set to 1 if the local system's BFD implementation is independent Set to 1 if the local system's BFD implementation is independent
of the control plane (it can continue to function through a of the control plane (it can continue to function through a
disruption of the control plane.) disruption of the control plane).
Authentication Present (A) Authentication Present (A)
Set to 1 if authentication is in use on this session (bfd.AuthType Set to 1 if authentication is in use on this session (bfd.AuthType
is nonzero), or 0 if not. is nonzero), or 0 if not.
Demand (D) Demand (D)
Set to bfd.DemandMode if bfd.SessionState is Up and Set to bfd.DemandMode if bfd.SessionState is Up and
bfd.RemoteSessionState is Up. Otherwise it is set to 0. bfd.RemoteSessionState is Up. Otherwise, it is set to 0.
Multipoint (M) Multipoint (M)
Set to 0. Set to 0.
Detect Mult Detect Mult
Set to bfd.DetectMult. Set to bfd.DetectMult.
Length Length
skipping to change at page 41, line 15 skipping to change at page 39, line 19
Required Min Echo RX Interval Required Min Echo RX Interval
Set to the minimum required Echo packet receive interval for this Set to the minimum required Echo packet receive interval for this
session. If this field is set to zero, the local system is session. If this field is set to zero, the local system is
unwilling or unable to loop back BFD Echo packets to the remote unwilling or unable to loop back BFD Echo packets to the remote
system, and the remote system will not send Echo packets. system, and the remote system will not send Echo packets.
Authentication Section Authentication Section
Included and set according to the rules in section 6.7 if Included and set according to the rules in section 6.7 if
authentication is in use (bfd.AuthType is nonzero.) Otherwise authentication is in use (bfd.AuthType is nonzero). Otherwise,
this section is not present. this section is not present.
6.8.8. Reception of BFD Echo Packets 6.8.8. Reception of BFD Echo Packets
A received BFD Echo packet MUST be demultiplexed to the appropriate A received BFD Echo packet MUST be demultiplexed to the appropriate
session for processing. A means of detecting missing Echo packets session for processing. A means of detecting missing Echo packets
MUST be implemented, which most likely involves processing of the MUST be implemented, which most likely involves processing of the
Echo packets that are received. The processing of received Echo Echo packets that are received. The processing of received Echo
packets is otherwise outside the scope of this specification. packets is otherwise outside the scope of this specification.
6.8.9. Transmission of BFD Echo Packets 6.8.9. Transmission of BFD Echo Packets
BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
Up. BFD Echo packets MUST NOT be transmitted unless the last BFD Up. BFD Echo packets MUST NOT be transmitted unless the last BFD
Control packet received from the remote system contains a nonzero Control packet received from the remote system contains a nonzero
value in Required Min Echo RX Interval. value in Required Min Echo RX Interval.
BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The
interval between transmitted BFD Echo packets MUST NOT be less than interval between transmitted BFD Echo packets MUST NOT be less than
the value advertised by the remote system in Required Min Echo RX the value advertised by the remote system in Required Min Echo RX
Interval, except as follows: Interval, except as follows:
A 25% jitter MAY be applied to the rate of transmission, such that A 25% jitter MAY be applied to the rate of transmission, such that
the actual interval MAY be between 75% and 100% of the advertised the actual interval MAY be between 75% and 100% of the advertised
value. A single BFD Echo packet MAY be transmitted between value. A single BFD Echo packet MAY be transmitted between
normally scheduled Echo transmission intervals. normally scheduled Echo transmission intervals.
The transmission of BFD Echo packets is otherwise outside the scope The transmission of BFD Echo packets is otherwise outside the scope
of this specification. of this specification.
6.8.10. Min Rx Interval Change 6.8.10. Min Rx Interval Change
When it is desired to change the rate at which BFD Control packets When it is desired to change the rate at which BFD Control packets
arrive from the remote system, bfd.RequiredMinRxInterval can be arrive from the remote system, bfd.RequiredMinRxInterval can be
changed at any time to any value. The new value will be transmitted changed at any time to any value. The new value will be transmitted
in the next outgoing Control packet, and the remote system will in the next outgoing Control packet, and the remote system will
adjust accordingly. See section 6.8.3 for further requirements. adjust accordingly. See section 6.8.3 for further requirements.
6.8.11. Min Tx Interval Change 6.8.11. Min Tx Interval Change
When it is desired to change the rate at which BFD Control packets When it is desired to change the rate at which BFD Control packets
are transmitted to the remote system (subject to the requirements of are transmitted to the remote system (subject to the requirements of
the neighboring system), bfd.DesiredMinTxInterval can be changed at the neighboring system), bfd.DesiredMinTxInterval can be changed at
any time to any value. The rules in section 6.8.3 apply. any time to any value. The rules in section 6.8.3 apply.
6.8.12. Detect Multiplier Change 6.8.12. Detect Multiplier Change
When it is desired to change the detect multiplier, the value of When it is desired to change the detect multiplier, the value of
bfd.DetectMult can be changed to any nonzero value. The new value bfd.DetectMult can be changed to any nonzero value. The new value
will be transmitted with the next BFD Control packet, and the use of will be transmitted with the next BFD Control packet, and the use of
a Poll Sequence is not necessary. See section 6.6 for additional a Poll Sequence is not necessary. See section 6.6 for additional
requirements. requirements.
6.8.13. Enabling or Disabling The Echo Function 6.8.13. Enabling or Disabling The Echo Function
If it is desired to start or stop the transmission of BFD Echo If it is desired to start or stop the transmission of BFD Echo
packets, this MAY be done at any time (subject to the transmission packets, this MAY be done at any time (subject to the transmission
requirements detailed in section 6.8.9.) requirements detailed in section 6.8.9).
If it is desired to enable or disable the looping back of received If it is desired to enable or disable the looping back of received
BFD Echo packets, this MAY be done at any time by changing the value BFD Echo packets, this MAY be done at any time by changing the value
of Required Min Echo RX Interval to zero or nonzero in outgoing BFD of Required Min Echo RX Interval to zero or nonzero in outgoing BFD
Control packets. Control packets.
6.8.14. Enabling or Disabling Demand Mode 6.8.14. Enabling or Disabling Demand Mode
If it is desired to start or stop Demand mode, this MAY be done at If it is desired to start or stop Demand mode, this MAY be done at
any time by setting bfd.DemandMode to the proper value. Demand mode any time by setting bfd.DemandMode to the proper value. Demand mode
will subsequently become active under the rules described in section will subsequently become active under the rules described in section
6.6. 6.6.
If Demand mode is no longer active on the remote system, the local If Demand mode is no longer active on the remote system, the local
system MUST begin transmitting periodic BFD Control packets as system MUST begin transmitting periodic BFD Control packets as
described in section 6.8.7. described in section 6.8.7.
6.8.15. Forwarding Plane Reset 6.8.15. Forwarding Plane Reset
When the forwarding plane in the local system is reset for some When the forwarding plane in the local system is reset for some
reason, such that the remote system can no longer rely on the local reason, such that the remote system can no longer rely on the local
forwarding state, the local system MUST set bfd.LocalDiag to 4 forwarding state, the local system MUST set bfd.LocalDiag to 4
(Forwarding Plane Reset), and set bfd.SessionState to Down. (Forwarding Plane Reset), and set bfd.SessionState to Down.
6.8.16. Administrative Control 6.8.16. Administrative Control
There may be circumstances where it is desirable to administratively There may be circumstances where it is desirable to administratively
enable or disable a BFD session. When this is desired, the following enable or disable a BFD session. When this is desired, the following
procedure MUST be followed: procedure MUST be followed:
If enabling session If enabling session
Set bfd.SessionState to Down Set bfd.SessionState to Down
Else Else
Set bfd.SessionState to AdminDown Set bfd.SessionState to AdminDown
skipping to change at page 43, line 37 skipping to change at page 41, line 37
has failed, an implementation MAY administratively disable the has failed, an implementation MAY administratively disable the
session with the diagnostic Path Down. session with the diagnostic Path Down.
Other scenarios MAY use the diagnostic Administratively Down. Other scenarios MAY use the diagnostic Administratively Down.
BFD Control packets SHOULD be transmitted for at least a Detection BFD Control packets SHOULD be transmitted for at least a Detection
Time after transitioning to AdminDown state in order to ensure that Time after transitioning to AdminDown state in order to ensure that
the remote system is aware of the state change. BFD Control packets the remote system is aware of the state change. BFD Control packets
MAY be transmitted indefinitely after transitioning to AdminDown MAY be transmitted indefinitely after transitioning to AdminDown
state in order to maintain session state in each system (see section state in order to maintain session state in each system (see section
6.8.18 below.) 6.8.18 below).
6.8.17. Concatenated Paths 6.8.17. Concatenated Paths
If the path being monitored by BFD is concatenated with other paths If the path being monitored by BFD is concatenated with other paths
(connected end-to-end in series), it may be desirable to propagate (connected end-to-end in series), it may be desirable to propagate
the indication of a failure of one of those paths across the BFD the indication of a failure of one of those paths across the BFD
session (providing an interworking function for liveness monitoring session (providing an interworking function for liveness monitoring
between BFD and other technologies.) between BFD and other technologies).
Two diagnostic codes are defined for this purpose: Concatenated Path Two diagnostic codes are defined for this purpose: Concatenated Path
Down and Reverse Concatenated Path Down. The first propagates Down and Reverse Concatenated Path Down. The first propagates
forward path failures (in which the concatenated path fails in the forward path failures (in which the concatenated path fails in the
direction toward the interworking system), and the second propagates direction toward the interworking system), and the second propagates
reverse path failures (in which the concatenated path fails in the reverse path failures (in which the concatenated path fails in the
direction away from the interworking system, assuming a bidirectional direction away from the interworking system, assuming a bidirectional
link.) link).
A system MAY signal one of these failure states by simply setting A system MAY signal one of these failure states by simply setting
bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD
session is not taken down. If Demand mode is not active on the session is not taken down. If Demand mode is not active on the
remote system, no other action is necessary, as the diagnostic code remote system, no other action is necessary, as the diagnostic code
will be carried via the periodic transmission of BFD Control packets. will be carried via the periodic transmission of BFD Control packets.
If Demand mode is active on the remote system (the local system is If Demand mode is active on the remote system (the local system is
not transmitting periodic BFD Control packets), a Poll Sequence MUST not transmitting periodic BFD Control packets), a Poll Sequence MUST
be initiated to ensure that the diagnostic code is transmitted. Note be initiated to ensure that the diagnostic code is transmitted. Note
that if the BFD session subsequently fails, the diagnostic code will that if the BFD session subsequently fails, the diagnostic code will
be overwritten with a code detailing the cause of the failure. It is be overwritten with a code detailing the cause of the failure. It is
up to the interworking agent to perform the above procedure again, up to the interworking agent to perform the above procedure again,
once the BFD session reaches Up state, if the propagation of the once the BFD session reaches Up state, if the propagation of the
concatenated path failure is to resume. concatenated path failure is to resume.
6.8.18. Holding Down Sessions 6.8.18. Holding Down Sessions
A system MAY choose to prevent a BFD session from being established. A system MAY choose to prevent a BFD session from being established.
One possible reason might be to manage the rate at which sessions are One possible reason might be to manage the rate at which sessions are
established. This can be done by holding the session in Down or established. This can be done by holding the session in Down or
AdminDown state, as appropriate. AdminDown state, as appropriate.
There are two related mechanisms that are available to help with this There are two related mechanisms that are available to help with this
task. First, a system is REQUIRED to maintain session state task. First, a system is REQUIRED to maintain session state
(including timing parameters), even when a session is down, until a (including timing parameters), even when a session is down, until a
Detection Time has passed without the receipt of any BFD Control Detection Time has passed without the receipt of any BFD Control
skipping to change at page 45, line 5 skipping to change at page 43, line 5
whatsoever. whatsoever.
So long as the local system continues to transmit BFD Control So long as the local system continues to transmit BFD Control
packets, the remote system is obligated to obey the value carried in packets, the remote system is obligated to obey the value carried in
Required Min RX Interval. If the remote system does not receive any Required Min RX Interval. If the remote system does not receive any
BFD Control packets for a Detection Time, it SHOULD reset BFD Control packets for a Detection Time, it SHOULD reset
bfd.RemoteMinRxInterval to its initial value of 1 (per section 6.8.1, bfd.RemoteMinRxInterval to its initial value of 1 (per section 6.8.1,
since it is no longer required to maintain previous session state) since it is no longer required to maintain previous session state)
and then can transmit at its own rate. and then can transmit at its own rate.
7. Operational Considerations 7. Operational Considerations
BFD is likely to be deployed as a critical part of network BFD is likely to be deployed as a critical part of network
infrastructure. As such, care should be taken to avoid disruption. infrastructure. As such, care should be taken to avoid disruption.
Obviously, any mechanism that blocks BFD packets, such as firewalls Obviously, any mechanism that blocks BFD packets, such as firewalls
or other policy processes, will cause BFD to fail. or other policy processes, will cause BFD to fail.
Mechanisms that control packet scheduling, such as policers, traffic Mechanisms that control packet scheduling, such as policers, traffic
shapers, priority queueing, etc., have the potential of impacting BFD shapers, priority queueing, etc., have the potential of impacting BFD
operations if the Detection Time is similar in scale to the scheduled operations if the Detection Time is similar in scale to the scheduled
skipping to change at page 45, line 29 skipping to change at page 43, line 29
deployment, particularly when very short Detection Times are to be deployment, particularly when very short Detection Times are to be
used. used.
When BFD is used across multiple hops, a congestion control mechanism When BFD is used across multiple hops, a congestion control mechanism
MUST be implemented, and when congestion is detected, the BFD MUST be implemented, and when congestion is detected, the BFD
implementation MUST reduce the amount of traffic it generates. The implementation MUST reduce the amount of traffic it generates. The
exact mechanism used is outside the scope of this specification, and exact mechanism used is outside the scope of this specification, and
the requirements of this mechanism may differ depending on how BFD is the requirements of this mechanism may differ depending on how BFD is
deployed, and how it interacts with other parts of the system (for deployed, and how it interacts with other parts of the system (for
example, exponential backoff may not be appropriate in cases where example, exponential backoff may not be appropriate in cases where
routing protocols are interacting closely with BFD.) routing protocols are interacting closely with BFD).
Note that "congestion" is not only a traffic phenomenon, but also a Note that "congestion" is not only a traffic phenomenon, but also a
computational one. It is possible for systems with a large number of computational one. It is possible for systems with a large number of
BFD sessions and/or very short packet intervals to become CPU-bound. BFD sessions and/or very short packet intervals to become CPU-bound.
As such, a congestion control algorithm SHOULD be used even across As such, a congestion control algorithm SHOULD be used even across
single hops in order to avoid the possibility of catastrophic system single hops in order to avoid the possibility of catastrophic system
collapse, as such failures have been seen repeatedly in other collapse, as such failures have been seen repeatedly in other
periodic hello-based protocols. periodic Hello-based protocols.
The mechanisms for detecting congestion are outside the scope of this The mechanisms for detecting congestion are outside the scope of this
specification, but may include the detection of lost BFD Control specification, but may include the detection of lost BFD Control
packets (by virtue of holes in the authentication sequence number packets (by virtue of holes in the authentication sequence number
space, or by BFD session failure) or other means. space, or by BFD session failure) or other means.
The mechanisms for reducing BFD's traffic load are the control of the The mechanisms for reducing BFD's traffic load are the control of the
local and remote packet transmission rate via the Min RX Interval and local and remote packet transmission rate via the Min RX Interval and
Min TX Interval fields. Min TX Interval fields.
skipping to change at page 46, line 10 skipping to change at page 44, line 13
intervals will increase the Detection Time for the session. intervals will increase the Detection Time for the session.
It is worth noting that a single BFD session does not consume a large It is worth noting that a single BFD session does not consume a large
amount of bandwidth. An aggressive session that achieves a detection amount of bandwidth. An aggressive session that achieves a detection
time of 50 milliseconds, by using a transmit interval of 16.7 time of 50 milliseconds, by using a transmit interval of 16.7
milliseconds and a detect multiplier of 3, will generate 60 packets milliseconds and a detect multiplier of 3, will generate 60 packets
per second. The maximum length of each packet on the wire is on the per second. The maximum length of each packet on the wire is on the
order of 100 bytes, for a total of around 48 kilobits per second of order of 100 bytes, for a total of around 48 kilobits per second of
bandwidth consumption in each direction. bandwidth consumption in each direction.
8. IANA Considerations 8. IANA Considerations
This document defines two registries to be administered by IANA. The This document defines two registries administered by IANA. The first
first is entitled "BFD Diagnostic Codes" (see section 4.1). Initial is titled "BFD Diagnostic Codes" (see section 4.1). Initial values
values for the BFD Diagnostic Code registry are given below. Further for the BFD Diagnostic Code registry are given below. Further
assignments are to be made through Expert Review [IANA- assignments are to be made through Expert Review
CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name [IANA-CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code
and its associated value. name and its associated value.
Value BFD Diagnostic Code Name Value BFD Diagnostic Code Name
----- ------------------------ ----- ------------------------
0 No Diagnostic 0 No Diagnostic
1 Control Detection Time Expired 1 Control Detection Time Expired
2 Echo Function Failed 2 Echo Function Failed
3 Neighbor Signaled Session Down 3 Neighbor Signaled Session Down
4 Forwarding Plane Reset 4 Forwarding Plane Reset
5 Path Down 5 Path Down
6 Concatenated Path Down 6 Concatenated Path Down
7 Administratively Down 7 Administratively Down
8 Reverse Concatenated Path Down 8 Reverse Concatenated Path Down
9-31 Unassigned 9-31 Unassigned
The second registry is entitled "BFD Authentication Types" (see section The second registry is titled "BFD Authentication Types" (see section
4.1). Initial values for the BFD Authentication Type registry are given 4.1). Initial values for the BFD Authentication Type registry are
below. Further assignments are to be made through Expert Review given below. Further assignments are to be made through Expert
[IANA-CONSIDERATIONS]. Assignments consist of a BFD Authentication Type Review [IANA-CONSIDERATIONS]. Assignments consist of a BFD
Code name and its associated value. Authentication Type Code name and its associated value.
Value BFD Authentication Type Name Value BFD Authentication Type Name
----- ---------------------------- ----- ----------------------------
0 Reserved 0 Reserved
1 Simple Password 1 Simple Password
2 Keyed MD5 2 Keyed MD5
3 Meticulous Keyed MD5 3 Meticulous Keyed MD5
4 Keyed SHA1 4 Keyed SHA1
5 Meticulous Keyed SHA1 5 Meticulous Keyed SHA1
6-255 Unassigned 6-255 Unassigned
9. Security Considerations 9. Security Considerations
As BFD may be tied into the stability of the network infrastructure As BFD may be tied into the stability of the network infrastructure
(such as routing protocols), the effects of an attack on a BFD (such as routing protocols), the effects of an attack on a BFD
session may be very serious: a link may be falsely declared to be session may be very serious: a link may be falsely declared to be
down, or falsely declared to be up; in either case, the effect is down, or falsely declared to be up; in either case, the effect is
denial-of-service. denial of service.
An attacker who is in complete control of the link between the An attacker who is in complete control of the link between the
systems can easily drop all BFD packets but forward everything else systems can easily drop all BFD packets but forward everything else
(causing the link to be falsely declared down), or forward only the (causing the link to be falsely declared down), or forward only the
BFD packets but nothing else (causing the link to be falsely declared BFD packets but nothing else (causing the link to be falsely declared
up). This attack cannot be prevented by BFD. up). This attack cannot be prevented by BFD.
To mitigate threats from less capable attackers, BFD specifies two To mitigate threats from less capable attackers, BFD specifies two
mechanisms to prevent spoofing of BFD Control packets. The mechanisms to prevent spoofing of BFD Control packets. The
Generalized TTL Security Mechanism [GTSM] uses the TTL or Hop Count Generalized TTL Security Mechanism [GTSM] uses the time to live (TTL)
to prevent off-link attackers from spoofing packets. The or Hop Count to prevent off-link attackers from spoofing packets.
Authentication Section authenticates the BFD Control packets. These The Authentication Section authenticates the BFD Control packets.
mechanisms are described in more detail below. These mechanisms are described in more detail below.
When a BFD session is directly connected across a single link When a BFD session is directly connected across a single link
(physical, or a secure tunnel such as IPsec), the TTL or Hop Count (physical, or a secure tunnel such as IPsec), the TTL or Hop Count
MUST be set to the maximum on transmit, and checked to be equal to MUST be set to the maximum on transmit, and checked to be equal to
the maximum value on reception (and the packet dropped if this is not the maximum value on reception (and the packet dropped if this is not
the case.) See [GTSM] for more information on this technique. If the case). See [GTSM] for more information on this technique. If
BFD is run across multiple hops or an insecure tunnel (such as GRE), BFD is run across multiple hops or an insecure tunnel (such as
the Authentication Section SHOULD be utilized. Generic Routing Encapsulation (GRE)), the Authentication Section
SHOULD be utilized.
The level of security provided by the Authentication Section varies The level of security provided by the Authentication Section varies
based on the authentication type used. Simple Password based on the authentication type used. Simple Password
authentication is obviously only as secure as the secrecy of the authentication is obviously only as secure as the secrecy of the
passwords used, and should be considered only if the BFD session is passwords used, and should be considered only if the BFD session is
guaranteed to be run over an infrastructure not subject to packet guaranteed to be run over an infrastructure not subject to packet
interception. Its chief advantage is that it minimizes the interception. Its chief advantage is that it minimizes the
computational effort required for authentication. computational effort required for authentication.
Keyed MD5 authentication is much stronger than Simple Password Keyed MD5 Authentication is much stronger than Simple Password
authentication since the keys cannot be discerned by intercepting Authentication since the keys cannot be discerned by intercepting
packets. It is vulnerable to replay attacks in between increments of packets. It is vulnerable to replay attacks in between increments of
the sequence number. The sequence number can be incremented as the sequence number. The sequence number can be incremented as
seldom (or as often) as desired, trading off resistance to replay seldom (or as often) as desired, trading off resistance to replay
attacks with the computational effort required for authentication. attacks with the computational effort required for authentication.
Meticulous Keyed MD5 authentication is stronger yet, as it requires Meticulous Keyed MD5 authentication is stronger yet, as it requires
the sequence number to be incremented for every packet. Replay the sequence number to be incremented for every packet. Replay
attack vulnerability is reduced due to the requirement that the attack vulnerability is reduced due to the requirement that the
sequence number must be incremented on every packet, the window size sequence number must be incremented on every packet, the window size
of acceptable packets is small, and the initial sequence number is of acceptable packets is small, and the initial sequence number is
skipping to change at page 48, line 16 skipping to change at page 46, line 17
the session while the sequence number is being determined. This the session while the sequence number is being determined. This
authentication scheme requires an MD5 calculation on every packet authentication scheme requires an MD5 calculation on every packet
transmitted and received. transmitted and received.
Using SHA1 is believed to have stronger security properties than MD5. Using SHA1 is believed to have stronger security properties than MD5.
All comments about MD5 in this section also apply to SHA1. All comments about MD5 in this section also apply to SHA1.
Both Keyed MD5/SHA1 and Meticulous Keyed MD5/SHA1 use the "secret Both Keyed MD5/SHA1 and Meticulous Keyed MD5/SHA1 use the "secret
suffix" construction (also called "append only") in which the shared suffix" construction (also called "append only") in which the shared
secret key is appended to the data before calculating the hash, secret key is appended to the data before calculating the hash,
instead of the more common HMAC construction [HMAC]. This instead of the more common Hashed Message Authentication Code (HMAC)
construction is believed to be appropriate for BFD, but designers of construction [HMAC]. This construction is believed to be appropriate
any additional authentication mechanisms for BFD are encouraged to for BFD, but designers of any additional authentication mechanisms
read [HMAC] and its references. for BFD are encouraged to read [HMAC] and its references.
If both systems randomize their Local Discriminator values at the If both systems randomize their Local Discriminator values at the
beginning of a session, replay attacks may be further mitigated, beginning of a session, replay attacks may be further mitigated,
regardless of the authentication type in use. Since the Local regardless of the authentication type in use. Since the Local
Discriminator may be changed at any time during a session, this Discriminator may be changed at any time during a session, this
mechanism may also help mitigate attacks. mechanism may also help mitigate attacks.
The security implications of the use of BFD Echo packets are The security implications of the use of BFD Echo packets are
dependent on how those packets are defined, since their structure is dependent on how those packets are defined, since their structure is
local to the transmitting system and outside the scope of this local to the transmitting system and outside the scope of this
specification. However, since Echo packets are defined and processed specification. However, since Echo packets are defined and processed
only by the transmitting system, the use of cryptographic only by the transmitting system, the use of cryptographic
authentication does not guarantee that the other system is actually authentication does not guarantee that the other system is actually
alive; an attacker could loop the Echo packets back (without knowing alive; an attacker could loop the Echo packets back (without knowing
any secret keys) and cause the link to be falsely declared to be up. any secret keys) and cause the link to be falsely declared to be up.
This can be mitigated by using a suitable interval for BFD Control This can be mitigated by using a suitable interval for BFD Control
packets. [GTSM] could be applied to BFD Echo packets, though the packets. [GTSM] could be applied to BFD Echo packets, though the
TTL/Hop Count will be decremented by 1 in the course of echoing the TTL/Hop Count will be decremented by 1 in the course of echoing the
packet, so spoofing is possible from one hop away. packet, so spoofing is possible from one hop away.
10. References 10. References
10.1. Normative References 10.1. Normative References
[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism [GTSM] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
(GTSM)", RFC 5082, October 2007. Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1992. April 1992.
[SHA1] Eastlake, D., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, [SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
September 2001. (SHA1)", RFC 3174, September 2001.
10.2. Informative References 10.2. Informative References
[HMAC] Krawczyk, H., et al, "HMAC: Keyed-Hashing for Message [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Authentication", RFC 2104, February, 1997. Hashing for Message Authentication", RFC 2104, February
1997.
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for [IANA-CONSIDERATIONS]
Writing an IANA Considerations Section in RFCs", BCP 26, RFC Narten, T. and H. Alvestrand, "Guidelines for Writing an
5226, May 2008. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
Backward Compatibility (Non-Normative) Appendix A. Backward Compatibility (Non-Normative)
Although Version 0 of this document is unlikely to have been deployed Although version 0 of this protocol (as defined in early versions of
widely, some implementors may wish to have a backward compatibility the Internet-Draft that became this RFC) is unlikely to have been
mechanism. Note that any mechanism may be potentially used that does deployed widely, some implementors may wish to have a backward
not alter the protocol definition, so interoperability should not be compatibility mechanism. Note that any mechanism may be potentially
an issue. used that does not alter the protocol definition, so interoperability
should not be an issue.
The suggested mechanism described here has the property that it will The suggested mechanism described here has the property that it will
converge on version 1 if both systems implement it, even if one converge on version 1 if both systems implement it, even if one
system is upgraded from version 0 within a Detection Time. It will system is upgraded from version 0 within a Detection Time. It will
interoperate with a system that implements only one version (or is interoperate with a system that implements only one version (or is
configured to support only one version.) A system should obviously configured to support only one version). A system should obviously
not perform this function if it is configured to or is only capable not perform this function if it is configured to or is only capable
of using a single version. of using a single version.
A BFD session will enter a "negotiation holddown" if it is configured A BFD session will enter a "negotiation holddown" if it is configured
for automatic versioning and either has just started up, or the for automatic versioning and either has just started up, or the
session has been manually cleared. The session is set to AdminDown session has been manually cleared. The session is set to AdminDown
state and Version 1. During the holddown period, which lasts for one state and version 1. During the holddown period, which lasts for one
Detection Time, the system sends BFD Control packets as usual, but Detection Time, the system sends BFD Control packets as usual, but
ignores received packets. After the holddown time is complete, the ignores received packets. After the holddown time is complete, the
state transitions to Down and normal operation resumes. state transitions to Down and normal operation resumes.
When a system is not in holddown, if it doing automatic versioning When a system is not in holddown, if it doing automatic versioning
and is currently using Version 1, if any Version 0 packet is received and is currently using version 1, if any version 0 packet is received
for the session, it switches immediately to Version 0. If it is for the session, it switches immediately to version 0. If it is
currently using Version 0 and a Version 1 packet is received that currently using version 0 and a version 1 packet is received that
indicates that the neighbor is in state AdminDown, it switches to indicates that the neighbor is in state AdminDown, it switches to
Version 1. If using Version 0 and a Version 1 packet is received version 1. If using version 0 and a version 1 packet is received
indicating a state other than AdminDown, the packet is ignored (per indicating a state other than AdminDown, the packet is ignored (per
spec.) spec).
If the version being used is changed, the session goes down as If the version being used is changed, the session goes down as
appropriate for the new version (Down state for Version 1 or Failing appropriate for the new version (Down state for version 1 or Failing
state for Version 0.) state for version 0).
Contributors Appendix B. Contributors
Kireeti Kompella and Yakov Rekhter of Juniper Networks were also Kireeti Kompella and Yakov Rekhter of Juniper Networks were also
significant contributors to this document. significant contributors to this document.
Acknowledgments Appendix C. Acknowledgments
This document was inspired by (and is intended to replace) the This document was inspired by (and is intended to replace) the
Protocol Liveness Protocol draft, written by Kireeti Kompella. Protocol Liveness Protocol document, written by Kireeti Kompella.
Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang Demand mode was inspired by "A Traffic-Based Method of Detecting Dead
et al. Internet Key Exchange (IKE) Peers", by G. Huang, et al.
The authors would also like to thank Mike Shand, John Scudder, The authors would also like to thank Mike Shand, John Scudder,
Stewart Bryant, Pekka Savola, Richard Spencer, and Pasi Eronen for Stewart Bryant, Pekka Savola, Richard Spencer, and Pasi Eronen for
their substantive input. their substantive input.
The authors would also like to thank Owen Wheeler for hosting The authors would also like to thank Owen Wheeler for hosting
teleconferences between the authors of this specification and teleconferences between the authors of this specification and
multiple vendors in order address implementation and clarity issues. multiple vendors in order address implementation and clarity issues.
Authors' Addresses Authors' Addresses
Dave Katz Dave Katz
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 USA Sunnyvale, CA 94089-1206
Phone: +1-408-745-2000 USA
Email: dkatz@juniper.net
Dave Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 USA
Phone: +1-408-745-2000
Email: dward@juniper.net
Changes from the Previous Draft
The definition and configuration of passwords and authentication keys Phone: +1-408-745-2000
was changed slightly to improve interoperability with deployed code. EMail: dkatz@juniper.net
The security considerations for the Echo protocol was changed
slightly.
All other changes are purely editorial in nature. Dave Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089-1206
USA
This document expires in July, 2010. Phone: +1-408-745-2000
EMail: dward@juniper.net
 End of changes. 253 change blocks. 
545 lines changed or deleted 537 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/