Network Working Group                                           D. Katz
Internet Draft                                         Juniper Networks
                                                                D. Ward
                                                          Cisco Systems
Expires: April, 2006                                      October, 2005

                       Generic Application of BFD

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   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
   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

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Katz, Ward                                                      [Page 1]

Internet Draft         Generic Application of BFD          October, 2005


   This document describes the generic application of the Bidirectional
   Forwarding Detection (BFD) protocol in environments not specifically
   documented in other specifications.  Comments on this draft should be
   directed to

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [KEYWORDS].

1. Introduction

   BFD [BFD] provides a liveness detection mechanism that can be
   utilized by other network components for which their integral
   liveness mechanisms are either too slow, inappropriate, or
   nonexistent.  Other drafts have detailed the use of BFD in specific
   situations ([BFD-1HOP], [BFD-MULTI], [BFD-MPLS]).  As the utility of
   BFD has become understood, there have been calls to specify BFD
   interactions with a growing list of network functions.  Rather than
   producing a long series of short documents on the application of BFD,
   it seemed worthwhile to describe the interactions between BFD and
   other network functions in a broad way.

   This document describes the generic application of BFD.  Applications
   with specific requirements should be spelled out in specific

2. Overview

   The Bidirectional Forwarding Detection (BFD) specification defines a
   protocol with simple and specific semantics.  Its sole purpose is to
   verify connectivity between a pair of systems, for a particular data
   protocol across a path (which may be of any technology, length, or
   OSI layer).  The promptness of the detection of a path failure can be
   controlled by trading off protocol overhead and system load with
   detection times.

   BFD is *not* intended to directly provide control protocol liveness
   information; those protocols have their own means and vagaries.

Katz, Ward                                                      [Page 2]

Internet Draft         Generic Application of BFD          October, 2005

   Rather, control protocols can use the services provided by BFD to
   inform their operation.  BFD can be viewed as a service provided by
   the layer in which it is running.

   The service interface with BFD is straightforward.  The application
   supplies session parameters (neighbor address, time parameters,
   protocol options), and BFD provides the session state, of which the
   most interesting transitions are to and from the Up state.  The
   application is expected to bootstrap the BFD session, as BFD has no
   discovery mechanism.

   An implementation SHOULD establish only a single BFD session per data
   protocol path, regardless of the number of applications that wish to
   utilize it.  There is no additional value in having multiple BFD
   sessions to the same endpoints.  If multiple applications request
   different session parameters, it is a local issue as to how to
   resolve the parameter conflicts.  BFD in turn will notify all
   applications bound to a session when a session state change occurs.

   BFD should be viewed as having an advisory role to the protocol or
   protocols or other network function with which it is interacting,
   which will then use their own mechanisms to effect any state
   transitions.  The interaction is very much at arm's length, which
   keeps things simple and decoupled.  In particular, BFD explicitly
   does not carry application-specific information, partly for
   architectural reasons, and partly because BFD may have curious and
   unpredictable latency characteristics and as such makes a poor
   transport mechanism.

3. Control Protocol Interactions

   The object when BFD interacts with a control protocol is to advise
   the control protocol of the connectivity of the data protocol.  In
   the case of routing protocols, for example, this allows the
   connectivity failure to trigger the rerouting of traffic around the
   failed path.

   BFD sessions are typically bootstrapped by the control protocol,
   using the mechanism (discovery, configuration) used by the control
   protocol to find neighbors.  In most cases it is not desirable to
   preclude the control protocol from establishing an adjacency if the
   BFD session cannot be established (usually because the neighbor does
   not support BFD.)

   If the control protocol carries signaling that indicates the
   willingness of each system to establish a BFD session, the lack of a

Katz, Ward                                                      [Page 3]

Internet Draft         Generic Application of BFD          October, 2005

   BFD session may be used to block establishment of a control protocol

   If it appears that the neighboring system does not support BFD
   (because the control protocol adjacency was established but no BFD
   Control packets have been received from the neighbor) it is useful to
   increase the interval between transmitted BFD Control packets beyond
   the minimum.  This will have minimal impact on BFD session
   establishment if the neighbor decides to run BFD after all, since BFD
   Control packets will be sent on an event-driven basis once the first
   packet is seen from the neighbor.

   The mechanism by which the control protocol achieves its reaction to
   the path failure depends on the capabilities of the protocol.  A
   protocol which is tightly bound to the failing data protocol may wish
   to emulate a control protocol failure across the path (such as
   tearing down an adjacency or peer in a routing protocol that supports
   only the failed data protocol.)  Note that this should not be
   interpreted as BFD replacing the control protocol liveness mechanism,
   if any, as the control protocol may rely on mechanisms not verified
   by BFD (multicast, for instance) so BFD most likely cannot detect all
   failures that would impact the control protocol.  However, a control
   protocol may choose to use BFD session state information to more
   rapidly detect an impending control protocol failure, particularly if
   the control protocol operates in band (over the data protocol.)

   If the control protocol has a more explicit mechanism for announcing
   path state, it is preferable to use that mechanism rather than
   impacting the connectivity of the control protocol (since the control
   protocol may be supporting other data protocols that are still
   functioning), particularly if the control protocol operates out of
   band from the failed data protocol.

   If the control protocol has a Graceful Restart mechanism, BFD may be
   used in conjunction with this mechanism.  If BFD is implemented in
   the forwarding plane, a session failure implies that data can no
   longer be forwarded.  In this case, any Graceful Restart in progress
   should be aborted.  See [BFD-1HOP] for a more detailed discussion.

   If hierarchical or dependent layers of control protocols are in use
   (say, OSPF and IBGP), it may not be useful for more than one of them
   to interact with BFD.  In this example, because IBGP is dependent on
   OSPF for its routing information, the faster failure detection
   relayed to IBGP may actually be detrimental.  The cost of a peer
   state transition is high in BGP, and OSPF will naturally heal the
   path through the network if it were to receive the failure detection.

   In general, it is best for the protocol at the lowest point in the

