draft-ietf-bfd-base-03.txt   draft-ietf-bfd-base-04.txt 
Network Working Group D. Katz Network Working Group D. Katz
Internet Draft Juniper Networks Internet Draft Juniper Networks
D. Ward D. Ward
Cisco Systems Cisco Systems
Expires: January, 2006 July, 2005 Expires: April, 2006 October, 2005
Bidirectional Forwarding Detection Bidirectional Forwarding Detection
draft-ietf-bfd-base-03.txt draft-ietf-bfd-base-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 22 skipping to change at page 3, line 22
IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 42 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 42
Normative References . . . . . . . . . . . . . . . . . . . . . 42 Normative References . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42
Changes from the previous draft . . . . . . . . . . . . . . . . 43 Changes from the previous draft . . . . . . . . . . . . . . . . 43
IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 43 IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 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. Currently, in order to more quickly establish alternative paths. Detection can
detection can come fairly quickly in certain circumstances when data come fairly quickly in certain circumstances when data link hardware
link hardware comes into play (such as SONET alarms.) However, there comes into play (such as SONET alarms.) However, there are media
are media that do not provide this kind of signaling (such as that do not provide this kind of signaling (such as Ethernet), and
Ethernet), and some media may not detect certain kinds of failures in some media may not detect certain kinds of failures in the path, for
the path, for example, failing interfaces or forwarding engine example, failing interfaces or forwarding engine components.
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 in
the path between the two routing protocol engines. the path between the two routing protocol engines.
skipping to change at page 4, line 6 skipping to change at page 4, line 4
of failures in the path between adjacent forwarding engines, of failures in the path between adjacent forwarding engines,
including the interfaces, data link(s), and to the extent possible including the interfaces, data link(s), and to the extent possible
the forwarding engines themselves. 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 will be 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 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.
BFD operates on top of any data protocol being forwarded between two BFD operates on top of any data protocol being forwarded between two
systems. It is always run in a unicast, point-to-point mode. BFD systems. It is always run in a unicast, point-to-point mode. BFD
packets are carried as the payload of whatever encapsulating protocol packets are carried as the payload of whatever encapsulating protocol
is appropriate for the medium and network. BFD may be running at is appropriate for the medium and network. BFD may be running at
multiple layers in a system. The context of the operation of any multiple layers in a system. The context of the operation of any
particular BFD session is bound to its encapsulation. particular BFD session is bound to its encapsulation.
skipping to change at page 5, line 17 skipping to change at page 5, line 17
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 to not 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
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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 each system has an independent way of verifying that it has that each system has an independent way of verifying that it has
connectivity to the other system, so once a BFD session is connectivity to the other system. Once a BFD session is established,
established, the systems stop sending BFD Control packets, except the systems stop sending BFD Control packets, except when either
when either system feels the need to verify connectivity explicitly, system feels the need to verify connectivity explicitly, in which
in which case a short sequence of BFD Control packets is sent, and case a short sequence of BFD Control packets is sent, and then the
then the protocol quiesces. protocol quiesces.
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 in a row of the echoed data forwarding path. If a number of packets of the echoed data stream
stream are not received, the session is declared to be down. The are not received, the session is declared to be down. The Echo
Echo function may be used with either Asynchronous or Demand modes. function may be used with either Asynchronous or Demand modes. Since
Since the Echo function is handling the task of detection, the rate the Echo function is handling the task of detection, the rate of
of periodic transmission of Control packets may be reduced (in the periodic transmission of Control packets may be reduced (in the case
case of Asynchronous mode) or eliminated completely (in the case of of Asynchronous mode) or eliminated completely (in the case of Demand
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, which 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.
The Echo function may be enabled individually in each direction. It The Echo function may be enabled individually in each direction. It
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
skipping to change at page 7, line 10 skipping to change at page 7, line 10
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 also may not be used when the path round trip time is greater mode also may not be used when the path round trip time is greater
than the desired detection time. See section 6.5 for more details. than the desired detection time. See section 6.5 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, which is outside of the scope of this document. See the environment. The specific encapsulation is outside of the scope of
appropriate application document for encapsulation details. this document. See the appropriate application document for
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
skipping to change at page 14, line 26 skipping to change at page 14, line 26
Auth Key/Checksum Auth Key/Checksum
This field carries the 20 byte SHA1 checksum for the packet. When This field carries the 20 byte SHA1 checksum for the packet. When
the checksum is calculated, the shared SHA1 key is stored in this the checksum is calculated, the shared SHA1 key is stored in this
field. (See section 6.6.4 for details.) field. (See section 6.6.4 for details.)
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 document 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.
6. Elements of Procedure 6. Elements of Procedure
skipping to change at page 15, line 33 skipping to change at page 15, line 33
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 comes 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 to 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.
If both systems signal that they want to use Demand mode, the If both systems signal that they want to use Demand mode, the
transmission of BFD Control packets ceases once the session is Up. transmission of BFD Control packets ceases once the session is Up.
Other means of implying connectivity are used to keep the session Other means of implying connectivity are used to keep the session
alive. If one of the systems wishes to verify connectivity, it can alive. If one of the systems wishes to verify connectivity, it can
initiate a short exchange (a "Poll Sequence") of BFD Control packets initiate a short exchange (a "Poll Sequence") of BFD Control packets
to verify this. to verify this.
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.7.4), the session is the calculated detection time (see section 6.7.4), the session is
declared down, and signalled to the remote end via the State (Sta) declared Down. This is signalled to the remote end via the State
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. the same manner. See section 6.7.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. in the same manner. See section 6.5.
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
skipping to change at page 18, line 29 skipping to change at page 18, line 29
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 during a session without affecting the session state, since only that
that system uses its discriminator for demultiplexing purposes (by system uses its discriminator for demultiplexing purposes (by having
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 signalled to the system looping them back. packets is not directly signalled to the system looping them back.
skipping to change at page 43, line 7 skipping to change at page 43, line 7
Dave Ward Dave Ward
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 USA San Jose, CA 95134 USA
Phone: +1-408-526-4000 Phone: +1-408-526-4000
Email: dward@cisco.com Email: dward@cisco.com
Changes from the previous draft Changes from the previous draft
The primary technical change was the addition of a suggested (non- All changes from the previous draft are purely editorial.
normative) backward compatibility mechanism with version 0 of BFD. A
minor tweak to the state machine to more explicitly spell out the
action to be taken in AdminDown state was done.
Otherwise, the changes in this draft from the previous version are
cosmetic and/or editorial.
IPR Notice IPR Notice
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
skipping to change at page 44, line 26 skipping to change at page 44, line 13
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
This document expires in January, 2006. This document expires in April, 2006.
 End of changes. 18 change blocks. 
45 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/