--- 1/draft-ietf-bfd-base-02.txt 2006-02-04 22:51:08.000000000 +0100 +++ 2/draft-ietf-bfd-base-03.txt 2006-02-04 22:51:08.000000000 +0100 @@ -1,26 +1,26 @@ Network Working Group D. Katz Internet Draft Juniper Networks D. Ward Cisco Systems -Expires: September, 2005 March, 2005 +Expires: January, 2006 July, 2005 Bidirectional Forwarding Detection - draft-ietf-bfd-base-02.txt + draft-ietf-bfd-base-03.txt Status of this Memo - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - or will be disclosed, and any of which I become aware will be - disclosed, in accordance with RFC 3668. + 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." @@ -79,36 +79,38 @@ 6.7 Functional Specifics . . . . . . . . . . . . . . . . . . 25 6.7.1 State Variables . . . . . . . . . . . . . . . . . 25 6.7.2 Timer Negotiation . . . . . . . . . . . . . . . . 28 6.7.3 Timer Manipulation . . . . . . . . . . . . . . . . 29 6.7.4 Calculating the Detection Time . . . . . . . . . . 30 6.7.5 Detecting Failures with the Echo Function . . . . 31 6.7.6 Reception of BFD Control Packets . . . . . . . . . 31 6.7.7 Transmitting BFD Control Packets . . . . . . . . . 33 6.7.8 Initiation of a Poll Sequence . . . . . . . . . . 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.12 Min Tx Interval 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.16 Forwarding Plane Reset . . . . . . . . . . . . . 38 6.7.17 Administrative Control . . . . . . . . . . . . . 38 - 6.7.18 Concatenated Paths . . . . . . . . . . . . . . . 38 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 - Security Considerations . . . . . . . . . . . . . . . . . . . . 39 - Normative References . . . . . . . . . . . . . . . . . . . . . 41 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41 - Changes from the previous draft . . . . . . . . . . . . . . . . 41 - IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 42 + 6.7.18 Concatenated Paths . . . . . . . . . . . . . . . 39 + Backward Compatibility (Non-Normative) . . . . . . . . . . . . 39 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 40 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 + Security Considerations . . . . . . . . . . . . . . . . . . . . 41 + IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 42 + Normative References . . . . . . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42 + Changes from the previous draft . . . . . . . . . . . . . . . . 43 + IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction An increasingly important feature of networking equipment is the rapid detection of communication failures between adjacent systems, in order to more quickly establish alternative paths. Currently, detection can come fairly quickly in certain circumstances when data link hardware comes into play (such as SONET alarms.) However, there are media that do not provide this kind of signaling (such as Ethernet), and some media may not detect certain kinds of failures in @@ -1397,58 +1399,61 @@ the local system, and the Final (F) bit in the received packet is set, the Poll Sequence MUST be terminated. If Demand mode is not active, the Final (F) bit in the received 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 subsequent transmitted packets. 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 bfd.SessionState is not Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down 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 Set bfd.SessionState to Init Else if received State is Init Set bfd.SessionState to Up Else if bfd.SessionState is Init If received State is Init or Up Set bfd.SessionState to Up + Else (bfd.SessionState is Up) 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 - Update the transmit interval as described in section 6.7.2. - If the Demand (D) bit is set and bfd.DemandModeDesired is 1, and bfd.SessionState is Up, Demand mode is active. If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, or bfd.SessionState is not Up, Demand mode is not active. 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 set. - If the packet was not discarded, it has been received for purposes of - the Detection Time expiration rules in section 6.7.4. + If the packet was not discarded, it has been received for purposes + of the Detection Time expiration rules in section 6.7.4. 6.7.7. Transmitting BFD Control Packets BFD Control packets MUST be transmitted periodically at the rate determined according to section 6.7.2, except as specified in this section. The transmit interval MUST be recalculated whenever bfd.DesiredMinTxInterval changes, or whenever the received Required Min RX Interval changes, and is equal to the greater of those two @@ -1556,23 +1560,21 @@ Included and set according to the rules in section 6.6 if authentication is in use (bfd.AuthType is nonzero.) Otherwise this section is not present. 6.7.8. Initiation of a Poll Sequence 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 different than the contents of the previous packet, with the exception of the Poll (P) and Final (F) bits. This ensures that - parameter changes are transmitted to the remote system. Note that if - the I Hear You (H) bit is changing to zero, the session is going down - and Demand mode will no longer be active. + parameter changes are transmitted to the remote system. If Demand mode is active, a Poll Sequence SHOULD be initiated whenever the system feels the need to verify connectivity with the remote system. The conditions under which this is desirable are outside the scope of this specification. If a Poll Sequence is being sent, and a new Poll Sequence is initiated due to one of the above conditions, the detection interval MUST be restarted in order to ensure that a full Poll Sequence is transmitted under the new conditions. @@ -1660,23 +1662,23 @@ procedure MUST be followed: If enabling session Set bfd.SessionState to Down Else Set bfd.SessionState to AdminDown Set bfd.LocalDiag to an appropriate value Cease the transmission of BFD Echo packets - If signalling is received from outside BFD that the underlying path - has failed, an implementation MAY adminstratively disable the session - with the diagnostic Path Down. + If signalling is received from outside BFD that the underlying + path has failed, an implementation MAY adminstratively disable + the session with the diagnostic Path Down. Other scenarios MAY use the diagnostic Administratively Down. 6.7.18. Concatenated 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 of those paths across the BFD session (providing an interworking function for liveness monitoring between BFD and other technologies.) @@ -1694,20 +1696,57 @@ action is necessary, as the diagnostic code will be carried via the periodic transmission of BFD Control packets. If Demand Mode is active, a Poll Sequence MUST be initiated to ensure that the diagnostic code is transmitted. Note that if the BFD session subsequently fails, the diagnostic code will be overwritten with a code detailing the cause of the failure. It is up to the interworking agent to perform the above procedure again, once the BFD session reaches Up state, if the propagation of the concatenated path 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 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also significant contributors to this document. Acknowledgments This document was inspired by (and is intended to replace) the Protocol Liveness Protocol draft, written by Kireeti Kompella. @@ -1763,20 +1803,24 @@ Using SHA1 rather than MD5 is believed to have stronger security properties. All comments about MD5 in this section also apply to SHA1. If both systems randomize their Local Discriminator values at the beginning of a session, replay attacks may be further mitigated, regardless of the authentication type in use. Since the Local Discriminator may be changed at any time during a session, this mechanism may also help mitigate attacks. +IANA Considerations + + This document has no actions for IANA. + Normative References [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004. [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. @@ -1798,82 +1842,69 @@ Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 Email: dward@cisco.com Changes from the previous draft - The primary technical change in this draft from the previous version - is an updated state machine, and an updated packet format to effect - it (with an appropriate change to the version number.) This version - of the draft is incompatible with previous versions, and will not - 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. + The primary technical change was the addition of a suggested (non- + 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 The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 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 this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. + 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 + http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. 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. + 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. - This document expires in September, 2005. + This document expires in January, 2006.