draft-ietf-mpls-ldp-capabilities-04.txt		rfc5561.txt
	Network Working Group Bob Thomas		Network Working Group B. Thomas
	Internet Draft Cisco Systems, Inc.		Request for Comments: 5561 K. Raza
	Updates: 5036		Updates: 5036 Cisco Systems, Inc.
	Intended Status: Proposed Standard S. Aggarwal		Category: Standards Track S. Aggarwal
	Expiration Date: October 22, 2009 Juniper Networks
	R. Aggarwal		R. Aggarwal
	Juniper Networks		Juniper Networks
			JL. Le Roux
	J.L. Le Roux
	France Telecom		France Telecom
	Syed Kamran Raza
	Cisco Systems, Inc.
	April 23, 2009
	LDP Capabilities		LDP Capabilities
	draft-ietf-mpls-ldp-capabilities-04.txt		Abstract
	Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		A number of enhancements to the Label Distribution Protocol (LDP)
	http://www.ietf.org/ietf/1id-abstracts.txt.		have been proposed. Some have been implemented, and some are
			advancing toward standardization. It is likely that additional
			enhancements will be proposed in the future. This document defines a
			mechanism for advertising LDP enhancements at session initialization
			time, as well as a mechanism to enable and disable enhancements after
			LDP session establishment.
	The list of Internet-Draft Shadow Directories can be accessed at		Status of This Memo
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on October 22, 2009.		This document specifies an Internet standards track protocol for the
			Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
			Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Copyright		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Abstract		This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
	A number of enhancements to the Label Distribution Protocol (LDP)		10, 2008. The person(s) controlling the copyright in some of this
	have been proposed. Some have been implemented, and some are		material may not have granted the IETF Trust the right to allow
	advancing toward standardization. It is likely that additional		modifications of such material outside the IETF Standards Process.
	enhancements will be proposed in the future. This document defines a		Without obtaining an adequate license from the person(s) controlling
	mechanism for advertising LDP enhancements at session initialization		the copyright in such materials, this document may not be modified
	time, as well as a mechanism to enable and disable enhancements after		outside the IETF Standards Process, and derivative works of it may
	LDP session establishment.		not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
	Conventions used in this document		than English.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	This document uses the terms "LDP speaker" and "speaker"
	interchangably.
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction ....................................................2
	2. The LDP Capability Mechanism...................................4		1.1. Conventions Used in This Document ..........................3
	2.1. Capability Document.......................................5		2. The LDP Capability Mechanism ....................................3
	3. Specifying Capabilities in LDP Messages........................5		2.1. Capability Document ........................................4
	3.1. Backward Compatibility TLVs...............................7		3. Specifying Capabilities in LDP Messages .........................4
	4. Capability Message.............................................7		3.1. Backward Compatibility TLVs ................................6
	5. Note on Terminology............................................8		4. Capability Message ..............................................6
	6. Procedures for Capability Parameters in Initialization Messages8		5. Note on Terminology .............................................7
	7. Procedures for Capability Parameters in Capability Messages...10		6. Procedures for Capability Parameters in Initialization
	8. Extensions to Error Handling..................................10		Messages ........................................................7
	9. Dynamic Capability Announcement TLV...........................11		7. Procedures for Capability Parameters in Capability Messages .....8
	10. Backward Compatibility.......................................11		8. Extensions to Error Handling ....................................9
	11. Security Considerations......................................12		9. Dynamic Capability Announcement TLV .............................9
	12. IANA Considerations..........................................12		10. Backward Compatibility ........................................10
	13. Acknowledgments..............................................12		11. Security Considerations .......................................10
	14. References...................................................13		12. IANA Considerations ...........................................11
	14.1. Normative References....................................13		13. Acknowledgments ...............................................11
	14.2. Informative References..................................13		14. References ....................................................11
	15. Author's Addresses...........................................14		14.1. Normative References .....................................11
			14.2. Informative References ...................................11
	1. Introduction		1. Introduction
	A number of enhancements to LDP as specified in [RFC5036] have been		A number of enhancements to LDP as specified in [RFC5036] have been
	proposed. These include LDP Graceful Restart [RFC3478], Fault		proposed. These include LDP Graceful Restart [RFC3478], Fault
	Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for		Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for
	layer 2 circuits [RFC4447], a method for learning labels advertised		Layer 2 circuits [RFC4447], a method for learning labels advertised
	by next-next-hop routers in support of fast reroute node protection		by next-next-hop routers in support of fast reroute node protection
	[NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for		[NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for
	signaling inter-area LSPs [IALDP]. Some have been implemented, and		signaling inter-area Label Switched Paths (LSPs) [RFC5283]. Some
	some are advancing toward standardization. It is also likely that		have been implemented, and some are advancing toward standardization.
	additional enhancements will be implemented and deployed in the		It is also likely that additional enhancements will be implemented
	future.		and deployed in the future.
	This document proposes and defines a mechanism for advertising LDP		This document proposes and defines a mechanism for advertising LDP
	enhancements at session initialization time. It also defines a		enhancements at session initialization time. It also defines a
	mechanism to enable and disable these enhancements after LDP session		mechanism to enable and disable these enhancements after LDP session
	establishment.		establishment.
	LDP capability advertisement provides means for an LDP speaker to		LDP capability advertisement provides means for an LDP speaker to
	announce what it can receive and process. It also provides means for		announce what it can receive and process. It also provides means for
	a speaker to inform peers of deviationts from behavior specified by		a speaker to inform peers of deviations from behavior specified by
	[RFC5036]. An example of such a deviation is LDP graceful restart		[RFC5036]. An example of such a deviation is LDP Graceful Restart,
	where a speaker retains MPLS forwarding state for LDP-signaled LSPs		where a speaker retains MPLS forwarding state for LDP-signaled LSPs
	when its LDP control plane goes down. It is important to point out		when its LDP control plane goes down. It is important to point out
	that not all LDP enhancements require capability advertisement. For		that not all LDP enhancements require capability advertisement. For
	example, upstream label allocation does but inbound label filtering,		example, upstream label allocation requires capability advertisement,
	where a speaker installs forwarding state for only certain FECs,		but inbound label filtering, where a speaker installs forwarding
	does not.		state for only certain Forwarding Equivalence Classes (FECs), does
			not.
			1.1. Conventions Used in This Document
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			This document uses the terms "LDP speaker" and "speaker"
			interchangeably.
	2. The LDP Capability Mechanism		2. The LDP Capability Mechanism
	Enhancements are likely to be announced during LDP session		Enhancements are likely to be announced during LDP session
	establishment as each LDP speaker advertises capabilities		establishment as each LDP speaker advertises capabilities
	corresponding to the enhancements it desires.		corresponding to the enhancements it desires.
	Beyond that, capability advertisements may be used to dynamically		Beyond that, capability advertisements may be used to dynamically
	modify the characteristics of the session to suit the changing		modify the characteristics of the session to suit the changing
	conditions. For example, an LSR capable of a particular enhancement		conditions. For example, an LSR capable of a particular enhancement
	skipping to change at page 4, line 26		skipping to change at page 3, line 47
	because the feature was disabled at that time. Later, an operator		because the feature was disabled at that time. Later, an operator
	may enable the feature, at which time the LSR would react by		may enable the feature, at which time the LSR would react by
	advertising the corresponding capability to its peers. Similarly,		advertising the corresponding capability to its peers. Similarly,
	when an operator disables a feature associated with a capability, the		when an operator disables a feature associated with a capability, the
	LSR reacts by withdrawing the capability advertisement from its		LSR reacts by withdrawing the capability advertisement from its
	peers.		peers.
	The LDP capability advertisement mechanism operates as follows:		The LDP capability advertisement mechanism operates as follows:
	- Each LDP speaker is assumed to implement a set of enhancements,		- Each LDP speaker is assumed to implement a set of enhancements,
	each of which has an associated capability. At any time, a		each of which has an associated capability. At any time, a speaker
	speaker may have none, one, or more of those enhancements		may have none, one, or more of those enhancements "enabled". When
	"enabled". When an enhancement is enabled, the speaker		an enhancement is enabled, the speaker advertises the associated
	advertises the associated capability to its peers. By		capability to its peers. By advertising the capability to a peer,
	advertising the capability to a peer, the speaker asserts that it		the speaker asserts that it shall perform the protocol actions
	shall perform the protocol actions specified for the associated		specified for the associated enhancement. For example, the actions
	enhancement. For example, the actions may require the LDP speaker		may require the LDP speaker to receive and process enhancement-
	to receive and process enhancement-specific messages from its		specific messages from its peer. Unless the capability has been
	peer. Unless the capability has been advertised, the speaker will		advertised, the speaker will not perform protocol actions specified
	not perform protocol actions specified for the corresponding		for the corresponding enhancement.
	enhancement.
	- At session establishment time an LDP speaker MAY advertise a		- At session establishment time, an LDP speaker MAY advertise a
	particular capability by including an optional parameter		particular capability by including an optional parameter associated
	associated with the capability in its Initialization message.		with the capability in its Initialization message.
	- There is a well-known capability called Dynamic Capability		- There is a well-known capability called Dynamic Capability
	Announcement which an LDP speaker MAY advertise in its		Announcement that an LDP speaker MAY advertise in its
	Initialization message to indicate that it is capable of		Initialization message to indicate that it is capable of processing
	processing capability announcements following a session		capability announcements following a session establishment.
	establishment.
	If a peer had advertised the Dynamic Capability Announcement		If a peer had advertised the Dynamic Capability Announcement
	capability in its Initialization message, then at any time		capability in its Initialization message, then at any time
	following session establishment an LDP speaker MAY announce		following session establishment, an LDP speaker MAY announce
	changes in its advertised capabilities to that peer. To do this,		changes in its advertised capabilities to that peer. To do this,
	the LDP speaker sends the peer a Capability message that		the LDP speaker sends the peer a Capability message that specifies
	specifies the capabilities being advertised or withdrawn.		the capabilities being advertised or withdrawn.
	2.1. Capability Document		2.1. Capability Document
	When the capability advertisement mechanism is in place, an LDP		When the capability advertisement mechanism is in place, an LDP
	enhancement requiring LDP capability advertisement will be specified		enhancement requiring LDP capability advertisement will be specified
	by a document that:		by a document that:
	- Describes the motivation for the enhancement;		- Describes the motivation for the enhancement;
	- Specifies the behavior of LDP when the enhancement is enabled.		- Specifies the behavior of LDP when the enhancement is enabled.
	This includes the procedures, parameters, messages, and TLVs		This includes the procedures, parameters, messages, and TLVs
	required by the enhancement;		required by the enhancement;
	- Includes an IANA considerations section that requests IANA		- Includes an IANA considerations section that requests IANA
	assignment of a code point (from TLV Type namespace) for the		assignment of a code point (from TLV Type namespace) for the
	optional capability parameter corresponding to the enhancement.		optional capability parameter corresponding to the enhancement.
	The capability document MUST also describe the interpretation and		The capability document MUST also describe the interpretation
	processing of associated capability data, if present.		and processing of associated capability data, if present.
	3. Specifying Capabilities in LDP Messages		3. Specifying Capabilities in LDP Messages
	This document uses the term "Capability Parameter" to refer to an		This document uses the term "Capability Parameter" to refer to an
	optional parameter that may be included in Initialization and		optional parameter that may be included in Initialization and
	Capability messages to advertise a capability.		Capability messages to advertise a capability.
	The format of a "Capability Parameter" TLV is as follows:		The format of a "Capability Parameter" TLV is as follows:
	0 1 2 3		0 1 2 3
	skipping to change at page 6, line 17		skipping to change at page 5, line 19
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| TLV Code Point | Length |		|U|F| TLV Code Point | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved | |		|S| Reserved | |
	+-+-+-+-+-+-+-+-+ Capability Data |		+-+-+-+-+-+-+-+-+ Capability Data |
	| +-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	U-bit:		U-bit:
	Unknown TLV bit, as described in [RFC5036]. The value could be		Unknown TLV bit, as described in [RFC5036]. The value could be
	either 0 or 1 as specified in Capability document associated		either 0 or 1 as specified in the Capability document associated
	with given capability.		with the given capability.
	F-bit:		F-bit:
	Forward unknown TLV bit, as described in [RFC5036]. The value of		Forward unknown TLV bit, as described in [RFC5036]. The value
	this bit MUST be 0 since a Capability Paramter TLV is sent only		of this bit MUST be 0 since a Capability Parameter TLV is sent
	in Initialization and Capability messages which are not		only in Initialization and Capability messages, which are not
	forwarded.		forwarded.
	TLV Code Point:		TLV Code Point:
	The TLV type which identifies a specific capability. This is		The TLV type that identifies a specific capability. This is an
	IANA assigned code point (from TLV Type namespace) for given		IANA-assigned code point (from TLV Type namespace) for a given
	capability as requested in the associated capability document.		capability as requested in the associated capability document.
	S-bit:		S-bit:
	The State Bit. It indicates whether the sender is advertising or		The State Bit. It indicates whether the sender is advertising
	withdrawing the capability corresponding to the TLV Code Point.		or withdrawing the capability corresponding to the TLV code
	The State bit value is used as follows:		point. The State Bit value is used as follows:
	1 - The TLV is advertising the capability specified by the		1 - The TLV is advertising the capability specified by the TLV
	TLV Code Point.		code point.
	0 - The TLV is withdrawing the capability specified by the
	TLV Code Point.		0 - The TLV is withdrawing the capability specified by the TLV
			code point.
	Capability Data:		Capability Data:
	Information, if any, about the capability in addition to the TLV		Information, if any, about the capability in addition to the TLV
	Code Point required to fully specify the capability.		code point required to fully specify the capability.
	The method for interpreting and processing this data is specific		The method for interpreting and processing this data is specific
	to the TLV Code Point and MUST be described in the document		to the TLV code point and MUST be described in the document
	specifying the capability.		specifying the capability.
	An LDP speaker MUST NOT include more than one instance of a		An LDP speaker MUST NOT include more than one instance of a
	Capability Parameter (as identified by the same TLV code point) in an		Capability Parameter (as identified by the same TLV code point) in an
	Initialization or Capability message. If an LDP speaker receives more		Initialization or Capability message. If an LDP speaker receives
	than one instance of the same Capability Parameter type in a message,		more than one instance of the same Capability Parameter type in a
	it SHOULD send a Notification message to peer before terminating the		message, it SHOULD send a Notification message to the peer before
	session with peer. The Status Code in the Status TLV of the		terminating the session with the peer. The Status Code in the Status
	Notification message MUST be Malformed TLV, and the message SHOULD		TLV of the Notification message MUST be Malformed TLV value, and the
	contain the second Capability Parameter TLV of the same type (Code		message SHOULD contain the second Capability Parameter TLV of the
	point) that is received in the message.		same type (code point) that is received in the message.
	3.1. Backward Compatibility TLVs		3.1. Backward Compatibility TLVs
	LDP extensions that require advertisement or negotiation of some		LDP extensions that require advertisement or negotiation of some
	capability at session establishment time typically use TLVs that are		capability at session establishment time typically use TLVs that are
	included in an Initialization message. To ensure backward		included in an Initialization message. To ensure backward
	compatibility with existing implementations, such TLVs continue to be		compatibility with existing implementations, such TLVs continue to be
	supported in an Initialization message and are known in this document		supported in an Initialization message and are known in this document
	as "Backward Compatibility TLVs". A Backward Compatibility TLV plays		as "Backward Compatibility TLVs". A Backward Compatibility TLV plays
	the role of a "Capability Parameter" TLV; that is the presence of a		the role of a "Capability Parameter" TLV; that is, the presence of a
	Backward Compatibility TLV has the same meaning as a Capability		Backward Compatibility TLV has the same meaning as a Capability
	Parameter TLV with the S bit set for the same capability.		Parameter TLV with the S-bit set for the same capability.
	One example of a Backward Capability TLV is the "FT Session TLV" that		One example of a Backward Capability TLV is the "FT Session TLV" that
	is exchanged in an Initialization message between peers to announce		is exchanged in an Initialization message between peers to announce
	LDP Fault Tolerance [RFC3479] capability.		LDP Fault Tolerance [RFC3479] capability.
	4. Capability Message		4. Capability Message
	The LDP Capability message is used by an LDP speaker to announce		The LDP Capability message is used by an LDP speaker to announce
	changes in the state of one or more of its capabilities subsequent to		changes in the state of one or more of its capabilities subsequent to
	session establishment.		session establishment.
	The format of the Capability message is as follows:		The format of the Capability message is 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| Capability (IANA) | Length |		|0| Capability (0x0202) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message ID |		| Message ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TLV_1 |		| TLV_1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| . . . |		| . . . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TLV_N |		| TLV_N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where TLV_1 through TLV_N are Capability Parameter TLVs. The S-bit		where TLV_1 through TLV_N are Capability Parameter TLVs. The S-bit
	of each of the TLVs specifies the new state for the corresponding		of each of the TLVs specifies the new state for the corresponding
	capability.		capability.
	Note that Backward Compatibility TLVs (see Section 3.1. ) MUST NOT be		Note that Backward Compatibility TLVs (see Section 3.1) MUST NOT be
	included in Capability messages.		included in Capability messages. An LDP speaker that receives a
			Capability message from a peer that includes Backward Compatibility
			TLVs SHOULD silently ignore these Backward Compatibility TLVs and
			continue processing the rest of the message.
	5. Note on Terminology		5. Note on Terminology
	The following sections in this document talk about enabling and		The following sections in this document talk about enabling and
	disabling capabilities. The terminology "enabling (or disabling) a		disabling capabilities. The terminology "enabling (or disabling) a
	capability" is short hand for "advertising (or withdrawing) a		capability" is short hand for "advertising (or withdrawing) a
	capability associated with an enhancement". Bear in mind that it is		capability associated with an enhancement". Bear in mind that it is
	an LDP enhancement that is being enabled or disabled, and that it is		an LDP enhancement that is being enabled or disabled, and that it is
	the corresponding capability that is being advertisted or withdrawn.		the corresponding capability that is being advertised or withdrawn.
	6. Procedures for Capability Parameters in Initialization Messages		6. Procedures for Capability Parameters in Initialization Messages
	The S-bit of a Capability Parameter in an Initialization message MUST		The S-bit of a Capability Parameter in an Initialization message MUST
	be 1 and SHOULD be ignored on receipt. This ensures that any		be 1 and SHOULD be ignored on receipt. This ensures that any
	Capability Parameter in an Initialization message enables the		Capability Parameter in an Initialization message enables the
	corresponding capability.		corresponding capability.
	An LDP speaker determines the capabilities of a peer by examining the		An LDP speaker determines the capabilities of a peer by examining the
	set of of Capability Parameters present in the Initialization message		set of Capability Parameters present in the Initialization message
	received from the peer.		received from the peer.
	An LDP speaker MAY use a particular capability with its peer after		An LDP speaker MAY use a particular capability with its peer after
	the speaker determines that the peer has enabled that capability.		the speaker determines that the peer has enabled that capability.
	These procedures enable an LDP speaker S1, that advertises a specific		These procedures enable an LDP speaker S1, that advertises a specific
	LDP capability C, to establish an LDP session with speaker S2 that		LDP capability C, to establish an LDP session with speaker S2 that
	does not advertise C. In this situation whether or not capability C		does not advertise C. In this situation, whether or not capability C
	may be used for the session depends on the semantics of the		may be used for the session depends on the semantics of the
	enhancement associated with C. If the semantics do not require both		enhancement associated with C. If the semantics do not require both
	S1 and S2 advertise C to one another, then S2 could use it; i.e. S1's		S1 and S2, advertise C to one another, then S2 could use it; i.e.,
	advertisement of C permits S2 to send messages to S1 used by the		S1's advertisement of C permits S2 to send messages to S1 used by the
	enhancement.		enhancement.
	It is the responsibility of the capability designer to specify the		It is the responsibility of the capability designer to specify the
	behavior of an LDP speaker that has enabled a certain enhancement,		behavior of an LDP speaker that has enabled a certain enhancement,
	advertised its capability and determines that its peer has not		advertised its capability and determines that its peer has not
	advertised the corresponding capability. The document specifying		advertised the corresponding capability. The document specifying
	procedures for the capability MUST describe the behavior in this		procedures for the capability MUST describe the behavior in this
	situation. If the specified procedure is to terminate the session,		situation. If the specified procedure is to terminate the session,
	then the LDP speaker SHOULD send a Notification message to the peer		then the LDP speaker SHOULD send a Notification message to the peer
	before terminating the session. The Status Code in the Status TLV		before terminating the session. The Status Code in the Status TLV of
	of the Notification message MUST be Unsupported Capability, and the		the Notification message MUST be Unsupported Capability, and the
	message SHOULD contain the unsupported capability (see Section 8.		message SHOULD contain the unsupported capability (see Section 8 for
	for more details).		more details).
	An LDP speaker that supports capability advertisement and includes a		An LDP speaker that supports capability advertisement and includes a
	Capability Parameter in its Initialization message MUST set the TLV		Capability Parameter in its Initialization message MUST set the TLV
	U-bit to 0 or 1, as specified by Capability document. LDP speaker		U-bit to 0 or 1, as specified by Capability document. The LDP
	should set U-bit to 1 if the capability document allows to continue		speaker should set the U-bit to 1 if the capability document allows
	with a peer that does not understand the enhancement, and set U-bit		it to continue with a peer that does not understand the enhancement,
	to 0 otherwise. If a speaker receives a message containng unsupported		and set the U-bit to 0 otherwise. If a speaker receives a message
	capability, it responds according to U-bit setting in the TLV. If U-		containing unsupported capability, it responds according to the U-bit
	bit is 1, then speaker MUST silently ignore the Capability Parameter		setting in the TLV. If the U-bit is 1, then the speaker MUST
	and allow the session to be established. However, if U-bit is 0, then		silently ignore the Capability Parameter and allow the session to be
	speaker SHOULD send a Notification message to the peer before		established. However, if the U-bit is 0, then speaker SHOULD send a
	terminating the session. The Status Code in the Status TLV of the		Notification message to the peer before terminating the session. The
	Notification message MUST be Unsupported Capability, and the		Status Code in the Status TLV of the Notification message MUST be
	message SHOULD contain the unsupported capability (see Section 8.		Unsupported Capability, and the message SHOULD contain the
	for more details).		unsupported capability (see Section 8 for more details).
	7. Procedures for Capability Parameters in Capability Messages		7. Procedures for Capability Parameters in Capability Messages
	An LDP speaker MUST NOT send a Capability message to a peer unless		An LDP speaker MUST NOT send a Capability message to a peer unless
	its peer had advertised the Dynamic Capability Announcement		its peer advertised the Dynamic Capability Announcement capability in
	capability in its session Initialization message. An LDP speaker MAY		its session Initialization message. An LDP speaker MAY send a
	send a Capability message to a peer if its peer had advertised the		Capability message to a peer if its peer advertised the Dynamic
	Dynamic Capability Announcement capability in its session		Capability Announcement capability in its session Initialization
	Initialization message (see Section 9. ).		message (see Section 9).
	An LDP speaker determines the capabilities enabled by a peer by		An LDP speaker determines the capabilities enabled by a peer by
	determining the set of capabilities enabled at session initialization		determining the set of capabilities enabled at session initialization
	(as specified in Section 6. ) and tracking changes to that set made		(as specified in Section 6) and tracking changes to that set made by
	by Capability messages from the peer.		Capability messages from the peer.
	An LDP speaker that has enabled a particular capability MAY use the		An LDP speaker that has enabled a particular capability MAY use the
	enhancement corresponding to the capability with a peer after the		enhancement corresponding to the capability with a peer after the
	speaker determines that the peer has enabled the capability.		speaker determines that the peer has enabled the capability.
	8. Extensions to Error Handling		8. Extensions to Error Handling
	This document defines a new LDP status code named Unsupported		This document defines a new LDP status code named Unsupported
	Capability. The E-bit of the Status TLV carried in a Notification		Capability. The E-bit of the Status TLV carried in a Notification
	message that includes this status code MUST be set to 0.		message that includes this status code MUST be set to 0.
	In addition, this document defines a new LDP TLV, named Returned		In addition, this document defines a new LDP TLV, named Returned
	TLVs, that MAY be carried in a Notification message. The U-bit		TLVs, that MAY be carried in a Notification message as an Optional
	setting for a Returned TLVs TLV in a Notification message SHOULD be 1		Parameter. The U-bit setting for a Returned TLVs TLV in a
	and the F-bit setting SHOULD be 0.		Notification message SHOULD be 1, and the F-bit setting SHOULD be 0.
	When the Status Code in a Notification message is Unsupported		When the Status Code in a Notification message is Unsupported
	Capability, the message SHOULD specify the capabilities that are		Capability, the message SHOULD specify the capabilities that are
	unsupported. When the Notification message specifies the unsupported		unsupported. When the Notification message specifies the unsupported
	capabilities, it MUST include a Returned TLVs TLV. The Returned TLVs		capabilities, it MUST include a Returned TLVs TLV. The Returned TLVs
	TLV MUST include only the Capability Parameters for unsupported		TLV MUST include only the Capability Parameters for unsupported
	capabilities, and the Capability Parameter for each such capability		capabilities, and the Capability Parameter for each such capability
	SHOULD be encoded as received from the peer.		SHOULD be encoded as received from the peer.
	When the Status Code in a Notification Message is Unknown TLV, the		When the Status Code in a Notification Message is Unknown TLV, the
	skipping to change at page 11, line 13		skipping to change at page 9, line 46
	include the unknown TLV in a Returned TLVs TLV.		include the unknown TLV in a Returned TLVs TLV.
	9. Dynamic Capability Announcement TLV		9. Dynamic Capability Announcement TLV
	The Dynamic Capability Announcement TLV is a Capability Parameter		The Dynamic Capability Announcement TLV is a Capability Parameter
	defined by this document with following format:		defined by this document with following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|0| DynCap Announcement (IANA)| Length (1) |		|1|0| DynCap Ann. (0x0506) | Length (1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1| Reserved |		|1| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
			The value of the U-bit for the Dynamic Capability Announcement
	The value of U-bit for Dynamic Capability Announcement Parameter TLV		Parameter TLV MUST be set to 1 so that a receiver MUST silently
	MUST be set to 1 so that a receiver MUST silently ignore this TLV, if		ignore this TLV if unknown to it, and continue processing the rest of
	unknown to it, and continue processing the rest of the message. There		the message. There is no "Capability Data" associated with this TLV
	is no "Capability Data" associated with this TLV and hence TLV length		and hence the TLV length MUST be set to 1.
	MUST be set to 1.
	The Dynamic Capability Announcement Parameter MAY be included by an		The Dynamic Capability Announcement Parameter MAY be included by an
	LDP speaker in an Initialization message to signal its peer that the		LDP speaker in an Initialization message to signal its peer that the
	speaker is capable of processing Capability messages.		speaker is capable of processing Capability messages.
	An LDP speaker MUST NOT include the Dynamic Capability Announcement		An LDP speaker MUST NOT include the Dynamic Capability Announcement
	Parameter in Capability messages sent to its peers. Once enabled		Parameter in Capability messages sent to its peers. Once enabled
	during session initialization, the Dynamic Capability Announcement		during session initialization, the Dynamic Capability Announcement
	capability cannot be disabled. This implies that S-bit is always 1		capability cannot be disabled. This implies that the S-bit is always
	for Dynamic Capability Announcement.		1 for the Dynamic Capability Announcement.
	An LDP speaker that receives a Capability message from a peer that		An LDP speaker that receives a Capability message from a peer that
	includes the Dynamic Capability Announcement Parameter SHOULD		includes the Dynamic Capability Announcement Parameter SHOULD
	silently ignore the parameter and process any other Capability		silently ignore the parameter and process any other Capability
	Parameters in the message.		Parameters in the message.
	10. Backward Compatibility		10. Backward Compatibility
	From the point of view of the LDP capability advertisement mechanism,		From the point of view of the LDP capability advertisement mechanism,
	an [RFC5036] compliant peer has label distribution for IPv4 enabled		an [RFC5036]-compliant peer has label distribution for IPv4 enabled
	by default. To ensure compatibility with an [RFC5036] compliant		by default. To ensure compatibility with an [RFC5036]-compliant
	peer, LDP implementations that support capability advertisement have		peer, LDP implementations that support capability advertisement have
	label distribution for IPv4 enabled until it is explicitly disabled		label distribution for IPv4 enabled until it is explicitly disabled
	and MUST assume that their peers do as well.		and MUST assume that their peers do as well.
	Section 3.1 introduces the concept of Backward Compatibility TLVs		Section 3.1 introduces the concept of Backward Compatibility TLVs
	that may appear in an Initialization message in the role of a		that may appear in an Initialization message in the role of a
	Capability Parameter. This permits existing LDP enhancements that		Capability Parameter. This permits existing LDP enhancements that
	use an adhoc mechanism for enabling capabilities at sesssion		use an ad hoc mechanism for enabling capabilities at session
	initialization time to continue to do so.		initialization time to continue to do so.
	11. Security Considerations		11. Security Considerations
	[MPLS_SEC] describes the security framework for MPLS networks,		[MPLS_SEC] describes the security framework for MPLS networks,
	whereas [RFC5036] describes the security considerations that apply to		whereas [RFC5036] describes the security considerations that apply to
	the base LDP specification. The same security framework and		the base LDP specification. The same security framework and
	considerations apply to the capability mechanism described in this		considerations apply to the capability mechanism described in this
	document.		document.
	12. IANA Considerations		12. IANA Considerations
	This document specifies the following which require code points assigned		This document specifies the following code points assigned by IANA:
	by IANA:
	- LDP message code point for the Capability message. The authors		- LDP message code point for the Capability message (0x0202).
	request message type 0x0202 for the Capability message.
	- LDP TLV code point for the Dynamic Capability Announcemnt TLV.		- LDP TLV code point for the Dynamic Capability Announcement TLV
	The authors request TLV type code 0x0506.		(0x0506).
	- LDP TLV code point for the Returned TLVs TLV. The authors		- LDP TLV code point for the Returned TLVs TLV (0x0304).
	request TLV type 0x304.
	- LDP Status Code code point for the Unsupported Capability Status		- LDP Status Code code point for the Unsupported Capability Status
	Code. The authors request Status Code 0x0000002C.		Code (0x0000002E).
	13. Acknowledgments		13. Acknowledgments
	The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo,		The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo,
	Yakov Rekhter, and Eric Rosen for their comments.		Yakov Rekhter, and Eric Rosen for their comments.
	This document was prepared using 2-Word-v2.0.template.dot.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas,
	Specification", RFC 5036, September 2007.		Ed., "LDP Specification", RFC 5036, October 2007.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC2119, March 1997.		Requirement Levels", BCP 14, RFC2119, March 1997.
	[RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label		[RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label
	Distribution Protocol (LDP)", RFC 3479, February 2003.		Distribution Protocol (LDP)", RFC 3479, February 2003.
	14.2. Informative References		14.2. Informative References
	[IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for		[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP
	Inter-Area LSPs", draft-decraene-mpls-ldp-interarea-04.txt,		Extension for Inter-Area Label Switched Paths (LSPs)",
			RFC 5283, July 2008.
	[MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution Protocol		[MLDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and
	Extensions for Point-to-Multipoint and Multipoint-to-		B. Thomas, "Label Distribution Protocol Extensions for
	Multipoint Label Switched Paths", draft-minei-wijnands-mpls-		Point-to-Multipoint and Multipoint-to-Multipoint Label
	ldp-p2mp-00.txt, Work in Progress, September 2005		Switched Paths", Work in Progress, April 2009.
	[NNHOP] Shen, N., Chen, E., Tian, A. "Discovery LDP Next-Nexthop		[NNHOP] Shen, N., Chen, E., and A. Tian, "Discovery LDP Next-
	Labels", draft-shen-mpls-ldp-nnhop-label-02.txt, Work in		Nexthop Labels", Work in Progress, May 2005.
	[RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. Heron,		[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T.,
	"Pseudowire Setup and Maintenance using the Label Distribution		and G. Heron, "Pseudowire Setup and Maintenance Using
	Protocol", RFC 4447, April 2006.		the Label Distribution Protocol (LDP)", RFC 4447,
			April 2006.
	[RFC3478] Leelanivas, M., Rekhter, Y, Aggarwal, R., "Graceful Restart		[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal,
	Mechanism for Label Distribution Protocol (LDP)", RFC 3478,		"Graceful Restart Mechanism for Label Distribution
	February 2003.		Protocol", RFC 3478, February 2003.
	[UPSTREAM_LDP] Aggarwal R., Le Roux, J.L., "MPLS Upstream Label		[UPSTREAM_LDP] Aggarwal R., and J.L. Le Roux, "MPLS Upstream Label
	Assignment for LDP" draft-ietf-mpls-ldp-upstream-00.txt, Work		Assignment for LDP" Work in Progress, July 2008.
	in Progress, February 2006.
	[MPLS_SEC] Fang, L. et al., Security Framework for MPLS and GMPLS		[MPLS_SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
	Networks, draft-ietf-mpls-mpls-and-gmpls-security-framework-		Networks", Work in Progress, March 2009.
	05.txt, Work in Progress, March 2009.
	15. Author's Addresses		Authors' Addresses
	Bob Thomas		Bob Thomas
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1414 Massachusetts Ave.		1414 Massachusetts Ave.
	Boxborough, MA 01719		Boxborough, MA 01719
	E-mail: bobthomas@alum.mit.edu		EMail: bobthomas@alum.mit.edu
	Shivani Aggarwal		Shivani Aggarwal
	Juniper Networks		Juniper Networks
	1194 North Mathilda Ave.		1194 North Mathilda Ave.
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	Email: shivani@juniper.net		EMail: shivani@juniper.net
	Rahul Aggarwal		Rahul Aggarwal
	Juniper Networks		Juniper Networks
	1194 North Mathilda Ave.		1194 North Mathilda Ave.
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	Email: rahul@juniper.net		EMail: rahul@juniper.net
	Jean-Louis Le Roux		Jean-Louis Le Roux
	France Telecom		France Telecom
	2, Avenue Pierre-Marzin		2, Avenue Pierre-Marzin
	22307 Lannion Cedex, France		22307 Lannion Cedex, France
	E-mail: jeanlouis.leroux@orange-ftgroup.com		EMail: jeanlouis.leroux@orange-ftgroup.com
	Syed Kamran Raza		Kamran Raza
	Cisco Systems, Inc.		Cisco Systems, Inc.
	2000 Innovation Dr.		2000 Innovation Dr.
	Kanata, ON K2K-3E8, Canada		Kanata, ON K2K 3E8, Canada
	E-mail: skraza@cisco.com		EMail: skraza@cisco.com
End of changes. 70 change blocks.
	227 lines changed or deleted		203 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/