draft-ietf-mpls-ldp-ft-03.txt		draft-ietf-mpls-ldp-ft-04.txt
	MPLS Working Group Adrian Farrel		MPLS Working Group Adrian Farrel
	Internet Draft Movaz Networks, Inc.		Internet Draft Movaz Networks, Inc.
	Document: draft-ietf-mpls-ldp-ft-03.txt		Document: draft-ietf-mpls-ldp-ft-04.txt
	Expiration Date: December 2002 Paul Brittain		Expiration Date: January 2003 Paul Brittain
	Data Connection Ltd.		Data Connection Ltd.
	Philip Matthews		Philip Matthews
	Hyperchip		Hyperchip
	Eric Gray		Eric Gray
	Sandburst		Celox Networks
	Toby Smith		Toby Smith
	Laurel Networks		Laurel Networks
	Andy Malis		Andrew G. Malis
	Jack Shaio		Jack Shaio
	Vivace Networks		Vivace Networks
	June 2002		July 2002
	Fault Tolerance for LDP and CR-LDP		Fault Tolerance for the Label Distribution Protocol (LDP)
	draft-ietf-mpls-ldp-ft-03.txt		draft-ietf-mpls-ldp-ft-04.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full		This document is an Internet-Draft and is in full
	conformance with all provisions of Section 10 of RFC2026		conformance with all provisions of Section 10 of RFC2026
	[1].		[RFC2026].
	Internet-Drafts are working documents of the Internet		Internet-Drafts are working documents of the Internet
	Engineering Task Force (IETF), its areas, and its working		Engineering Task Force (IETF), its areas, and its working
	groups. Note that other groups may also distribute		groups. Note that other groups may also distribute
	working documents as Internet-Drafts. Internet-Drafts are		working documents as Internet-Drafts. Internet-Drafts are
	draft documents valid for a maximum of six months and may		draft documents valid for a maximum of six months and may
	be updated, replaced, or obsoleted by other documents at		be updated, replaced, or obsoleted by other documents at
	any time. It is inappropriate to use Internet- Drafts as		any time. It is inappropriate to use Internet- Drafts as
	reference material or to cite them other than as "work in		reference material or to cite them other than as "work in
	progress."		progress."
	skipping to change at page 2, line 14		skipping to change at page 2, line 14
	Abstract		Abstract
	MPLS systems will be used in core networks where system		MPLS systems will be used in core networks where system
	downtime must be kept to an absolute minimum. Many MPLS		downtime must be kept to an absolute minimum. Many MPLS
	LSRs may, therefore, exploit Fault Tolerant (FT) hardware		LSRs may, therefore, exploit Fault Tolerant (FT) hardware
	or software to provide high availability of the core		or software to provide high availability of the core
	networks.		networks.
	The details of how FT is achieved for the various		The details of how FT is achieved for the various
	components of an FT LSR, including LDP, CR-LDP, the		components of an FT LSR, including LDP, the switching
	switching hardware and TCP, are implementation specific.		hardware and TCP, are implementation specific. This
	This document identifies issues in the CR-LDP		document identifies issues in the LDP specification
	specification [2] and the LDP specification [4] that make		[RFC3036] that make it difficult to implement an FT LSR
	it difficult to implement an FT LSR using the current LDP		using the current LDP protocols, and proposes
	and CR-LDP protocols, and proposes enhancements to the		enhancements to the LDP specification to ease such FT LSR
	LDP specification to ease such FT LSR implementations.		implementations.
	The extensions described here are equally applicable to		The issues and extensions described here are equally
	CR-LDP.		applicable to CR-LDP [RFC3212].
	Contents		Contents
	1. Conventions and Terminology used in this document 4		1. Conventions and Terminology used in this document 3
	2. Introduction 5		2. Introduction 4
	2.1. Fault Tolerance for MPLS 5		2.1. Fault Tolerance for MPLS 5
	2.2. Issues with LDP and CR-LDP 6		2.2. Issues with LDP and CR-LDP 5
	3. Overview of LDP FT Enhancements 7		3. Overview of LDP FT Enhancements 7
	3.1. Establishing an FT LDP Session 8		3.1. Establishing an FT LDP Session 8
	3.1.1 Interoperation with Non-FT LSRs 9		3.1.1 Interoperation with Non-FT LSRs 8
	3.2. TCP Connection Failure 9		3.2. TCP Connection Failure 9
	3.2.1 Detecting TCP Connection Failures 9		3.2.1 Detecting TCP Connection Failures 9
	3.2.2 LDP Processing after Connection Failure 10		3.2.2 LDP Processing after Connection Failure 9
	3.3. Data Forwarding During TCP Connection Failure 10		3.3. Data Forwarding During TCP Connection Failure 10
	3.4. FT LDP Session Reconnection 11		3.4. FT LDP Session Reconnection 10
	3.5. Operations on FT Labels 12		3.5. Operations on FT Labels 11
	3.6. Check-Pointing 12		3.6. Check-Pointing 12
	3.6.1 Graceful Termination 13		3.6.1 Graceful Termination 13
	3.7. Label Space Depletion and Replenishment 13		3.7. Label Space Depletion and Replenishment 13
	4. FT Operations 14		4. FT Operations 14
	4.1. FT LDP Messages 14		4.1. FT LDP Messages 14
	4.1.1 FT Label Messages 14		4.1.1 Sequence Numbered FT Label Messages 14
	4.1.2 FT Address Messages 15		4.1.2 FT Address Messages 15
	4.1.3 FT Label Resources Available Notification Messages 16		4.1.3 Label Resources Available Notifications 15
	4.2. FT Operation ACKs 17		4.2. FT Operation ACKs 17
	4.3. Preservation of FT State 18		4.3. Preservation of FT State 17
	4.4. FT Procedure After TCP Failure 19		4.4. FT Procedure After TCP Failure 19
	4.4.1 FT LDP Operations During TCP Failure 20		4.4.1 FT LDP Operations During TCP Failure 20
	4.5. FT Procedure After TCP Re-connection 21		4.5. FT Procedure After TCP Re-connection 21
	4.5.1 Re-Issuing FT Messages 22		4.5.1 Re-Issuing FT Messages 22
	4.5.2 Interaction with CR-LDP LSP Modification 23		4.5.2 Interaction with CR-LDP LSP Modification 22
	5. Checkpointing Procedures 23		5. Checkpointing Procedures 23
	5.1. Checkpointing with the Keepalive Message 24		5.1. Checkpointing with the Keepalive Message 23
	5.2. Quiesce and Keepalive 24		5.2. Quiesce and Keepalive 24
	6. Changes to Existing Messages 25		6. Changes to Existing Messages 24
	6.1. LDP Initialization Message 25		6.1. LDP Initialization Message 24
	6.2. LDP Keepalive Messages 25		6.2. LDP Keepalive Messages 25
	6.3. All Other LDP Session Messages 26		6.3. All Other LDP Session Messages 25
	7. New Fields and Values 26		7. New Fields and Values 26
	7.1. Status Codes 26		7.1. Status Codes 26
	7.2. FT Session TLV 27		7.2. FT Session TLV 27
	7.3. FT Protection TLV 29		7.3. FT Protection TLV 30
	7.4. FT ACK TLV 32		7.4. FT ACK TLV 32
	7.5. FT Cork TLV 33		7.5. FT Cork TLV 34
	8. Example Use 34		8. Example Use 35
	8.1. Session Failure and Recovery - FT Procedures 35		8.1. Session Failure and Recovery - FT Procedures 36
	8.2. Use of Check-Pointing With FT Procedures 37		8.2. Use of Check-Pointing With FT Procedures 38
	8.3. Temporary Shutdown With FT Procedures 39		8.3. Temporary Shutdown With FT Procedures 40
	8.4. Temporary Shutdown With FT Procedures and Check-Pointing 41		8.4. Temporary Shutdown With FT Procedures and Check-Pointing 42
	8.5. Checkpointing Without FT Procedures 43		8.5. Checkpointing Without FT Procedures 44
	8.6. Graceful Shutdown With Checkpointing But No FT Procedures 45		8.6. Graceful Shutdown With Checkpointing But No FT Procedures 46
	9. Security Considerations 46		9. Security Considerations 47
	10. Implementation Notes 47		10. Implementation Notes 49
	10.1. FT Recovery Support on Non-FT LSRs 47		10.1. FT Recovery Support on Non-FT LSRs 49
	10.2. ACK Generation Logic 48		10.2. ACK generation logic 49
	10.2.1 Ack Generation Logic When Using Check-Pointing 48		10.2.1 Ack Generation Logic When Using Check-Pointing 49
	11. Acknowledgments 49		11. Acknowledgments 50
	12. Intellectual Property Consideration 49		12. Intellectual Property Consideration 50
	13. Full Copyright Statement 49		13. Full Copyright Statement 51
	14. IANA Considerations 50		14. IANA Considerations 51
	14.1. FT Session TLV 50		14.1. New TLVs 52
	14.2. FT Protection TLV 50		14.2. New Status Codes 52
	14.3. FT ACK TLV 51		15. Authors' Addresses 53
	14.4. FT Cork TLV 51		16. References 53
	14.5. Status Codes 51		16.1. Normative References 53
	15. Authors' Addresses 51		16.2. Informative References 53
	16. Normative References 52
	17. Informative References 52
	0. Changes From Version 2 to Version 3
	This section to be removed before final publication.
	2.2 Add notes about graceful shutdown and check-pointing.
	3 Allow sequence number on Keepalive to facilitate check-
	pointing.
	3.6 New section to describe the use of check-pointing
	3.6.1 New sub-section to describe the use of check-
	pointing for graceful restart
	3.7 and 4.1.3 Make acknowledgement and request for
	acknowledgement of Notification messages carrying 'Label
	Resources Available' optional.
	4.1.1 Explicitly state it is allowable to make all labels
	FT labels.
	5. Add section to describe Checkpointing procedures.
	6.2 Allow FT Protection TLV on Keepalive message.
	7.1 Add Unexpected FT Cork TLV status code
	7.2 Define bits in the FT Session TLV to define which FT
	processes are in use.
	7.3 Allow FT Protection TLV on Keepalive message.
	7.5 Add FT Cork TLV
	8. Add examples of further message flows.
	10.2.1 Add description of Ack generation logic when using
	check-pointing
	14.4 Add FT Cork TLV
	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		Definitions of key words and terms applicable to LDP and
	CR-LDP are inherited from [2] and [4].		CR-LDP are inherited from [RFC3212] and [RFC3036].
	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		indicated a label for which some fault tolerant operation
	used. A "non-FT label" is not fault tolerant and is		is used. A "non-FT Label" is not fault tolerant and is
	handled as specified in [2] and [4].		handled as specified in [RFC3212] and [RFC3036].
			The term "Sequence Numbered FT Label" is used to indicate
			an FT label which is secured using the sequence number in
			the FT Protection TLV described in this document.
			The term "Checkpointable FT Label" is used to indicate an
			FT label which is secured by using the checkpointing
			techniques described in this document.
	The extensions to LDP specified in this document are		The extensions to LDP specified in this document are
	collectively referred to as the "LDP FT enhancements".		collectively referred to as the "LDP FT enhancements".
	Within the context of this draft, "Checkpointing" refers		Within the context of this draft, "Checkpointing" refers
	to a process of messages exchanges that confirm receipt		to a process of messages exchanges that confirm receipt
	and processing (or secure storage) of specific protocol		and processing (or secure storage) of specific protocol
	messages.		messages.
	In the examples quoted, the following notation is used.		In the examples quoted, the following notation is used:
	Ln : An LSP. For example L1.		Ln : An LSP. For example L1.
	Pn : An LDP peer. For example P1.		Pn : An LDP peer. For example P1.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",		"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
	"MAY", and "OPTIONAL" in this document are to be		"MAY", and "OPTIONAL" in this document are to be
	interpreted as described in RFC-2119 [3].		interpreted as described in RFC-2119 [RFC2119].
	2. Introduction		2. Introduction
	High Availability (HA) is typically claimed by equipment		High Availability (HA) is typically claimed by equipment
	vendors when their hardware achieves availability levels		vendors when their hardware achieves availability levels
	of at least 99.999% (five 9s). To implement this, the		of at least 99.999% (five 9s). To implement this, the
	equipment must be capable of recovering from local		equipment must be capable of recovering from local
	hardware and software failures through a process known as		hardware and software failures through a process known as
	fault tolerance (FT).		fault tolerance (FT).
	skipping to change at page 7, line 10		skipping to change at page 6, line 41
	- re-issuing lost messages after failover to ensure that		- re-issuing lost messages after failover to ensure that
	LSP/label state is correctly recovered after reconnection of		LSP/label state is correctly recovered after reconnection of
	the LDP session.		the LDP session.
	Other objectives of this draft are to		Other objectives of this draft are to
	- offer back-compatibility with LSRs that do not implement		- offer back-compatibility with LSRs that do not implement
	these proposals		these proposals
	- preserve existing protocol rules described in [2] and [4]		- preserve existing protocol rules described in [RFC3212]
	for handling unexpected duplicate messages and for		and [RFC3036] for handling unexpected duplicate messages and
	processing unexpected messages referring to unknown		for processing unexpected messages referring to unknown
	LSPs/labels		LSPs/labels
	- integrate with the LSP modification function described in [5]		- integrate with the LSP modification function described in
			[RFC3214]
	- avoid full state refresh solutions (such as those present		- avoid full state refresh solutions (such as those present
	in RSVP: see [6], [7], [8] and [12]) whether they be full-		in RSVP: see [RFC2205], [RFC2961], [RFC3209] and [LDP-
	time, or limited to post-failover recovery.		RESTART]) whether they be full-time, or limited to post-
			failover recovery.
	Note that this draft concentrates on the preservation of		Note that this draft concentrates on the preservation of
	label state for labels exchanged between a pair of		label state for labels exchanged between a pair of
	adjacent LSRs when the TCP connection between those LSRs		adjacent LSRs when the TCP connection between those LSRs
	is lost. This is a requirement for Fault Tolerant		is lost. This is a requirement for Fault Tolerant
	operation of LSPs, but a full implementation of end-to-		operation of LSPs, but a full implementation of end-to-
	end protection for LSPs requires that this is combined		end protection for LSPs requires that this is combined
	with other techniques that are outside the scope of this		with other techniques that are outside the scope of this
	draft.		draft.
	In particular, this draft does not attempt to describe		In particular, this draft does not attempt to describe
	how to modify the routing of an LSP or the resources		how to modify the routing of an LSP or the resources
	allocated to a label or LSP, which is covered by [5].		allocated to a label or LSP, which is covered by
	This draft also does not address how to provide automatic		[RFC3214]. This draft also does not address how to
	layer 2/3 protection switching for a label or LSP, which		provide automatic layer 2/3 protection switching for a
	is a separate area for study.		label or LSP, which is a separate area for study.
	This specification does not preclude an implementation		This specification does not preclude an implementation
	from attempting (or require it to attempt) to use the FT		from attempting (or require it to attempt) to use the FT
	behavior described here to recover from a preemptive		behavior described here to recover from a preemptive
	failure of a connection on a non-FT system due to, for		failure of a connection on a non-FT system due to, for
	example, a partial system crash. Note, however, that		example, a partial system crash. Note, however, that
	there are potential issues too numerous to list here -		there are potential issues too numerous to list here -
	not least the likelihood that the same crash will		not least the likelihood that the same crash will
	immediately occur when processing the restored data.		immediately occur when processing the restored data.
	skipping to change at page 8, line 6		skipping to change at page 7, line 45
	- The presence of an FT Session TLV on the LDP		- The presence of an FT Session TLV on the LDP
	Initialization message indicates that an LSR supports some		Initialization message indicates that an LSR supports some
	form of protection or recovery from session failure. A flag		form of protection or recovery from session failure. A flag
	bit within this TLV (the S bit) indicates that the LSR		bit within this TLV (the S bit) indicates that the LSR
	supports the LDP FT enhancements on this session. Another		supports the LDP FT enhancements on this session. Another
	flag (the C bit) indicates that the checkpointing procedures		flag (the C bit) indicates that the checkpointing procedures
	are to be used.		are to be used.
	- An FT Reconnect Flag in the FT Session TLV indicates		- An FT Reconnect Flag in the FT Session TLV indicates
	whether an LSR has preserved FT label state across a failure		whether an LSR has preserved FT Label state across a failure
	of the TCP connection.		of the TCP connection.
	- An FT Reconnection Timeout, exchanged on the LDP		- An FT Reconnection Timeout, exchanged on the LDP
	Initialization message, that indicates the maximum time peer		Initialization message, that indicates the maximum time peer
	LSRs will preserve FT label state after a failure of the TCP		LSRs will preserve FT Label state after a failure of the TCP
	connection.		connection.
	- An FT Protection TLV used to identify operations that		- An FT Protection TLV used to identify operations that
	affect LDP labels. All LDP messages carrying the FT		affect LDP labels. All LDP messages carrying the FT
	Protection TLV need to be secured (e.g. to NVRAM) and ACKed		Protection TLV need to be secured (e.g. to NVRAM) and ACKed
	to the sending LDP peer in order that the state for FT		to the sending LDP peer in order that the state for Sequence
	labels can be correctly recovered after LDP session		Numbered FT Labels can be correctly recovered after LDP
	reconnection.		session reconnection.
	Note that the implementation within an FT system is left		Note that the implementation within an FT system is left
	open by this draft. An implementation could choose to		open by this draft. An implementation could choose to
	secure entire messages relating to FT labels, or it could		secure entire messages relating to Sequence Numbered FT
	secure only the relevant state information.		Labels, or it could secure only the relevant state
			information.
	- Address advertisement may also be secured by use of the		- Address advertisement may also be secured by use of the
	FT Protection TLV. This enables recovery after LDP session		FT Protection TLV. This enables recovery after LDP session
	reconnection without the need to re-advertise what may be a		reconnection without the need to re-advertise what may be a
	very large number of addresses.		very large number of addresses.
	- The FT Protection TLV may also be used on the Keepalive		- The FT Protection TLV may also be used on the Keepalive
	message to flush acknowledgement of all previous FT		message to flush acknowledgement of all previous FT
	operations. This enables a check-point for future recovery,		operations. This enables a check-point for future recovery,
	either in mid-session or prior to graceful shutdown of an		either in mid-session or prior to graceful shutdown of an
	LDP session. This procedure may also be used to checkpoint		LDP session. This procedure may also be used to checkpoint
	all (that is both FT and non-FT) operations for future		all (that is both FT and non-FT) operations for future
	recovery.		recovery.
	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]		In order that the extensions to LDP [RFC3036] and CR-LDP
	described in this draft can be used successfully on an		[RFC3212] described in this draft can be used
	LDP session between a pair of LDP peers, they MUST		successfully on an LDP session between a pair of LDP
	negotiate that the LDP FT enhancements are to be used on		peers, they MUST negotiate that the LDP FT enhancements
	the LDP session.		are to be used on the LDP session.
	This is done on the LDP Initialization message exchange		This is done on the LDP Initialization message exchange
	using a new FT Session TLV. Presence of this TLV		using a new FT Session TLV. Presence of this TLV
	indicates that the peer wants to support some form of		indicates that the peer wants to support some form of
	protection or recovery processing. The S bit within this		protection or recovery processing. The S bit within this
	TLV indicates that the peer wants to support the LDP FT		TLV indicates that the peer wants to support the LDP FT
	enhancements on this LDP session. The C bit indicates		enhancements on this LDP session. The C bit indicates
	that the peer wants to support the checkpointing		that the peer wants to support the checkpointing
	functions described in this draft. The S and C bits may		functions described in this draft. The S and C bits may
	be set independently.		be set independently.
	skipping to change at page 10, line 9		skipping to change at page 9, line 45
	- Sockets send failure.		- Sockets send failure.
	- New (incoming) Socket opened.		- New (incoming) Socket opened.
	- LDP protocol timeout.		- LDP protocol timeout.
	3.2.2 LDP Processing after Connection Failure		3.2.2 LDP Processing after Connection Failure
	If the LDP FT enhancements are not in use on an LDP		If the LDP FT enhancements are not in use on an LDP
	session, the action of the LDP peers on failure of the		session, the action of the LDP peers on failure of the
	TCP connection is as specified in [2] and [4].		TCP connection is as specified in [RFC3212] and
			[RFC3036].
	All state information and resources associated with non-		All state information and resources associated with non-
	FT labels MUST be released on the failure of the TCP		FT Labels MUST be released on the failure of the TCP
	connection, including deprogramming the non-FT label from		connection, including deprogramming the non-FT Label from
	the switching hardware. This is equivalent to the		the switching hardware. This is equivalent to the
	behavior specified in [4].		behavior specified in [RFC3036].
	If the LDP FT enhancements are in use on an LDP session,		If the LDP FT enhancements are in use on an LDP session,
	both LDP peers SHOULD preserve state information and		both LDP peers SHOULD preserve state information and
	resources associated with FT labels exchanged on the LDP		resources associated with FT Labels exchanged on the LDP
	session. Both LDP peers SHOULD use a timer to release		session. Both LDP peers SHOULD use a timer to release
	the preserved state information and resources associated		the preserved state information and resources associated
	with FT-labels if the TCP connection is not restored		with FT-labels if the TCP connection is not restored
	within a reasonable period. The behavior when this timer		within a reasonable period. The behavior when this timer
	expires is equivalent to the LDP session failure behavior		expires is equivalent to the LDP session failure behavior
	described in [4].		described in [RFC3036].
	The FT Reconnection Timeout each LDP peer intends to		The FT Reconnection Timeout each LDP peer intends to
	apply to the LDP session is carried in the FT Session TLV		apply to the LDP session is carried in the FT Session TLV
	on the LDP Initialization messages. Both LDP peers MUST		on the LDP Initialization messages. Both LDP peers MUST
	use the value that corresponds to the lesser timeout		use the value that corresponds to the lesser timeout
	interval of the two proposed timeout values from the LDP		interval of the two proposed timeout values from the LDP
	Initialization exchange, where a value of zero is treated		Initialization exchange, where a value of zero is treated
	as positive infinity.		as positive infinity.
	3.3. Data Forwarding During TCP Connection Failure		3.3. Data Forwarding During TCP Connection Failure
	skipping to change at page 11, line 28		skipping to change at page 11, line 9
	If an LDP peer has preserved all state information for		If an LDP peer has preserved all state information for
	previous instantiations of the LDP session, then it		previous instantiations of the LDP session, then it
	SHOULD set the FT Reconnect Flag to 1 in the FT Session		SHOULD set the FT Reconnect Flag to 1 in the FT Session
	TLV. Otherwise, it MUST set the FT Reconnect Flag to 0.		TLV. Otherwise, it MUST set the FT Reconnect Flag to 0.
	If either LDP peer sets the FT Reconnect Flag to 0, or		If either LDP peer sets the FT Reconnect Flag to 0, or
	omits the FT Session TLV, both LDP peers MUST release any		omits the FT Session TLV, both LDP peers MUST release any
	state information and resources associated with the		state information and resources associated with the
	previous instantiation of the LDP session between the		previous instantiation of the LDP session between the
	same LDP peers, including FT label state and Addresses.		same LDP peers, including FT Label state and Addresses.
	This ensures that network resources are not permanently		This ensures that network resources are not permanently
	lost by one LSR if its LDP peer is forced to undergo a		lost by one LSR if its LDP peer is forced to undergo a
	cold start.		cold start.
	If an LDP peer changes any session parameters (for		If an LDP peer changes any session parameters (for
	example, the label space bounds) from the previous		example, the label space bounds) from the previous
	instantiation the nature of any preserved labels may have		instantiation the nature of any preserved labels may have
	changed. In particular, previously allocated labels may		changed. In particular, previously allocated labels may
	now be out of range. For this reason, session		now be out of range. For this reason, session
	reconnection MUST use the same parameters as were in use		reconnection MUST use the same parameters as were in use
	on the session before the failure. If an LDP peer		on the session before the failure. If an LDP peer
	notices that the parameters have been changed by the		notices that the parameters have been changed by the
	other peer it SHOULD send a Notification message with the		other peer it SHOULD send a Notification message with the
	'FT Session parameters changed' status code.		'FT Session parameters changed' status code.
	If both LDP peers set the FT Reconnect Flag to 1, both		If both LDP peers set the FT Reconnect Flag to 1, both
	LDP peers MUST use the FT label operation procedures		LDP peers MUST use the procedures indicated in this draft
	indicated in this draft to complete any label operations		to complete any label operations on Sequence Numbered FT
	on FT labels that were interrupted by the LDP session		Labels that were interrupted by the LDP session failure.
	failure.
	If an LDP peer receives an LDP Initialization message		If an LDP peer receives an LDP Initialization message
	with the FT Reconnect Flag set before it sends its own		with the FT Reconnect Flag set before it sends its own
	Initialization message, but has retained no information		Initialization message, but has retained no information
	about the previous version of the session, it MUST		about the previous version of the session, it MUST
	respond with an Initialization message with the FT		respond with an Initialization message with the FT
	Reconnect Flag clear. If an LDP peer receives an LDP		Reconnect Flag clear. If an LDP peer receives an LDP
	Initialization message with the FT Reconnect Flag set in		Initialization message with the FT Reconnect Flag set in
	response to an Initialization message that it has sent		response to an Initialization message that it has sent
	with the FT Reconnect Flag clear it MUST act as if no		with the FT Reconnect Flag clear it MUST act as if no
	state was retained by either peer on the session.		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		Label operations on Sequence Numbered FT Labels are made
	providing acknowledgement of all LDP messages that affect		Fault Tolerant by providing acknowledgement of all LDP
	FT labels.Acknowledgements are achieved by means of		messages that affect Sequence Numbered FT Labels.
	sequence numbers on these LDP messages.		Acknowledgements are achieved by means of sequence
			numbers on these LDP messages.
	The message exchanges used to achieve acknowledgement of		The message exchanges used to achieve acknowledgement of
	label operations and the procedures used to complete		label operations and the procedures used to complete
	interrupted label operations are detailed in the section		interrupted label operations are detailed in the section
	"FT Operations".		"FT Operations".
	Using these acknowledgements and procedures, it is not		Using these acknowledgements and procedures, it is not
	necessary for LDP peers to perform a complete re-		necessary for LDP peers to perform a complete re-
	synchronization of state for all FT labels, either on re-		synchronization of state for all Sequence Numbered FT
	connection of the LDP session between the LDP peers or on		Labels, either on re-connection of the LDP session
	a timed basis.		between the LDP peers or on a timed basis.
	3.6. Check-Pointing		3.6. Check-Pointing
	Check-pointing is a useful feature that allows nodes to		Check-pointing is a useful feature that allows nodes to
	reduce the amount of processing that they need to do to		reduce the amount of processing that they need to do to
	acknowledge LDP messages. The C bit in the FT Session		acknowledge LDP messages. The C bit in the FT Session
	TLV is used to indicate that checkpointing is supported.		TLV is used to indicate that checkpointing is supported.
	Under the normal operation on FT labels, acknowledgments		Under the normal operation on Sequence Numbered FT
	may be deferred during normal processing and only sent		Labels, acknowledgments may be deferred during normal
	periodically. Check-pointing may be used to flush		processing and only sent periodically. Check-pointing
	acknowledgement from a peer by including a sequence		may be used to flush acknowledgement from a peer by
	number on a Keepalive message requesting acknowledgement		including a sequence number on a Keepalive message
	of that message and all previous messages.		requesting acknowledgement of that message and all
			previous messages. In this case, all Sequence Numbered
			FT Labels are Checkpointable FT Labels.
	If the S bit is not agreed upon, checkpointing may still		If the S bit is not agreed upon, checkpointing may still
	be used. In this case it is used to acknowledge all		be used. In this case it is used to acknowledge all
	messages exchanged between the peers.		messages exchanged between the peers, and all labels are
			Checkpointable FT Labels.
	This offers an approach where acknowledgements need not		This offers an approach where acknowledgements need not
	be sent to every message or even frequently, but are only		be sent to every message or even frequently, but are only
	sent as check-points in response to requests carried on		sent as check-points in response to requests carried on
	Keepalive messages. Such an approach may be considered		Keepalive messages. Such an approach may be considered
	optimal in systems that do not show a high degree of		optimal in systems that do not show a high degree of
	change over time (such as targeted LDP session or CR-LDP		change over time (such as targeted LDP session or CR-LDP
	systems) and that are prepared to risk loss of state for		systems) and that are prepared to risk loss of state for
	the most recent LDP exchanges. More dynamic systems		the most recent LDP exchanges. More dynamic systems
	(such as LDP discovery sessions) are more likely to want		(such as LDP discovery sessions) are more likely to want
	skipping to change at page 14, line 39		skipping to change at page 14, line 31
	bit in the FT Session TLV on the Session Initialization		bit in the FT Session TLV on the Session Initialization
	message as described in the section "Establishing an FT		message as described in the section "Establishing an FT
	LDP Session", both LDP peers MUST apply the procedures		LDP Session", both LDP peers MUST apply the procedures
	described in this section for FT LDP message exchanges.		described in this section for FT LDP message exchanges.
	If the LDP session has been negotiated to not use the LDP		If the LDP session has been negotiated to not use the LDP
	FT enhancements, these procedures MUST NOT be used.		FT enhancements, these procedures MUST NOT be used.
	4.1. FT LDP Messages		4.1. FT LDP Messages
	4.1.1 FT Label Messages		4.1.1 Sequence Numbered FT Label Messages
	A label is identified as being an FT label if the initial		A label is identified as being a Sequence Numbered FT
	Label Request or Label Mapping message relating to that		Label if the initial Label Request or Label Mapping
	label carries the FT Protection TLV.		message relating to that label carries the FT Protection
			TLV.
	It is a valid implementation option to flag all labels as		It is a valid implementation option to flag all labels as
	FT labels. Indeed this may be a preferred option for		Sequence Numbered FT Labels. Indeed this may be a
	implementations wishing to use Keepalive messages		preferred option for implementations wishing to use
	carrying the FT Protection TLV to achieve periodic saves		Keepalive messages carrying the FT Protection TLV to
	of the complete label forwarding state.		achieve periodic saves of the complete label forwarding
			state.
	If a label is an FT label, all LDP messages affecting
	that label MUST carry the FT Protection TLV in order that
	the state of the label can be recovered after a failure
	of the LDP session.
	A valid option is for no labels on an FT session to be FT
	labels.
	The checkpointing mechanism (see section 5) is an integral		If a label is a Sequence Numbered FT Label, all LDP
	part of the FT procedures and is available whenever the FT		messages affecting that label MUST carry the FT
	procedures are selected. When the FT procedures are in use		Protection TLV in order that the state of the label can
	checkpointing applies only to FT labels. If no labels on		be recovered after a failure of the LDP session.
	the session are FT labels but the use of the FT procedures
	has been negotiated, checkpointing will not secure any
	message exchanges.
	If the FT procedures are not in use, checkpointing using the		A valid option is for no labels to be Sequence Numbered
	Keepalive message applies to all messages exchanged on the		FT Labels. In this case checkpointing using the
	session.		Keepalive message applies to all messages exchanged on
			the session.
	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		The scope of the FT/non-FT status of a label is limited
	to the LDP message exchanges between a pair of LDP peers.		to the LDP message exchanges between a pair of LDP peers.
	In Ordered Control, when the message is forwarded		In Ordered Control, when the message is forwarded
	downstream or upstream, the TLV may be present or absent		downstream or upstream, the TLV may be present or absent
	according to the requirements of the LSR sending the		according to the requirements of the LSR sending the
	message.		message.
	If a platform-wide label space is used for FT labels, an		If a platform-wide label space is used for FT Labels, an
	FT label value MUST NOT be reused until all LDP FT peers		FT Label value MUST NOT be reused until all LDP FT peers
	to which the label was passed have acknowledged the		to which the label was passed have acknowledged the
	withdrawal of the FT label, either by an explicit LABEL		withdrawal of the FT Label, either by an explicit LABEL
	WITHDRAW/LABEL RELEASE exchange or implicitly if the LDP		WITHDRAW/LABEL RELEASE exchange or implicitly if the LDP
	session is reconnected after failure but without the FT		session is reconnected after failure but without the FT
	Reconnect Flag set. In the event that a session is not		Reconnect Flag set. In the event that a session is not
	re-established within the Reconnection Timeout, a label		re-established within the Reconnection Timeout, a label
	MAY become available for re-use if it is not still in use		MAY become available for re-use if it is not still in use
	on some other session.		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		If an LDP session uses the LDP FT enhancements, both LDP
	skipping to change at page 15, line 57		skipping to change at page 15, line 45
	on a previous instantiation of a recovered LDP session is		on a previous instantiation of a recovered LDP session is
	no longer valid, it MUST explicitly issue an Address		no longer valid, it MUST explicitly issue an Address
	Withdraw for that address when the session is		Withdraw for that address when the session is
	reconnected.		reconnected.
	If the FT Reconnect Flag is not set by both LDP peers on		If the FT Reconnect Flag is not set by both LDP peers on
	reconnection of an LDP session (i.e. state has not been		reconnection of an LDP session (i.e. state has not been
	preserved), both LDP peers MUST consider all Addresses to		preserved), both LDP peers MUST consider all Addresses to
	have been withdrawn. The LDP peers SHOULD issue new		have been withdrawn. The LDP peers SHOULD issue new
	Address messages for all their valid addresses as		Address messages for all their valid addresses as
	specified in [4].		specified in [RFC3036].
	4.1.3 FT Label Resources Available Notification Messages		4.1.3 Label Resources Available Notifications
	In LDP, it is possible that a downstream LSR may not have		In LDP, it is possible that a downstream LSR may not have
	labels available to respond to a Label Request. In this		labels available to respond to a Label Request. In this
	case, as specified in RFC3036, the downstream LSR must		case, as specified in RFC3036, the downstream LSR must
	respond with a Notification - No Label Resources message.		respond with a Notification - No Label Resources message.
	The upstream LSR then suspends asking for new labels		The upstream LSR then suspends asking for new labels
	until it receives a Notification - Label Resources		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 session		When the FT extensions are used on a session,
	implementations may choose whether to secure the label		implementations may choose whether to secure the label
	resource state of their peer or not. This choice impacts		resource state of their peer or not. This choice impacts
	the number of LDP messages that will be incorrectly		the number of LDP messages that will be incorrectly
	routed to a peer with depleted resources on session re-		routed to a peer with depleted resources on session re-
	establishment, but does not otherwise impact		establishment, but does not otherwise impact
	interoperability.		interoperability.
	For full preservation of state:		For full preservation of state:
	- The downstream LSR must preserve the label availability		- The downstream LSR must preserve the label availability
	skipping to change at page 18, line 9		skipping to change at page 17, line 54
	sequence numbers (because its partner on the session has		sequence numbers (because its partner on the session has
	not acknowledged them in a timely way) it cannot allocate		not acknowledged them in a timely way) it cannot allocate
	a new sequence number for any further FT LPD message. It		a new sequence number for any further FT LPD message. It
	SHOULD send a Notification message with the status code		SHOULD send a Notification message with the status code
	"FT Seq Numbers Exhausted".		"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,		If the LDP FT enhancements are in use on an LDP session,
	each LDP peer SHOULD NOT release the state information		each LDP peer SHOULD NOT release the state information
	and resources associated with FT labels exchanged on that		and resources associated with FT Labels exchanged on that
	LDP session when the TCP connection fails. This is		LDP session when the TCP connection fails. This is
	contrary to [2] and [4], but allows label operations on		contrary to [RFC3212] and [RFC3036], but allows label
	FT labels to be completed after re-connection of the TCP		operations on FT Labels to be completed after re-
	connection.		connection of the TCP connection.
	Both LDP peers on an LDP session that is using the LDP FT		Both LDP peers on an LDP session that is using the LDP FT
	enhancements SHOULD preserve the state information and		enhancements SHOULD preserve the state information and
	resources they hold for that LDP session as described		resources they hold for that LDP session as described
	below.		below.
	- An upstream LDP peer SHOULD release the resources (in		- An upstream LDP peer SHOULD release the resources (in
	particular bandwidth) associated with an FT label when it		particular bandwidth) associated with a Sequence Numbered FT
	initiates a Label Release or Label Abort message for the		Label when it initiates a Label Release or Label Abort
	label. The upstream LDP peer MUST preserve state		message for the label. The upstream LDP peer MUST preserve
	information for the label, even if it releases the resources		state information for the Sequence Numbered FT Label, even
	associated with the label, as it may need to reissue the		if it releases the resources associated with the label, as
	label operation if the TCP connection is interrupted.		it may need to reissue the label operation if the TCP
			connection is interrupted.
	- An upstream LDP peer MUST release the state information		- An upstream LDP peer MUST release the state information
	and resources associated with an FT label when it receives		and resources associated with a Sequence Numbered FT Label
	an acknowledgement to a Label Release or Label Abort message		when it receives an acknowledgement to a Label Release or
	that it sent for the label, or when it sends a Label Release		Label Abort message that it sent for the label, or when it
	message in response to a Label Withdraw message received		sends a Label Release message in response to a Label
	from the downstream LDP peer.		Withdraw message received from the downstream LDP peer.
	- A downstream LDP peer SHOULD NOT release the resources		- A downstream LDP peer SHOULD NOT release the resources
	associated with an FT label when it sends a Label Withdraw		associated with a Sequence Numbered FT Label when it sends a
	message for the label as it has not yet received		Label Withdraw message for the label as it has not yet
	confirmation that the upstream LDP peer has ceased to send		received confirmation that the upstream LDP peer has ceased
	data using the label. The downstream LDP peer MUST NOT		to send data using the label. The downstream LDP peer MUST
	release the state information it holds for the label as it		NOT release the state information it holds for the label as
	may yet have to reissue the label operation if the TCP		it may yet have to reissue the label operation if the TCP
	connection is interrupted.		connection is interrupted.
	- A downstream LDP peer MUST release the resources and		- A downstream LDP peer MUST release the resources and
	state information associated with an FT label when it		state information associated with a Sequence Numbered FT
	receives an acknowledgement to a Label Withdraw message for		Label when it receives an acknowledgement to a Label
	the label.		Withdraw message for the label.
	- When the FT Reconnection Timeout expires, an LSR SHOULD		- When the FT Reconnection Timeout expires, an LSR SHOULD
	release all state information and resources from previous		release all state information and resources from previous
	instantiations of the (permanently) failed LDP session.		instantiations of the (permanently) failed LDP session.
	- Either LDP peer MAY elect to release state information		- Either LDP peer MAY elect to release state information
	based on its internal knowledge of the loss of integrity of		based on its internal knowledge of the loss of integrity of
	the state information or an inability to pend (or queue) LDP		the state information or an inability to pend (or queue) LDP
	operations (as described in section 4.4.1) during a TCP		operations (as described in section 4.4.1) during a TCP
	failure. That is, the peer is not required to wait for the		failure. That is, the peer is not required to wait for the
	skipping to change at page 19, line 33		skipping to change at page 19, line 21
	set the E-bit without knowledge of the implementation of		set the E-bit without knowledge of the implementation of
	that partner LSR.		that partner LSR.
	Note that the "Temporary Shutdown" status code does not have		Note that the "Temporary Shutdown" status code does not have
	the E-bit set, and MAY be used during maintenance or upgrade		the E-bit set, and MAY be used during maintenance or upgrade
	operations to indicate that the LSR intends to preserve		operations to indicate that the LSR intends to preserve
	state across a closure and re-establishment of the TCP		state across a closure and re-establishment of the TCP
	session.		session.
	- If an LSR determines that it must release state for any		- If an LSR determines that it must release state for any
	single FT label during a failure of the TCP connection on		single FT Label during a failure of the TCP connection on
	which that label was exchanged, it MUST release all state		which that label was exchanged, it MUST release all state
	for all labels on the LDP session.		for all labels on the LDP session.
	The release of state information and resources associated		The release of state information and resources associated
	with non-FT labels is as described in [2] and [4].		with non-FT labels is as described in [RFC3212] and
			[RFC3036].
	Note that a Label Release and the acknowledgement to a		Note that a Label Release and the acknowledgement to a
	Label Withdraw may be received by a downstream LSR in any		Label Withdraw may be received by a downstream LSR in any
	order. The downstream LSR MAY release its resources on		order. The downstream LSR MAY release its resources on
	receipt of the first message and MUST release its		receipt of the first message and MUST release its
	resources on receipt of the second message.		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		When an LSR discovers or is notified of a TCP connection
	skipping to change at page 20, line 32		skipping to change at page 20, line 21
	Reconnect Flag to 0 if it released the preserved state		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		If the TCP connection is successfully re-established
	within the FT Reconnection Timeout, both peers MUST re-		within the FT Reconnection Timeout, both peers MUST re-
	issue LDP operations that were interrupted by (that is,		issue LDP operations that were interrupted by (that is,
	un-acknowledged as a result of) the TCP connection		un-acknowledged as a result of) the TCP connection
	failure. This procedure is described in section "FT		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 (see [4] section		The Hold Timer for an FT LDP Session (see [RFC3036]
	2.5.5) SHOULD be ignored while the FT Reconnection Timer		section 2.5.5) SHOULD be ignored while the FT
	is running. The hold timer SHOULD be restarted when the		Reconnection Timer is running. The hold timer SHOULD be
	TCP connection is re-established.		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		When the LDP FT enhancements are in use for an LDP
	session, it is possible that an LSR may determine that it		session, it is possible that an LSR may determine that it
	needs to send an LDP message to an LDP peer but that the		needs to send an LDP message to an LDP peer but that the
	TCP connection to that peer is currently down. These		TCP connection to that peer is currently down. These
	label operations affect the state of FT labels preserved		label operations affect the state of FT Labels preserved
	for the failed TCP connection, so it is important that		for the failed TCP connection, so it is important that
	the state changes are passed to the LDP peer when the TCP		the state changes are passed to the LDP peer when the TCP
	connection is restored.		connection is restored.
	If an LSR determines that it needs to issue a new FT LDP		If an LSR determines that it needs to issue a new FT LDP
	operation to an LDP peer to which the TCP connection is		operation to an LDP peer to which the TCP connection is
	currently failed, it MUST pend the operation (e.g. on a		currently failed, it MUST pend the operation (e.g. on a
	queue) and complete that operation with the LDP peer when		queue) and complete that operation with the LDP peer when
	the TCP connection is restored, unless the label		the TCP connection is restored, unless the label
	operation is overridden by a subsequent additional		operation is overridden by a subsequent additional
	operation during the TCP connection failure (see section		operation during the TCP connection failure (see section
	"FT Procedure After TCP Re-connection").		"FT Procedure After TCP Re-connection").
	If, during TCP Failure, an LSR determines that it cannot		If, during TCP Failure, an LSR determines that it cannot
	pend an operation which it cannot simply fail (for		pend an operation which it cannot simply fail (for
	example a Label Withdraw, Release, or Abort operation),		example, a Label Withdraw, Release or Abort operation),
	it MUST NOT attempt to re-establish the previous LDP		it MUST NOT attempt to re-establish the previous LDP
	session. The LSR MUST behave as if the Reconnection		session. The LSR MUST behave as if the Reconnection
	Timer expired and release all state information with		Timer expired and release all state information with
	respect to the LDP peer. An LSR may be unable (or		respect to the LDP peer. An LSR may be unable (or
	unwilling) to pend operations; for instance, if a major		unwilling) to pend operations; for instance, if a major
	routing transition occurred while TCP was inoperable		routing transition occurred while TCP was inoperable
	between LDP peers it might result in excessively large		between LDP peers it might result in excessively large
	numbers of FT LDP Operations. An LSR that releases state		numbers of FT LDP Operations. An LSR that releases state
	before the expiration of the Reconnection Timeout MUST		before the expiration of the Reconnection Timeout MUST
	NOT re-use any label that was in use on the session until		NOT re-use any label that was in use on the session until
	the Reconnection Timeout has expired.		the Reconnection Timeout has expired.
	In ordered operation, received FT LDP operations that		In ordered operation, received FT LDP operations that
	cannot be correctly forwarded because of a TCP connection		cannot be correctly forwarded because of a TCP connection
	failure MAY be processed immediately (provided sufficient		failure MAY be processed immediately (provided sufficient
	state is kept to forward the label operation) or pended		state is kept to forward the label operation) or pended
	for processing when the onward TCP connection is restored		for processing when the onward TCP connection is restored
	and the operation can be correctly forwarded upstream or		and the operation can be correctly forwarded upstream or
	downstream. Operations on existing FT labels SHOULD NOT		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		It is RECOMMENDED that Label Request operations for new
	FT labels are not pended awaiting the re-establishment of		FT Labels are not pended awaiting the re-establishment of
	TCP connection that is awaiting recovery at the time the		TCP connection that is awaiting recovery at the time the
	LSR determines that it needs to issue the Label Request		LSR determines that it needs to issue the Label Request
	message. Instead, such Label Request operations SHOULD		message. Instead, such Label Request operations SHOULD
	be failed and, if necessary, a notification message		be failed and, if necessary, a notification message
	containing the "No LDP Session" status code sent		containing the "No LDP Session" status code sent
	upstream.		upstream.
	Label Requests for new non-FT labels MUST be rejected		Label Requests for new non-FT Labels MUST be rejected
	during TCP connection failure, as specified in [2] and		during TCP connection failure, as specified in [RFC3212]
	[4].		and [RFC3036].
	4.5. FT Procedure After TCP Re-connection		4.5. FT Procedure After TCP Re-connection
	The FT operation handshaking described above means that		The FT operation handshaking described above means that
	all state changes for FT labels and Address messages are		all state changes for Sequence Numbered FT Labels and
	confirmed or reproducible at each LSR.		Address messages are confirmed or reproducible at each LSR.
	If the TCP connection between LDP peers fails but is re-		If the TCP connection between LDP peers fails but is re-
	connected within the FT Reconnection Timeout, and both		connected within the FT Reconnection Timeout, and both
	LSRs have indicated they will be re-establishing the		LSRs have indicated they will be re-establishing the
	previous LDP session, both LDP peers on the connection		previous LDP session, both LDP peers on the connection
	MUST complete any label operations for FT labels that		MUST complete any label operations for Sequence Numbered
	were interrupted by the failure and re-connection of the		FT Labels that were interrupted by the failure and re-
	TCP connection.		connection of the TCP connection.
	The procedures for FT Reconnection Timeout MAY have been		The procedures for FT Reconnection Timeout MAY have been
	invoked as a result of either LDP peer being unable (or		invoked as a result of either LDP peer being unable (or
	unwilling) to pend operations which occurred during the		unwilling) to pend operations which occurred during the
	TCP Failure (as described in section 4.4.1).		TCP Failure (as described in section 4.4.1).
	If, for any reason, an LSR has been unable to pend		If, for any reason, an LSR has been unable to pend operations
	operations with respect to an LDP peer, as described in		with respect to an LDP peer, as described in section 4.4.1, the
	section 4.4.1, the LSR MUST set the FT Reconnect Flag to		LSR MUST set the FT Reconnect Flag to 0 on re-connection to that
	0 on re-connection to that LDP peer indicating that no FT		LDP peer indicating that no FT state has been preserved.
	state has been preserved.
	Label operations are completed using the procedure		Label operations are completed using the procedure described below.
	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,		On restoration of the TCP connection between LDP peers,
	any FT LDP messages that were lost because of the TCP		any LDP messages for Sequence Numbered FT Labels that
	connection failure are re-issued. The LDP peer that		were lost because of the TCP connection failure are re-
	receives a re-issued message processes the message as if		issued. The LDP peer that receives a re-issued message
	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		"Net-zero" combinations of messages need not be re-issued
	after re-establishment of the TCP connection between LDP		after re-establishment of the TCP connection between LDP
	peers. This leads to the following rules for re-issuing		peers. This leads to the following rules for re-issuing
	messages that are not ACKed by the LDP peer on the LDP		messages that are not ACKed by the LDP peer on the LDP
	Initialization message exchange after re-connection of		Initialization message exchange after re-connection of
	the TCP session.		the TCP session.
	- A Label Request message MUST be re-issued unless a Label		- A Label Request message MUST be re-issued unless a Label Abort
	Abort would be re-issued for the same FT label.		would be re-issued for the same Sequence Numbered FT Label.
	- A Label Mapping message MUST be re-issued unless a Label		- A Label Mapping message MUST be re-issued unless a Label
	Withdraw message would be re-issued for the same FT label.		Withdraw message would be re-issued for the same Sequence
			Numbered 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		Protection TLV MUST be re-issued if an acknowledgement had
	not previously been received.		not previously been received.
	Any FT label operations that were pended (see section "FT		Any FT Label operations that were pended (see section
	Label Operations During TCP Failure") during the TCP		4.4.1) during the TCP connection failure MUST also be
	connection failure MUST also be issued on re-		issued on re-establishment of the LDP session, except
	establishment of the LDP session, except where they form		where they form part of a "net-zero" combination of
	part of a "net-zero" combination of messages according to		messages according to the above rules.
	the above rules.
	The determination of "net-zero" FT label operations		The determination of "net-zero" FT Label operations
	according to the above rules MAY be performed on pended		according to the above rules MAY be performed on pended
	messages prior to the re-establishment of the TCP		messages prior to the re-establishment of the TCP
	connection in order to optimize the use of queue		connection in order to optimize the use of queue
	resources. Messages that were sent to the LDP peer		resources. Messages that were sent to the LDP peer
	before the TCP connection failure, or pended messages		before the TCP connection failure, or pended messages
	that are paired with them, MUST NOT be subject to such		that are paired with them, MUST NOT be subject to such
	optimization until an FT ACK TLV is received from the LDP		optimization until an FT ACK TLV is received from the LDP
	peer. This ACK allows the LSR to identify which messages		peer. This ACK allows the LSR to identify which messages
	were received by the LDP peer prior to the TCP connection		were received by the LDP peer prior to the TCP connection
	failure.		failure.
	4.5.2 Interaction with CR-LDP LSP Modification		4.5.2 Interaction with CR-LDP LSP Modification
	Re-issuing LDP messages for FT operation is orthogonal to		Re-issuing LDP messages for FT operation is orthogonal to
	the use of duplicate messages marked with the Modify		the use of duplicate messages marked with the Modify
	ActFlg, as specified in [5]. Each time an LSR uses the		ActFlg, as specified in [RFC3214]. Each time an LSR uses
	modification procedure for an FT LSP to issue a new Label		the modification procedure for an FT LSP to issue a new
	Request message, the FT label operation procedures MUST		Label Request message, the FT label operation procedures
	be separately applied to the new Label Request message.		MUST be separately applied to the new Label Request
			message to the same degree that they were applied to the
			original Label Request.
	5. Checkpointing Procedures		5. Checkpointing Procedures
	Checkpointing can be selected independently from the FT		Checkpointing can be selected independently from the FT
	procedures described above by using the C bit in the FT		procedures described above by using the C bit in the FT
	Session TLV on the Session Initialization message. Note,		Session TLV on the Session Initialization message. Note,
	however, that checkpointing is an integral part of the FT		however, that checkpointing is an integral part of the FT
	procedures. Setting the S and the C bit will achieve the		procedures. Setting the S and the C bit will achieve the
	same function as setting just the S bit.		same function as setting just the S bit.
	If the C bit is set, but the S bit is not set, no label		If the C bit is set, but the S bit is not set, no label
	is an FT label. Checkpointing is used to synchronize all		is aSequence Numbered FT Label. Instead, all labels are
	labels exchanges for labels requested or distributed by		Checkpointable FT Labels. Checkpointing is used to
	the LDP peer requesting the exchange up to the time of		synchronize all labels exchanges. No message apart from
	requesting the checkpoint. No message apart from the		the checkpoint request and acknowledgement carries an
	checkpoint request and acknowledgement carries an active		active sequence number. (Note that the Session
	sequence number. (Note that the Session Initialization		Initialization message may carry a sequence number to
	message may carry a sequence number to confirm that the		confirm that the checkpoint is still in place).
	checkpoint is still in place).
	It is an implementation matter to decide the ordering of		It is an implementation matter to decide the ordering of
	received messages and checkpoint requests to ensure that		received messages and checkpoint requests to ensure that
	checkpoint acknowledgements are secured.		checkpoint acknowledgements are secured.
	If the S and C bits are both set, or only the S bit is		If the S and C bits are both set, or only the S bit is
	set, checkpointing applies only to FT labels and to		set, checkpointing applies only to Sequence Numbered FT
	address messages.		Labels and to address messages.
	The set of all messages that are checkpointed in this way		The set of all messages that are checkpointed in this way
	is called the Checkpointable Messages.		is called the Checkpointable Messages.
	5.1 Checkpointing with the Keepalive Message		5.1. Checkpointing with the Keepalive Message
	If an LSR receives a FT Protection TLV on a Keepalive		If an LSR receives a FT Protection TLV on a Keepalive
	message, this is a request to flush the acknowledgements		message, this is a request to flush the acknowledgements
	for all previously received Checkpointable Messages on		for all previously received Checkpointable Messages on
	the session.		the session.
	As soon as the LSR has completed securing the		As soon as the LSR has completed securing the
	Checkpointable Messages (or state changes consequent on		Checkpointable Messages (or state changes consequent on
	those messages) received before the Keepalive, it MUST		those messages) received before the Keepalive, it MUST
	send an acknowledgement to the sequence number of the		send an acknowledgement to the sequence number of the
	skipping to change at page 24, line 29		skipping to change at page 24, line 5
	acknowledgements have been stored up, this may be		acknowledgements have been stored up, this may be
	immediately on receipt of the Keepalive.		immediately on receipt of the Keepalive.
	An example message flow showing this use of the Keepalive		An example message flow showing this use of the Keepalive
	message to perform a periodic check-point of state is		message to perform a periodic check-point of state is
	shown in section 8.		shown in section 8.
	An example message flow showing the use of checkpointing		An example message flow showing the use of checkpointing
	without the FT procedures is shown in section 8.		without the FT procedures is shown in section 8.
	5.2 Quiesce and Keepalive		5.2. Quiesce and Keepalive
	If the Keepalive Message also contains the FT Cork TLV,		If the Keepalive Message also contains the FT Cork TLV,
	this indicates that the peer LSR wishes to quiesce the		this indicates that the peer LSR wishes to quiesce the
	session prior to a graceful restart.		session prior to a graceful restart.
	It is RECOMMENDED that on receiving a Keepalive with the		It is RECOMMENDED that on receiving a Keepalive with the
	FT CORK TLV, an LSR should cease to send any further		FT CORK TLV, an LSR should cease to send any further
	label or address related messages on the session until it		label or address related messages on the session until it
	has been disconnected and reconnected, other than any		has been disconnected and reconnected, other than any
	messages generated while processing and securing any		messages generated while processing and securing any
	skipping to change at page 26, line 6		skipping to change at page 25, line 29
	FT Protection		FT Protection
	If present, specifies FT Sequence Number		If present, specifies FT Sequence Number
	for the LDP message. When present on a		for the LDP message. When present on a
	Keepalive message, this indicates a		Keepalive message, this indicates a
	solicited flush of the acknowledgements to		solicited flush of the acknowledgements to
	all previous LDP messages containing		all previous LDP messages containing
	sequence numbers and issued by the sender		sequence numbers and issued by the sender
	of the Keepalive on the same session.		of the Keepalive on the same session.
	FT Cork		FT Cork
	Only permitted if the FT Protection TLV is		Indicates that the remote LSR wishes to
	also present. Indicates that the remote		quiesce the LDP session. See section 5 for
	LSR wishes to quiesce the LDP session. See		the recommended action in such cases.
	section 4.2 for the recommended action in
	such cases.
	FT ACK TLV		FT ACK TLV
	If present, specifies the most recent FT		If present, specifies the most recent FT
	message that the sending LDP peer has been		message that the sending LDP peer has been
	able to secure.		able to secure.
	6.3. All Other LDP Session Messages		6.3. All Other LDP Session Messages
	The LDP FT enhancements add the following optional		The LDP FT enhancements add the following optional
	parameters to all other message types that flow on an LDP		parameters to all other message types that flow on an LDP
	skipping to change at page 27, line 25		skipping to change at page 26, line 45
	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		FT Session parameters / 1 0x000000xx
	changed		changed
	Unexpected FT Cork TLV 1 0x000000xx		Unexpected FT Cork TLV 1 0x000000xx
	The Temporary Shutdown status code SHOULD be used in		The Temporary Shutdown status code SHOULD be used in
	place of the Shutdown status code (which has the E-bit		place of the Shutdown status code (which has the E-bit
	set) if the LSR that is shutting down wishes to inform		set) if the LSR that is shutting down wishes to inform
	its LDP peer that it expects to be able to preserve FT		its LDP peer that it expects to be able to preserve FT
	label state and to return to service before the FT		Label state and to return to service before the FT
	Reconnection Timer expires.		Reconnection Timer expires.
	7.2. FT Session TLV		7.2. FT Session TLV
	LDP peers can negotiate whether the LDP session between		LDP peers can negotiate whether the LDP session between
	them supports FT extensions by using a new OPTIONAL		them supports FT extensions by using a new OPTIONAL
	parameter, the FT Session TLV, on LDP Initialization		parameter, the FT Session TLV, on LDP Initialization
	Messages.		Messages.
	The FT Session TLV is encoded as follows.		The FT Session TLV is encoded as follows.
	skipping to change at page 27, line 50		skipping to change at page 27, line 27
	|1|0| FT Session TLV (0x0503) | Length (= 12) |		|1|0| FT Session TLV (0x0503) | Length (= 12) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FT Flags | Reserved |		| FT Flags | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FT Reconnect Timeout (in milliseconds) |		| FT Reconnect Timeout (in milliseconds) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Recovery Time (in milliseconds) |		| Recovery Time (in milliseconds) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	FT Flags		FT Flags
	FT Flags: A 16 bit field that indicates various
	attributes the FT support on this LDP session.		FT Flags: A 16 bit field that indicates
	This fields is formatted as follows:		various attributes the FT support on this
			LDP session. This fields is formatted as
			follows:
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Reserved |S|A|C|L|		|R| Reserved |S|A|C|L|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	R: FT Reconnect Flag.		R: FT Reconnect Flag.
	Set to 1 if the sending LSR has		Set to 1 if the sending LSR has
	preserved state and resources for all		preserved state and resources for all
	FT-labels since the previous LDP		FT-labels since the previous LDP
	session between the same LDP peers,		session between the same LDP peers,
	and set to 0 otherwise. See the		and set to 0 otherwise. See the
	section "FT LDP Session Reconnection"		section "FT LDP Session Reconnection"
	for details of how this flag is used.		for details of how this flag is used.
	skipping to change at page 28, line 24		skipping to change at page 28, line 11
	If the FT Reconnect Flag is set, the		If the FT Reconnect Flag is set, the
	sending LSR MUST include an FT ACK TLV		sending LSR MUST include an FT ACK TLV
	on the LDP Initialization message.		on the LDP Initialization message.
	S: Save State Flag.		S: Save State Flag.
	Set to 1 if the use of the FT		Set to 1 if the use of the FT
	Protection TLV is supported on		Protection TLV is supported on
	messages other than the KeepAlive		messages other than the KeepAlive
	message used for chekpointing (see the		message used for chekpointing (see the
	C bit)		C bit). I.e., the S bit indicates hat
			some label on the session may be a
			Sequence Numbered FT Label.
	A: All-Label Protection Required		A: All-Label Protection Required
	Set to 1 if all labels on the session		Set to 1 if all labels on the session
	MUST be treated as FT Labels. This		MUST be treated as Sequence Numbered
	removes from a node the option of		FT Labels. This removes from a node
	treating some labels as FT labels and		the option of treating some labels as
	some labels as non-FT labels.		FT Labels and some labels as non-FT
			Labels.
	Passing this information may be		Passing this information may be
	considered helpful to a peer since it		considered helpful to a peer since it
	may allow it to make optimizations in		may allow it to make optimizations in
	its processing.		its processing.
	The A bit only has meaning if the S		The A bit only has meaning if the S
	bit is set.		bit is set.
	C: Checkpointing Flag.		C: Checkpointing Flag.
	Set to 1 to indicate that the		Set to 1 to indicate that the
	checkpointing procedures in this draft		checkpointing procedures in this draft
	are in use.		are in use.
	If the S bit is also set to 1 then the		If the S bit is also set to 1 then the
	C bit indicates that checkpointing is		C bit indicates that checkpointing is
	applied only to those message		applied only to Sequence Numbered FT
	exchanges that carry the FT Protection		Labels.
	TLV.
	If the S bit is set to 0 (zero) then		If the S bit is set to 0 (zero) then
	the C bit indicates that checkpointing		the C bit indicates that checkpointing
	applies to all message exchanges on		applies to all labels - all labels are
	the session.		Checkpointable FT Labels.
	L: Learn From Network Flag.		L: Learn From Network Flag.
	Set to 1 if the Fault Recovery		Set to 1 if the Fault Recovery
	procedures of [12] are to be used to		procedures of [LDP-RESTART] are to be
	re-learn state from the network.		used to re-learn state from the
			network.
	It is not valid for all of the S, C and L bits to be zero.		It is not valid for all of the S, C and L
			bits to be zero.
	It is not valid for both the L and either the S or C bits		It is not valid for both the L and either
	to be set to 1.		the S or C bits to be set to 1.
			All other bits in this field are currently
			reserved and SHOULD be set to zero on
			transmission and ignored on receipt.
			The following table summarizes the settings
			of these bits.
			S A C L Comments
			=========================
			0 x 0 0 Invalid
			0 x 0 1 See [LDP-RESTART]
			0 x 1 0 Checkpointing of all labels
			0 x 1 1 Invalid
			1 0 0 0 Full FT on selected labels
			1 1 0 0 Full FT on all labels
			1 x 0 1 Invalid
			1 x 1 0 Same as (S=1,A=x,C=0,L=0)
			1 x 1 1 Invalid.
	FT Reconnection Timeout		FT Reconnection Timeout
	If the S bit or C bit in the FT Flags field		If the S bit or C bit in the FT Flags field
	is set this indicates the period of time		is set this indicates the period of time
	the sending LSR will preserve state and		the sending LSR will preserve state and
	resources for FT labels exchanged on the		resources for FT Labels exchanged on the
	previous instantiation of an FT LDP session		previous instantiation of an FT LDP session
	that has currently failed. The timeout is		that has currently failed. The timeout is
	encoded as a 32-bit unsigned integer number		encoded as a 32-bit unsigned integer number
	of milliseconds.		of milliseconds.
	A value of zero in this field means that		A value of zero in this field means that
	the sending LSR will preserve state and		the sending LSR will preserve state and
	resources indefinitely.		resources indefinitely.
	See the section "FT Procedure After TCP		See section 4.4 for details of how this
	Failure" for details of how this field is		field is used.
	used.
	If the L bit is set to 1 in the FT Flags		If the L bit is set to 1 in the FT Flags
	field, the meaning of this field is defined		field, the meaning of this field is defined
	in [12].		in [LDP-RESTART].
	Recovery Time		Recovery Time
	The Recovery Time only has meaning if the L		The Recovery Time only has meaning if the L
	bit is set in the FT Flags. The meaning is		bit is set in the FT Flags. The meaning is
	defined in [12].		defined in [LDP-RESTART].
	7.3. FT Protection TLV		7.3. FT Protection TLV
	LDP peers use the FT Protection TLV to indicate that an		LDP peers use the FT Protection TLV to indicate that an
	LDP message contains an FT label operation.		LDP message contains an FT label operation.
	The FT Protection TLV MUST NOT be used in messages		The FT Protection TLV MUST NOT be used in messages
	flowing on an LDP session that does not support the LDP		flowing on an LDP session that does not support the LDP
	FT enhancements. Its presence in such messages SHALL be		FT enhancements. Its presence in such messages SHALL be
	treated as a protocol error by the receiving LDP peer		treated as a protocol error by the receiving LDP peer
	which SHOULD send a Notification message with the		which SHOULD send a Notification message with the
	'Unexpected TLV Session Not FT' status code.		'Unexpected TLV Session Not FT' status code. LSRs that
			do not recognize this TLV SHOULD respond with a
			Notification message with the 'Unknown TLV' status code.
	The FT Protection TLV MAY be carried on an LDP message		The FT Protection TLV MAY be carried on an LDP message
	transported on the LDP session after the initial exchange		transported on the LDP session after the initial exchange
	of LDP Initialization messages. In particular, this TLV		of LDP Initialization messages. In particular, this TLV
	MAY optionally be present on the following messages:		MAY optionally be present on the following messages:
	- Label Request Messages in downstream on-demand		- Label Request Messages in downstream on-demand
	distribution mode		distribution mode
	- Label Mapping messages in downstream unsolicited mode		- Label Mapping messages in downstream unsolicited mode
	- Keepalive messages used to request flushing of		- Keepalive messages used to request flushing of
	acknowledgement of all previous messages that contained this		acknowledgement of all previous messages that contained this
	TLV.		TLV.
	If a label is to be an FT label, then the Protection TLV		If a label is to be a Sequence Numbered FT Label, then
	MUST be present:		the Protection TLV MUST be 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		Here 'subsequent messages concerning this label' means
	any message whose Label TLV specifies this label or whose		any message whose Label TLV specifies this label or whose
	Label Request Message ID TLV specifies the initial Label		Label Request Message ID TLV specifies the initial Label
	Request message.		Request message.
	If a label is not to be an FT label, then the Protection		If a label is not to be a Sequence Numbered FT Label,
	TLV MUST NOT be present on any of these messages. The		then the Protection TLV MUST NOT be present on any of
	presence of the FT TLV on a message relating to a non-FT		these messages that relate to the label. The presence of
	label SHALL be treated as a protocol error by the		the FT TLV on a message relating to a non-FT Label SHALL
	receiving LDP peer which SHOULD send a notification		be treated as a protocol error by the receiving LDP peer
	message with the 'Unexpected TLV Label Not FT' status		which SHOULD send a notification message with the
	code.		'Unexpected TLV Label Not FT' status code.
	Where a Label Withdraw or Label Release message contains		Where a Label Withdraw or Label Release message contains
	only a FEC TLV and does not identify a single specific		only a FEC TLV and does not identify a single specific
	label, the FT TLV should be included in the message if		label, the FT TLV should be included in the message if
	any label affected by the message is an FT label. If		any label affected by the message is a Sequence Numbered
	there is any doubt as to whether an FT TLV should be		FT Label. If there is any doubt as to whether an FT TLV
	present, it is RECOMMENDED that the sender add the TLV.		should be present, it is RECOMMENDED that the sender add
			the TLV.
	When an LDP peer receives a Label Withdraw Message or		When an LDP peer receives a Label Withdraw Message or
	Label Release message that contains only a FEC, it SHALL		Label Release message that contains only a FEC, it SHALL
	accept the FT TLV if it is present regardless of the FT		accept the FT TLV if it is present regardless of the FT
	status of the labels which it affects.		status of the labels which it affects.
	If an LDP session is an FT session as determined by the		If an LDP session is an FT session as determined by the
	presence of the FT Session TLV with the S bit set on the		presence of the FT Session TLV with the S bit set on the
	LDP Initialization messages, the FT Protection TLV MUST		LDP Initialization messages, the FT Protection TLV MUST
	be present on all Address messages on the session.		be present on all Address messages on the session.
	skipping to change at page 31, line 24		skipping to change at page 31, line 42
	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 sequence number is encoded		The sequence number for this Sequence
	as a 32-bit unsigned integer. The initial		Numbered FT Label operation. The sequence
	value for this field on a new LDP session		number is encoded as a 32-bit unsigned
	is 0x00000001 and is incremented by one for		integer. The initial value for this field
	each FT LDP message issued by the sending		on a new LDP session is 0x00000001 and is
	LSR on this LDP session. This field may		incremented by one for each FT LDP message
	wrap from 0xFFFFFFFF to 0x00000001.		issued by the sending LSR on this LDP
			session. This field may wrap from
			0xFFFFFFFF to 0x00000001.
	This field MUST be reset to 0x00000001 if		This field MUST be reset to 0x00000001 if
	either LDP peer does not set the FT		either LDP peer does not set the FT
	Reconnect Flag on re-establishment of the		Reconnect Flag on re-establishment of the
	TCP connection.		TCP connection.
	See the section "FT Operation Acks" for		See the section "FT Operation Acks" for
	details of how this field is used.		details of how this field is used.
	The special use of 0x00000000 is discussed		The special use of 0x00000000 is discussed
	in the section "FT ACK TLV" below.		in the section "FT ACK TLV" below.
	If an LSR receives an FT Protection TLV on a session that		If an LSR receives an FT Protection TLV on a session that
	does not support the FT LDP enhancements, it SHOULD send		does not support the FT LDP enhancements, it SHOULD send
	a Notification message to its LDP peer containing the		a Notification message to its LDP peer containing the
	"Unexpected TLV, Session Not FT" status code.		"Unexpected TLV, Session Not FT" status code. LSRs that
			do not recognize this TLV SHOULD respond with a
			Notification message with the 'Unknown TLV' status code.
	If an LSR receives an FT Protection TLV on an operation		If an LSR receives an FT Protection TLV on an operation
	affecting a label that it believes is a non-FT label, it		affecting a label that it believes is a non-FT Label, it
	SHOULD send a Notification message to its LDP peer		SHOULD send a Notification message to its LDP peer
	containing the "Unexpected TLV, Label Not FT" status		containing the "Unexpected TLV, Label Not FT" status
	code.		code.
	If an LSR receives a message without the FT Protection		If an LSR receives a message without the FT Protection
	TLV affecting a label that it believes is an FT label, it		TLV affecting a label that it believes is a Sequence
	SHOULD send a Notification message to its LDP peer		Numbered FT Label, it SHOULD send a Notification message
	containing the "Missing FT Protection TLV" status code.		to its LDP peer containing the "Missing FT Protection
			TLV" status code.
	If an LSR receives an FT Protection TLV containing a zero		If an LSR receives an FT Protection TLV containing a zero
	FT Sequence Number, it SHOULD send a Notification message		FT Sequence Number, it SHOULD send a Notification message
	to its LDP peer containing the "Zero FT Seqnum" status		to its LDP peer containing the "Zero FT Seqnum" status
	code.		code.
	7.4. FT ACK TLV		7.4. FT ACK TLV
	LDP peers use the FT ACK TLV to acknowledge FT label		LDP peers use the FT ACK TLV to acknowledge FT Label
	operations.		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 that does not support the LDP FT		LDP session that does not support the LDP FT
	enhancements. Its presence on such messages SHALL be		enhancements. Its presence on such messages SHALL be
	treated as a protocol error by the receiving LDP peer.		treated as a protocol error by the receiving LDP peer.
	The FT ACK TLV MAY be present on any LDP message		The FT ACK TLV MAY be present on any LDP message
	exchanged on an LDP session after the initial LDP		exchanged on an LDP session after the initial LDP
	Initialization messages. It is RECOMMENDED that the FT		Initialization messages. It is RECOMMENDED that the FT
	skipping to change at page 32, line 41		skipping to change at page 33, line 4
	The FT ACK TLV is encoded as follows.		The FT ACK 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 ACK (0x0504) | Length (= 4) |		|0|0| FT ACK (0x0504) | Length (= 4) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FT ACK Sequence Number |		| FT ACK Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	FT ACK Sequence Number		FT ACK Sequence Number
	The sequence number for this most recent FT
			The sequence number for the most recent FT
	label message that the sending LDP peer has		label message that the sending LDP peer has
	received from the receiving LDP peer and		received from the receiving LDP peer and
	secured against failure of the LDP session.		secured against failure of the LDP session.
	It is not necessary for the sending peer to		It is not necessary for the sending peer to
	have fully processed the message before		have fully processed the message before
	ACKing it. For example, an LSR MAY ACK a		ACKing it. For example, an LSR MAY ACK a
	Label Request message as soon as it has		Label Request message as soon as it has
	securely recorded the message, without		securely recorded the message, without
	waiting until it can send the Label Mapping		waiting until it can send the Label Mapping
	message in response.		message in response.
	skipping to change at page 33, line 24		skipping to change at page 33, line 37
	FT label operations on this LDP session.		FT label operations on this LDP session.
	This would apply to LDP sessions to new LDP		This would apply to LDP sessions to new LDP
	peers or after an LSR determines that it		peers or after an LSR determines that it
	must drop all state for a failed TCP		must drop all state for a failed TCP
	connection.		connection.
	See the section "FT Operation Acks" for		See the section "FT Operation Acks" for
	details of how this field is used.		details of how this field is used.
	If an LSR receives a message affecting a label that it		If an LSR receives a message affecting a label that it
	believes is an FT label and that message does not contain		believes is a Sequence Numbered FT Label and that message
	the FT Protection TLV, it SHOULD send a Notification		does not contain the FT Protection TLV, it SHOULD send a
	message to its LDP peer containing the "Missing FT		Notification message to its LDP peer containing the
	Protection TLV" status code.		"Missing FT Protection TLV" status code.
	If an LSR receives an FT ACK TLV that contains an FT ACK		If an LSR receives an FT ACK TLV that contains an FT ACK
	Sequence Number that is less than the previously received		Sequence Number that is less than the previously received
	FT ACK Sequence Number (remembering to take account of		FT ACK Sequence Number (remembering to take account of
	wrapping), it SHOULD send a Notification message to its		wrapping), it SHOULD send a Notification message to its
	LDP peer containing the "FT ACK Sequence Error" status		LDP peer containing the "FT ACK Sequence Error" status
	code.		code.
	7.5. FT Cork TLV		7.5. FT Cork TLV
	skipping to change at page 33, line 51		skipping to change at page 34, line 20
	control-plane software upgrade.		control-plane software upgrade.
	The FT Cork TLV is encoded as follows.		The FT Cork 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 Cork (0x0505) | Length (= 0) |		|0|0| FT Cork (0x0505) | Length (= 0) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	On receipt of a Keepalive message with the FT Cork TLV		On receipt of a Keepalive message with the FT Cork TLV and the FT
	and the FT Protection TLV, an LSR SHOULD perform the		Protection TLV, an LSR SHOULD perform the following actions.
	following actions
	- Process and secure any messages from the peer LSR that		- Process and secure any messages from the peer LSR that
	have sequence numbers less than (accounting for wrap) that		have sequence numbers less than (accounting for wrap) that
	contained in the FT Protection TLV on the Keepalive message.		contained in the FT Protection TLV on the Keepalive message.
	- Send a Keepalive message back to the peer containing the		- Send a Keepalive message back to the peer containing the
	FT Cork TLV and the FT ACK TLV specifying the FT ACK		FT Cork TLV and the FT ACK TLV specifying the FT ACK
	sequence number equal to that in the original Keepalive		sequence number equal to that in the original Keepalive
	message (i.e. ACKing all messages up to that point).		message (i.e. ACKing all messages up to that point).
	skipping to change at page 34, line 21		skipping to change at page 34, line 43
	messages it has sent containing the FT Protection TLV, then		messages it has sent containing the FT Protection TLV, then
	also include an FT Protection TLV on the Keepalive sent to		also include an FT Protection TLV on the Keepalive sent to
	the peer LSR. This tells the remote peer that the local LSR		the peer LSR. This tells the remote peer that the local LSR
	has saved state prior to quiesce but is still awaiting		has saved state prior to quiesce but is still awaiting
	confirmation that the remote peer has saved state.		confirmation that the remote peer has saved state.
	- Cease sending any further state changing messages on this		- Cease sending any further state changing messages on this
	LDP session until it has been disconnected and recovered.		LDP session until it has been disconnected and recovered.
	On receipt of a Keepalive message with the FT Cork TLV		On receipt of a Keepalive message with the FT Cork TLV
	and the FT ACK TLV (but NOT the FT Protection TLV), an		and an FT ACK TLV that acknowledges the previously sent
	LSR knows that 3-way handshake it initiated is complete		Keepalive that carried the FT Cork TLV, an LSR knows that
	and it SHOULD now send a "Temporary Shutdown"		quiesce is complete. If the received Keepalive also
	Notification message, disconnect the TCP session and		carries the FT Protection TLV, the LSR must respond with
	perform whatever control plane actions required this		a further Keepalive to complete the 3-way handshake. It
	session shutdown.		SHOULD now send a "Temporary Shutdown" Notification
			message, disconnect the TCP session and perform whatever
			control plane actions required this session shutdown.
	An example such 3-way handshake for controlled shutdown		An example such 3-way handshake for controlled shutdown
	is given in section 8.		is given in section 8.
	If an LSR receives a message that should not carry the FT		If an LSR receives a message that should not carry the FT
	Cork TLV, or if the FT Cork TLV is used on a Keepalive		Cork TLV, or if the FT Cork TLV is used on a Keepalive
	message without one of the FT Protection or FT ACK TLVs		message without one of the FT Protection or FT ACK TLVs
	present, , it SHOULD send a Notification message to its		present, , it SHOULD send a Notification message to its
	LDP peer containing the "Unexpected FR Cork TLV" status		LDP peer containing the "Unexpected FR Cork TLV" status code.
	code.
	8. Example Use		8. Example Use
	Consider two LDP peers, P1 and P2, implementing LDP over		Consider two LDP peers, P1 and P2, implementing LDP over
	a TCP connection that connects them, and the message flow		a TCP connection that connects them, and the message flow
	shown below.		shown below.
	The parameters shown on each message shown below are as		The parameters shown on each message shown below are as
	follows:		follows:
	skipping to change at page 42, line 5		skipping to change at page 43, line 5
	: <--------------------------		: <--------------------------
	:		:
	===== TCP Session restored =====		===== TCP Session restored =====
	(11) LDP Init(n/a,n/a,96)		(11) LDP Init(n/a,n/a,96)
	--------------------------->		--------------------------->
	LDP Init(n/a,n/a,31)		LDP Init(n/a,n/a,31)
	<---------------------------		<---------------------------
	Label Withdraw(L1,97,-)		Label Withdraw(L1,97,-)
	<---------------------------		<---------------------------
	Notes:		Notes:
			======
	This example operates much as the previous one. However,		This example operates much as the previous one. However,
	at (1), (2), (3), (4) and (5) no acknowledgements are		at (1), (2), (3), (4) and (5) no acknowledgements are
	made.		made.
	At (6), P1 determines that graceful shutdown is required		At (6), P1 determines that graceful shutdown is required
	and sends a Keepalive acknowledging all previously		and sends a Keepalive acknowledging all previously
	received messages and itself containing a FT Protection		received messages and itself containing a FT Protection
	TLV number and the FT Cork TLV.		TLV number and the FT Cork TLV.
	skipping to change at page 43, line 46		skipping to change at page 44, line 46
	(8) LDP Init(n/a,n/a,23)		(8) LDP Init(n/a,n/a,23)
	--------------------------->		--------------------------->
	LDP Init(n/a,n/a,12)		LDP Init(n/a,n/a,12)
	<---------------------------		<---------------------------
	(9) Label Request(L3)		(9) Label Request(L3)
	--------------------------->		--------------------------->
	Label Request(L3)		Label Request(L3)
	-------------------------->		-------------------------->
	Label Mapping(L3)		Label Mapping(L3)
	<--------------------------		<--------------------------
	Label Mapping(L3)		(10) Label Mapping(L3)
	<---------------------------		<---------------------------
	(10) Label Request(L2)		(11) Label Request(L2)
	<---------------------------		<---------------------------
	Notes:		Notes:
			======
	(1), (2) and (3) show label distribution without FT sequence numbers.		(1), (2) and (3) show label distribution without FT sequence numbers.
	(4) A checkpoint request from P1. It carries the sequence number of		(4) A checkpoint request from P1. It carries the sequence number of
	the checkpoint request.		the checkpoint request.
	(5) P1 immediately starts a new label distribution request.		(5) P1 immediately starts a new label distribution request.
	(6) P2 confirms that it has secured all previous transactions.		(6) P2 confirms that it has secured all previous transactions.
	skipping to change at page 45, line 19		skipping to change at page 46, line 19
	(1) Label Request(L1)		(1) Label Request(L1)
	--------------------------->		--------------------------->
	(2) Label Request(L2)		(2) Label Request(L2)
	<---------------------------		<---------------------------
	Label Request(L1)		Label Request(L1)
	-------------------------->		-------------------------->
	Label Mapping(L1)		Label Mapping(L1)
	<--------------------------		<--------------------------
	(3) Label Mapping(L1)		(3) Label Mapping(L1)
	<---------------------------		<---------------------------
	(4) Keepalive(n/a,12,23) * With FT Cork TLV *		(4) Keepalive(n/a,12,23) * With Cork TLV
	--------------------------->		--------------------------->
	(5) :		(5) :
	:		:
	:		:
	(6) Keepalive(n/a,24,12) * With FT Cork TLV *		(6) Keepalive(n/a,24,12) * With Cork TLV
	<---------------------------		<---------------------------
	(7) Keepalive(n/a,-,24) * With FT Cork TLV *		(7) Keepalive(n/a,-,24) * With Cork TLV
	--------------------------->		--------------------------->
	(8) Notification(Temporary shutdown)		(8) Notification(Temporary shutdown)
	--------------------------->		--------------------------->
	===== TCP Session failure =====		===== TCP Session failure =====
	:		:
	:		:
	:		:
	===== TCP Session restored =====		===== TCP Session restored =====
	(9) LDP Init(n/a,n/a,24)		(9) LDP Init(n/a,n/a,24)
	--------------------------->		--------------------------->
	LDP Init(n/a,n/a,12)		LDP Init(n/a,n/a,12)
	<---------------------------		<---------------------------
	(10) Label Request(L3)		(10) Label Request(L3)
	--------------------------->		--------------------------->
	Label Request(L3)		Label Request(L3)
	-------------------------->		-------------------------->
	Label Mapping(L3)		Label Mapping(L3)
	<--------------------------		<--------------------------
	Label Mapping(L3)		(11) Label Mapping(L3)
	<---------------------------		<---------------------------
	(11) Label Mapping(L2)		(12) Label Mapping(L2)
	--------------------------->		--------------------------->
	Notes:		Notes:
			======
	(1), (2) and (3) show label distribution without FT sequence numbers.		(1), (2) and (3) show label distribution without FT sequence numbers.
	(4) A checkpoint request from P1. It carries the sequence number of		(4) A checkpoint request from P1. It carries the sequence number of
	the checkpoint request and a Cork TLV.		the checkpoint request and a Cork TLV.
	(5) P1 has sent a Cork TLV so quieces.		(5) P1 has sent a Cork TLV so quieces.
	(6) P2 confirms the checkpoint and continues the three-way handshake		(6) P2 confirms the checkpoint and continues the three-way handshake
	by including a Cork TLV itself.		by including a Cork TLV itself.
	skipping to change at page 46, line 32		skipping to change at page 47, line 33
	of the last secured checkpoints.		of the last secured checkpoints.
	(10) P1 starts a new label distribution request.		(10) P1 starts a new label distribution request.
	(11) P1 continues processing a previously received label distribution		(11) P1 continues processing a previously received label distribution
	request.		request.
	9. Security Considerations		9. Security Considerations
	The LDP FT enhancements inherit similar security		The LDP FT enhancements inherit similar security
	considerations to those discussed in [2] and [4].		considerations to those discussed in [RFC3212] and
			[RFC3036].
	The LDP FT enhancements allow the re-establishment of a		The LDP FT enhancements allow the re-establishment of a
	TCP connection between LDP peers without a full re-		TCP connection between LDP peers without a full re-
	exchange of the attributes of established labels, which		exchange of the attributes of established labels, which
	renders LSRs that implement the extensions specified in		renders LSRs that implement the extensions specified in
	this draft vulnerable to additional denial-of-service		this draft vulnerable to additional denial-of-service
	attacks as follows:		attacks as follows:
	- An intruder may impersonate an LDP peer in order to force		- An intruder may impersonate an LDP peer in order to force
	a failure and reconnection of the TCP connection, but where		a failure and reconnection of the TCP connection, but where
	skipping to change at page 47, line 7		skipping to change at page 48, line 7
	- Similarly, an intruder could set the FT Reconnect Flag on		- Similarly, an intruder could set the FT Reconnect Flag on
	re-establishment of the TCP session without preserving the		re-establishment of the TCP session without preserving the
	state and resources for FT labels.		state and resources for FT labels.
	- An intruder could intercept the traffic between LDP peers		- An intruder could intercept the traffic between LDP peers
	and override the setting of the FT Label Flag to be set to 0		and override the setting of the FT Label Flag to be set to 0
	for all labels.		for all labels.
	All of these attacks may be countered by use of an		All of these attacks may be countered by use of an
	authentication scheme between LDP peers, such as the MD5-		authentication scheme between LDP peers, such as the MD5-
	based scheme outlined in [4].		based scheme outlined in [RFC3036].
	Alternative authentication schemes for LDP peers are		Alternative authentication schemes for LDP peers are
	outside the scope of this draft, but could be deployed to		outside the scope of this draft, but could be deployed to
	provide enhanced security to implementations of LDP, CR-		provide enhanced security to implementations of LDP, CR-
	LDP and the LDP FT enhancements.		LDP and the LDP FT enhancements.
	As with LDP and CR-LDP, a security issue may exist if an		As with LDP and CR-LDP, a security issue may exist if an
	LDP implementation continues to use labels after		LDP implementation continues to use labels after
	expiration of the session that first caused them to be		expiration of the session that first caused them to be
	used. This may arise if the upstream LSR detects the		used. This may arise if the upstream LSR detects the
	skipping to change at page 48, line 13		skipping to change at page 49, line 23
	enhancements described in this draft.		enhancements described in this draft.
	Consider an LSR, P1, that is an LDP peer of a fully Fault		Consider an LSR, P1, that is an LDP peer of a fully Fault
	Tolerant LSR, P2. If P2 experiences a fault in the		Tolerant LSR, P2. If P2 experiences a fault in the
	hardware or software that serves an LDP session between		hardware or software that serves an LDP session between
	P1 and P2, it may fail the TCP connection between the		P1 and P2, it may fail the TCP connection between the
	peers. When the connection is recovered, the LSPs/labels		peers. When the connection is recovered, the LSPs/labels
	between P1 and P2 can only be recovered if both LSRs were		between P1 and P2 can only be recovered if both LSRs were
	applying the FT recovery procedures to the LDP session.		applying the FT recovery procedures to the LDP session.
	10.2. ACK Generation Logic		10.2. ACK generation logic
	FT ACKs SHOULD be returned to the sending LSR as soon as		FT ACKs SHOULD be returned to the sending LSR as soon as
	is practicable in order to avoid building up a large		is practicable in order to avoid building up a large
	quantity of unacknowledged state changes at the LSR.		quantity of unacknowledged state changes at the LSR.
	However, immediate one-for-one acknowledgements would		However, immediate one-for-one acknowledgements would
	waste bandwidth unnecessarily.		waste bandwidth unnecessarily.
	A possible implementation strategy for sending ACKs to FT		A possible implementation strategy for sending ACKs to FT
	LDP messages is as follows:		LDP messages is as follows:
	skipping to change at page 49, line 17		skipping to change at page 50, line 24
	targeted LDP session or CR-LDP systems) and that are		targeted LDP session or CR-LDP systems) and that are
	prepared to risk loss of state for the most recent LDP		prepared to risk loss of state for the most recent LDP
	exchanges. More dynamic systems (such as LDP discovery		exchanges. More dynamic systems (such as LDP discovery
	sessions) are more likely to want to acknowledge state		sessions) are more likely to want to acknowledge state
	changes more frequently so that the maximum amount of		changes more frequently so that the maximum amount of
	state can be preserved over a failure.		state can be preserved over a failure.
	11. Acknowledgments		11. Acknowledgments
	The work in this draft is based on the LDP and CR-LDP		The work in this draft is based on the LDP and CR-LDP
	ideas expressed by the authors of [2] and [4].		ideas expressed by the authors of [RFC3212] and [].
	The ACK scheme used in this draft was inspired by the		The ACK scheme used in this draft was inspired by the
	proposal by David Ward and John Scudder for restarting		proposal by David Ward and John Scudder for restarting
	BGP sessions now included in [9].		BGP sessions now included in [BGP-RESTART].
	The authors would also like to acknowledge the careful		The authors would also like to acknowledge the careful
	review and comments of Nick Weeds, Piers Finlayson, Tim		review and comments of Nick Weeds, Piers Finlayson, Tim
	Harrison, Duncan Archer, Peter Ashwood-Smith, Bob Thomas,		Harrison, Duncan Archer, Peter Ashwood-Smith, Bob Thomas,
	S.Manikantan, Adam Sheppard and Alan Davey.		S.Manikantan, Adam Sheppard, Alan Davey and Iftekhar
			Hussain.
	12. Intellectual Property Consideration		12. Intellectual Property Consideration
	The IETF has been notified of intellectual property		The IETF has been notified of intellectual property
	rights claimed in regard to some or all of the		rights claimed in regard to some or all of the
	specification contained in this document. For more		specification contained in this document. For more
	information, consult the online list of claimed rights.		information, consult the online list of claimed rights.
	13. Full Copyright Statement		13. Full Copyright Statement
	Copyright (c) The Internet Society (2000, 2001). All		Copyright (c) The Internet Society (2000, 2001, 2002). All
	Rights Reserved. This document and translations of it may		Rights Reserved. This document and translations of it may
	be copied and furnished to others, and derivative works		be copied and furnished to others, and derivative works
	that comment on or otherwise explain it or assist in its		that comment on or otherwise explain it or assist in its
	implementation may be prepared, copied, published and		implementation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of		distributed, in whole or in part, without restriction of
	any kind, provided that the above copyright notice and		any kind, provided that the above copyright notice and
	this paragraph are included on all such copies and		this paragraph are included on all such copies and
	derivative works. However, this document itself may not		derivative works. However, this document itself may not
	be modified in any way, such as by removing the copyright		be modified in any way, such as by removing the copyright
	notice or references to the Internet Society or other		notice or references to the Internet Society or other
	skipping to change at page 50, line 27		skipping to change at page 52, line 5
	protocol. This section explains the logic used by the		protocol. This section explains the logic used by the
	authors to choose the most appropriate number space for		authors to choose the most appropriate number space for
	each new entity, and is intended to assist in the		each new entity, and is intended to assist in the
	determination of any final values assigned by IANA or the		determination of any final values assigned by IANA or the
	MPLS WG in the event that the MPLS WG chooses to advance		MPLS WG in the event that the MPLS WG chooses to advance
	this draft on the standards track.		this draft on the standards track.
	This section will be removed when the TLV and status code		This section will be removed when the TLV and status code
	values have been agreed with IANA.		values have been agreed with IANA.
	14.1. FT Session TLV		14.1. New TLVs
	The FT Session TLV carries attributes that affect the
	entire LDP session between LDP peers. It is suggested
	that the type for this TLV should be chosen from the
	0x05xx range for TLVs that is used in [4] by other TLVs
	carrying session-wide attributes. At the time of this
	writing, the next available number in this range is
	0x0503.
	14.2. FT Protection TLV		The FT Protection TLV carries attributes that affect a single label
			exchanged between LDP peers. It is taken from the 0x02xx range for
			TLVs that is used in [RFC3036] by other TLVs carrying label
			attributes. The next available value in this range is 0x0203.
	The FT Protection TLV carries attributes that affect a		The FT Session TLV carries attributes that affect the entire LDP
	single label exchanged between LDP peers. It is		session between LDP peers. It is taken from the 0x05xx range for
	suggested that the type for this TLV should be chosen		TLVs that is used in [RFC3036] by other TLVs carrying session-wide
	from the 0x02xx range for TLVs that is used in [4] by		attributes. The next available value in this range is 0x0503.
	other TLVs carrying label attributes. At the time of
	this writing, the next available number in this range is
	0x0203.
	Consideration was given to using the message number field		The FT Protection TLV may ACK many label operations at once if
	instead of a new FT Sequence Number field. However, the		cumulative ACKS are used. It is taken from the 0x05xx range for
	authors felt this placed unacceptable implementation		TLVs that is used in [RFC3036] by other TLVs carrying session-wide
	constraints on the use of message number (e.g. it could		attributes. The next available value in this range is 0x0504.
	no longer be used to reference a control block).
	14.3. FT ACK TLV		The FT Cork TLV carries attributes that apply to all labels exchanged
			between LDP peers. It is taken from the 0x05xx range for TLVs that
			is used in [RFC3036] by other TLVs carrying label attributes. The
			next available value in this range is 0x0505.
	The FT Protection TLV may ACK many label operations at		In summary:
	once if cumulative ACKS are used. It is suggested that
	the type for this TLV should be chosen from the 0x05xx
	range for TLVs that is used in [4] by other TLVs carrying
	session-wide attributes. At the time of this writing,
	the next available number in this range is 0x0504.
	Consideration was given to carrying the FT ACK Number in		FT Protection TLV 0x0203
	the FT Protection TLV, but the authors felt this would be		FT Session TLV 0x0503
	inappropriate as many implementations may wish to carry		FT Ack TLV 0x0504
	the ACKs on Keepalive messages.		FT Cork TLV 0x0505
	14.4. FT Cork TLV		14.2. New Status Codes
	The FT Cork TLV carries attributes that affect a single		LDP status codes are not sub-divided into specific ranges
	label exchanged between LDP peers. It is suggested that		for different types of error. Hence, the numeric status
	the type for this TLV should be chosen from the 0x05xx		code values are selected as the next available.
	range for TLVs that is used in [4] by other TLVs carrying
	label attributes. At the time of this writing, the next
	available number in this range is 0x0505.
	14.5. Status Codes		Section 7.1 lists the new status codes required by this
			draft and gives interpretative information. The new
			codes are as follows.
	The authors' current understanding is that MPLS status		Status Code E Status Data
	codes are not sub-divided into specific ranges for
	different types of error. 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
	substituted for other numeric values.
	See section "Status Codes" for details of the status		No LDP Session 0 0x0000001A
	codes defined in this draft.		Zero FT seqnum 1 0x0000001B
			Unexpected TLV / 1 0x0000001C
			Session Not FT
			Unexpected TLV / 1 0x0000001D
			Label Not FT
			Missing FT Protection TLV 1 0x0000001E
			FT ACK sequence error 1 0x0000001F
			Temporary Shutdown 0 0x00000020
			FT Seq Numbers Exhausted 1 0x00000021
			FT Session parameters / 1 0x00000022
			changed
			Unexpected FT Cork TLV 1 0x00000023
	15. Authors' Addresses		15. Authors' Addresses
	Adrian Farrel (editor) Paul Brittain		Adrian Farrel (editor) Paul Brittain
	Movaz Networks, Inc. Data Connection Ltd.		Movaz Networks, Inc. Data Connection Ltd.
	7926 Jones Branch Drive, Suite 615 Windsor House, Pepper Street,		7926 Jones Branch Drive, Suite 615 Windsor House, Pepper Street,
	McLean, VA 22102 Chester, Cheshire		McLean, VA 22102 Chester, Cheshire
	Phone: +1 703-847-1867 CH1 1DF, UK		Phone: +1 703-847-1867 CH1 1DF, UK
	Email: afarrel@movaz.com Phone: +44-(0)20-8366-1177		Email: afarrel@movaz.com Phone: +44-(0)20-8366-1177
	Email: pjb@dataconnection.com		Email: pjb@dataconnection.com
	Philip Matthews Eric Gray		Philip Matthews Eric Gray
	Hyperchip Sandburst Corporation		Hyperchip Celox Networks, Inc.
	1800 Rene-Levesque Blvd W 600 Federal Street		1800 Rene-Levesque Blvd W 2 Park Central Drive,
	Montreal, Quebec H3H 2H2 Andover, MA 01810		Montreal, Quebec H3H 2H2 Southborough, MA 01772
	Canada Phone: +1 978-689-1600		Canada Phone: +1 508-305-7214
	Phone: +1 514-906-4965 Email:eric.gray@sandburst.com		Phone: +1 514-906-4965 Email: egray@celoxnetworks.com
	Email: pmatthews@hyperchip.com		Email: pmatthews@hyperchip.com
	Jack Shaio Toby Smith		Jack Shaio Toby Smith
	Vivace Networks Laurel Networks, Inc.		Vivace Networks Laurel Networks, Inc.
	2730 Orchard Parkway 1300 Omega Drive		2730 Orchard Parkway 1300 Omega Drive
	San Jose, CA 95134 Pittsburgh, PA 15205		San Jose, CA 95134 Pittsburgh, PA 15205
	Phone: +1 408 432 7623 Email: tob@laurelnetworks.com		Phone: +1 408 432 7623 Email: tob@laurelnetworks.com
	Email: jack.shaio@vivacenetworks.com		Email: jack.shaio@vivacenetworks.com
	Andy Malis		Andrew G. Malis
	Vivace Networks		Vivace Networks
	2730 Orchard Parkway		2730 Orchard Parkway
	San Jose, CA 95134		San Jose, CA 95134
	Phone: +1 408 383 7223		Phone: +1 408 383 7223
	andy.malis@vivacenetworks.com		andy.malis@vivacenetworks.com
	16. Normative References		16. References
	4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001.
	17. Informative References		16.1. Normative References
	1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP		[RFC3036] Andersson, L., et. al., LDP Specification, RFC 3036,
	9, RFC 2026, October 1996.		January 2001.
	2 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP,		[RFC3212] Jamoussi, B., et. al., Constraint-Based LSP Setup
	draft-ietf-mpls-cr-ldp-06.txt, November 2001, (work in progress).		using LDP, RFC 3212, January 2002.
	3 Bradner, S., "Key words for use in RFCs to Indicate Requirement		16.2. Informative References
	Levels", BCP 14, RFC 2119, March 1997.
	5 Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls-		[RFC2026] Bradner, S., "The Internet Standards Process --
	crlsp-modify-03.txt, March 2001 (work in progress).		Revision 3", BCP 9, RFC 2026, October 1996.
	6 Braden, R., et al., Resource ReSerVation Protocol (RSVP) --		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Version 1, Functional Specification, RFC 2205, September 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	7 Berger, L., et al., RSVP Refresh Reduction Extensions, RFC 2961		[RFC2205] Braden, R., et al., Resource ReSerVation Protocol
	April 2001.		(RSVP) -- Version 1, Functional Specification, RFC
			2205, September 1997.
	8 Awduche, D., et al,. Extensions to RSVP for LSP Tunnels, RFC 3209,		[RFC2961] Berger, L., et al., RSVP Refresh Reduction Extensions,
	December 2001.		RFC 2961, April 2001.
	9 Ramachandra, S., et al., Graceful Restart Mechanism for BGP,		[RFC3209] Awduche, D., et al,. Extensions to RSVP for LSP
	draft-ietf-idr-restart-00.txt, December 2000 (work in progress).		Tunnels, RFC 3209, December 2001.
	10 Stewart, R., et al., Stream Control Transmission Protocol,		[RFC3214] Ash, G., et al., LSP Modification Using CR-LDP, RFC
	RFC 2906, October 2000.		3214, January 2001.
	11 Moy, J., Hitless OSPF Restart, draft-ietf-ospf-hitless-restart-		[BGP-RESTART] Sangli, S., et al., Graceful Restart Mechanism
	00.txt, February 2001 (work in progress).		for BGP, draft-ietf-idr-restart-05.txt, June 2002
			(work in progress).
	12 Leelanivas, M., et al., Graceful Restart Mechanism for LDP, draft-		[LDP-RESTART] Leelanivas, M., et al., Graceful Restart Mechanism for
	ietf-ldp-restart-00.txt, January 2002, work in progress.		LDP, draft-ietf-ldp-restart-02.txt, June 2002, work in
			progress.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/