draft-ietf-ccamp-lmp-behavior-negotiation-09.txt		draft-ietf-ccamp-lmp-behavior-negotiation-10.txt
	Network Working Group Dan Li		Network Working Group Dan Li
	Internet Draft Huawei		Internet Draft Huawei
	Updates: 4204, 4207, 4209, 5818 D. Ceccarelli		Updates: 4204, 4207, 4209, 5818 D. Ceccarelli
	Category: Standards Track Ericsson		Category: Standards Track Ericsson
	Lou Berger		Lou Berger
	LabN		LabN
	Expires: June 2013 December 20, 2012		Expires: July 2013 January 24, 2013
	Link Management Protocol Behavior Negotiation and		Link Management Protocol Behavior Negotiation and
	Configuration Modifications		Configuration Modifications
	draft-ietf-ccamp-lmp-behavior-negotiation-09.txt		draft-ietf-ccamp-lmp-behavior-negotiation-10.txt
	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 Generalized
	Multiprotocol Label Switching (GMPLS) networks. This document		Multiprotocol Label Switching (GMPLS)-controlled networks. This
	defines an extension to LMP to negotiate capabilities and indicate		document defines an extension to LMP to negotiate capabilities and
	support for LMP extensions. The defined extension is compatible		indicate support for LMP extensions. The defined extension is
	with non-supporting implementations.		compatible with non-supporting implementations.
	This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818.		This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with		This Internet-Draft is submitted to IETF in full conformance with
	the provisions of BCP 78 and BCP 79.		the provisions of BCP 78 and 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 4		skipping to change at page 2, line 4
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference		at any time. It is inappropriate to use Internet-Drafts as reference
	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
	This Internet-Draft will expire on June 19, 2013.		This Internet-Draft will expire on July 21, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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 to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	skipping to change at page 3, line 11		skipping to change at page 3, line 11
	3.2. Processing ............................................. 7		3.2. Processing ............................................. 7
	4. Backward Compatibility....................................... 7		4. Backward Compatibility....................................... 7
	5. Security Considerations...................................... 8		5. Security Considerations...................................... 8
	6. IANA Considerations ......................................... 9		6. IANA Considerations ......................................... 9
	6.1. New LMP Class Type...................................... 9		6.1. New LMP Class Type...................................... 9
	6.2. New Capabilities Registry............................... 9		6.2. New Capabilities Registry............................... 9
	7. Contributors ............................................... 10		7. Contributors ............................................... 10
	8. Acknowledgments ............................................ 10		8. Acknowledgments ............................................ 10
	9. References ................................................. 10		9. References ................................................. 10
	9.1. Normative References................................... 10		9.1. Normative References................................... 10
	9.2. Informative References................................. 11
	10. Authors' Addresses ........................................ 11		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 Generalized Multiprotocol Label Switching (GMPLS)-
	controlled networks.		controlled networks.
	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 node supports a new behavior or protocol		In a network, if one LMP-capable node supports a new behavior or
	extension but its adjacent node does not, it is beneficial to have a		protocol extension but its adjacent node does not, it is beneficial
	protocol mechanism to discover the capabilities of peer nodes so		to have a protocol mechanism to discover the capabilities of peer
	that the right protocol extensions can be selected and the correct		nodes so that the right protocol extensions can be selected and the
	features can be enabled. There are no such procedures defined in the		correct features can be enabled. There are no such procedures
	base LMP specification [RFC4204]. [RFC4209] defined a specific		defined in the base LMP specification [RFC4204]. [RFC4209] defined a
	mechanism to identify support for the functions defined in that		specific mechanism to identify support for the functions specified
	document. This document defines an LMP extension to support the		in that document. This document defines an LMP extension to support
	identification of supported LMP functions in a generic fashion, as		the identification of supported LMP functions in a generic fashion,
	well as how a node supporting these extensions would communicate		as well as how a node supporting these extensions would communicate
	with legacy nodes.		with 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 the standard LMP messages, which include Config, Hello, Verify,		of the standard LMP messages, which include Config, Hello, Verify,
	Test, LinkSummary, and ChannelStatus. Per [RFC4204], these behaviors		Test, LinkSummary, and ChannelStatus. Per [RFC4204], these behaviors
	MUST be supported when LMP is implemented, and the message types		MUST be supported when LMP is implemented, and the message types
	from 1 to 20 have been assigned by IANA for these messages. Support		from 1 to 20 have been assigned by IANA for these messages. Support
	for all functions required by [RFC4204] is assumed by this document.		for all 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 were assigned by IANA for the
	messages that provide the TRACE function. The Trace function has		messages that provide the TRACE function.
	been extended for the support of OTNs (Optical Transport Networks)
	in [LMP TEST].
	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 sub-object class name have been extended
	to support DWDM behavior.		to support 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.
	skipping to change at page 4, line 32		skipping to change at page 4, line 29
	defined CONFIG object.		defined CONFIG object.
	This document also modifies the format of messages that carry CONFIG		This document also modifies the format of messages that carry CONFIG
	object to allow for multiple objects. Multiple CONFIG objects allow		object to allow for multiple objects. Multiple CONFIG objects allow
	behavior negotiation concurrent with existing usage of the CONFIG		behavior negotiation concurrent with existing usage of the CONFIG
	object, i.e., HelloConfig C-Type defined in [RFC4204] and		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		which supports the extensions defined in this document interacts
	with a legacy LMP node.		with a legacy LMP-capable node.
	2. LMP Message Modifications		2. LMP Message Modifications
	LMP Config, ConfigNack and ConfigAck messages are modified by this		LMP Config, ConfigNack and ConfigAck messages are modified by this
	document to allow for the inclusion of multiple CONFIG objects. The		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
			(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>		<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
	<LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]		<LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]
	The format of the ConfigAck message as updated by this document is		The format of the ConfigAck message as updated by this document is
	as follows:		as follows:
	skipping to change at page 5, line 41		skipping to change at page 5, line 41
	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 is not significant.		object definition, ordering of CONFIG objects is not significant.
	Nodes which support the extensions defined in this document MUST		Nodes which 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 a neighbor whose support for the extensions is either known or		to 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		Nodes MAY include HelloConfig, LMP_WDM_CONFIG, BehaviorConfig object
	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 on the processing of a received Config message. Per [RFC4204]		based 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 which 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".
	skipping to change at page 7, line 23		skipping to change at page 7, line 23
	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).
	The number of bits present is based on the Length field of the		The number of bits present is based on the Length field of the
	LMP object header and MUST include enough bits so the Length		LMP object header and MUST include enough bits so the Length
	field MUST be at least 8, and MUST be a multiple of 4.		field MUST be at least 8, and MUST be a multiple of 4.
	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 MBZ bits field is expected to change.		number of bits in 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
	skipping to change at page 8, line 29		skipping to change at page 8, line 29
	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, [RFC4204]-defined, "retry limit", 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,
	skipping to change at page 9, line 31		skipping to change at page 9, line 31
	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(suggested) BehaviorConfig [This.I-D]
	6.2. New Capabilities Registry		6.2. New Capabilities Registry
	IANA is requested to create a new subregistry of the "Link		IANA is requested to create a new subregistry of the "Link
	Management Protocol (LMP)" registry to track the Behaviour		Management Protocol (LMP)" registry to track the Behavior
	Configuration bits defined in Section 2 of this document. It is		Configuration bits defined in Section 2 of this document. It is
	suggested that this registry be called "LMP Behaviour Configuration		suggested that this registry be called "LMP 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.
	skipping to change at page 11, line 12		skipping to change at page 11, line 12
	Management Protocol (LMP) Test Messages", RFC 4207,		Management Protocol (LMP) Test Messages", RFC 4207,
	October 2005.		October 2005.
	[RFC4209] A. Fredette, Ed., "Link Management Protocol (LMP) for		[RFC4209] A. Fredette, Ed., "Link Management Protocol (LMP) for
	Dense Wavelength Division Multiplexing (DWDM) Optical Line		Dense Wavelength Division Multiplexing (DWDM) Optical Line
	Systems", RFC 4209, October 2005.		Systems", RFC 4209, October 2005.
	[RFC5818] D. Li, Ed., "Data Channel Status Confirmation Extensions		[RFC5818] D. Li, Ed., "Data Channel Status Confirmation Extensions
	for the Link Management Protocol", RFC 5818, April 2010.		for the Link Management Protocol", RFC 5818, April 2010.
	9.2. Informative References		[RFC5511] Farrel, A., Ed., "Routing Backus-Naur Form (RBNF): A
			Syntax Used to Form Encoding Rules in Various Routing
	[LMP TEST] D. Ceccarelli, Ed., "Link Management Protocol (LMP) Test		Protocol Specifications", RFC 5511, April 2009.
	Messages Extensions for Evolutive Optical Transport
	Networks (OTN)" draft-ceccarelli-ccamp-gmpls-g709-lmp-
	test-04.txt, July, 2012.
	10. Authors' Addresses		10. 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 China
	Phone: +86 755-289-70230		Phone: +86 755-289-70230
	Email: danli@huawei.com		Email: huawei.danli@huawei.com
	Daniele Ceccarelli		Daniele Ceccarelli
	Ericsson		Ericsson
	Via A. Negrone 1/A		Via A. Negrone 1/A
	Genova - Sestri Ponente		Genova - Sestri Ponente
	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.
End of changes. 18 change blocks.
	37 lines changed or deleted		34 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/