--- 1/draft-ietf-bfd-base-04.txt 2006-06-14 22:12:18.000000000 +0200 +++ 2/draft-ietf-bfd-base-05.txt 2006-06-14 22:12:18.000000000 +0200 @@ -1,19 +1,19 @@ Network Working Group D. Katz Internet Draft Juniper Networks D. Ward Cisco Systems -Expires: April, 2006 October, 2005 +Expires: December, 2006 June, 2006 Bidirectional Forwarding Detection - draft-ietf-bfd-base-04.txt + draft-ietf-bfd-base-05.txt 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 @@ -26,21 +26,21 @@ material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice - Copyright (C) The Internet Society (2005). All Rights Reserved. + Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. @@ -635,21 +635,21 @@ If both systems signal that they want to use Demand mode, the transmission of BFD Control packets ceases once the session is Up. Other means of implying connectivity are used to keep the session alive. If one of the systems wishes to verify connectivity, it can initiate a short exchange (a "Poll Sequence") of BFD Control packets to verify this. 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 - 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. If sufficient Echo packets are lost, the session is declared down in the same manner. See section 6.7.5. If Demand mode is active and no appropriate Control packets are received in response to a Poll Sequence, the session is declared down in the same manner. See section 6.5. If the session goes down, the transmission of Echo packets (if any) @@ -761,37 +761,37 @@ the other system reflect it back.) The implications on an implementation for changing the discriminator value is outside the scope of this specification. 6.4. The Echo Function and Asymmetry The Echo function can be run independently in each direction between 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 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 - 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 - controlled by manipulating the Desired Min TX Interval field (see + controlled by manipulating the Required Min RX Interval field (see section 6.7.3.) 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. Since BFD allows independent transmission rates in each direction, this is easily accomplished. - A system SHOULD always advertise the lowest value of Required Min RX - Interval and Required Min Echo RX Interval that it can under the + A system SHOULD otherwise advertise the lowest value of Required Min + RX Interval and Required Min Echo RX Interval that it can under the circumstances, to give the other system more freedom in choosing its transmission rate. Note that a system is committing to be able to receive both streams of packets at the rate it advertises, so this should be taken into account when choosing the values to advertise. 6.5. Demand Mode Demand mode is negotiated by virtue of both systems setting the Demand (D) bit in its BFD Control packets. Both systems must request Demand mode for it to become active. @@ -1079,21 +1079,21 @@ Sequence Number field, and the received packet MUST be accepted. 6.7. Functional Specifics The following section of this specification is normative. The means by which this specification is achieved is outside the scope of this specification. When a system is said to have "the Echo function active," it means 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. When a system is said to have "Demand mode active," it means that bfd.DemandModeDesired is 1 in the local system (see State Variables below), the remote system is signalling with the Demand (D) bit set, and that the session is Up. 6.7.1. State Variables A minimum amount of information about a session needs to be tracked @@ -1274,24 +1274,24 @@ higher rate (and those packets are being received) prior to the detection time being reduced. When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD. When the Echo function is active, a system SHOULD set - bfd.DesiredMinTxInterval to a value of not less than one second - (1,000,000 microseconds.) This is intended to keep BFD Control - traffic at a negligible level, since the actual detection function is - being performed using BFD Echo packets. + bfd.RequiredMinRxInterval to a value of not less than one second + (1,000,000 microseconds.) This is intended to keep received BFD + Control traffic at a negligible level, since the actual detection + function is being performed using BFD Echo packets. 6.7.4. Calculating the Detection Time The Detection Time (the period of time without receiving BFD packets after which the session is determined to have failed) is not carried explicitly in the protocol. Rather, it is calculated independently in each direction by the receiving system based on the negotiated transmit interval and the detection multiplier. Note that, in Asynchronous mode, there may be different detection times in each direction. @@ -1842,21 +1842,28 @@ 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 - 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 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 Rights or other rights that might be claimed to @@ -1875,30 +1882,30 @@ 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 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). + Copyright (C) The Internet Society (2006). 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 April, 2006. + This document expires in December, 2006.