draft-ietf-bfd-base-02.txt   draft-ietf-bfd-base-03.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: September, 2005 March, 2005 Expires: January, 2006 July, 2005
Bidirectional Forwarding Detection Bidirectional Forwarding Detection
draft-ietf-bfd-base-02.txt draft-ietf-bfd-base-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 2, line 47 skipping to change at page 2, line 47
6.7 Functional Specifics . . . . . . . . . . . . . . . . . . 25 6.7 Functional Specifics . . . . . . . . . . . . . . . . . . 25
6.7.1 State Variables . . . . . . . . . . . . . . . . . 25 6.7.1 State Variables . . . . . . . . . . . . . . . . . 25
6.7.2 Timer Negotiation . . . . . . . . . . . . . . . . 28 6.7.2 Timer Negotiation . . . . . . . . . . . . . . . . 28
6.7.3 Timer Manipulation . . . . . . . . . . . . . . . . 29 6.7.3 Timer Manipulation . . . . . . . . . . . . . . . . 29
6.7.4 Calculating the Detection Time . . . . . . . . . . 30 6.7.4 Calculating the Detection Time . . . . . . . . . . 30
6.7.5 Detecting Failures with the Echo Function . . . . 31 6.7.5 Detecting Failures with the Echo Function . . . . 31
6.7.6 Reception of BFD Control Packets . . . . . . . . . 31 6.7.6 Reception of BFD Control Packets . . . . . . . . . 31
6.7.7 Transmitting BFD Control Packets . . . . . . . . . 33 6.7.7 Transmitting BFD Control Packets . . . . . . . . . 33
6.7.8 Initiation of a Poll Sequence . . . . . . . . . . 36 6.7.8 Initiation of a Poll Sequence . . . . . . . . . . 36
6.7.9 Reception of BFD Echo Packets . . . . . . . . . . 36 6.7.9 Reception of BFD Echo Packets . . . . . . . . . . 36
6.7.10 Transmission of BFD Echo Packets . . . . . . . . 36 6.7.10 Transmission of BFD Echo Packets . . . . . . . . 37
6.7.11 Min Rx Interval Change . . . . . . . . . . . . . 37 6.7.11 Min Rx Interval Change . . . . . . . . . . . . . 37
6.7.12 Min Tx Interval Change . . . . . . . . . . . . . 37 6.7.12 Min Tx Interval Change . . . . . . . . . . . . . 37
6.7.13 Detect Multiplier Change . . . . . . . . . . . . 37 6.7.13 Detect Multiplier Change . . . . . . . . . . . . 37
6.7.14 Enabling or Disabling the Echo Function . . . . . 37 6.7.14 Enabling or Disabling the Echo Function . . . . . 38
6.7.15 Enabling or Disabling Demand Mode . . . . . . . . 38 6.7.15 Enabling or Disabling Demand Mode . . . . . . . . 38
6.7.16 Forwarding Plane Reset . . . . . . . . . . . . . 38 6.7.16 Forwarding Plane Reset . . . . . . . . . . . . . 38
6.7.17 Administrative Control . . . . . . . . . . . . . 38 6.7.17 Administrative Control . . . . . . . . . . . . . 38
6.7.18 Concatenated Paths . . . . . . . . . . . . . . . 38 6.7.18 Concatenated Paths . . . . . . . . . . . . . . . 39
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 39
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 40
Security Considerations . . . . . . . . . . . . . . . . . . . . 39 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
Normative References . . . . . . . . . . . . . . . . . . . . . 41 Security Considerations . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 42
Changes from the previous draft . . . . . . . . . . . . . . . . 41 Normative References . . . . . . . . . . . . . . . . . . . . . 42
IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42
Changes from the previous draft . . . . . . . . . . . . . . . . 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. Currently,
detection can come fairly quickly in certain circumstances when data detection can come fairly quickly in certain circumstances when data
link hardware comes into play (such as SONET alarms.) However, there link hardware comes into play (such as SONET alarms.) However, there
are media that do not provide this kind of signaling (such as are media that do not provide this kind of signaling (such as
Ethernet), and some media may not detect certain kinds of failures in Ethernet), and some media may not detect certain kinds of failures in
skipping to change at page 32, line 33 skipping to change at page 32, line 33
the local system, and the Final (F) bit in the received packet is the local system, and the Final (F) bit in the received packet is
set, the Poll Sequence MUST be terminated. set, the Poll Sequence MUST be terminated.
If Demand mode is not active, the Final (F) bit in the received If Demand mode is not active, the Final (F) bit in the received
packet is set, and the local system has been transmitting packets packet is set, and the local system has been transmitting packets
with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in
subsequent transmitted packets. subsequent transmitted packets.
Update the Detection Time as described in section 6.7.4. Update the Detection Time as described in section 6.7.4.
Update the transmit interval as described in section 6.7.2.
If bfd.SessionState is AdminDown
Discard the packet
If received state is AdminDown If received state is AdminDown
If bfd.SessionState is not Down If bfd.SessionState is not 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
Else Else
If bfd.SessionState is AdminDown
Discard the packet
Else if bfd.SessionState is Down If bfd.SessionState is Down
If received State is Down If received State is Down
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
Update the transmit interval as described in section 6.7.2.
If the Demand (D) bit is set and bfd.DemandModeDesired is 1, If the Demand (D) bit is set and bfd.DemandModeDesired is 1,
and bfd.SessionState is Up, Demand mode is active. and bfd.SessionState is Up, Demand mode is active.
If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, If the Demand (D) bit is clear or bfd.DemandModeDesired is 0,
or bfd.SessionState is not Up, Demand mode is not or bfd.SessionState is not Up, Demand mode is not
active. active.
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. set.
If the packet was not discarded, it has been received for purposes of If the packet was not discarded, it has been received for purposes
the Detection Time expiration rules in section 6.7.4. of the Detection Time expiration rules in section 6.7.4.
6.7.7. Transmitting BFD Control Packets 6.7.7. Transmitting BFD Control Packets
BFD Control packets MUST be transmitted periodically at the rate BFD Control packets MUST be transmitted periodically at the rate
determined according to section 6.7.2, except as specified in this determined according to section 6.7.2, except as specified in this
section. section.
The transmit interval MUST be recalculated whenever The transmit interval MUST be recalculated whenever
bfd.DesiredMinTxInterval changes, or whenever the received Required bfd.DesiredMinTxInterval changes, or whenever the received Required
Min RX Interval changes, and is equal to the greater of those two Min RX Interval changes, and is equal to the greater of those two
skipping to change at page 36, line 17 skipping to change at page 36, line 24
Included and set according to the rules in section 6.6 if Included and set according to the rules in section 6.6 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.7.8. Initiation of a Poll Sequence 6.7.8. Initiation of a Poll Sequence
If Demand mode is active, a Poll Sequence MUST be initiated whenever If Demand mode is active, a Poll Sequence MUST be initiated whenever
the contents of the next BFD Control packet to be sent would be the contents of the next BFD Control packet to be sent would be
different than the contents of the previous packet, with the different than the contents of the previous packet, with the
exception of the Poll (P) and Final (F) bits. This ensures that exception of the Poll (P) and Final (F) bits. This ensures that
parameter changes are transmitted to the remote system. Note that if parameter changes are transmitted to the remote system.
the I Hear You (H) bit is changing to zero, the session is going down
and Demand mode will no longer be active.
If Demand mode is active, a Poll Sequence SHOULD be initiated If Demand mode is active, a Poll Sequence SHOULD be initiated
whenever the system feels the need to verify connectivity with the whenever the system feels the need to verify connectivity with the
remote system. The conditions under which this is desirable are remote system. The conditions under which this is desirable are
outside the scope of this specification. outside the scope of this specification.
If a Poll Sequence is being sent, and a new Poll Sequence is If a Poll Sequence is being sent, and a new Poll Sequence is
initiated due to one of the above conditions, the detection interval initiated due to one of the above conditions, the detection interval
MUST be restarted in order to ensure that a full Poll Sequence is MUST be restarted in order to ensure that a full Poll Sequence is
transmitted under the new conditions. transmitted under the new conditions.
skipping to change at page 38, line 33 skipping to change at page 38, line 44
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
Set bfd.LocalDiag to an appropriate value Set bfd.LocalDiag to an appropriate value
Cease the transmission of BFD Echo packets Cease the transmission of BFD Echo packets
If signalling is received from outside BFD that the underlying path If signalling is received from outside BFD that the underlying
has failed, an implementation MAY adminstratively disable the session path has failed, an implementation MAY adminstratively disable
with the diagnostic Path Down. the session with the diagnostic Path Down.
Other scenarios MAY use the diagnostic Administratively Down. Other scenarios MAY use the diagnostic Administratively Down.
6.7.18. Concatenated Paths 6.7.18. 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,
it may be desirable to propagate the indication of a failure of one it may be desirable to propagate the indication of a failure of one
of those paths across the BFD session (providing an interworking of those paths across the BFD session (providing an interworking
function for liveness monitoring between BFD and other technologies.) function for liveness monitoring between BFD and other technologies.)
skipping to change at page 39, line 21 skipping to change at page 39, line 33
action is necessary, as the diagnostic code will be carried via the action is necessary, as the diagnostic code will be carried via the
periodic transmission of BFD Control packets. If Demand Mode is periodic transmission of BFD Control packets. If Demand Mode is
active, a Poll Sequence MUST be initiated to ensure that the active, a Poll Sequence MUST be initiated to ensure that the
diagnostic code is transmitted. Note that if the BFD session diagnostic code is transmitted. Note that if the BFD session
subsequently fails, the diagnostic code will be overwritten with a subsequently fails, the diagnostic code will be overwritten with a
code detailing the cause of the failure. It is up to the code detailing the cause of the failure. It is up to the
interworking agent to perform the above procedure again, once the BFD interworking agent to perform the above procedure again, once the BFD
session reaches Up state, if the propagation of the concatenated path session reaches Up state, if the propagation of the concatenated path
failure is to resume. failure is to resume.
Backward Compatibility (Non-Normative)
Although Version 0 of this document is unlikely to have been deployed
widely, some implementors may wish to have a backward compatibility
mechanism. Note that any mechanism may be potentially 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
converge on version 1 if both systems implement it, even if one
system is upgraded from version 0 within a detection time. It will
interoperate with a system that implements only one version (or is
configured to support only one version.) A system should obviously
not perform this function if it is configured to or is only capable
of using a single version.
A BFD session will enter a "negotiation holddown" if it is configured
for automatic versioning and either has just started up, or the
session has been manually cleared. The session is set to AdminDown
state and Version 1. During the holddown period, which lasts for one
detection time, the system sends BFD Control packets as usual, but
ignores received packets. After the holddown time is complete, the
state transitions to Down and normal operation resumes.
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
for the session, it switches immediately to Version 0. If it is
currently using Version 0 and a Version 1 packet is received that
indicates that the neighbor is in state AdminDown, it switches to
Version 1. If using Version 0 and a Version 1 packet is received
indicating a state other than AdminDown, the packet is ignored (per
spec.)
If the version being used is changed, the session goes down as
appropriate for the new version (Down state for Version 1 or Failing
state for Version 0.)
Contributors 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 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 draft, written by Kireeti Kompella.
skipping to change at page 41, line 5 skipping to change at page 42, line 9
Using SHA1 rather than MD5 is believed to have stronger security Using SHA1 rather than MD5 is believed to have stronger security
properties. All comments about MD5 in this section also apply to properties. All comments about MD5 in this section also apply to
SHA1. SHA1.
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.
IANA Considerations
This document has no actions for IANA.
Normative References Normative References
[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism
(GTSM)", RFC 3682, February 2004. (GTSM)", RFC 3682, February 2004.
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", 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, April
1992. 1992.
skipping to change at page 41, line 40 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 in this draft from the previous version The primary technical change was the addition of a suggested (non-
is an updated state machine, and an updated packet format to effect normative) backward compatibility mechanism with version 0 of BFD. A
it (with an appropriate change to the version number.) This version minor tweak to the state machine to more explicitly spell out the
of the draft is incompatible with previous versions, and will not action to be taken in AdminDown state was done.
interoperate with them (but the two versions will ignore one
another.)
The packet transmission rules were relaxed to allow multiple "extra"
packets to be sent between regularly scheduled transmissions, in
order to take advantage of the new state machine to speed up session
establishment.
Verbiage regarding the Poll/Final bits was updated to state that
Polls must be sent when in Up state and the timing parameters change
(but that Finals in response to Polls are sent in any state.)
A mistake in the description of the calculation of the Detection Time
while in Demand Mode was corrected.
The fact that SHA1 authentication is mandatory only when implementing
authentication was clarified.
Otherwise, the changes in this draft from the previous version are Otherwise, the changes in this draft from the previous version are
cosmetic and/or editorial. 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 or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
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 which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Full Copyright Notice Full Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 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 September, 2005. This document expires in January, 2006.
 End of changes. 

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