Katz, Ward                                                      [Page 4]

Internet Draft         Generic Application of BFD          October, 2005

   hierarchy to interact with BFD, and then to use existing interactions
   between the control protocols to effect changes as necessary.  This
   will provide the fastest possible failure detection and recovery in a

4. Interactions With Non-Protocol Functions

   BFD session status may be used to affect other system functions that
   are not protocol-based (for example, static routes.)  If the path to
   a remote system fails, it may be desirable to avoid passing traffic
   to that remote system, so the local system may wish to take internal
   measures to accomplish this (such as withdrawing a static route and
   withdrawing that route from routing protocols.)

   Bootstrapping of the BFD session in the non-protocol case is likely
   to be derived from configuration information.

   There is no need to exchange endpoints or discriminator values via
   any mechanism other than configuration (via Operational Support
   Systems or any other means) as the endpoints must be known and
   configured by the same means.

5. Data Protocols and Demultiplexing

   BFD is intended to protect a single "data protocol" and is
   encapsulated within that protocol.  A pair of systems may have
   multiple BFD sessions over the same topology if they support (and are
   encapsulated by) different protocols.  For example, if two systems
   have IPv4 and IPv6 running across the same link between them, these
   are considered two separate paths and require two separate BFD

   This same technique is used for more fine-grained paths.  For
   example, if multiple differentiated services [DIFFSERV] are being
   operated on over IPv4, an independent BFD session may be run for each
   service level.  The BFD Control packets must be marked in the same
   way as the data packets, partly to ensure as much fate sharing as
   possible between BFD and data traffic, and also to demultiplex the
   initial packet if the discriminator values have not been exchanged.

Katz, Ward                                                      [Page 5]

Internet Draft         Generic Application of BFD          October, 2005

6. Other Application Issues

   BFD can provide liveness detection for OAM-like functions in
   tunneling and pseudowire protocols.  Running BFD inside the tunnel is
   recommended, as it exercises more aspects of the path.  One way to
   accommodate this is to address BFD packets based on the tunnel
   endpoints, assuming that they are numbered.

   If a planned outage is to take place on a path over which BFD is run,
   it is preferable to take down the BFD session by going into ADMIN
   DOWN state prior to the outage.

7. Interoperability Issues

   The BFD protocol itself is designed so that it will always
   interoperate at a basic level;  asynchronous mode is mandatory and is
   always available, and other modes and functions are negotiated at run
   time.  Since the service provided by BFD is identical regardless of
   the variants used, the particular choice of BFD options has no
   bearing on interoperability.

   The interaction between BFD and other protocols and control functions
   is very loosely coupled.  The actions taken are based on existing
   mechanisms in those protocols and functions, so interoperability
   problems are very unlikely unless BFD is applied in contradictory
   ways (such as a BFD session failure causing one implementation to go
   down and another implementation to come up.)

Normative References

   [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
       draft-ietf-bfd-base-04.txt, October, 2005.

   [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single
       Hop)", draft-ietf-bfd-v4v6-1hop-04.txt, October, 2005.

   [BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs",
       draft-ietf-bfd-mpls-02.txt, July, 2005.

   [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft-
       ietf-bfd-multihop-03.txt, July, 2005.

   [DIFFSERV] Nichols, K. et al, "Definition of the Differentiated
       Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC

Katz, Ward                                                      [Page 6]

Internet Draft         Generic Application of BFD          October, 2005

       2474, December, 1998.

   [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
       Requirement Levels", RFC 2119, March 1997.

Security Considerations

   This specification does not raise any additional security issues
   beyond those of the specifications referred to in the list of
   normative references.

IANA Considerations

   This document has no actions for IANA.

Authors' Addresses

    Dave Katz
    Juniper Networks
    1194 N. Mathilda Ave.
    Sunnyvale, California 94089-1206 USA
    Phone: +1-408-745-2000

    Dave Ward
    Cisco Systems
    170 W. Tasman Dr.
    San Jose, CA 95134 USA
    Phone: +1-408-526-4000

Katz, Ward                                                      [Page 7]

Internet Draft         Generic Application of BFD          October, 2005

Changes from the previous draft

   Text concerning the interaction between BFD and a hierarchy of
   control protocols was added.  A discussion of bootstrapping and
   session establishment was included.  Graceful Restart interactions
   were mentioned.  A section on fine-grained path demultiplexing was

IPR Disclaimer

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

Full Copyright Notice

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Katz, Ward                                                      [Page 8]

Internet Draft         Generic Application of BFD          October, 2005



   Funding for the RFC Editor function is currently provided by the
   Internet Society.

   This document expires in April, 2006.

Katz, Ward                                                      [Page 9]