draft-ietf-ccamp-lmp-behavior-negotiation-11.txt		rfc6898.txt
	Network Working Group Dan Li
	Internet Draft Huawei
	Updates: 4204, 4207, 4209, 5818 D. Ceccarelli
	Category: Standards Track Ericsson
	Lou Berger
	LabN
	Expires: August 2013 February 8, 2013
	Link Management Protocol Behavior Negotiation and		Internet Engineering Task Force (IETF) D. Li
	Configuration Modifications		Request for Comments: 6898 Huawei
			Updates: 4204, 4207, 4209, 5818 D. Ceccarelli
			Category: Standards Track Ericsson
			ISSN: 2070-1721 L. Berger
			LabN
			March 2013
	draft-ietf-ccamp-lmp-behavior-negotiation-11.txt		Link Management Protocol Behavior Negotiation and
			Configuration Modifications
	Abstract		Abstract
	The Link Management Protocol (LMP) is used to coordinate the		The Link Management Protocol (LMP) is used to coordinate the
	properties, use, and faults of data links in Generalized		properties, use, and faults of data links in networks controlled by
	Multiprotocol Label Switching (GMPLS)-controlled networks. This		Generalized Multiprotocol Label Switching (GMPLS). This document
	document defines an extension to LMP to negotiate capabilities and		defines an extension to LMP to negotiate capabilities and indicate
	indicate support for LMP extensions. The defined extension is		support for LMP extensions. The defined extension is compatible with
	compatible with non-supporting implementations.		non-supporting implementations.
	This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818.
	Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with		This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.
	the provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Status of This Memo
	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		This is an Internet Standards Track document.
	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		This document is a product of the Internet Engineering Task Force
	http://www.ietf.org/ietf/1id-abstracts.txt		(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by the
			Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	The list of Internet-Draft Shadow Directories can be accessed at		Information about the current status of this document, any errata,
	http://www.ietf.org/shadow.html		and how to provide feedback on it may be obtained at
	This Internet-Draft will expire on August 5, 2013.		http://www.rfc-editor.org/info/rfc6898.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with respect
	respect to this document. Code Components extracted from this		to this document. Code Components extracted from this document must
	document must include Simplified BSD License text as described in		include Simplified BSD License text as described in Section 4.e of
	Section 4.e of the Trust Legal Provisions and are provided without		the Trust Legal Provisions and are provided without warranty as
	warranty as described in the Simplified BSD License.		described in the Simplified BSD License.
	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.
	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].
	Table of Contents		Table of Contents
	1. Introduction ................................................ 3		1. Introduction ....................................................3
	2. LMP Message Modifications.................................... 4		1.1. Conventions Used in This Document ..........................4
	2.1. Modified Message Formats................................ 4		2. LMP Message Modifications .......................................4
	2.2. Processing ............................................. 5		2.1. Modified Message Formats ...................................4
	3. LMP Behavior Negotiation..................................... 6		2.2. Processing .................................................5
	3.1. BehaviorConfig C-Type Format............................ 6		3. LMP Behavior Negotiation ........................................6
	3.2. Processing ............................................. 7		3.1. BehaviorConfig C-Type Format ...............................6
	4. Backward Compatibility....................................... 7		3.2. Processing .................................................7
	5. Security Considerations...................................... 8		4. Backward Compatibility ..........................................7
	6. IANA Considerations ......................................... 9		5. Security Considerations .........................................8
	6.1. New LMP Class Type...................................... 9		6. IANA Considerations .............................................9
	6.2. New Capabilities Registry............................... 9		6.1. New LMP Class Type .........................................9
	7. Contributors ............................................... 10		6.2. New Capabilities Registry ..................................9
	8. Acknowledgments ............................................ 10		7. Normative References ...........................................10
	9. References ................................................. 10		8. Acknowledgments ................................................10
	9.1. Normative References................................... 10		9. Contributors ...................................................10
	10. Authors' Addresses ........................................ 11
	1. Introduction		1. Introduction
	The Link Management Protocol (LMP) [RFC4204] has been successfully		The Link Management Protocol (LMP) [RFC4204] has been successfully
	deployed in Generalized Multiprotocol Label Switching (GMPLS)-		deployed in networks controlled by Generalized Multiprotocol Label
	controlled networks.		Switching (GMPLS).
	New LMP behaviors and protocol extensions have been introduced in a		New LMP behaviors and protocol extensions have been introduced in a
	number of IETF documents as set out later in this section. It is		number of IETF documents, as set out later in this section. It is
	likely that future extensions will be made to support additional		likely that future extensions will be made to support additional
	functions.		functions.
	In a network, if one LMP-capable node supports a new behavior or		In a network, if one LMP-capable node supports a new behavior or
	protocol extension but its adjacent node does not, it is beneficial		protocol extension but its adjacent node does not, it is beneficial
	to have a protocol mechanism to discover the capabilities of peer		to have a protocol mechanism to discover the capabilities of peer
	nodes so that the right protocol extensions can be selected and the		nodes so that the right protocol extensions can be selected and the
	correct features can be enabled. There are no such procedures		correct features can be enabled. There are no such procedures
	defined in the base LMP specification [RFC4204]. [RFC4209] defined a		defined in the base LMP specification [RFC4204]. [RFC4209] defined a
	specific mechanism to identify support for the functions specified		specific mechanism to identify support for the functions specified in
	in that document. This document defines an LMP extension to support		that document. This document defines an LMP extension to support the
	the identification of supported LMP functions in a generic fashion,		identification of supported LMP functions in a generic fashion, as
	as well as how a node supporting these extensions would communicate		well as how a node supporting these extensions would communicate with
	with legacy nodes.		legacy nodes.
	In [RFC4204], the basic behaviors have been defined around the use		In [RFC4204], the basic behaviors have been defined around the use of
	of the standard LMP messages, which include Config, Hello, Verify,		the standard LMP messages, which include Config, Hello, Verify, Test,
	Test, LinkSummary, and ChannelStatus. Per [RFC4204], these behaviors		LinkSummary, and ChannelStatus. Per [RFC4204], these behaviors MUST
	MUST be supported when LMP is implemented, and the message types		be supported when LMP is implemented, and the message types from 1 to
	from 1 to 20 have been assigned by IANA for these messages. Support		20 have been assigned by IANA for these messages. Support for all
	for all functions required by [RFC4204] is assumed by this document.		functions required by [RFC4204] is assumed by this document.
	In [RFC4207], the SONET/SDH technology-specific behavior and		In [RFC4207], the SONET/SDH technology-specific behavior and
	information for LMP is defined. The Trace behavior is added to LMP,		information for LMP is defined. The Trace behavior is added to LMP,
	and the message types from 21 to 31 were assigned by IANA for the		and the message types from 21 to 31 have been assigned by IANA for
	messages that provide the TRACE function.		the messages that provide the Trace function.
	In [RFC4209], extensions to LMP are defined to allow it to be used		In [RFC4209], extensions to LMP are defined to allow it to be used
	between a peer node and an adjacent Optical Line System (OLS). The		between a peer node and an adjacent Optical Line System (OLS). The
	LMP object class type and sub-object class name have been extended		LMP object class type and subobject class name have been extended to
	to support DWDM behavior.		support Dense Wavelength Division Multiplexing (DWDM) behavior.
	In [RFC5818], the data channel consistency check behavior is defined,		In [RFC5818], the data channel consistency check behavior is defined,
	and the message types from 32 to 34 have been assigned by IANA for		and the message types from 32 to 34 have been assigned by IANA for
	messages that provide this behavior.		messages that provide this behavior.
	It is likely that future extensions to LMP for other functions or		It is likely that future extensions to LMP for other functions or
	technologies will require the definition of further LMP messages.		technologies will require the definition of further LMP messages.
	This document describes an LMP extension, which is referred to as		This document describes an LMP extension, referred to as behavior
	behavior negotiation, which enables nodes at the ends of a link to		negotiation, that enables the nodes at the ends of a link to identify
	identify the LMP messages and functions supported by the adjacent		the LMP messages and functions supported by the adjacent node. The
	node. The extension makes use of a new CONFIG object. The use of		extension makes use of a new CONFIG object. The use of this new
	this new object does not preclude the use of existing or yet to be		object does not preclude the use of existing or yet to be defined
	defined CONFIG object.		CONFIG objects.
	This document also modifies the format of messages that carry CONFIG		This document also modifies the format of messages that carry the
	object to allow for multiple objects. Multiple CONFIG objects allow		CONFIG object to allow for multiple objects. Multiple CONFIG objects
	behavior negotiation concurrent with existing usage of the CONFIG		allow behavior negotiation concurrent with existing usage of the
	object, i.e., HelloConfig C-Type defined in [RFC4204] and		CONFIG object, i.e., HelloConfig C-Type defined in [RFC4204] and
	LMP_WDM_CONFIG C-Type defined in [RFC4209]. This document modifies		LMP-WDM_CONFIG C-Type defined in [RFC4209]. This document modifies
	the ConfigAck message to include CONFIG objects so that acceptable		the ConfigAck message to include CONFIG objects so that acceptable
	parameters are explicitly identified. It also describes how a node		parameters are explicitly identified. It also describes how a node
	which supports the extensions defined in this document interacts		that supports the extensions defined in this document interacts with
	with a legacy LMP-capable node.		a legacy LMP-capable node.
	2. LMP Message Modifications		1.1. Conventions Used in This Document
	LMP Config, ConfigNack and ConfigAck messages are modified by this		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	document to allow for the inclusion of multiple CONFIG objects. The		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			2. LMP Message Modifications
			LMP Config, ConfigNack, and ConfigAck messages are modified by this
			document to allow for the inclusion of multiple CONFIG objects. The
	Config and ConfigNack messages were only defined to carry one CONFIG		Config and ConfigNack messages were only defined to carry one CONFIG
	object in [RFC4204]. The ConfigAck message, which was defined		object in [RFC4204]. The ConfigAck message, which was defined
	without carrying any CONFIG objects in [RFC4204], is modified to		without carrying any CONFIG objects in [RFC4204], is modified to
	enable explicit identification of negotiated configuration		enable explicit identification of negotiated configuration
	parameters. The inclusion of CONFIG objects in ConfigAck messages is		parameters. The inclusion of CONFIG objects in ConfigAck messages is
	triggered by the use of the BehaviorConfig object (defined below) in		triggered by the use of the BehaviorConfig object (defined below) in
	a received Config message.		a received Config message.
	The message formats in the sections that follow use Backus-Naur Form		The message formats in the sections that follow use Backus-Naur Form
	(BNF) encoding as defined in [RFC5511].		(BNF) encoding as defined in [RFC5511].
	2.1. Modified Message Formats		2.1. Modified Message Formats
	The format of the Config message as updated by this document is as		The format of the Config message as updated by this document is as
	follows:		follows:
			<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
			<LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]
	<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>		The format of the ConfigAck message as updated by this document is as
	<LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]		follows:
	The format of the ConfigAck message as updated by this document is
	as follows:
	<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>		<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
	<REMOTE_CCID> <MESSAGE_ID_ACK>		<REMOTE_CCID> <MESSAGE_ID_ACK>
	<REMOTE_NODE_ID>[ <CONFIG> ... ]		<REMOTE_NODE_ID>[ <CONFIG> ... ]
	The format of the ConfigNack message as updated by this document is		The format of the ConfigNack message as updated by this document is
	as follows:		as follows:
	<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>		<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
	<LOCAL_NODE_ID> <REMOTE_CCID>		<LOCAL_NODE_ID> <REMOTE_CCID>
	<MESSAGE_ID_ACK> <REMOTE_NODE_ID>		<MESSAGE_ID_ACK> <REMOTE_NODE_ID>
	<CONFIG> [ <CONFIG> ... ]		<CONFIG> [ <CONFIG> ... ]
	2.2. Processing		2.2. Processing
	Nodes that support the extensions defined in this document MAY		Nodes that support the extensions defined in this document MAY
	include multiple CONFIG objects when sending a Config, ConfigAck and		include multiple CONFIG objects when sending a Config, ConfigAck, and
	ConfigNack message. A maximum of a single object of any particular		ConfigNack message. A maximum of a single object of any particular
	C-type SHALL be included. A node which receives a message with		C-type SHALL be included. A node that receives a message with
	multiple CONFIG objects of the same C-type SHALL process the first		multiple CONFIG objects of the same C-type SHALL process the first
	object of a particular C-type and ignore any subsequent CONFIG		object of a particular C-type and ignore any subsequent CONFIG
	objects of the same C-type. Unless specified as part of the CONFIG		objects of the same C-type. Unless specified as part of the CONFIG
	object definition, ordering of CONFIG objects with different C-type		object definition, ordering of CONFIG objects with different C-type
	values is not significant.		values is not significant.
	Nodes that support the extensions defined in this document MUST		Nodes that support the extensions defined in this document MUST
	include a BehaviorConfig type object when sending a Config message		include a BehaviorConfig type object when sending a Config message to
	to a neighbor whose support for the extensions is either known or		a neighbor whose support for the extensions is either known or
	unknown. When the neighbor is known to not support the extensions,		unknown. When the neighbor is known to not support the extensions,
	the object MUST NOT be sent. Inclusion of other CONFIG objects in a		the object MUST NOT be sent. Inclusion of other CONFIG objects in a
	Config message is at the discretion of the message sender, and is		Config message is at the discretion of the message sender and is
	based on the rules defined as part of CONFIG object definition.		based on the rules defined as part of CONFIG object definition.
	Nodes MAY include HelloConfig, LMP_WDM_CONFIG, BehaviorConfig object		Nodes MAY include HelloConfig, LMP-WDM_CONFIG, BehaviorConfig object
	types in a single message.		types in a single message.
	Inclusion of multiple CONFIG objects in a ConfigNack message is		Inclusion of multiple CONFIG objects in a ConfigNack message is based
	based on the processing of a received Config message. Per [RFC4204]		on the processing of a received Config message. Per [RFC4204],
	"Parameters where agreement was reached MUST NOT be included in the		"Parameters where agreement was reached MUST NOT be included in the
	ConfigNack Message." As such, a ConfigNack message MUST NOT include		ConfigNack Message." As such, a ConfigNack message MUST NOT include
	CONFIG objects which are acceptable and MUST include any CONFIG		CONFIG objects that are acceptable and MUST include any CONFIG
	objects which are not acceptable. When a CONFIG object is included		objects which are not acceptable. When a CONFIG object is included
	in a ConfigNack message, per [RFC4204], the object is to include		in a ConfigNack message, per [RFC4204], the object is to include
	"acceptable alternate values for negotiable parameters".		"acceptable alternate values for negotiable parameters".
	When sending a ConfigAck message, nodes supporting the extensions		When sending a ConfigAck message, nodes supporting the extensions
	defined in this document MUST include all CONFIG objects received in		defined in this document MUST include all CONFIG objects received in
	the corresponding Config message when that message includes a CONFIG		the corresponding Config message when that message includes a CONFIG
	object of type BehaviorConfig.		object of type BehaviorConfig.
	3. LMP Behavior Negotiation		3. LMP Behavior Negotiation
	The Config message is used in the control channel negotiation phase		The Config message is used in the control channel negotiation phase
	of LMP [RFC4204]. The LMP behavior negotiation procedure is defined		of LMP [RFC4204]. The LMP behavior negotiation procedure is defined
	in this document as an addition to this phase.		in this document as an addition to this phase.
	The Config message is defined in Section 12.3.1 of [RFC4204] and		The Config message is defined in Section 12.3.1 of [RFC4204] and
	carries the CONFIG object (class name 6) as defined in Section 13.6		carries the CONFIG object (class name 6) as defined in Section 13.6
	of [RFC4204].		of [RFC4204].
	Two class types have been defined:		Two class types have been defined:
	- C-Type = 1, HelloConfig, defined in [RFC4204]		- C-Type = 1, HelloConfig, defined in [RFC4204]
	- C-Type = 2, LMP_WDM_CONFIG, defined in [RFC4209]		- C-Type = 2, LMP-WDM_CONFIG, defined in [RFC4209]
	This document defines a third C-Type to report and negotiate LMP		This document defines a third C-Type to report and negotiate LMP
	mechanisms and behaviors. Its usage indicates support for the		mechanisms and behaviors. Its usage indicates support for the
	extensions defined in this document.		extensions defined in this document.
	3.1. BehaviorConfig C-Type Format		3.1. BehaviorConfig C-Type Format
	Class = 6		Class = 6
	- C-Type = (To be assigned by IANA), BehaviorConfig		- C-Type = 3, BehaviorConfig
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S|D|C| Must Be Zero (MBZ) |		|S|D|C| Must Be Zero (MBZ) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Flags:		Flags:
	S: 1 bit		S: 1 bit
	This bit indicates support for the Trace behavior of SONET/SDH		This bit indicates support for the Trace behavior of SONET/SDH
	technology-specific defined in [RFC4207].		technology-specific defined in [RFC4207].
	D: 1 bit		D: 1 bit
	skipping to change at page 7, line 23		skipping to change at page 7, line 13
	[RFC4209].		[RFC4209].
	C: 1 bit		C: 1 bit
	This bit indicates support for the data channel consistency check		This bit indicates support for the data channel consistency check
	behavior defined in [RFC5818].		behavior defined in [RFC5818].
	Must Be Zero (MBZ): Variable length		Must Be Zero (MBZ): Variable length
	The remaining bits in the flags field MUST be set to zero (0).		The remaining bits in the flags field MUST be set to zero (0).
	This field MUST be sized to ensure 32 bit alignment of the object.		This field MUST be sized to ensure 32-bit alignment of the object.
	Other bits may be defined in future documents, in which case the		Other bits may be defined in future documents, in which case the
	number of bits in MBZ field is expected to change.		number of bits in the MBZ field is expected to change.
	3.2. Processing		3.2. Processing
	The inclusion of a BehaviorConfig type object in a message is		The inclusion of a BehaviorConfig type object in a message is
	discussed above in Section 2.2.		discussed above in Section 2.2.
	When sending a BehaviorConfig type object, the N-bit (negotiable) in		When sending a BehaviorConfig type object, the N-bit (negotiable) in
	the LMP object header MUST be set (N=1) in the LMP object header.		the LMP object header MUST be set (N=1) in the LMP object header.
	When sending a BehaviorConfig type object in Config and ConfigNack		When sending a BehaviorConfig type object in Config and ConfigNack
	messages, the flags field SHOULD be set based on the supported		messages, the flags field SHOULD be set based on the supported
	capabilities of the sending node. When sending a ConfigAck message,		capabilities of the sending node. When sending a ConfigAck message,
	the flags field MUST be set to the value received in the		the flags field MUST be set to the value received in the
	corresponding Config message.		corresponding Config message.
	When receiving a BehaviorConfig type object, the node compares the		When receiving a BehaviorConfig type object, the node compares the
	flags field against its capacities. Any bit set in the MBZ portion		flags field against its capacities. Any bit set in the MBZ portion
	of the flags field MUST be interpreted as unacceptable. Processing		of the flags field MUST be interpreted as unacceptable. Processing
	related to unacceptable values in CONFIG objects is defined in		related to unacceptable values in CONFIG objects is defined in
	[RFC4204] and is not modified by this document.		[RFC4204] and is not modified by this document.
	4. Backward Compatibility		4. Backward Compatibility
	The required use of the BehaviorConfig type CONFIG object enables		The required use of the BehaviorConfig type CONFIG object enables
	nodes which support the extensions defined in this document to		nodes that support the extensions defined in this document to
	explicitly identify when a neighboring node does not. When a non-		explicitly identify when a neighboring node does not. When a non-
	supporting node receives a Config message with the BehaviorConfig		supporting node receives a Config message with the BehaviorConfig
	type CONFIG object or multiple CONFIG objects its behavior is to be		type CONFIG object or multiple CONFIG objects, its behavior is to be
	one of the following behaviors:		one of the following behaviors:
	a) Reject the Config message because of the unknown BehaviorConfig		a) Reject the Config message because of the unknown BehaviorConfig
	object type and send a ConfigNack message which includes the		object type and send a ConfigNack message which includes the
	unsupported C-type.		unsupported C-type.
	b) Reject the message because of multiple CONFIG objects and send a		b) Reject the message because of multiple CONFIG objects and send a
	ConfigNack message which includes all but one of the CONFIG		ConfigNack message which includes all but one of the CONFIG
	objects.		objects.
	c) Silently ignore the one or more of the CONFIG object, and respond		c) Silently ignore the one or more of the CONFIG object, and respond
	with a ConfigAck message that does not include any CONFIG objects.		with a ConfigAck message that does not include any CONFIG objects.
	d) Treat the message as malformed, and discard it without any		d) Treat the message as malformed, and discard it without any
	response.		response.
	Behaviors (a) and (b) result in ConfigNack messages with a		Behaviors (a) and (b) result in ConfigNack messages with a
	BehaviorConfig type object whose contents are identical to what was		BehaviorConfig type object whose contents are identical to what was
	sent in the Config message. Behavior (c) results in a ConfigAck		sent in the Config message. Behavior (c) results in a ConfigAck
	message without a BehaviorConfig type CONFIG object. In each of		message without a BehaviorConfig type CONFIG object. In each of
	these cases, the node SHOULD explicitly identify that the LMP		these cases, the node SHOULD explicitly identify that the LMP
	neighbor does not support the extensions defined in this document.		neighbor does not support the extensions defined in this document.
	Behavior (d) results in no response at all. When the node reaches		Behavior (d) results in no response at all. When the node reaches
	the, [RFC4204]-defined, "retry limit", the node SHOULD infer that		the "retry limit", defined in [RFC4204], the node SHOULD infer that
	the LMP neighbor does not support the extensions defined in this		the LMP neighbor does not support the extensions defined in this
	document.		document.
	Once a node identifies a neighbor as not supporting the extensions		Once a node identifies a neighbor as not supporting the extensions
	defined in this document, the node SHOULD follow previously defined		defined in this document, the node SHOULD follow previously defined
	Config message usage.		Config message usage.
	5. Security Considerations		5. Security Considerations
	[RFC4204] describes how LMP messages between peers can be secured,		[RFC4204] describes how LMP messages between peers can be secured,
	and these measures are equally applicable to messages carrying the		and these measures are equally applicable to messages carrying the
	new CONFIG object defined in this document.		new CONFIG object defined in this document.
	The procedures described in this document do not of itself		Alone, the procedures described in this document do not constitute a
	constitute a security risk since they do not cause any change in		security risk, since they do not cause any change in network state.
	network state. It would be possible, if the messages were		It would be possible, if the messages were intercepted or spoofed to
	intercepted or spoofed to cause bogus alerts in the management plane,		cause bogus alerts in the management plane, or to cause LMP peers to
	or to cause LMP peers to consider that they could or could not		consider that they could or could not operate protocol extensions,
	operate protocol extensions, and so the use of the LMP security		and so the use of the LMP security measures are RECOMMENDED.
	measures are RECOMMENDED.
	Note, however that [RFC4204] references for security have been		Note, however, that [RFC4204] references for security have been
	updated with [RFC4301] and the current reference for IKEv2 is		updated with [RFC4301], and the current reference for IKEv2 is
	[RFC5996].		[RFC5996].
	6. IANA Considerations		6. IANA Considerations
	6.1. New LMP Class Type		6.1. New LMP Class Type
	IANA maintains the "Link Management Protocol (LMP)" registry which		IANA maintains the "Link Management Protocol (LMP) Parameters"
	has a subregistry called "LMP Object Class name space and Class type		registry, which has a subregistry called "LMP Object Class name space
	(C-Type)".		and Class type (C-Type)".
	IANA is requested to make an assignment from this registry as		IANA has made an assignment from this registry as follows:
	follows:
	6 CONFIG [RFC4204]		6 CONFIG [RFC4204]
	CONFIG Object Class type name space:		CONFIG Object Class type name space:
	C-Type Description Reference		C-Type Description Reference
	------------ --------------------- ---------		------------ --------------------- ---------
	3(suggested) BehaviorConfig [This.I-D]		3 BehaviorConfig RFC 6898
	6.2. New Capabilities Registry		6.2. New Capabilities Registry
	IANA is requested to create a new subregistry of the "Link		IANA has created a new subregistry of the "Link Management Protocol
	Management Protocol (LMP)" registry to track the Behavior		(LMP) Parameters" registry to track the Behavior Configuration bits
	Configuration bits defined in Section 2 of this document. It is		defined in Section 2 of this document. This registry is called "LMP
	suggested that this registry be called "LMP Behavior Configuration		Behavior Configuration Flags".
	Flags".
	Allocations from this registry are by Standards Action.		Allocations from this registry are by Standards Action.
	Bits in this registry are numbered from zero as the most significant		Bits in this registry are numbered from zero as the most significant
	bit (transmitted first). The number of bits that can be present is		bit (transmitted first). The number of bits that can be present is
	limited by the length field of the CONFIG object which gives rise to		limited by the length field of the CONFIG object, which gives rise to
	(255 x 32)-8 = 8152. IANA is strongly recommended to allocate new		(255 x 32)-8 = 8152. IANA is strongly recommended to allocate new
	bits with the lowest available unused number.		bits with the lowest available unused number.
	The registry is initially populated as follows:		The registry is initially populated as follows:
	Bit | Bit | Meaning | Reference		Bit | Bit | Meaning | Reference
	Number | Name | |		Number | Name | |
	-------+------+----------------------------------------+----------		-------+------+----------------------------------------+----------
	0 | S | SONET/SDH Test support | [This.ID]		0 | S | SONET/SDH Test support | RFC 6898
	1 | D | DWDM support | [This.ID]		1 | D | DWDM support | RFC 6898
	2 | C | Data Channel consistency check support | [This.ID]		2 | C | Data Channel consistency check support | RFC 6898
	7. Contributors
	Diego Caviglia		7. Normative References
	Ericsson
	Via A. Negrone 1/A 16153
	Genoa Italy
	Phone: +39 010 600 3736
	Email: diego.caviglia@ericsson.com
	8. Acknowledgments		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
	Thanks to Adrian Farrel and Richard Graveman for their useful		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	comments.		Internet Protocol", RFC 4301, December 2005.
	9. References		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
			"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
			5996, September 2010.
	9.1. Normative References		[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
			October 2005.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC4207] Lang, J. and D. Papadimitriou, "Synchronous Optical
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Network (SONET)/Synchronous Digital Hierarchy (SDH)
			Encoding for Link Management Protocol (LMP) Test
			Messages", RFC 4207, October 2005.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4209] Fredette, A., Ed., and J. Lang, Ed., "Link Management
	Internet Protocol", RFC 4301, December 2005		Protocol (LMP) for Dense Wavelength Division Multiplexing
			(DWDM) Optical Line Systems", RFC 4209, October 2005.
	[RFC5996] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, "Internet Key		[RFC5818] Li, D., Xu, H., Bardalai, S., Meuric, J., and D. Caviglia,
	Exchange Protocol: IKEv2", RFC 5996, September 2010.		"Data Channel Status Confirmation Extensions for the Link
			Management Protocol", RFC 5818, April 2010.
	[RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204,		[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
	October 2005.		Used to Form Encoding Rules in Various Routing Protocol
			Specifications", RFC 5511, April 2009.
	[RFC4207] J. Lang, Ed., "Synchronous Optical Network (SONET)/		8. Acknowledgments
	Synchronous Digital Hierarchy (SDH) Encoding for Link
	Management Protocol (LMP) Test Messages", RFC 4207,
	October 2005.
	[RFC4209] A. Fredette, Ed., "Link Management Protocol (LMP) for		Thanks to Adrian Farrel and Richard Graveman for their useful
	Dense Wavelength Division Multiplexing (DWDM) Optical Line		comments.
	Systems", RFC 4209, October 2005.
	[RFC5818] D. Li, Ed., "Data Channel Status Confirmation Extensions		9. Contributors
	for the Link Management Protocol", RFC 5818, April 2010.
	[RFC5511] Farrel, A., Ed., "Routing Backus-Naur Form (RBNF): A		Diego Caviglia
	Syntax Used to Form Encoding Rules in Various Routing		Ericsson
	Protocol Specifications", RFC 5511, April 2009.		Via E. Melen, 77
			Genova - Erzelli
			Italy
			Phone: +39 010 600 3736
			EMail: diego.caviglia@ericsson.com
	10. Authors' Addresses		Authors' Addresses
	Dan Li		Dan Li
	Huawei Technologies		Huawei Technologies
	F3-5-B R&D Center, Huawei Industrial Base,		F3-5-B R&D Center, Huawei Industrial Base,
	Shenzhen 518129 China		Shenzhen 518129
	Phone: +86 755-289-70230		China
	Email: huawei.danli@huawei.com		Phone: +86 755-289-70230
			EMail: huawei.danli@huawei.com
	Daniele Ceccarelli		Daniele Ceccarelli
	Ericsson		Ericsson
	Via A. Negrone 1/A		Via E. Melen, 77
	Genova - Sestri Ponente		Genova - Erzelli
	Italy		Italy
	Email: daniele.ceccarelli@ericsson.com		EMail: daniele.ceccarelli@ericsson.com
	Lou Berger		Lou Berger
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Email: lberger@labn.net		EMail: lberger@labn.net
End of changes. 84 change blocks.
	250 lines changed or deleted		226 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/