draft-ietf-bfd-base-04.txt   draft-ietf-bfd-base-05.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: April, 2006 October, 2005 Expires: December, 2006 June, 2006
Bidirectional Forwarding Detection Bidirectional Forwarding Detection
draft-ietf-bfd-base-04.txt draft-ietf-bfd-base-05.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 1, line 37 skipping to change at page 1, line 37
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract Abstract
This document describes a protocol intended to detect faults in the This document describes a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including bidirectional path between two forwarding engines, including
interfaces, data link(s), and to the extent possible the forwarding interfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. independently of media, data protocols, and routing protocols.
Comments on this draft should be directed to rtg-bfd@ietf.org. Comments on this draft should be directed to rtg-bfd@ietf.org.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
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. This is signalled 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.7.5. 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. See section 6.5. 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)
skipping to change at page 18, line 41 skipping to change at page 18, line 41
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 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 transmission 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 Desired Min TX Interval field (see controlled by manipulating the Required Min RX Interval field (see
section 6.7.3.) section 6.7.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 send 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 always advertise the lowest value of Required Min RX A system SHOULD otherwise advertise the lowest value of Required Min
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. Demand Mode 6.5. Demand Mode
Demand mode is negotiated by virtue of both systems setting the Demand mode is negotiated by virtue of both systems setting the
Demand (D) bit in its BFD Control packets. Both systems must request Demand (D) bit in its BFD Control packets. Both systems must request
Demand mode for it to become active. Demand mode for it to become active.
skipping to change at page 25, line 31 skipping to change at page 25, line 31
Sequence Number field, and the received packet MUST be accepted. Sequence Number field, and the received packet MUST be accepted.
6.7. Functional Specifics 6.7. 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 signalled its willingness to session is Up and the other system has signaled its willingness to
loop back Echo packets. loop back Echo packets.
When a system is said to have "Demand mode active," it means that When a system is said to have "Demand mode active," it means that
bfd.DemandModeDesired is 1 in the local system (see State Variables bfd.DemandModeDesired is 1 in the local system (see State Variables
below), the remote system is signalling with the Demand (D) bit set, below), the remote system is signalling with the Demand (D) bit set,
and that the session is Up. and that the session is Up.
6.7.1. State Variables 6.7.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
skipping to change at page 29, line 50 skipping to change at page 29, line 50
higher rate (and those packets are being received) prior to the higher rate (and those packets are being received) prior to the
detection time being reduced. detection time being 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.
When the Echo function is active, a system SHOULD set When the Echo function is active, a system SHOULD set
bfd.DesiredMinTxInterval 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 BFD Control (1,000,000 microseconds.) This is intended to keep received BFD
traffic at a negligible level, since the actual detection function is Control traffic at a negligible level, since the actual detection
being performed using BFD Echo packets. function is being performed using BFD Echo packets.
6.7.4. Calculating the Detection Time 6.7.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, in transmit interval and the detection multiplier. Note that, in
Asynchronous mode, there may be different detection times in each Asynchronous mode, there may be different detection times in each
direction. direction.
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
All changes from the previous draft are purely editorial. The only substantive change from the previous draft is to fix a bug
in section 6.4 regarding the manipulation of timers when the Echo
Function is active. The previous text discussed manipulation of the
transmit timing, when it is actually the receive timing that matters.
This change does not affect interoperability or correctness of
function, but instead properly describes an optimization.
All other changes are purely editorial in nature.
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 43, line 40 skipping to change at page 44, line 7
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Notice Full Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
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 April, 2006. This document expires in December, 2006.
 End of changes. 14 change blocks. 
17 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/