draft-ietf-mpls-ldp-ft-01.txt		draft-ietf-mpls-ldp-ft-02.txt
	MPLS WG Adrian Farrel		MPLS WG Adrian Farrel
	Internet Draft Paul Brittain		Internet Draft Movaz Networks, Inc.
	Document: draft-ietf-mpls-ldp-ft-01.txt Data Connection Ltd		Document: draft-ietf-mpls-ldp-ft-02.txt
	Expiration Date: August 2001		Expiration Date: October 2001 Paul Brittain
			MetaSwitch Ltd
	Philip Matthews		Philip Matthews
	Nortel		Nortel
	Eric Gray		Eric Gray
	Sandburst		Sandburst
	February 2001
			May 2001
	Fault Tolerance for LDP and CR-LDP		Fault Tolerance for LDP and CR-LDP
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026 [1].		all provisions of Section 10 of RFC2026 [1].
	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 2, line 13		skipping to change at page 2, line 13
	The extensions described here are equally applicable to CR-LDP.		The extensions described here are equally applicable to CR-LDP.
	Contents		Contents
	0. Changes from Previous Version...................................3		0. Changes from Previous Version...................................3
	1. Conventions and Terminology used in this document...............3		1. Conventions and Terminology used in this document...............3
	2. Introduction....................................................4		2. Introduction....................................................4
	2.1 Fault Tolerance for MPLS.......................................4		2.1 Fault Tolerance for MPLS.......................................4
	2.2 Issues with LDP and CR-LDP.....................................5		2.2 Issues with LDP and CR-LDP.....................................5
	3. Overview of LDP FT Enhancements.................................6		3. Overview of LDP FT Enhancements.................................6
	3.1 Establishing an FT LDP Session.................................6		3.1 Establishing an FT LDP Session.................................7
	3.1.1 Interoperation with Non-FT LSRs.............................7		3.1.1 Interoperation with Non-FT LSRs.............................7
	3.2 TCP Connection Failure.........................................7		3.2 TCP Connection Failure.........................................7
	3.2.1 Detecting TCP Connection Failures............................7		3.2.1 Detecting TCP Connection Failures............................7
	3.2.2 LDP Processing after Connection Failure......................7		3.2.2 LDP Processing after Connection Failure......................8
	3.3 Data Forwarding During TCP Connection Failure..................8		3.3 Data Forwarding During TCP Connection Failure..................8
	3.4 FT LDP Session Reconnection....................................8		3.4 FT LDP Session Reconnection....................................8
	3.5 Operations on FT Labels........................................9		3.5 Operations on FT Labels........................................9
	3.6 Label Space Depletion and Replenishment........................9		3.6 Label Space Depletion and Replenishment........................9
	4. FT Operations..................................................10		4. FT Operations..................................................10
	4.1 FT LDP Messages...............................................10		4.1 FT LDP Messages...............................................10
	4.1.1 FT Label Messages...........................................10		4.1.1 FT Label Messages...........................................10
	4.1.1.1 Scope of FT Labels........................................10		4.1.1.1 Scope of FT Labels........................................10
	4.1.2 FT Address Messages........................................10		4.1.2 FT Address Messages........................................11
	4.1.3 FT Label Resources Available Notification Messages..........11		4.1.3 FT Label Resources Available Notification Messages..........11
	4.2 FT Operation ACKs.............................................11		4.2 FT Operation ACKs.............................................12
	4.3 Preservation of FT State......................................12		4.3 Preservation of FT State......................................12
	4.4 FT Procedure After TCP Failure................................13		4.4 FT Procedure After TCP Failure................................14
	4.4.1 FT LDP Operations During TCP Failure........................14		4.4.1 FT LDP Operations During TCP Failure........................15
	4.5 FT Procedure After TCP Re-connection..........................15		4.5 FT Procedure After TCP Re-connection..........................16
	4.5.1 Re-Issuing FT Messages......................................15		4.5.1 Re-Issuing FT Messages......................................16
	4.5.2 Interaction with CR-LDP LSP Modification....................16		4.5.2 Interaction with CR-LDP LSP Modification....................17
	5. Changes to Existing Messages...................................16		5. Changes to Existing Messages...................................17
	5.1 LDP Initialization Message....................................16		5.1 LDP Initialization Message....................................17
	5.2 LDP Keepalive Message.........................................16		5.2 LDP Keepalive Message.........................................18
	5.3 All Other LDP Session Messages................................17		5.3 All Other LDP Session Messages................................18
	6. New Fields and Values..........................................17		6. New Fields and Values..........................................18
	6.1 Status Codes..................................................17		6.1 Status Codes..................................................18
	6.2 FT Session TLV................................................18		6.2 FT Session TLV................................................19
	6.3 FT Protection TLV.............................................19		6.3 FT Protection TLV.............................................20
	6.4 FT ACK TLV....................................................21		6.4 FT ACK TLV....................................................22
	7. Example Use....................................................22		7. Example Use....................................................23
	7.1 Session Failure and Recovery..................................23		7.1 Session Failure and Recovery..................................24
	7.2 Temporary Shutdown............................................25		7.2 Temporary Shutdown............................................26
	8. Security Considerations........................................26		8. Security Considerations........................................27
	9. Implementation Notes...........................................27		9. Implementation Notes...........................................28
	9.1 FT Recovery Support on Non-FT LSRs............................27		9.1 FT Recovery Support on Non-FT LSRs............................28
	9.2 ACK generation logic..........................................27		9.2 ACK generation logic..........................................28
	10. Acknowledgements..............................................27		10. Acknowledgements..............................................29
	11. Intellectual Property Consideration...........................28		11. Intellectual Property Consideration...........................29
	12. Full Copyright Statement......................................28		12. Full Copyright Statement......................................29
	13. IANA Considerations...........................................28		13. IANA Considerations...........................................30
	13.1 FT Session TLV...............................................29		13.1 FT Session TLV...............................................30
	13.2 FT Protection TLV............................................29		13.2 FT Protection TLV............................................30
	13.3 FT ACK TLV...................................................29		13.3 FT ACK TLV...................................................31
	13.4 Status Codes.................................................29		13.4 Status Codes.................................................31
	14. Authors' Addresses............................................29		14. Authors' Addresses............................................31
	15. References....................................................30		15. References....................................................31
			0. Changes From Version 1 to Version 2
	0.Changes From Version 0 to Version 1
	This section will be removed from the final version of the draft.
	The following substantive changes have been made since version 0.
	Referenced section numbers apply to version 1 of the draft.
	3.2.1 Add brief note on processes for detecting TCP connection
	Failures
	3.4 Session reconnection must use the same session parameters as were
	in use on the failed session.
	3.6 Add a section on label space depletion and replenishment.		This section to be removed before final publication.
	4.1.3 Describe FT procedures for Label Resources Available		2.2 Add paragraph discussing use of this draft for recovery in non-
	Notification Messages		FT systems.
	4.2 Explain use of "FT Seq Numbers Exhausted" status code.		3.2.2 Clarify selection of FT Reconnect Timeout value.
	4.4 Recommend default value for FT Reconnection Timeout.		3.4 Explain procedure when FT Reconnect flag is 'unexpectedly' set.
	6.2 Define meaning of FT Reconnection Timeout with value 0.		4.1.1.1 Explain re-use of labels from the per platform label space.
	6.3 Describe how to handle a message that describes a FEC that may		4.3 Clarify that the Reconnection Timeout provides an upper limit on
	have wider coverage than a single label.		the preservation of state, but that other events may cause state
			to be released sooner.
	6.3 The sequence number 0x00000000 is invalid under all		4.4.1 Describe behavior if an LDP peer is unwilling or unable to
	circumstances. Sequence numbers wrap from 0xFFFFFFFF to 0x00000001.		queue operations during TCP failure.
	7.1 Correct sequence numbers in example.		4.5 Describe behavior if an LDP peer is unwilling or unable to
			queue operations during TCP failure.
	7.2 Add example for Temporary Shutdown.		8. Text to expose security risks concerned with reuse of labels.
	1. Conventions and Terminology used in this document		1. Conventions and Terminology used in this document
	Definitions of key words and terms applicable to LDP and CR-LDP are		Definitions of key words and terms applicable to LDP and CR-LDP are
	inherited from [2] and [4].		inherited from [2] and [4].
	The term "FT label" is introduced in this document to		The term "FT label" is introduced in this document to
	indicated a label for which fault tolerant operation is used. A		indicated a label for which fault tolerant operation is used. A
	"non-FT label" is not fault tolerant and is handled as specified in		"non-FT label" is not fault tolerant and is handled as specified in
	[2] and [4].		[2] and [4].
	skipping to change at page 4, line 14		skipping to change at page 4, line 14
	2. Introduction		2. Introduction
	High Availability (HA) is typically claimed by equipment vendors		High Availability (HA) is typically claimed by equipment vendors
	when their hardware achieves availability levels of at least 99.999%		when their hardware achieves availability levels of at least 99.999%
	(five 9s). To implement this, the equipment must be capable of		(five 9s). To implement this, the equipment must be capable of
	recovering from local hardware and software failures through a		recovering from local hardware and software failures through a
	process known as fault tolerance (FT).		process known as fault tolerance (FT).
	The usual approach to FT involves provisioning backup copies of		The usual approach to FT involves provisioning backup copies of
	hardware and software. When a primary copy fails, processing is		hardware and/or software. When a primary copy fails, processing is
	switched to the backup copy. This process, called failover, should		switched to the backup copy. This process, called failover, should
	result in minimal disruption to the Data Plane.		result in minimal disruption to the Data Plane.
	In an FT system, backup resources are sometimes provisioned on a		In an FT system, backup resources are sometimes provisioned on a
	one-to-one basis (1:1), sometimes as many-to-one (1:n), and		one-to-one basis (1:1), sometimes as many-to-one (1:n), and
	occasionally as many-to-many (m:n). Whatever backup provisioning is		occasionally as many-to-many (m:n). Whatever backup provisioning is
	made, the system must switch to the backup automatically on failure		made, the system must switch to the backup automatically on failure
	of the primary, and the software and hardware state in the backup		of the primary, and the software and hardware state in the backup
	must be set to replicate the state in the primary at the point		must be set to replicate the state in the primary at the point
	of failure.		of failure.
	skipping to change at page 5, line 54		skipping to change at page 5, line 54
	- preserve existing protocol rules described in [2] and [4] for		- preserve existing protocol rules described in [2] and [4] for
	handling unexpected duplicate messages and for processing		handling unexpected duplicate messages and for processing
	unexpected messages referring to unknown LSPs/labels		unexpected messages referring to unknown LSPs/labels
	- integrate with the LSP modification function described in [5]		- integrate with the LSP modification function described in [5]
	- avoid full state refresh solutions (such as those present in RSVP:		- avoid full state refresh solutions (such as those present in RSVP:
	see [6], [7] and [8]) whether they be full-time, or limited to		see [6], [7] and [8]) whether they be full-time, or limited to
	post-failover recovery.		post-failover recovery.
	Note that this draft concentrates on the preservation of label state		Note that this draft concentrates on the preservation of label state
	for labels exchanged between a pair of adjacent LSRs when the TCP		for labels exchanged between a pair of adjacent LSRs when the TCP
	connection between those LSRs is lost. The is a requirement for		connection between those LSRs is lost. This is a requirement for
	Fault Tolerant operation of LSPs, but a full implementation of end-		Fault Tolerant operation of LSPs, but a full implementation of end-
	to-end protection for LSPs requires that this is combined with other		to-end protection for LSPs requires that this is combined with other
	techniques that are outside the scope of this draft.		techniques that are outside the scope of this draft.
	In particular, this draft does not attempt to describe how to modify		In particular, this draft does not attempt to describe how to modify
	the routing of an LSP or the resources allocated to a label or LSP,		the routing of an LSP or the resources allocated to a label or LSP,
	which is covered by [5]. This draft also does not address how to		which is covered by [5]. This draft also does not address how to
	provide automatic layer 2/3 protection switching for a label or LSP,		provide automatic layer 2/3 protection switching for a label or LSP,
	which is a separate area for study.		which is a separate area for study.
			This specification does not preclude an implementation from
			attempting (or require it to attempt) to use the FT behavior
			described here to recover from a preemptive failure of a connection
			on a non-FT system due to, for example, a partial system crash.
			Note, however, that there are potential issues too numerous to list
			here - not least the likelihood that the same crash will immediately
			occur when processing the restored data.
	3. Overview of LDP FT Enhancements		3. Overview of LDP FT Enhancements
	The LDP FT enhancements consist of the following main elements, which		The LDP FT enhancements consist of the following main elements, which
	are described in more detail in the sections that follow.		are described in more detail in the sections that follow.
	- The presence of an FT Session TLV on the LDP Initialization		- The presence of an FT Session TLV on the LDP Initialization
	message indicates that an LSR supports the LDP FT enhancements on		message indicates that an LSR supports the LDP FT enhancements on
	this session.		this session.
	- An FT Reconnect Flag in the FT Session TLV indicates whether an		- An FT Reconnect Flag in the FT Session TLV indicates whether an
	skipping to change at page 7, line 6		skipping to change at page 7, line 21
	This is done on the LDP Initialization message exchange using a new		This is done on the LDP Initialization message exchange using a new
	FT Session TLV. Presence of this TLV indicates that the peer wants		FT Session TLV. Presence of this TLV indicates that the peer wants
	to support the LDP FT enhancements on this LDP session.		to support the LDP FT enhancements on this LDP session.
	The LDP FT enhancements MUST be supported on an LDP session if both		The LDP FT enhancements MUST be supported on an LDP session if both
	LDP peers include an FT Session TLV on the LDP Initialization		LDP peers include an FT Session TLV on the LDP Initialization
	message.		message.
	If either LDP Peer does not include the FT Session TLV on the LDP		If either LDP Peer does not include the FT Session TLV on the LDP
	Initialization message, the LDP FT enhancements MUST NOT be		Initialization message, the LDP FT enhancements MUST NOT be used
	the receiving LDP peer as a serious protocol error causing the		during this LDP session. Use of LDP FT enhancements by a sending
	session to be torn down.		LDP peer MUST be interpreted by the receiving LDP peer as a serious
			protocol error causing the session to be terminated.
	An LSR MAY present different FT/non-FT behavior on different TCP		An LSR MAY present different FT/non-FT behavior on different TCP
	connections, even if those connections are successive instantiations		connections, even if those connections are successive instantiations
	of the LDP session between the same LDP peers.		of the LDP session between the same LDP peers.
	3.1.1 Interoperation with Non-FT LSRs		3.1.1 Interoperation with Non-FT LSRs
	The FT Session TLV on the LDP Initialization message carries the		The FT Session TLV on the LDP Initialization message carries the
	U-bit. If an LSR does not support the LDP FT enhancements, it will		U-bit. If an LSR does not support the LDP FT enhancements, it will
	ignore this TLV. Since such partners also do not include the FT		ignore this TLV. Since such partners also do not include the FT
	skipping to change at page 8, line 15		skipping to change at page 8, line 26
	If the LDP FT enhancements are in use on an LDP session, both LDP		If the LDP FT enhancements are in use on an LDP session, both LDP
	peers SHOULD preserve state information and resources associated with		peers SHOULD preserve state information and resources associated with
	FT labels exchanged on the LDP session. Both LDP peers SHOULD use a		FT labels exchanged on the LDP session. Both LDP peers SHOULD use a
	timer to release the preserved state information and resources		timer to release the preserved state information and resources
	associated with FT-labels if the TCP connection is not restored		associated with FT-labels if the TCP connection is not restored
	within a reasonable period. The behavior when this timer expires is		within a reasonable period. The behavior when this timer expires is
	equivalent to the LDP session failure behavior described in [4].		equivalent to the LDP session failure behavior described in [4].
	The FT Reconnection Timeout each LDP peer intends to apply to the LDP		The FT Reconnection Timeout each LDP peer intends to apply to the LDP
	session is carried in the FT Session TLV on the LDP Initialization		session is carried in the FT Session TLV on the LDP Initialization
	messages. It is RECOMMENDED that both LDP peers use the lower		messages. Both LDP peers MUST use the value that corresponds to the
	timeout value from the LDP Initialization exchange when setting their		lesser timeout interval of the two proposed timeout values from the
	reconnection timer after a TCP connection failure.		LDP Initialization exchange, where a value of zero is treated as
			positive infinity.
	3.3 Data Forwarding During TCP Connection Failure		3.3 Data Forwarding During TCP Connection Failure
	An LSR that implements the LDP FT enhancements SHOULD preserve the		An LSR that implements the LDP FT enhancements SHOULD preserve the
	programming of the switching hardware across a failover. This		programming of the switching hardware across a failover. This
	ensures that data forwarding is unaffected by the state of the TCP		ensures that data forwarding is unaffected by the state of the TCP
	connection between LSRs.		connection between LSRs.
	It is an integral part of FT failover processing in some hardware		It is an integral part of FT failover processing in some hardware
	configurations that some data packets might be lost. If data loss is		configurations that some data packets might be lost. If data loss is
	skipping to change at page 9, line 20		skipping to change at page 9, line 32
	session before the failure. If an LDP peer notices that the		session before the failure. If an LDP peer notices that the
	parameters have been changed by the other peer it SHOULD send a		parameters have been changed by the other peer it SHOULD send a
	Notification message with the 'FT Session parameters changed' status		Notification message with the 'FT Session parameters changed' status
	code.		code.
	If both LDP peers set the FT Reconnect Flag to 1, both LDP peers MUST		If both LDP peers set the FT Reconnect Flag to 1, both LDP peers MUST
	use the FT label operation procedures indicated in this draft to		use the FT label operation procedures indicated in this draft to
	complete any label operations on FT labels that were interrupted by		complete any label operations on FT labels that were interrupted by
	the LDP session failure.		the LDP session failure.
			If an LDP peer receives an LDP Initialization message with the FT
			Reconnect Flag set before it sends its own Initialization message,
			but has retained no information about the previous version of the
			session, it MUST respond with an Initialization message with the FT
			Reconnect Flag clear. If an LDP peer receives an LDP Initialization
			message with the FT Reconnect Flag set in response to an
			Initialization message that it has sent with the FT Reconnect Flag
			clear it MUST act as if no state was retained by either peer on the
			session.
	3.5 Operations on FT Labels		3.5 Operations on FT Labels
	Label operations on FT labels are made Fault Tolerant by providing		Label operations on FT labels are made Fault Tolerant by providing
	acknowledgement of all LDP messages that affect FT labels.		acknowledgement of all LDP messages that affect FT labels.
	Acknowledgements are achieved by means of sequence numbers on these		Acknowledgements are achieved by means of sequence numbers on these
	LDP messages.		LDP messages.
	The message exchanges used to achieve acknowledgement of label		The message exchanges used to achieve acknowledgement of label
	operations and the procedures used to complete interrupted label		operations and the procedures used to complete interrupted label
	operations are detailed in the section "FT Operations".		operations are detailed in the section "FT Operations".
	skipping to change at page 10, line 36		skipping to change at page 11, line 5
	4.1.1.1 Scope of FT Labels		4.1.1.1 Scope of FT Labels
	The scope of the FT/non-FT status of a label is limited to the		The scope of the FT/non-FT status of a label is limited to the
	LDP message exchanges between a pair of LDP peers.		LDP message exchanges between a pair of LDP peers.
	In Ordered Control, when the message is forwarded downstream or		In Ordered Control, when the message is forwarded downstream or
	upstream, the TLV may be present or absent according to the		upstream, the TLV may be present or absent according to the
	requirements of the LSR sending the message.		requirements of the LSR sending the message.
			If a platform-wide label space is used for FT labels, an FT label
			value MUST NOT be reused until all LDP FT peers to which the label
			was passed have acknowledged the withdrawal of the FT label, either
			by an explicit LABEL WITHDRAW/LABEL RELEASE exchange or implicitly if
			the LDP session is reconnected after failure but without the FT
			Reconnect Flag set. In the event that a session is not re-
			established within the Reconnection Timeout, a label MAY become
			available for re-use if it is not still in use on some other
			session.
	4.1.2 FT Address Messages		4.1.2 FT Address Messages
	If an LDP session uses the LDP FT enhancements, both LDP peers		If an LDP session uses the LDP FT enhancements, both LDP peers
	MUST secure Address and Address Withdraw messages using FT Operation		MUST secure Address and Address Withdraw messages using FT Operation
	ACKs, as described below. This avoids any ambiguity over whether		ACKs, as described below. This avoids any ambiguity over whether
	an Address is still valid after the LDP session is reconnected.		an Address is still valid after the LDP session is reconnected.
	If an LSR determines that an Address message that it sent on a		If an LSR determines that an Address message that it sent on a
	previous instantiation of a recovered LDP session is no longer valid,		previous instantiation of a recovered LDP session is no longer valid,
	it MUST explicitly issue an Address Withdraw for that address when		it MUST explicitly issue an Address Withdraw for that address when
	skipping to change at page 11, line 14		skipping to change at page 11, line 42
	4.1.3 FT Label Resources Available Notification Messages		4.1.3 FT Label Resources Available Notification Messages
	In LDP, it is possible that a downstream LSR may not have labels		In LDP, it is possible that a downstream LSR may not have labels
	available to respond to a Label Request. In this case, as specified		available to respond to a Label Request. In this case, as specified
	in RFC3036, the downstream LSR must respond with a Notification - No		in RFC3036, the downstream LSR must respond with a Notification - No
	Label Resources message. The upstream LSR then suspends asking for		Label Resources message. The upstream LSR then suspends asking for
	new labels until it receives a Notification - Label Resources		new labels until it receives a Notification - Label Resources
	Available message from the downstream LSR.		Available message from the downstream LSR.
	When the FT extensions are used on a sesssion:		When the FT extensions are used on a session:
	1. The downstream LSR must preserve the label availability state		1. The downstream LSR must preserve the label availability state
	across a failover so that it remembers to send Notification -		across a failover so that it remembers to send Notification -
	Label Resources Available when the resources become available.		Label Resources Available when the resources become available.
	2. The upstream LSR must recall the label availability state across		2. The upstream LSR must recall the label availability state across
	failover so that it can optimize not sending Label Requests when		failover so that it can optimize not sending Label Requests when
	it recovers.		it recovers.
	3. The downstream LSR must use sequence numbers on Notification -		3. The downstream LSR must use sequence numbers on Notification -
	Label Resources Available so that it can check that LSR A has		Label Resources Available so that it can check that LSR A has
	received the message and clear its secured state, or resend the		received the message and clear its secured state, or resend the
	message if LSR A recovers without having received it.		message if LSR A recovers without having received it.
	skipping to change at page 13, line 5		skipping to change at page 13, line 36
	operation if the TCP connection is interrupted.		operation if the TCP connection is interrupted.
	- A downstream LDP peer MUST release the resources and state		- A downstream LDP peer MUST release the resources and state
	information associated with an FT label when it receives an		information associated with an FT label when it receives an
	acknowledgement to a Label Withdraw message for the label.		acknowledgement to a Label Withdraw message for the label.
	- When the FT Reconnection Timeout expires, an LSR SHOULD release		- When the FT Reconnection Timeout expires, an LSR SHOULD release
	all state information and resources from previous instantiations		all state information and resources from previous instantiations
	of the (permanently) failed LDP session.		of the (permanently) failed LDP session.
			- Either LDP peer MAY elect to release state information based on
			its internal knowledge of the loss of integrity of the state
			information or an inability to pend (or queue) LDP operations
			(as described in section 4.4.1) during a TCP failure. That is,
			the peer is not required to wait for the duration of the FT
			Reconnection Timeout before releasing state; the timeout provides
			an upper limit on the persistence of state. However, In the event
			that a peer releases state before the expiration of the
			Reconnection Timeout it MUST NOT re-use any label that was in use
			on the session until the Reconnection Timeout has expired.
	- When an LSR receives a Status TLV with the E-bit set in		- When an LSR receives a Status TLV with the E-bit set in
	the status code, which causes it to close the TCP connection, the		the status code, which causes it to close the TCP connection, the
	LSR MUST release all state information and resources associated		LSR MUST release all state information and resources associated
	with the session. This behavior is mandated because it is		with the session. This behavior is mandated because it is
	impossible for the LSR to predict the precise state and future		impossible for the LSR to predict the precise state and future
	behavior of the partner LSR that set the E-bit without knowledge		behavior of the partner LSR that set the E-bit without knowledge
	of the implementation of that partner LSR.		of the implementation of that partner LSR.
	Note that the "Temporary Shutdown" status code does not have the		Note that the "Temporary Shutdown" status code does not have the
	E-bit set, and MAY be used during maintenance or upgrade		E-bit set, and MAY be used during maintenance or upgrade
	skipping to change at page 14, line 31		skipping to change at page 15, line 21
	preserved for the failed TCP connection, so it is important that the		preserved for the failed TCP connection, so it is important that the
	state changes are passed to the LDP peer when the TCP connection is		state changes are passed to the LDP peer when the TCP connection is
	restored.		restored.
	If an LSR determines that it needs to issue a new FT LDP operation to		If an LSR determines that it needs to issue a new FT LDP operation to
	an LDP peer to which the TCP connection is currently failed, it MUST		an LDP peer to which the TCP connection is currently failed, it MUST
	pend the operation (e.g. on a queue) and complete that operation		pend the operation (e.g. on a queue) and complete that operation
	with the LDP peer when the TCP connection is restored, unless the		with the LDP peer when the TCP connection is restored, unless the
	label operation is overridden by a subsequent additional operation		label operation is overridden by a subsequent additional operation
	during the TCP connection failure (see section "FT Procedure After		during the TCP connection failure (see section "FT Procedure After
	TCP Re-connection")		TCP Re-connection").
			If, during TCP Failure, an LSR determines that it cannot pend an
			operation which it cannot simply fail (for example a Label Withdraw,
			Release, or Abort operation), it MUST NOT attempt to re-establish
			the previous LDP session. The LSR MUST behave as if the Reconnection
			Timer expired and release all state information with respect to the
			LDP peer. An LSR may be unable (or unwilling) to pend operations;
			for instance, if a major routing transition occurred while TCP was
			inoperable between LDP peers it might result in excessively large
			numbers of FT LDP Operations. An LSR that releases state before the
			expiration of the Reconnection Timeout MUST NOT re-use any label that
			was in use on the session until the Reconnection Timeout has expired.
	In ordered operation, received FT LDP operations that cannot be		In ordered operation, received FT LDP operations that cannot be
	correctly forwarded because of a TCP connection failure MAY be		correctly forwarded because of a TCP connection failure MAY be
	processed immediately (provided sufficient state is kept to forward		processed immediately (provided sufficient state is kept to forward
	the label operation) or pended for processing when the onward TCP		the label operation) or pended for processing when the onward TCP
	connection is restored and the operation can be correctly forwarded		connection is restored and the operation can be correctly forwarded
	upstream or downstream. Operations on existing FT labels SHOULD NOT		upstream or downstream. Operations on existing FT labels SHOULD NOT
	be failed during TCP session failure.		be failed during TCP session failure.
	It is RECOMMENDED that Label Request operations for new FT labels are		It is RECOMMENDED that Label Request operations for new FT labels are
	skipping to change at page 15, line 12		skipping to change at page 16, line 12
	Label Requests for new non-FT labels MUST be rejected during TCP		Label Requests for new non-FT labels MUST be rejected during TCP
	connection failure, as specified in [2] and [4].		connection failure, as specified in [2] and [4].
	4.5 FT Procedure After TCP Re-connection		4.5 FT Procedure After TCP Re-connection
	The FT operation handshaking described above means that all state		The FT operation handshaking described above means that all state
	changes for FT labels and Address messages are confirmed or		changes for FT labels and Address messages are confirmed or
	reproducible at each LSR.		reproducible at each LSR.
	If the TCP connection between LDP peers fails but is re-connected		If the TCP connection between LDP peers fails but is re-connected
	within the FT Reconnection Timeout, both LDP peers on the connection		within the FT Reconnection Timeout, and both LSRs have indicated
	MUST complete any label operations for FT labels that were		they will be re-establishing the previous LDP session, both LDP
	interrupted by the failure and re-connection of the TCP connection.		peers on the connection MUST complete any label operations for FT
	Label operation are completed using the procedure described below.		labels that were interrupted by the failure and re-connection of
			the TCP connection.
			The procedures for FT Reconnection Timeout MAY have been invoked as
			a result of either LDP peer being unable (or unwilling) to pend
			operations which occurred during the TCP Failure (as described in
			section 4.4.1).
			If, for any reason, an LSR has been unable to pend operations with
			respect to an LDP peer, as described in section 4.4.1, the LSR MUST
			set the FT Reconnect Flag to 0 on re-connection to that LDP peer
			indicating that no FT state has been preserved.
			Label operations are completed using the procedure described below.
	4.5.1 Re-Issuing FT Messages		4.5.1 Re-Issuing FT Messages
	On restoration of the TCP connection between LDP peers, any FT		On restoration of the TCP connection between LDP peers, any FT
	LDP messages that were lost because of the TCP connection		LDP messages that were lost because of the TCP connection
	failure are re-issued. The LDP peer that receives a re-issued message		failure are re-issued. The LDP peer that receives a re-issued message
	processes the message as if received for the first time.		processes the message as if received for the first time.
	"Net-zero" combinations of messages need not be re-issued after		"Net-zero" combinations of messages need not be re-issued after
	re-establishment of the TCP connection between LDP peers. This leads		re-establishment of the TCP connection between LDP peers. This leads
	skipping to change at page 27, line 5		skipping to change at page 28, line 5
	All of these attacks may be countered by use of an authentication		All of these attacks may be countered by use of an authentication
	scheme between LDP peers, such as the MD5-based scheme outlined in		scheme between LDP peers, such as the MD5-based scheme outlined in
	[4].		[4].
	Alternative authentication schemes for LDP peers are outside the		Alternative authentication schemes for LDP peers are outside the
	scope of this draft, but could be deployed to provide enhanced		scope of this draft, but could be deployed to provide enhanced
	security to implementations of LDP, CR-LDP and the LDP FT		security to implementations of LDP, CR-LDP and the LDP FT
	enhancements.		enhancements.
			As with LDP and CR-LDP, a security issue may exist if an LDP
			implementation continues to use labels after expiration of the
			session that first caused them to be used. This may arise if the
			upstream LSR detects the session failure after the downstream LSR
			has released and re-used the label. The problem is most obvious
			with the platform-wide label space and could result in mis-routing
			of data to other than intended destinations and it is conceivable
			that these behaviors may be deliberately exploited to either obtain
			services without authorization or to deny services to others.
			In this draft, the validity of the session may be extended by the FT
			Reconnection Timeout, and the session may be re-established in this
			period. After the expiry of the Reconnection Timeout the session
			must be considered to have failed and the same security issue applies
			as described above.
			However, the downstream LSR may declare the session as failed before
			the expiration of its Reconnection Timeout. This increases the
			period during which the downstream LSR might reallocate the label
			while the upstream LSR continues to transmit data using the old usage
			of the label. To reduce this issue, this draft requires that labels
			are not re-used until the Reconnection Timeout has expired.
			A further issue might apply if labels were re-used prior to the
			expiration of the FT Reconnection Timeout, but this is forbidden by
			this draft.
	9. Implementation Notes		9. Implementation Notes
	9.1 FT Recovery Support on Non-FT LSRs		9.1 FT Recovery Support on Non-FT LSRs
	In order to take full advantage of the FT capabilities of LSRs in the		In order to take full advantage of the FT capabilities of LSRs in the
	network, it may be that an LSR that does not itself contain the		network, it may be that an LSR that does not itself contain the
	ability to recover from local hardware or software faults still needs		ability to recover from local hardware or software faults still needs
	to support the LDP FT enhancements described in this draft.		to support the LDP FT enhancements described in this draft.
	Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant		Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant
	skipping to change at page 27, line 47		skipping to change at page 29, line 24
	This implementation combines the bandwidth benefits of accumulating		This implementation combines the bandwidth benefits of accumulating
	ACKs while still providing timely ACKs.		ACKs while still providing timely ACKs.
	10. Acknowledgments		10. Acknowledgments
	The work in this draft is based on the LDP and CR-LDP ideas		The work in this draft is based on the LDP and CR-LDP ideas
	expressed by the authors of [2] and [4].		expressed by the authors of [2] and [4].
	The ACK scheme used in this draft was inspired by the proposal by		The ACK scheme used in this draft was inspired by the proposal by
	David Ward and John Scudder for restarting BGP sessions [9].		David Ward and John Scudder for restarting BGP sessions now included
			in [9].
	The authors would also like to acknowledge the careful review and		The authors would also like to acknowledge the careful review and
	comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer,		comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer,
	Peter Ashwood-Smith, Bob Thomas, S.Manikantan, Adam Sheppard and		Peter Ashwood-Smith, Bob Thomas, S.Manikantan, Adam Sheppard and
	Alan Davey.		Alan Davey.
	11. Intellectual Property Consideration		11. Intellectual Property Consideration
	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
	skipping to change at page 30, line 8		skipping to change at page 31, line 32
	Hence, the numeric status code values assigned for this draft should		Hence, the numeric status code values assigned for this draft should
	simply be the next available values at the time of writing and may be		simply be the next available values at the time of writing and may be
	substituted for other numeric values.		substituted for other numeric values.
	See section "Status Codes" for details of the status codes defined in		See section "Status Codes" for details of the status codes defined in
	this draft.		this draft.
	14. Authors' Addresses		14. Authors' Addresses
	Adrian Farrel (editor) Paul Brittain		Adrian Farrel (editor) Paul Brittain
	Data Connection Ltd. Data Connection Ltd.		Movaz Networks, Inc. Data Connection Ltd.
	Windsor House Windsor House		7926 Jones Branch Drive, Suite 615 Windsor House, Pepper Street,
	Pepper Street Pepper Street		McLean, VA 22102 Chester, Cheshire
	Chester Chester		Voice: +1 703-847-1719 CH1 1DF, UK
	Cheshire Cheshire		Email: afarrel@movaz.com Phone: +44-(0)-1244-313440
	CH1 1DF CH1 1DF		Fax: +44-(0)-1244-312422
	UK UK		Email: pjb@dataconnection.com
	Phone: +44-(0)-1244-313440 Phone: +44-(0)-1244-313440
	Fax: +44-(0)-1244-312422 Fax: +44-(0)-1244-312422
	Email: af@dataconnection.com Email: pjb@dataconnection.com
	Philip Matthews Eric Gray		Philip Matthews Eric Gray
	Nortel Networks Corp. Sandburst Corporation		Nortel Networks Corp. Sandburst Corporation
	P.O. Box 3511 Station C, 600 Federal Street		P.O. Box 3511 Station C, 600 Federal Street
	Ottawa, ON K1Y 4H7 Andover, MA 01810		Ottawa, ON K1Y 4H7 Andover, MA 01810
	Canada Phone: +1 978-689-1600		Canada Phone: +1 978-689-1600
	Phone: +1 613-768-3262 eric.gray@sandburst.com		Phone: +1 613-768-3262 eric.gray@sandburst.com
	philipma@nortelnetworks.com		philipma@nortelnetworks.com
	15. References		15. References
	1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP		1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
	9, RFC 2026, October 1996.		9, RFC 2026, October 1996.
	2 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP,		2 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP,
	draft-ietf-mpls-cr-ldp-04.txt, July 2000, (work in progress).		draft-ietf-mpls-cr-ldp-05.txt, February 2001, (work in progress).
	3 Bradner, S., "Key words for use in RFCs to Indicate Requirement		3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001.		4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001.
	5 Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls-		5 Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls-
	crlsp-modify-02.txt, October 2000 (work in progress).		crlsp-modify-03.txt, March 2001 (work in progress).
	6 Braden, R., et al., Resource ReSerVation Protocol (RSVP) --		6 Braden, R., et al., Resource ReSerVation Protocol (RSVP) --
	Version 1, Functional Specification, RFC 2205, September 1997.		Version 1, Functional Specification, RFC 2205, September 1997.
	7 Berger, L., et al., RSVP Refresh Reduction Extensions, draft-		7 Berger, L., et al., RSVP Refresh Reduction Extensions, draft-
	ietf-rsvp-refresh-reduct-05.txt, June 2000 (work in progress).		ietf-rsvp-refresh-reduct-05.txt, June 2000 (work in progress).
	8 Swallow, G., et al,. Extensions to RSVP for LSP Tunnels, draft-		8 Swallow, G., et al,. Extensions to RSVP for LSP Tunnels, draft-
	ietf-mpls-rsvp-lsp-tunnel-07.txt, August 2000 (work in progress).		ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2000 (work in
			progress).
	9 Ward, D, et al., BGP Notification Cease: I'll Be Back,		9 Ramachandra, S., et al., Graceful Restart Mechanism for BGP,
	draft-ward-bgp4-ibb-00.txt, June 1999 (work in progress)		draft-ietf-idr-restart-00.txt, December 2000 (work in progress)
	10 Stewart, R, et al., Stream Control Transmission Protocol,		10 Stewart, R., et al., Stream Control Transmission Protocol,
	RFC 2906, October 2000.		RFC 2906, October 2000.
			11 Moy, J., Hitless OSPF Restart, draft-ietf-ospf-hitless-restart-
			00.txt, February 2001 (work in progress)
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/