draft-ietf-bfd-base-03.txt		draft-ietf-bfd-base-04.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: January, 2006 July, 2005		Expires: April, 2006 October, 2005
	Bidirectional Forwarding Detection		Bidirectional Forwarding Detection
	draft-ietf-bfd-base-03.txt		draft-ietf-bfd-base-04.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 3, line 22		skipping to change at page 3, line 22
	IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 42		IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 42
	Normative References . . . . . . . . . . . . . . . . . . . . . 42		Normative References . . . . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42
	Changes from the previous draft . . . . . . . . . . . . . . . . 43		Changes from the previous draft . . . . . . . . . . . . . . . . 43
	IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Detection can
	detection can come fairly quickly in certain circumstances when data		come fairly quickly in certain circumstances when data link hardware
	link hardware comes into play (such as SONET alarms.) However, there		comes into play (such as SONET alarms.) However, there are media
	are media that do not provide this kind of signaling (such as		that do not provide this kind of signaling (such as Ethernet), and
	Ethernet), and some media may not detect certain kinds of failures in		some media may not detect certain kinds of failures in the path, for
	the path, for example, failing interfaces or forwarding engine		example, failing interfaces or forwarding engine components.
	components.
	Networks use relatively slow "Hello" mechanisms, usually in routing		Networks use relatively slow "Hello" mechanisms, usually in routing
	protocols, to detect failures when there is no hardware signaling to		protocols, to detect failures when there is no hardware signaling to
	help out. The time to detect failures ("detection times") available		help out. The time to detect failures ("detection times") available
	in the existing protocols are no better than a second, which is far		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		too long for some applications and represents a great deal of lost
	data at gigabit rates. Furthermore, routing protocol Hellos are of		data at gigabit rates. Furthermore, routing protocol Hellos are of
	no help when those routing protocols are not in use, and the		no help when those routing protocols are not in use, and the
	semantics of detection are subtly different--they detect a failure in		semantics of detection are subtly different--they detect a failure in
	the path between the two routing protocol engines.		the path between the two routing protocol engines.
	skipping to change at page 4, line 6		skipping to change at page 4, line 4
	of failures in the path between adjacent forwarding engines,		of failures in the path between adjacent forwarding engines,
	including the interfaces, data link(s), and to the extent possible		including the interfaces, data link(s), and to the extent possible
	the forwarding engines themselves.		the forwarding engines themselves.
	An additional goal is to provide a single mechanism that can be used		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		for liveness detection over any media, at any protocol layer, with a
	wide range of detection times and overhead, to avoid a proliferation		wide range of detection times and overhead, to avoid a proliferation
	of different methods.		of different methods.
	This document specifies the details of the base protocol. The use of		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.		separate series of application documents. These issues are so noted.
	Note that many of the exact mechanisms are implementation dependent		Note that many of the exact mechanisms are implementation dependent
	and will not affect interoperability, and are thus outside the scope		and will not affect interoperability, and are thus outside the scope
	of this specification. Those issues are so noted.		of this specification. Those issues are so noted.
	2. Design		2. Design
	BFD is designed to detect failures in communication with a forwarding		BFD is designed to detect failures in communication with a forwarding
	plane next hop. It is intended to be implemented in some component		plane next hop. It is intended to be implemented in some component
	of the forwarding engine of a system, in cases where the forwarding		of the forwarding engine of a system, in cases where the forwarding
	and control engines are separated. This not only binds the protocol		and control engines are separated. This not only binds the protocol
	more to the forwarding plane, but decouples the protocol from the		more to the forwarding plane, but decouples the protocol from the
	fate of the routing protocol engine (making it useful in concert with		fate of the routing protocol engine, making it useful in concert with
	various "graceful restart" mechanisms for those protocols.) BFD may		various "graceful restart" mechanisms for those protocols. BFD may
	also be implemented in the control engine, though doing so may		also be implemented in the control engine, though doing so may
	preclude the detection of some kinds of failures.		preclude the detection of some kinds of failures.
	BFD operates on top of any data protocol being forwarded between two		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		systems. It is always run in a unicast, point-to-point mode. BFD
	packets are carried as the payload of whatever encapsulating protocol		packets are carried as the payload of whatever encapsulating protocol
	is appropriate for the medium and network. BFD may be running at		is appropriate for the medium and network. BFD may be running at
	multiple layers in a system. The context of the operation of any		multiple layers in a system. The context of the operation of any
	particular BFD session is bound to its encapsulation.		particular BFD session is bound to its encapsulation.
	skipping to change at page 5, line 17		skipping to change at page 5, line 17
	BFD is a simple hello protocol that in many respects is similar to		BFD is a simple hello protocol that in many respects is similar to
	the detection components of well-known routing protocols. A pair of		the detection components of well-known routing protocols. A pair of
	systems transmit BFD packets periodically over each path between the		systems transmit BFD packets periodically over each path between the
	two systems, and if a system stops receiving BFD packets for long		two systems, and if a system stops receiving BFD packets for long
	enough, some component in that particular bidirectional path to the		enough, some component in that particular bidirectional path to the
	neighboring system is assumed to have failed. Under some conditions,		neighboring system is assumed to have failed. Under some conditions,
	systems may negotiate to not send periodic BFD packets in order to		systems may negotiate to not send periodic BFD packets in order to
	reduce overhead.		reduce overhead.
	A path is only declared to be operational when two-way communication		A path is only declared to be operational when two-way communication
	has been established between systems (though this does not preclude		has been established between systems, though this does not preclude
	the use of unidirectional links.)		the use of unidirectional links.
	A separate BFD session is created for each communications path and		A separate BFD session is created for each communications path and
	data protocol in use between two systems.		data protocol in use between two systems.
	Each system estimates how quickly it can send and receive BFD packets		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		in order to come to an agreement with its neighbor about how rapidly
	detection of failure will take place. These estimates can be		detection of failure will take place. These estimates can be
	modified in real time in order to adapt to unusual situations. This		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		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		system to be able to more rapidly detect failures between the fast
	skipping to change at page 6, line 7		skipping to change at page 6, line 7
	additional function that can be used in combination with the two		additional function that can be used in combination with the two
	modes.		modes.
	The primary mode is known as Asynchronous mode. In this mode, the		The primary mode is known as Asynchronous mode. In this mode, the
	systems periodically send BFD Control packets to one another, and if		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		a number of those packets in a row are not received by the other
	system, the session is declared to be down.		system, the session is declared to be down.
	The second mode is known as Demand mode. In this mode, it is assumed		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		that each system has an independent way of verifying that it has
	connectivity to the other system, so once a BFD session is		connectivity to the other system. Once a BFD session is established,
	established, the systems stop sending BFD Control packets, except		the systems stop sending BFD Control packets, except when either
	when either system feels the need to verify connectivity explicitly,		system feels the need to verify connectivity explicitly, in which
	in which case a short sequence of BFD Control packets is sent, and		case a short sequence of BFD Control packets is sent, and then the
	then the protocol quiesces.		protocol quiesces.
	An adjunct to both modes is the Echo function. When the Echo		An adjunct to both modes is the Echo function. When the Echo
	function is active, a stream of BFD Echo packets is transmitted in		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		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		forwarding path. If a number of packets of the echoed data stream
	stream are not received, the session is declared to be down. The		are not received, the session is declared to be down. The Echo
	Echo function may be used with either Asynchronous or Demand modes.		function may be used with either Asynchronous or Demand modes. Since
	Since the Echo function is handling the task of detection, the rate		the Echo function is handling the task of detection, the rate of
	of periodic transmission of Control packets may be reduced (in the		periodic transmission of Control packets may be reduced (in the case
	case of Asynchronous mode) or eliminated completely (in the case of		of Asynchronous mode) or eliminated completely (in the case of Demand
	Demand mode.)		mode.)
	Pure asynchronous mode is advantageous in that it requires half as		Pure asynchronous mode is advantageous in that it requires half as
	many packets to achieve a particular detection time as does the Echo		many packets to achieve a particular detection time as does the Echo
	function. It is also used when the Echo function cannot be supported		function. It is also used when the Echo function cannot be supported
	for some reason.		for some reason.
	The Echo function has the advantage of truly testing only the		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		jitter and thus allow more aggressive detection times, as well as
	potentially detecting some classes of failure that might not		potentially detecting some classes of failure that might not
	otherwise be detected.		otherwise be detected.
	The Echo function may be enabled individually in each direction. It		The Echo function may be enabled individually in each direction. It
	is enabled in a particular direction only when the system that loops		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		the Echo packets back signals that it will allow it, and when the
	system that sends the Echo packets decides it wishes to.		system that sends the Echo packets decides it wishes to.
	Demand mode is useful in situations where the overhead of a periodic		Demand mode is useful in situations where the overhead of a periodic
	skipping to change at page 7, line 10		skipping to change at page 7, line 10
	detection times are essentially driven by the heuristics of the		detection times are essentially driven by the heuristics of the
	system implementation and are not known to the BFD protocol. Demand		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		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.		than the desired detection time. See section 6.5 for more details.
	4. BFD Control Packet Format		4. BFD Control Packet Format
	4.1. Generic BFD Control Packet Format		4.1. Generic BFD Control Packet Format
	BFD Control packets are sent in an encapsulation appropriate to the		BFD Control packets are sent in an encapsulation appropriate to the
	environment, which is outside of the scope of this document. See the		environment. The specific encapsulation is outside of the scope of
	appropriate application document for encapsulation details.		this document. See the appropriate application document for
			encapsulation details.
	The BFD Control packet has a Mandatory Section and an optional		The BFD Control packet has a Mandatory Section and an optional
	Authentication Section. The format of the Authentication Section, if		Authentication Section. The format of the Authentication Section, if
	present, is dependent on the type of authentication in use.		present, is dependent on the type of authentication in use.
	The Mandatory Section of a BFD Control packet has the following		The Mandatory Section of a BFD Control packet has the following
	format:		format:
	0 1 2 3		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		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
	skipping to change at page 14, line 26		skipping to change at page 14, line 26
	Auth Key/Checksum		Auth Key/Checksum
	This field carries the 20 byte SHA1 checksum for the packet. When		This field carries the 20 byte SHA1 checksum for the packet. When
	the checksum is calculated, the shared SHA1 key is stored in this		the checksum is calculated, the shared SHA1 key is stored in this
	field. (See section 6.6.4 for details.)		field. (See section 6.6.4 for details.)
	5. BFD Echo Packet Format		5. BFD Echo Packet Format
	BFD Echo packets are sent in an encapsulation appropriate to the		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.		specifics of particular environments.
	The payload of a BFD Echo packet is a local matter, since only the		The payload of a BFD Echo packet is a local matter, since only the
	sending system ever processes the content. The only requirement is		sending system ever processes the content. The only requirement is
	that sufficient information is included to demultiplex the received		that sufficient information is included to demultiplex the received
	packet to the correct BFD session after it is looped back to the		packet to the correct BFD session after it is looped back to the
	sender. The contents are otherwise outside the scope of this		sender. The contents are otherwise outside the scope of this
	specification.		specification.
	6. Elements of Procedure		6. Elements of Procedure
	skipping to change at page 15, line 33		skipping to change at page 15, line 33
	has received any BFD packets for that session. A system taking the		has received any BFD packets for that session. A system taking the
	Passive role MUST NOT begin sending BFD packets for a particular		Passive role MUST NOT begin sending BFD packets for a particular
	session until it has received a BFD packet for that session, and thus		session until it has received a BFD packet for that session, and thus
	has learned the remote system's discriminator value. At least one		has learned the remote system's discriminator value. At least one
	system MUST take the Active role (possibly both.) The role that a		system MUST take the Active role (possibly both.) The role that a
	system takes is specific to the application of BFD, and is outside		system takes is specific to the application of BFD, and is outside
	the scope of this specification.		the scope of this specification.
	A session begins with the periodic, slow transmission of BFD Control		A session begins with the periodic, slow transmission of BFD Control
	packets. When bidirectional communication is achieved, the BFD		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		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		function if it desires to and the other system signals that it will
	allow it. The rate of transmission of Control packets is typically		allow it. The rate of transmission of Control packets is typically
	kept low when the Echo function is active.		kept low when the Echo function is active.
	If the Echo function is not active, the transmission rate of Control		If the Echo function is not active, the transmission rate of Control
	packets may be increased to a level necessary to achieve the		packets may be increased to a level necessary to achieve the
	detection time requirements for the session.		detection time requirements for the session.
	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, and signalled to the remote end via the State (Sta)		declared Down. This is signalled to the remote end via the State
	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.		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.		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)
	ceases, and the transmission of Control packets goes back to the slow		ceases, and the transmission of Control packets goes back to the slow
	rate.		rate.
	Once a session has been declared down, it cannot come back up until		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		the remote end first signals that it is down (by leaving the Up
	state), thus implementing a three-way handshake.		state), thus implementing a three-way handshake.
	A session may be kept administratively down by entering the AdminDown		A session may be kept administratively down by entering the AdminDown
	skipping to change at page 18, line 29		skipping to change at page 18, line 29
	field only (which means that, among other things, the source address		field only (which means that, among other things, the source address
	field can change or the interface over which the packets are received		field can change or the interface over which the packets are received
	can change, but the packets will still be associated with the proper		can change, but the packets will still be associated with the proper
	session.)		session.)
	The method of demultiplexing the initial packets (in which Your		The method of demultiplexing the initial packets (in which Your
	Discriminator is zero) is application-dependent, and is thus outside		Discriminator is zero) is application-dependent, and is thus outside
	the scope of this specification.		the scope of this specification.
	Note that it is permissible for a system to change its discriminator		Note that it is permissible for a system to change its discriminator
	during a session (without affecting the session state), since only		during a session without affecting the session state, since only that
	that system uses its discriminator for demultiplexing purposes (by		system uses its discriminator for demultiplexing purposes (by having
	having 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 signalled to the system looping them back.
	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
	The primary technical change was the addition of a suggested (non-		All changes from the previous draft are purely editorial.
	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		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 44, line 26		skipping to change at page 44, line 13
	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 January, 2006.		This document expires in April, 2006.
End of changes. 18 change blocks.
	45 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/