draft-ietf-mpls-ldp-ft-00.txt		draft-ietf-mpls-ldp-ft-01.txt
	MPLS WG Adrian Farrel		MPLS WG Adrian Farrel
	Internet Draft Paul Brittain		Internet Draft Paul Brittain
	Document: draft-ietf-mpls-ldp-ft-00.txt Data Connection Ltd		Document: draft-ietf-mpls-ldp-ft-01.txt Data Connection Ltd
	Expiration Date: March 2001		Expiration Date: August 2001
	Philip Matthews		Philip Matthews
	Nortel		Nortel
	Eric Gray		Eric Gray
	Zaffire		Sandburst
	October 2000		February 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 7		skipping to change at page 2, line 7
	implementation specific. This document identifies issues in the		implementation specific. This document identifies issues in the
	CR-LDP specification [2] and the LDP specification [4] that make it		CR-LDP specification [2] and the LDP specification [4] that make it
	difficult to implement an FT LSR using the current LDP and CR-LDP		difficult to implement an FT LSR using the current LDP and CR-LDP
	protocols, and proposes enhancements to the LDP specification to ease		protocols, and proposes enhancements to the LDP specification to ease
	such FT LSR implementations.		such FT LSR implementations.
	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
	1. Conventions and Terminology used in this document...............3		1. Conventions and Terminology used in this document...............3
	2. Introduction....................................................3		2. Introduction....................................................4
	2.1 Fault Tolerance for MPLS.......................................3		2.1 Fault Tolerance for MPLS.......................................4
	2.2 Issues with LDP and CR-LDP.....................................4		2.2 Issues with LDP and CR-LDP.....................................5
	3. Overview of LDP FT Enhancements.................................5		3. Overview of LDP FT Enhancements.................................6
	3.1 Establishing an FT LDP Session.................................6		3.1 Establishing an FT LDP Session.................................6
	3.1.1 Interoperation with Non-FT LSRs.............................6		3.1.1 Interoperation with Non-FT LSRs.............................7
	3.2 TCP Connection Failure.........................................6		3.2 TCP Connection Failure.........................................7
	3.3 Data Forwarding During TCP Connection Failure..................7		3.2.1 Detecting TCP Connection Failures............................7
	3.4 FT LDP Session Reconnection....................................7		3.2.2 LDP Processing after Connection Failure......................7
	3.5 Operations on FT Labels........................................8		3.3 Data Forwarding During TCP Connection Failure..................8
	4. FT Operations...................................................8		3.4 FT LDP Session Reconnection....................................8
	4.1 FT LDP Messages................................................8		3.5 Operations on FT Labels........................................9
	4.1.1 FT Label Messages............................................8		3.6 Label Space Depletion and Replenishment........................9
	4.1.1.1 Scope of FT Labels.........................................9		4. FT Operations..................................................10
	4.1.2 FT Address Messages.........................................9		4.1 FT LDP Messages...............................................10
	4.2 FT Operation ACKs..............................................9		4.1.1 FT Label Messages...........................................10
	4.3 Preservation of FT State......................................10		4.1.1.1 Scope of FT Labels........................................10
	4.4 FT Procedure After TCP Failure................................11		4.1.2 FT Address Messages........................................10
	4.4.1 FT LDP Operations During TCP Failure........................12		4.1.3 FT Label Resources Available Notification Messages..........11
	4.5 FT Procedure After TCP Re-connection..........................12		4.2 FT Operation ACKs.............................................11
	4.5.1 Re-Issuing FT Messages......................................13		4.3 Preservation of FT State......................................12
	4.5.2 Interaction with CR-LDP LSP Modification....................14		4.4 FT Procedure After TCP Failure................................13
	5. Changes to Existing Messages...................................14		4.4.1 FT LDP Operations During TCP Failure........................14
	5.1 LDP Initialization Message....................................14		4.5 FT Procedure After TCP Re-connection..........................15
	5.2 LDP Keepalive Message.........................................14		4.5.1 Re-Issuing FT Messages......................................15
	5.3 All Other LDP Session Messages................................15		4.5.2 Interaction with CR-LDP LSP Modification....................16
	6. New Fields and Values..........................................15		5. Changes to Existing Messages...................................16
	6.1 Status Codes..................................................15		5.1 LDP Initialization Message....................................16
	6.2 FT Session TLV................................................16		5.2 LDP Keepalive Message.........................................16
	6.3 FT Protection TLV.............................................17		5.3 All Other LDP Session Messages................................17
	6.4 FT ACK TLV....................................................18		6. New Fields and Values..........................................17
	7. Example Use....................................................19		6.1 Status Codes..................................................17
	8. Security Considerations........................................23		6.2 FT Session TLV................................................18
	9. Implementation Notes...........................................23		6.3 FT Protection TLV.............................................19
	9.1 FT Recovery Support on Non-FT LSRs............................23		6.4 FT ACK TLV....................................................21
	9.2 ACK generation logic..........................................24		7. Example Use....................................................22
	10. Acknowledgements..............................................24		7.1 Session Failure and Recovery..................................23
	11. Intellectual Property Consideration...........................24		7.2 Temporary Shutdown............................................25
	12. Full Copyright Statement......................................25		8. Security Considerations........................................26
	13. IANA Considerations...........................................25		9. Implementation Notes...........................................27
	13.1 FT Session TLV...............................................25		9.1 FT Recovery Support on Non-FT LSRs............................27
	13.2 FT Protection TLV............................................26		9.2 ACK generation logic..........................................27
	13.3 FT ACK TLV...................................................26		10. Acknowledgements..............................................27
	13.4 Status Codes.................................................26		11. Intellectual Property Consideration...........................28
	14. Authors' Addresses............................................27		12. Full Copyright Statement......................................28
	15. References....................................................27		13. IANA Considerations...........................................28
			13.1 FT Session TLV...............................................29
			13.2 FT Protection TLV............................................29
			13.3 FT ACK TLV...................................................29
			13.4 Status Codes.................................................29
			14. Authors' Addresses............................................29
			15. References....................................................30
			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.
			4.1.3 Describe FT procedures for Label Resources Available
			Notification Messages
			4.2 Explain use of "FT Seq Numbers Exhausted" status code.
			4.4 Recommend default value for FT Reconnection Timeout.
			6.2 Define meaning of FT Reconnection Timeout with value 0.
			6.3 Describe how to handle a message that describes a FEC that may
			have wider coverage than a single label.
			6.3 The sequence number 0x00000000 is invalid under all
			circumstances. Sequence numbers wrap from 0xFFFFFFFF to 0x00000001.
			7.1 Correct sequence numbers in example.
			7.2 Add example for Temporary Shutdown.
	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 6, line 11		skipping to change at page 6, line 34
	- An FT Reconnection Timeout, exchanged on the LDP Initialization		- An FT Reconnection Timeout, exchanged on the LDP Initialization
	message, that indicates the maximum time peer LSRs will preserve		message, that indicates the maximum time peer LSRs will preserve
	FT label state after a failure of the TCP connection.		FT label state after a failure of the TCP connection.
	- An FT Protection TLV used to identify operations that affect LDP		- An FT Protection TLV used to identify operations that affect LDP
	labels. All LDP messages carrying the FT Protection TLV need to		labels. All LDP messages carrying the FT Protection TLV need to
	be secured (e.g. to NVRAM) and ACKed to the sending LDP peer in		be secured (e.g. to NVRAM) and ACKed to the sending LDP peer in
	order that the state for FT labels can be correctly recovered		order that the state for FT labels can be correctly recovered
	after LDP session reconnection.		after LDP session reconnection.
			Note that the implementation within an FT system is left open by
			this draft. An implementation could choose to secure entire
			messages relating to FT labels, or it could secure only the
			relevant state information.
			- Address advertisement is also secured by use of the FT Protection
			TLV. This enables recovery after LDP session reconnection without
			the need to re-advertise what may be a very large number of
			addresses.
	3.1 Establishing an FT LDP Session		3.1 Establishing an FT LDP Session
	In order that the extensions to LDP [4] and CR-LDP [2] described in		In order that the extensions to LDP [4] and CR-LDP [2] described in
	this draft can be used successfully on an LDP session between a pair		this draft can be used successfully on an LDP session between a pair
	of LDP peers, they MUST negotiate that the LDP FT enhancements		of LDP peers, they MUST negotiate that the LDP FT enhancements
	are to be used on the LDP session.		are to be used on the LDP session.
	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		FT Session TLV. Presence of this TLV indicates that the peer wants
	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 on the LDP session.		the receiving LDP peer as a serious protocol error causing the
			session to be torn down.
	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
	Session TLV, all LDP sessions to such LSRs will not use the LDP FT		Session TLV, all LDP sessions to such LSRs will not use the LDP FT
	enhancements.		enhancements.
	The rest of this draft assumes that the LDP sessions under discussion		The rest of this draft assumes that the LDP sessions under discussion
	are between LSRs that do support the LDP FT enhancements, except		are between LSRs that do support the LDP FT enhancements, except
	where explicitly stated otherwise.		where explicitly stated otherwise.
	3.2 TCP Connection Failure		3.2 TCP Connection Failure
			3.2.1 Detecting TCP Connection Failures
			TCP connection failures may be detected and reported to the LDP
			component in a variety of ways. These should all be treated in the
			same way by the LDP component.
			- Indication from the management component that a TCP connection or
			underlying resource is no longer active.
			- Notification from a hardware management component of an interface
			failure.
			- Sockets keepalive timeout.
			- Sockets send failure.
			- New (incoming) Socket opened.
			- LDP protocol timeout.
			3.2.2 LDP Processing after Connection Failure
	If the LDP FT enhancements are not in use on an LDP session, the		If the LDP FT enhancements are not in use on an LDP session, the
	action of the LDP peers on failure of the TCP connection is as		action of the LDP peers on failure of the TCP connection is as
	specified in [2] and [4].		specified in [2] and [4].
	All state information and resources associated with non-FT labels		All state information and resources associated with non-FT labels
	MUST be released on the failure of the TCP connection, including		MUST be released on the failure of the TCP connection, including
	deprogramming the non-FT label from the switching hardware. This is		deprogramming the non-FT label from the switching hardware. This is
	equivalent to the behavior specified in [4].		equivalent to the behavior specified in [4].
	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
	skipping to change at page 8, line 12		skipping to change at page 9, line 5
	Reconnect Flag to 1 in the FT Session TLV. Otherwise, it MUST set the		Reconnect Flag to 1 in the FT Session TLV. Otherwise, it MUST set the
	FT Reconnect Flag to 0.		FT Reconnect Flag to 0.
	If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT		If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT
	Session TLV, both LDP peers MUST release any state information and		Session TLV, both LDP peers MUST release any state information and
	resources associated with the previous instantiation of the LDP		resources associated with the previous instantiation of the LDP
	session between the same LDP peers, including FT label state and		session between the same LDP peers, including FT label state and
	Addresses. This ensures that network resources are not permanently		Addresses. This ensures that network resources are not permanently
	lost by one LSR if its LDP peer is forced to undergo a cold start.		lost by one LSR if its LDP peer is forced to undergo a cold start.
			If an LDP peer changes any session parameters (for example, the label
			space bounds) from the previous instantiation the nature of any
			preserved labels may have changed. In particular, previously
			allocated labels may now be out of range. For this reason, session
			reconnection MUST use the same parameters as were in use on the
			session before the failure. If an LDP peer notices that the
			parameters have been changed by the other peer it SHOULD send a
			Notification message with the 'FT Session parameters changed' status
			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.
	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
	skipping to change at page 8, line 33		skipping to change at page 9, line 36
	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".
	Using these acknowledgements and procedures, it is not necessary for		Using these acknowledgements and procedures, it is not necessary for
	LDP peers to perform a complete re-synchronization of state for all		LDP peers to perform a complete re-synchronization of state for all
	FT labels, either on re-connection of the LDP session between the LDP		FT labels, either on re-connection of the LDP session between the LDP
	peers or on a timed basis.		peers or on a timed basis.
			3.6 Label Space Depletion and Replenishment
			When an LDP peer is unable to satisfy a Label Request message because
			it has no more available labels, it sends a Notification message
			carrying the status code 'No label resources'. This warns the
			requesting LDP peer that subsequent Label Request messages are also
			likely to fail for the same reason. This message does not need to be
			acknowledged for FT purposes since Label Request messages sent after
			session recovery will receive the same response.
			However, the LDP peer that receives a 'No label resources'
			Notification stops sending Label Request messages until it receives a
			'Label resources available' Notification message. Since this
			unsolicited Notification might get lost during session failure, it
			must be protected using the procedures described in this draft.
	4. FT Operations		4. FT Operations
	Once an FT LDP session has been established, using the procedures		Once an FT LDP session has been established, using the procedures
	described in the section "Establishing an FT LDP Session", both LDP		described in the section "Establishing an FT LDP Session", both LDP
	peers MUST apply the procedures described in this section for FT LDP		peers MUST apply the procedures described in this section for FT LDP
	message exchanges.		message exchanges.
	If the LDP session has been negotiated to not use the LDP FT		If the LDP session has been negotiated to not use the LDP FT
	enhancements, these procedures MUST NOT be used.		enhancements, these procedures MUST NOT be used.
	skipping to change at page 9, line 32		skipping to change at page 11, line 5
	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
	the session is reconnected.		the session is reconnected.
	If the FT Reconnect Flag is not set by both LDP peers on reconnection		If the FT Reconnect Flag is not set by both LDP peers on reconnection
	of an LDP session (i.e. state has not been preserved), both LDP		of an LDP session (i.e. state has not been preserved), both LDP
	peers MUST consider all Addresses to have been withdrawn. The LDP		peers MUST consider all Addresses to have been withdrawn. The LDP
	peers SHOULD issue new Address messages for all their valid addresses		peers SHOULD issue new Address messages for all their valid addresses
	as specified in [4].		as specified in [4].
			4.1.3 FT Label Resources Available Notification Messages
			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
			in RFC3036, the downstream LSR must respond with a Notification - No
			Label Resources message. The upstream LSR then suspends asking for
			new labels until it receives a Notification - Label Resources
			Available message from the downstream LSR.
			When the FT extensions are used on a sesssion:
			1. The downstream LSR must preserve the label availability state
			across a failover so that it remembers to send Notification -
			Label Resources Available when the resources become available.
			2. The upstream LSR must recall the label availability state across
			failover so that it can optimize not sending Label Requests when
			it recovers.
			3. The downstream LSR must use sequence numbers on Notification -
			Label Resources Available so that it can check that LSR A has
			received the message and clear its secured state, or resend the
			message if LSR A recovers without having received it.
			If the FT Reconnect Flag is not set by both LDP peers on reconnection
			of an LDP session (i.e. state has not been preserved), both LDP
			peers MUST consider the label availability state to have been reset
			as if the session had been set up for the first time.
	4.2 FT Operation ACKs		4.2 FT Operation ACKs
	Handshaking of FT LDP messages is achieved by use of ACKs.		Handshaking of FT LDP messages is achieved by use of ACKs.
	Correlation between the original message and the ACK is by means of		Correlation between the original message and the ACK is by means of
	the FT Sequence Number contained in the FT Protection TLV, and passed		the FT Sequence Number contained in the FT Protection TLV, and passed
	back in the FT ACK TLV. The FT ACK TLV may be carried on any LDP		back in the FT ACK TLV. The FT ACK TLV may be carried on any LDP
	message that is sent on the TCP connection between LDP peers.		message that is sent on the TCP connection between LDP peers.
	An LDP peer maintains a separate FT sequence number for each LDP		An LDP peer maintains a separate FT sequence number for each LDP
	session it participates in. The FT Sequence number is incremented by		session it participates in. The FT Sequence number is incremented by
	one for each FT LDP message (i.e. containing the FT Protection TLV)		one for each FT LDP message (i.e. containing the FT Protection TLV)
	issued by this LSR on the FT LDP session with which the FT sequence		issued by this LSR on the FT LDP session with which the FT sequence
	number is associated.		number is associated.
	When an LDP Peer receives a message containing the FT Protection TLV,		When an LDP peer receives a message containing the FT Protection TLV,
	it MUST take steps to secure this message (or the state information		it MUST take steps to secure this message (or the state information
	derived from processing the message). Once the message is secured,		derived from processing the message). Once the message is secured,
	it MUST be ACKed. However, there is no requirement on the LSR to		it MUST be ACKed. However, there is no requirement on the LSR to
	send this ACK immediately.		send this ACK immediately.
	ACKs may be accumulated to reduce the message flow between LDP peers.		ACKs may be accumulated to reduce the message flow between LDP peers.
	For example, if an LSR received FT LDP messages with sequence numbers		For example, if an LSR received FT LDP messages with sequence numbers
	1, 2, 3, 4, it could send a single ACK with sequence number 4 to ACK		1, 2, 3, 4, it could send a single ACK with sequence number 4 to ACK
	receipt and securing of all these messages.		receipt and securing of all these messages.
	ACKs MUST NOT be sent out of sequence, as this is incompatible with		ACKs MUST NOT be sent out of sequence, as this is incompatible with
	the use of accumulated ACKs .		the use of accumulated ACKs. Duplicate ACKs (that is two successive
			messages that acknowledge the same sequence number) are acceptable.
			If an LDP peer discovers that its sequence number space for a
			specific session is full of un-acknowledged sequence numbers (because
			its partner on the session has not acknowledged them in a timely way)
			it cannot allocate a new sequence number for any further FT LPD
			message. It SHOULD send a Notification message with the status code
			"FT Seq Numbers Exhausted".
	4.3 Preservation of FT State		4.3 Preservation of FT State
	If the LDP FT enhancements are in use on an LDP session, each LDP		If the LDP FT enhancements are in use on an LDP session, each LDP
	peer SHOULD NOT release the state information and resources		peer SHOULD NOT release the state information and resources
	associated with FT labels exchanged on that LDP session when the TCP		associated with FT labels exchanged on that LDP session when the TCP
	connection fails. This is contrary to [2] and [4], but allows label		connection fails. This is contrary to [2] and [4], but allows label
	operations on FT labels to be completed after re-connection of the		operations on FT labels to be completed after re-connection of the
	TCP connection.		TCP connection.
	skipping to change at page 11, line 26		skipping to change at page 13, line 26
	across a closure and re-establishment of the TCP session.		across a closure and re-establishment of the TCP session.
	- If an LSR determines that it must release state for any single FT		- If an LSR determines that it must release state for any single FT
	label during a failure of the TCP connection on which that label		label during a failure of the TCP connection on which that label
	was exchanged, it MUST release all state for all labels on the LDP		was exchanged, it MUST release all state for all labels on the LDP
	session.		session.
	The release of state information and resources associated with non-FT		The release of state information and resources associated with non-FT
	labels is as described in [2] and [4].		labels is as described in [2] and [4].
	Note that a Label Release and the acknowledgemet to a Label Withdraw		Note that a Label Release and the acknowledgement to a Label Withdraw
	may be received by a downstream LSR in any order. The downstream LSR		may be received by a downstream LSR in any order. The downstream LSR
	MAY release its resources on receipt of the first message and MUST		MAY release its resources on receipt of the first message and MUST
	release its resources on receipt of the second message.		release its resources on receipt of the second message.
	4.4 FT Procedure After TCP Failure		4.4 FT Procedure After TCP Failure
	When an LSR discovers or is notified of a TCP connection failure it		When an LSR discovers or is notified of a TCP connection failure it
	SHOULD start an FT Reconnection Timer to allow a period for		SHOULD start an FT Reconnection Timer to allow a period for
	re-connection of the TCP connection between the LDP peers.		re-connection of the TCP connection between the LDP peers.
			The RECOMMENDED default value for this timer is 5 seconds. During
			this time, failure must be detected and reported, new hardware may
			need to be activated, software state must be audited, and a new TCP
			session must be set up.
	Once the TCP connection between LDP peers has failed, the active LSR		Once the TCP connection between LDP peers has failed, the active LSR
	SHOULD attempt to re-establish the TCP connection. The mechanisms,		SHOULD attempt to re-establish the TCP connection. The mechanisms,
	timers and retry counts to re-establish the TCP connection are an		timers and retry counts to re-establish the TCP connection are an
	implementation choice. It is RECOMMENDED that any attempt to		implementation choice. It is RECOMMENDED that any attempt to
	re-establish the connection take account of the failover processing		re-establish the connection take account of the failover processing
	necessary on the peer LSR, the nature of the network between the		necessary on the peer LSR, the nature of the network between the
	LDP peers, and the FT Reconnection Timeout chosen on the previous		LDP peers, and the FT Reconnection Timeout chosen on the previous
	instantiation of the TCP connection (if any).		instantiation of the TCP connection (if any).
	If the TCP connection cannot be re-established within the FT		If the TCP connection cannot be re-established within the FT
	skipping to change at page 12, line 11		skipping to change at page 14, line 11
	further Hello exchange to set up a new LDP session), the LSR MUST set		further Hello exchange to set up a new LDP session), the LSR MUST set
	the FT Reconnect Flag to 0 if it released the preserved state		the FT Reconnect Flag to 0 if it released the preserved state
	information on this timeout event.		information on this timeout event.
	If the TCP connection is successfully re-established within the FT		If the TCP connection is successfully re-established within the FT
	Reconnection Timeout, both peers MUST re-issue LDP operations that		Reconnection Timeout, both peers MUST re-issue LDP operations that
	were interrupted by (that is, un-acknowledged as a result of) the TCP		were interrupted by (that is, un-acknowledged as a result of) the TCP
	connection failure. This procedure is described in section "FT		connection failure. This procedure is described in section "FT
	Procedure After TCP Re-connection".		Procedure After TCP Re-connection".
	The Hold Timer for an FT LDP Session SHOULD be ignored while the FT		The Hold Timer for an FT LDP Session (see [4] section 2.5.5) SHOULD
	Reconnection Timer is running. The hold timer SHOULD be restarted		be ignored while the FT Reconnection Timer is running. The hold
	when the TCP connection is re-established.		timer SHOULD be restarted when the TCP connection is re-established.
	4.4.1 FT LDP Operations During TCP Failure		4.4.1 FT LDP Operations During TCP Failure
	When the LDP FT enhancements are in use for an LDP session, it is		When the LDP FT enhancements are in use for an LDP session, it is
	possible that an LSR may determine that it needs to send an LDP		possible that an LSR may determine that it needs to send an LDP
	message to an LDP peer but that the TCP connection to that peer is		message to an LDP peer but that the TCP connection to that peer is
	currently down. These label operations affect the state of FT labels		currently down. These label operations affect the state of FT labels
	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.
	skipping to change at page 12, line 46		skipping to change at page 14, line 46
	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
	not pended awaiting the re-establishment of TCP connection that is		not pended awaiting the re-establishment of TCP connection that is
	awaiting recovery at the time the LSR determines that it needs to		awaiting recovery at the time the LSR determines that it needs to
	issue the Label Request message. Instead, such Label Request		issue the Label Request message. Instead, such Label Request
	operations SHOULD be failed and, if necessary, a notification message		operations SHOULD be failed and, if necessary, a notification message
	containing the "No LDP Connection" status code sent upstream.		containing the "No LDP Session" status code sent upstream.
	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.
	skipping to change at page 13, line 25		skipping to change at page 15, line 31
	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
	to the following rules for re-issuing messages that are not ACKed by		to the following rules for re-issuing messages that are not ACKed by
	the LDP peer on the LDP Initialization message exchange after		the LDP peer on the LDP Initialization message exchange after
	re-connection of the TCP session.		re-connection of the TCP session.
	- A Label Request message MUST be re-issued unless a Label Abort		- A Label Request message MUST be re-issued unless a Label Abort
	would be re-issued for the same Label Request or the Label Request		would be re-issued for the same FT label.
	or if the requested label is no longer required.
	- A Label Mapping message MUST be re-issued unless a Label Withdraw		- A Label Mapping message MUST be re-issued unless a Label Withdraw
	message would be re-issued for the same FT label.		message would be re-issued for the same FT label.
	- All other messages on the LDP session that carried the FT		- All other messages on the LDP session that carried the FT
	Protection TLV MUST be re-issued if an acknowledgement had not		Protection TLV MUST be re-issued if an acknowledgement had not
	previously been received.		previously been received.
	Any FT label operations that were pended (see section "FT Label		Any FT label operations that were pended (see section "FT Label
	Operations During TCP Failure") during the TCP connection failure		Operations During TCP Failure") during the TCP connection failure
	skipping to change at page 16, line 4		skipping to change at page 17, line 56
	No LDP Session 0 0x000000xx		No LDP Session 0 0x000000xx
	Zero FT seqnum 1 0x000000xx		Zero FT seqnum 1 0x000000xx
	Unexpected TLV / 1 0x000000xx		Unexpected TLV / 1 0x000000xx
	Session Not FT		Session Not FT
	Unexpected TLV / 1 0x000000xx		Unexpected TLV / 1 0x000000xx
	Label Not FT		Label Not FT
	Missing FT Protection TLV 1 0x000000xx		Missing FT Protection TLV 1 0x000000xx
	FT ACK sequence error 1 0x000000xx		FT ACK sequence error 1 0x000000xx
	Temporary Shutdown 0 0x000000xx		Temporary Shutdown 0 0x000000xx
	FT Seq Numbers Exhausted 1 0x000000xx		FT Seq Numbers Exhausted 1 0x000000xx
			FT Session parameters / 1 0x000000xx
			changed
	The Temporary Shutdown status code SHOULD be used in place of		The Temporary Shutdown status code SHOULD be used in place of
	the Shutdown status code (which has the E-bit set) if the LSR that is		the Shutdown status code (which has the E-bit set) if the LSR that is
	shutting down wishes to inform its LDP peer that it expects to be		shutting down wishes to inform its LDP peer that it expects to be
	able to preserve FT label state and to return to service before the		able to preserve FT label state and to return to service before the
	FT Reconnection Timer expires.		FT Reconnection Timer expires.
	6.2 FT Session TLV		6.2 FT Session TLV
	LDP peers can negotiate whether the LDP session between them supports		LDP peers can negotiate whether the LDP session between them supports
	FT extensions by using a new OPTIONAL parameter, the FT Session		FT extensions by using a new OPTIONAL parameter, the FT Session
	skipping to change at page 17, line 11		skipping to change at page 19, line 5
	All other bits in this field are currently reserved and SHOULD		All other bits in this field are currently reserved and SHOULD
	be set to zero on transmission and ignored on receipt.		be set to zero on transmission and ignored on receipt.
	FT Reconnection Timeout		FT Reconnection Timeout
	The period of time the sending LSR will preserve state and		The period of time the sending LSR will preserve state and
	resources for FT labels exchanged on the previous instantiation of		resources for FT labels exchanged on the previous instantiation of
	an FT LDP session that has currently failed. The timeout is		an FT LDP session that has currently failed. The timeout is
	encoded as a 16-bit unsigned integer number of seconds.		encoded as a 16-bit unsigned integer number of seconds.
	The value of 0 for this field is reserved and MUST NOT be used.		A value of zero in this field means that the sending LSR will
			preserve state and resources indefinitely.
	See the section "LDP Session Failure" for details of how this field		See the section "FT Procedure After TCP Failure" for details of how
	is used.		this field is used.
	6.3 FT Protection TLV		6.3 FT Protection TLV
	LDP peers use the FT Protection TLV to indicate that an LDP message		LDP peers use the FT Protection TLV to indicate that an LDP message
	contains an FT label operation.		contains an FT label operation.
	The FT Protection TLV MUST NOT be used in messages flowing on an LDP		The FT Protection TLV MUST NOT be used in messages flowing on an LDP
	session that does not support the LDP FT enhancements.		session that does not support the LDP FT enhancements. Its presence
			in such messages SHALL be treated as a protocol error by the
			receiving LDP peer which SHOULD send a Notification message with the
			'Unexpected TLV Session Not FT' status code.
	The FT Protection TLV MAY be carried on an LDP message transported on		The FT Protection TLV MAY be carried on an LDP message transported on
	the LDP session after the initial exchange of LDP Initialization		the LDP session after the initial exchange of LDP Initialization
	messages. In particular, this TLV MAY optionally be present on the		messages. In particular, this TLV MAY optionally be present on the
	following messages:		following messages:
	- Label Request Messages in downstream on-demand distribution mode		- Label Request Messages in downstream on-demand distribution mode
	- Label Mapping messages in downstream unsolicited mode.		- Label Mapping messages in downstream unsolicited mode.
	If a label is to be an FT label, then the Protection TLV MUST be		If a label is to be an FT label, then the Protection TLV MUST be
	present:		present:
	- on the Label Request message in DoD mode		- on the Label Request message in DoD mode
	- on the Label Mapping message in DU mode		- on the Label Mapping message in DU mode
	- on all subsequent messages concerning this label.		- on all subsequent messages concerning this label.
	Here 'subsequent messages concerning this label' means any message		Here 'subsequent messages concerning this label' means any message
	whose Label TLV specifies this label or whose Label Request Message		whose Label TLV specifies this label or whose Label Request Message
	ID TLV specifies the initial Label Request message.		ID TLV specifies the initial Label Request message.
	If a label is not to be an FT label, then the Protection TLV		If a label is not to be an FT label, then the Protection TLV
	MUST NOT be present on any of these messages.		MUST NOT be present on any of these messages. The presence of the FT
			TLV on a message relating to a non-FT label SHALL be treated as a
			protocol error by the receiving LDP peer which SHOULD send a
			notification message with the 'Unexpected TLV Label Not FT' status
			code.
			Where a Label Withdraw or Label Release message contains only a FEC
			TLV and does not identify a single specific label, the FT TLV should
			be included in the message if any label affected by the message is an
			FT label. If there is any doubt as to whether an FT TLV should be
			present, it is RECOMMENDED that the sender add the TLV.
			When an LDP peer receives a Label Withdraw Message or Label Release
			message that contains only a FEC, it SHALL accept the FT TLV if it is
			present regardless of the FT status of the labels which it affects.
			If an LDP session is an FT session as determined by the presence of
			the FT Session TLV on the LDP Initialization messages, the FT
			Protection TLV MUST be present:
			- on all Address messages on the session
			- on all Notification messages on the session that have the status
			code 'Label Resources Available'.
	The FT Protection TLV is encoded as follows.		The FT Protection TLV is encoded as follows.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| FT Protection (0x0203) | Length (= 4) |		|0|0| FT Protection (0x0203) | Length (= 4) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FT Sequence Number |		| FT Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 18, line 4		skipping to change at page 20, line 21
	The FT Protection TLV is encoded as follows.		The FT Protection TLV is encoded as follows.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| FT Protection (0x0203) | Length (= 4) |		|0|0| FT Protection (0x0203) | Length (= 4) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FT Sequence Number |		| FT Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	FT Sequence Number		FT Sequence Number
	The sequence number for this FT label operation. The		The sequence number for this FT label operation. The
	sequence number is encoded as a 32-bit unsigned integer. The		sequence number is encoded as a 32-bit unsigned integer. The
	initial value for this field on a new LDP session is x00000001 and		initial value for this field on a new LDP session is 0x00000001 and
	is incremented by one for each FT LDP message issued by the sending		is incremented by one for each FT LDP message issued by the sending
	LSR on this LDP session. This field may wrap from xFFFFFFFF to		LSR on this LDP session. This field may wrap from 0xFFFFFFFF to
	x00000000.		0x00000001.
	This field MUST be reset to x00000001 if either LDP peer does not		This field MUST be reset to 0x00000001 if either LDP peer does not
	set the FT Reconnect Flag on re-establishment of the TCP		set the FT Reconnect Flag on re-establishment of the TCP
	connection.		connection.
	See the section "FT Operation Acks" for details of how this field		See the section "FT Operation Acks" for details of how this field
	is used.		is used.
			The special use of 0x00000000 is discussed in the section "FT ACK
			TLV" below.
	If an LSR receives an FT Protection TLV on a session that does not		If an LSR receives an FT Protection TLV on a session that does not
	support the FT LFP enhancements, it SHOULD send a Notification		support the FT LDP enhancements, it SHOULD send a Notification
	message to its LDP peer containing the "Unexpected TLV, Session Not		message to its LDP peer containing the "Unexpected TLV, Session Not
	FT" status code.		FT" status code.
	If an LSR receives an FT Protection TLV on an operation affecting a		If an LSR receives an FT Protection TLV on an operation affecting a
	label that it believes is a non-FT label, it SHOULD send a		label that it believes is a non-FT label, it SHOULD send a
	Notification message to its LDP peer containing the "Unexpected TLV,		Notification message to its LDP peer containing the "Unexpected TLV,
	Label Not FT" status code.		Label Not FT" status code.
	If an LSR receives a message without the FT Protection TLV affecting		If an LSR receives a message without the FT Protection TLV affecting
	a label that it believes is an FT label, it SHOULD send a		a label that it believes is an FT label, it SHOULD send a
	Notification message to its LDP peer containing the "Missing FT		Notification message to its LDP peer containing the "Missing FT
	Protection TLV" status code.		Protection TLV" status code.
	If an LSR receives an FT Protection TLV containing a zero FT		If an LSR receives an FT Protection TLV containing a zero FT
	Sequence Number, it SHOULD send a Notification message to its LDP		Sequence Number, it SHOULD send a Notification message to its LDP
	peer containing the "Zero FT Seqnum" status code.		peer containing the "Zero FT Seqnum" status code.
	6.4 FT ACK TLV		6.4 FT ACK TLV
	LDP peers use the FT ACK TLV to acknowledge FT		LDP peers use the FT ACK TLV to acknowledge FT label operations.
	label operations.
	The FT ACK TLV MUST NOT be used in messages flowing on an		The FT ACK TLV MUST NOT be used in messages flowing on an LDP session
	LDP session that does not support the LDP FT enhancements.		that does not support the LDP FT enhancements. Its presence on such
			messages SHALL be treated as a protocol error by the receiving LDP
			peer.
	The FT ACK TLV MAY be present on any LDP message exchanged on an		The FT ACK TLV MAY be present on any LDP message exchanged on an
	LDP session after the initial LDP Initialization messages. It is		LDP session after the initial LDP Initialization messages. It is
	RECOMMENDED that the FT ACK TLV is included on all FT		RECOMMENDED that the FT ACK TLV is included on all FT
	Keepalive messages in order to ensure that the LDP peers do not		Keepalive messages in order to ensure that the LDP peers do not
	build up a large backlog of unacknowledged state information.		build up a large backlog of unacknowledged state information.
	The FT ACK TLV is encoded as follows.		The FT ACK TLV is encoded as follows.
	0 1 2 3		0 1 2 3
	skipping to change at page 19, line 55		skipping to change at page 22, line 18
	Notification message to its LDP peer containing the "FT ACK		Notification message to its LDP peer containing the "FT ACK
	Sequence Error" status code.		Sequence Error" status code.
	7. Example Use		7. Example Use
	Consider two LDP peers, P1 and P2, implementing LDP over a TCP		Consider two LDP peers, P1 and P2, implementing LDP over a TCP
	connection that connects them, and the message flow shown below.		connection that connects them, and the message flow shown below.
	The parameters shown on each message shown below are as follows:		The parameters shown on each message shown below are as follows:
	message (label, senders FT sequence #, FT ACK #)		message (label, senders FT sequence number, FT ACK number)
	A "-" for FT ACK # means that the FT ACK TLV is not included on
	that message. "n/a" means that the parameter in question is not		A "-" for FT ACK number means that the FT ACK TLV is not included
			on that message. "n/a" means that the parameter in question is not
	applicable to that type of message.		applicable to that type of message.
	In the diagram below, time flows from top to bottom. The relative		In the diagrams below, time flows from top to bottom. The relative
	position of each message shows when it is transmitted. See the notes		position of each message shows when it is transmitted. See the notes
	for a description of when each message is received, secured for FT or		for a description of when each message is received, secured for FT or
	processed.		processed.
			7.1 Session Failure and Recovery
	notes P1 P2		notes P1 P2
	===== == ==		===== == ==
	(1) Label Request(L1,27,-)		(1) Label Request(L1,27,-)
	--------------------------->		--------------------------->
	Label Request(L2,28,-)		Label Request(L2,28,-)
	--------------------------->		--------------------------->
	(2) Label Request(L3,93,27)		(2) Label Request(L3,93,27)
	<---------------------------		<---------------------------
	(3) Label Request(L1,123,-)		(3) Label Request(L1,123,-)
	-------------------------->		-------------------------->
	skipping to change at page 21, line 34		skipping to change at page 23, line 36
	<---------------------------		<---------------------------
	(6) Address(n/a,29,-)		(6) Address(n/a,29,-)
	--------------------------->		--------------------------->
	(7) Label Request(L4,30,-)		(7) Label Request(L4,30,-)
	--------------------------->		--------------------------->
	(8) Keepalive(n/a,na/,94)		(8) Keepalive(n/a,na/,94)
	--------------------------->		--------------------------->
	(9) Label Abort(L3,96,-)		(9) Label Abort(L3,96,-)
	<---------------------------		<---------------------------
	(10) ===== TCP Session lost =====		(10) ===== TCP Session lost =====
			:
	(11) Label Withdraw(L1,59,-)		(11) : Label Withdraw(L1,59,-)
	<--------------------------		: <--------------------------
			:
	(12) === TCP Session restored ===		(12) === TCP Session restored ===
	LDP Init(n/a,n/a,95)		LDP Init(n/a,n/a,94)
	--------------------------->		--------------------------->
	LDP Init(n/a,n/a,29)		LDP Init(n/a,n/a,29)
	<---------------------------		<---------------------------
	(13) Label Request(L4,30,-)		(13) Label Request(L4,30,-)
	--------------------------->		--------------------------->
	(14) Label Mapping(L2,95,-)		(14) Label Mapping(L2,95,-)
	<---------------------------		<---------------------------
	Label Abort(L3,96,30)		Label Abort(L3,96,30)
	<---------------------------		<---------------------------
	(15) Label Withdraw(L1,97,-)		(15) Label Withdraw(L1,97,-)
	skipping to change at page 23, line 5		skipping to change at page 25, line 5
	to the failure.		to the failure.
	(13) From the LDP Init exchange, P1 determines that it needs to		(13) From the LDP Init exchange, P1 determines that it needs to
	re-issue the Label request for L4.		re-issue the Label request for L4.
	(14) Similarly, P2 determines that it needs to re-issue the Label		(14) Similarly, P2 determines that it needs to re-issue the Label
	Mapping for L2 and the Label Abort.		Mapping for L2 and the Label Abort.
	(15) P2 issues the queued Label Withdraw to P1.		(15) P2 issues the queued Label Withdraw to P1.
			7.2 Temporary Shutdown
			notes P1 P2
			===== == ==
			(1) Label Request(L1,27,-)
			--------------------------->
			Label Request(L2,28,-)
			--------------------------->
			(2) Label Request(L3,93,27)
			<---------------------------
			(3) Label Request(L1,123,-)
			-------------------------->
			Label Request(L2,124,-)
			-------------------------->
			(4) Label Mapping(L1,57,-)
			<--------------------------
			Label Mapping(L1,94,28)
			<---------------------------
			(5) Label Mapping(L2,58,-)
			<--------------------------
			Label Mapping(L2,95,-)
			<---------------------------
			(6) Address(n/a,29,-)
			--------------------------->
			(7) Label Request(L4,30,-)
			--------------------------->
			(8) Keepalive(n/a,na/,94)
			--------------------------->
			(9) Label Abort(L3,96,-)
			<---------------------------
			(10) Notification(Temporary shutdown)
			--------------------------->
			:
			(11) : Label Withdraw(L1,59,-)
			: <--------------------------
			:
			(12) LDP Init(n/a,n/a,94)
			--------------------------->
			LDP Init(n/a,n/a,29)
			<---------------------------
			(13) Label Request(L4,30,-)
			--------------------------->
			(14) Label Mapping(L2,95,-)
			<---------------------------
			Label Abort(L3,96,30)
			<---------------------------
			(15) Label Withdraw(L1,97,-)
			<---------------------------
			Notes:
			======
			Notes are as in the previous example except as follows.
			(10) P1 needs to upgrade the software or hardware that it is running.
			It issues a Notification message to terminate the LDP session,
			but sets the status code as 'Temporary shutdown' to inform P2
			that this is not a fatal error, and P2 should maintain FT state.
			The TCP connection may also fail during the period that the LDP
			session is down (in which case it will need to be
			re-established), but it is also possible that the TCP connection
			will be preserved.
	8. Security Considerations		8. Security Considerations
	The LDP FT enhancements inherit similar security considerations to		The LDP FT enhancements inherit similar security considerations to
	those discussed in [2] and [4].		those discussed in [2] and [4].
	The LDP FT enhancements allow the re-establishment of a TCP		The LDP FT enhancements allow the re-establishment of a TCP
	connection between LDP peers without a full re-exchange of the		connection between LDP peers without a full re-exchange of the
	attributes of established labels, which renders LSRs that implement		attributes of established labels, which renders LSRs that implement
	the extensions specified in this draft vulnerable to additional		the extensions specified in this draft vulnerable to additional
	denial-of-service attacks as follows:		denial-of-service attacks as follows:
	skipping to change at page 24, line 34		skipping to change at page 27, line 50
	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 [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 and Duncan		comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer,
	Archer at Data Connection Ltd, Peter Ashwood-Smith of Nortel and		Peter Ashwood-Smith, Bob Thomas, S.Manikantan, Adam Sheppard and
	Bon Thomas of Cisco.		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
	document. For more information, consult the online list of claimed		document. For more information, consult the online list of claimed
	rights.		rights.
	12. Full Copyright Statement		12. Full Copyright Statement
	Copyright (c) The Internet Society (2000). All Rights Reserved. This		Copyright (c) The Internet Society (2000, 2001). All Rights Reserved.
	document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph		kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this		are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	skipping to change at page 27, line 20		skipping to change at page 30, line 20
	Pepper Street Pepper Street		Pepper Street Pepper Street
	Chester Chester		Chester Chester
	Cheshire Cheshire		Cheshire Cheshire
	CH1 1DF CH1 1DF		CH1 1DF CH1 1DF
	UK UK		UK UK
	Phone: +44-(0)-1244-313440 Phone: +44-(0)-1244-313440		Phone: +44-(0)-1244-313440 Phone: +44-(0)-1244-313440
	Fax: +44-(0)-1244-312422 Fax: +44-(0)-1244-312422		Fax: +44-(0)-1244-312422 Fax: +44-(0)-1244-312422
	Email: af@dataconnection.com Email: pjb@dataconnection.com		Email: af@dataconnection.com Email: pjb@dataconnection.com
	Philip Matthews Eric Gray		Philip Matthews Eric Gray
	Nortel Networks Corp. Zaffire, Inc.		Nortel Networks Corp. Sandburst Corporation
	P.O. Box 3511 Station C, 2630 Orchard Parkway,		P.O. Box 3511 Station C, 600 Federal Street
	Ottawa, ON K1Y 4H7 San Jose, CA - 95134-2020		Ottawa, ON K1Y 4H7 Andover, MA 01810
	Canada Phone: (408) 894-7362		Canada Phone: +1 978-689-1600
	Phone: +1 613-768-3262 egray@zaffire.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-04.txt, July 2000, (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, draft-ietf-mpls-ldp-		4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001.
	11.txt, August 2000 (work in progress).
	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-01.txt, February 2000 (work in progress).		crlsp-modify-02.txt, October 2000 (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-07.txt, August 2000 (work in progress).
	9 Ward, D, et al., BGP Notification Cease: I'll Be Back,		9 Ward, D, et al., BGP Notification Cease: I'll Be Back,
	draft-ward-bgp4-ibb-00.txt, June 1999 (work in progress)		draft-ward-bgp4-ibb-00.txt, June 1999 (work in progress)
	10 Stewart, R, et al., Simple Control Transmission Protocol,
	draft-ietf-sigtran-sctp-07.txt, March 2000 (work in progress)		10 Stewart, R, et al., Stream Control Transmission Protocol,
			RFC 2906, October 2000.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/