draft-ietf-mpls-ldp-capabilities-00.txt		draft-ietf-mpls-ldp-capabilities-01.txt
	Network Working Group Bob Thomas		Network Working Group Bob Thomas
	Internet Draft Cisco Systems, Inc.		Internet Draft Cisco Systems, Inc.
	Expiration Date: November 2007		Expiration Date: August 2008
	S. Aggarwal		Intended Status: Proposed Standard S. Aggarwal
	Juniper Networks		Juniper Networks
	R. Aggarwal		R. Aggarwal
	Juniper Networks		Juniper Networks
	J.L. Le Roux		J.L. Le Roux
	France Telecom		France Telecom
			February 2008
	LDP Capabilities		LDP Capabilities
	draft-ietf-mpls-ldp-capabilities-00.txt		draft-ietf-mpls-ldp-capabilities-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 2, line 7		skipping to change at page 2, line 7
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF TRUST (2007).		Copyright (C) The IETF TRUST (2008).
	Abstract		Abstract
	A number of enhancements to the Label Distribution Protocol (LDP)		A number of enhancements to the Label Distribution Protocol (LDP)
	have been proposed. Some have been implemented, and some are		have been proposed. Some have been implemented, and some are
	advancing toward standardization. It is likely that additional		advancing toward standardization. It is likely that additional
	enhancements will be proposed in the future. At present LDP has no		enhancements will be proposed in the future. At present LDP has no
	guidelines for advertising such enhancements at LDP session		guidelines for advertising such enhancements at LDP session
	initialization time. There is also no mechanism to enable and		initialization time. There is also no mechanism to enable and
	disable enhancements after the session is established. This document		disable enhancements after the session is established. This document
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	12 Security Considerations ....................................... 10		12 Security Considerations ....................................... 10
	13 IANA Considerations ........................................... 10		13 IANA Considerations ........................................... 10
	14 Acknowledgements .............................................. 11		14 Acknowledgements .............................................. 11
	15 References .................................................... 11		15 References .................................................... 11
	16 Author Information ............................................ 12		16 Author Information ............................................ 12
	17 Intellectual Property Statement ............................... 12		17 Intellectual Property Statement ............................... 12
	18 Full Copyright Statement ...................................... 13		18 Full Copyright Statement ...................................... 13
	1. Introduction		1. Introduction
	A number of enhancements to LDP as specified in [RFC3036] 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 LSPs [IALDP]. Some have been implemented, and
	some are advancing toward standardization. It is likely that		some are advancing toward standardization. It is likely that
	additional enhancements will be proposed in the future.		additional enhancements will be proposed in the future.
	At present LDP has no guidelines for advertising such enhancements at		At present LDP has no guidelines for advertising such enhancements at
	LDP session initialization time. There is also no mechanism to		LDP session initialization time. There is also no mechanism to
	enable and disable enhancements after the session is established.		enable and disable enhancements after the session is established.
	This document provides guidelines for advertising LDP enhancements at		This document provides guidelines for advertising LDP enhancements at
	session initialization time. It also defines a mechanism to enable		session initialization time. It also defines a mechanism to enable
	and disable enhancements after LDP session establishment.		and disable enhancements after LDP session 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 deviations from behavior specified by		a speaker to inform peers of deviations from behavior specified by
	[RFC3036]. 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 does but inbound label filtering,
	where a speaker installs forwarding state for only certain FECs, does		where a speaker installs forwarding state for only certain FECs, does
	not.		not.
	2. Specification Language		2. Specification Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 5, line 33		skipping to change at page 5, line 33
	|U|F| TLV Code Point | Length |		|U|F| TLV Code Point | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved | |		|S| Reserved | |
	+-+-+-+-+-+-+-+-+ Capability Data |		+-+-+-+-+-+-+-+-+ Capability Data |
	| +-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	U and F bits:		U and F bits:
	As specified in [RFC3036].		As specified in [RFC5036].
	TLV Code Point:		TLV Code Point:
	The TLV type which identifies a specific capability. The "IANA		The TLV type, which identifies a specific capability. The "IANA
	Considerations" section of [RFC3036] specifies the assignment of		Considerations" section of [RFC5036] specifies the assignment of
	code points for LDP TLVs.		code points for LDP TLVs.
	S-bit:		S-bit:
	The State Bit indicates whether the sender is advertising or		The State Bit indicates whether the sender is advertising or
	withdrawing the capability corresponding to the TLV Code Point.		withdrawing the capability corresponding to the TLV Code Point.
	The State bit is used as follows:		The State bit 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 Code Point.		TLV Code Point.
	0 - The TLV is withdrawing the capability specified by the		0 - The TLV is withdrawing the capability specified by the
	skipping to change at page 8, line 14		skipping to change at page 8, line 14
	Notification message SHOULD be Unsupported Capability, and the		Notification message SHOULD be Unsupported Capability, and the
	message SHOULD contain the unsupported capabilities (see Section 9		message SHOULD contain the unsupported capabilities (see Section 9
	for more details). In this case the session SHOULD NOT be re-		for more details). In this case the session SHOULD NOT be re-
	established automatically. How the session is re-established is		established automatically. How the session is re-established is
	beyond the scope of this document. It depends on the LDP capability		beyond the scope of this document. It depends on the LDP capability
	and MUST be specified along with the procedures specifying the		and MUST be specified along with the procedures specifying the
	capability.		capability.
	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 SHOULD set the TLV		Capability Parameter in its Initialization message SHOULD set the TLV
	U bit to 1. This ensures that an [RFC3036] compliant peer that does		U bit to 1. This ensures that an [RFC5036] compliant peer that does
	not support the capability mechanism will ignore the Capability		not support the capability mechanism will ignore the Capability
	Parameter and allow the session to be established.		Parameter and allow the session to be established.
	8. Procedures for Capability Parameters in Capability Messages		8. 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 had advertised the Dynamic Capability Announcement
	capability in its session Initialization message (see Section 10).		capability in its session Initialization message (see Section 10).
	An LDP speaker MAY send a Capability message to a peer if its peer		An LDP speaker MAY send a Capability message to a peer if its peer
	skipping to change at page 10, line 8		skipping to change at page 10, line 8
	capability cannot be disabled.		capability cannot be disabled.
	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.
	11. Backward Compatibility		11. 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 [RFC3036] 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 [RFC3036] compliant peer		by default. To ensure compatibility with an [RFC5036] compliant peer
	LDP implementations that support capability advertisement have label		LDP implementations that support capability advertisement have label
	distribution for IPv4 enabled until it is explicitly disabled and		distribution for IPv4 enabled until it is explicitly disabled and
	MUST assume that their peers do as well.		MUST assume that their peers do as well.
	Section 3 identifies a set of Backward Compatibility TLVs that may		Section 3 identifies a set of Backward Compatibility TLVs that may
	appear in Initialization messages in the role of a Capability		appear in Initialization messages in the role of a Capability
	Parameter. This permits existing LDP enhancements that use an ad hoc		Parameter. This permits existing LDP enhancements that use an ad hoc
	mechanism for enabling capabilities at sesssion initialization time		mechanism for enabling capabilities at sesssion initialization time
	to continue to do so.		to continue to do so.
	12. Security Considerations		12. Security Considerations
	The security considerations described in [RFC3036] that apply to the		The security considerations described in [RFC5036] that apply to the
	base LDP specification apply to the capability mechanism described in		base LDP specification apply to the capability mechanism described in
	this document.		this document.
	13. IANA Considerations		13. IANA Considerations
	This document specifies the following which require code points		This document specifies the following which require code points
	assigned by IANA:		assigned by IANA:
	- LDP message code point for the Capability message. The authors		- LDP message code point for the Capability message. The authors
	request message type 0x0202 for the Capability message.		request message type 0x0202 for the Capability message.
	skipping to change at page 11, line 14		skipping to change at page 11, line 14
	14. Acknowledgements		14. Acknowledgements
	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.
	15. References		15. References
	Normative References		Normative References
	[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and		[RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP
	Thomas, B., "LDP Specification", RFC 3036, January 2001.		Specification", RFC 5036, September 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., Editor, "Fault Tolerance for the Label
	Distribution Protocol (LDP)", RFC 3479, February 2003.		Distribution Protocol (LDP)", RFC 3479, February 2003.
	Informative References		Informative References
	[IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for		[IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for
	skipping to change at page 13, line 13		skipping to change at page 13, line 13
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	18. Full Copyright Statement		18. Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
	AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
End of changes. 14 change blocks.
	17 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/