--- 1/draft-ietf-bfd-base-03.txt 2006-02-04 17:13:05.000000000 +0100 +++ 2/draft-ietf-bfd-base-04.txt 2006-02-04 17:13:05.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group D. Katz Internet Draft Juniper Networks D. Ward Cisco Systems -Expires: January, 2006 July, 2005 +Expires: April, 2006 October, 2005 Bidirectional Forwarding Detection - draft-ietf-bfd-base-03.txt + draft-ietf-bfd-base-04.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 @@ -102,27 +102,26 @@ 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 - the path, for example, failing interfaces or forwarding engine - components. + in order to more quickly establish alternative paths. 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 the path, for + example, failing interfaces or forwarding engine components. Networks use relatively slow "Hello" mechanisms, usually in routing protocols, to detect failures when there is no hardware signaling to help out. The time to detect failures ("detection times") available 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 data at gigabit rates. Furthermore, routing protocol Hellos are of no help when those routing protocols are not in use, and the semantics of detection are subtly different--they detect a failure in the path between the two routing protocol engines. @@ -131,36 +130,36 @@ of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and to the extent possible the forwarding engines themselves. 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 wide range of detection times and overhead, to avoid a proliferation of different methods. 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. Note that many of the exact mechanisms are implementation dependent and will not affect interoperability, and are thus outside the scope of this specification. Those issues are so noted. 2. Design BFD is designed to detect failures in communication with a forwarding plane next hop. It is intended to be implemented in some component of the forwarding engine of a system, in cases where the forwarding and control engines are separated. This not only binds the protocol more to the forwarding plane, but decouples the protocol from the - fate of the routing protocol engine (making it useful in concert with - various "graceful restart" mechanisms for those protocols.) BFD may + fate of the routing protocol engine, making it useful in concert with + various "graceful restart" mechanisms for those protocols. BFD may also be implemented in the control engine, though doing so may preclude the detection of some kinds of failures. 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 packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. BFD may be running at multiple layers in a system. The context of the operation of any particular BFD session is bound to its encapsulation. @@ -188,22 +187,22 @@ BFD is a simple hello protocol that in many respects is similar to the detection components of well-known routing protocols. A pair of systems transmit BFD packets periodically over each path between the two systems, and if a system stops receiving BFD packets for long enough, some component in that particular bidirectional path to the neighboring system is assumed to have failed. Under some conditions, systems may negotiate to not send periodic BFD packets in order to reduce overhead. A path is only declared to be operational when two-way communication - has been established between systems (though this does not preclude - the use of unidirectional links.) + has been established between systems, though this does not preclude + the use of unidirectional links. A separate BFD session is created for each communications path and data protocol in use between two systems. 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 detection of failure will take place. These estimates can be 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 system to be able to more rapidly detect failures between the fast @@ -225,44 +224,44 @@ additional function that can be used in combination with the two modes. The primary mode is known as Asynchronous mode. In this mode, the 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 system, the session is declared to be down. 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 - connectivity to the other system, so once a BFD session is - established, the systems stop sending BFD Control packets, except - when either system feels the need to verify connectivity explicitly, - in which case a short sequence of BFD Control packets is sent, and - then the protocol quiesces. + connectivity to the other system. Once a BFD session is established, + the systems stop sending BFD Control packets, except when either + system feels the need to verify connectivity explicitly, in which + case a short sequence of BFD Control packets is sent, and then the + protocol quiesces. An adjunct to both modes is the Echo function. When the Echo 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 - forwarding path. If a number of packets in a row of the echoed data - stream are not received, the session is declared to be down. The - Echo function may be used with either Asynchronous or Demand modes. - Since the Echo function is handling the task of detection, the rate - of periodic transmission of Control packets may be reduced (in the - case of Asynchronous mode) or eliminated completely (in the case of - Demand mode.) + forwarding path. If a number of packets of the echoed data stream + are not received, the session is declared to be down. The Echo + function may be used with either Asynchronous or Demand modes. Since + the Echo function is handling the task of detection, the rate of + periodic transmission of Control packets may be reduced (in the case + of Asynchronous mode) or eliminated completely (in the case of Demand + mode.) Pure asynchronous mode is advantageous in that it requires half as many packets to achieve a particular detection time as does the Echo function. It is also used when the Echo function cannot be supported for some reason. 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 potentially detecting some classes of failure that might not otherwise be detected. The Echo function may be enabled individually in each direction. It 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 system that sends the Echo packets decides it wishes to. Demand mode is useful in situations where the overhead of a periodic @@ -272,22 +271,23 @@ detection times are essentially driven by the heuristics of the 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 than the desired detection time. See section 6.5 for more details. 4. BFD Control Packet Format 4.1. Generic BFD Control Packet Format BFD Control packets are sent in an encapsulation appropriate to the - environment, which is outside of the scope of this document. See the - appropriate application document for encapsulation details. + environment. The specific encapsulation is outside of the scope of + this document. See the appropriate application document for + encapsulation details. The BFD Control packet has a Mandatory Section and an optional Authentication Section. The format of the Authentication Section, if present, is dependent on the type of authentication in use. The Mandatory Section of a BFD Control packet has the following format: 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 @@ -577,21 +577,21 @@ Auth Key/Checksum This field carries the 20 byte SHA1 checksum for the packet. When the checksum is calculated, the shared SHA1 key is stored in this field. (See section 6.6.4 for details.) 5. BFD Echo Packet Format 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. The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received packet to the correct BFD session after it is looped back to the sender. The contents are otherwise outside the scope of this specification. 6. Elements of Procedure @@ -615,49 +615,49 @@ has received any BFD packets for that session. A system taking the Passive role MUST NOT begin sending BFD packets for a particular session until it has received a BFD packet for that session, and thus has learned the remote system's discriminator value. At least one system MUST take the Active role (possibly both.) The role that a system takes is specific to the application of BFD, and is outside the scope of this specification. A session begins with the periodic, slow transmission of BFD Control 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 function if it desires to and the other system signals that it will allow it. The rate of transmission of Control packets is typically kept low when the Echo function is active. If the Echo function is not active, the transmission rate of Control packets may be increased to a level necessary to achieve the detection time requirements for the session. 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, and signalled to the remote end via the State (Sta) - field in outgoing packets. + declared Down. This is signalled 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. + 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. + in the same manner. See section 6.5. If the session goes down, the transmission of Echo packets (if any) ceases, and the transmission of Control packets goes back to the slow rate. 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 state), thus implementing a three-way handshake. A session may be kept administratively down by entering the AdminDown @@ -749,23 +749,23 @@ field only (which means that, among other things, the source address field can change or the interface over which the packets are received can change, but the packets will still be associated with the proper session.) The method of demultiplexing the initial packets (in which Your Discriminator is zero) is application-dependent, and is thus outside the scope of this specification. Note that it is permissible for a system to change its discriminator - during a session (without affecting the session state), since only - that system uses its discriminator for demultiplexing purposes (by - having the other system reflect it back.) The implications on an + during a session without affecting the session state, since only that + system uses its discriminator for demultiplexing purposes (by having + 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. @@ -1842,27 +1842,21 @@ 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 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. + All changes from the previous draft are purely 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 Rights or other rights that might be claimed to @@ -1900,11 +1894,11 @@ 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 January, 2006. + This document expires in April, 2006.