draft-ietf-ccamp-lmp-behavior-negotiation-03.txt		draft-ietf-ccamp-lmp-behavior-negotiation-04.txt
	Network Working Group Dan Li		Network Working Group Dan Li
	Internet Draft Huawei		Internet Draft Huawei
	Updates: RFC4204 D. Ceccarelli		Updates: 4204, 4207,4209, 5818 D. Ceccarelli
	Category: Standards Track Ericsson		Category: Standards Track Ericsson
			Lou Berger
			LabN
	Expires: October 2011 April 7, 2011		Expires: December 2011 June 7, 2011
	Behavior Negotiation in The Link Management Protocol		Link Management Protocol Behavior Negotiation and
			Configuration Modifications
	draft-ietf-ccamp-lmp-behavior-negotiation-03.txt		draft-ietf-ccamp-lmp-behavior-negotiation-04.txt
			Abstract
			The Link Management Protocol (LMP) is used to coordinate the
			properties, use, and faults of data links in Generalized
			Multiprotocol Label Switching (GMPLS) networks. This document
			defines an extension to LMP to negotiate capabilities and indicate
			support for LMP extensions. The defined extension is compatible
			with non-supporting implementations.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 34		skipping to change at page 1, line 46
	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 October 7, 2011.		This Internet-Draft will expire on December 7, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	warranty as described in the Simplified BSD License.		warranty as described in the Simplified BSD License.
	Abstract
	The Link Management Protocol (LMP) is used to coordinate the
	properties, use, and faults of data links in Generalized
	Multiprotocol Label Switching (GMPLS) networks. Various proposals
	have been advanced to provide extensions to the base LMP
	specification. This document defines an extension to negotiate
	capabilities and support for those extensions, and provides a
	generic procedure for LMP implementations that do not recognize or
	do not support any one of these extensions.
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction ................................................ 2		1. Introduction ................................................ 3
	2. LMP Behavior Negotiation Procedure........................... 3		2. LMP Message Modifications.................................... 4
	3. Backward Compatibility....................................... 5		2.1. Modified Message Formats................................ 4
	4. Security Considerations...................................... 6		2.2. Processing ............................................. 5
	5. IANA Considerations ......................................... 7		3. LMP Behavior Negotiation..................................... 6
	5.1. New LMP Class Type...................................... 7		3.1. BehaviorConfig C-Type Format............................ 6
	5.2. New Capabilities Registry............................... 7		3.2. Processing ............................................. 7
	6. Contributors ................................................ 8		4. Backward Compatibility....................................... 7
	7. Acknowledgments ............................................. 8		5. Security Considerations...................................... 8
	8. References .................................................. 8		6. IANA Considerations ......................................... 9
	8.1. Normative References.................................... 8		6.1. New LMP Class Type...................................... 9
	8.2. Informative References.................................. 9		6.2. New Capabilities Registry............................... 9
	9. Authors' Addresses .......................................... 9		7. Contributors ............................................... 10
			8. Acknowledgments ............................................ 10
			9. References ................................................. 10
			9.1. Normative References................................... 10
			9.2. Informative References................................. 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 the network, if one GMPLS Label Switch Router (LSR) supports a		In a network, if one LMP node supports a new behavior or protocol
	new behavior or protocol extension, but its peer LSR does not, it is		extension but its adjacent node does not, it is beneficial to have a
	necessary to have a protocol mechanism for resolving issues that may		protocol mechanism to discover the capabilities of peer nodes so
	arise. It is also beneficial to have a protocol mechanism to		that the right protocol extensions can be selected and the correct
	discover the capabilities of peer LSRs so that the right protocol		features can be enabled. There are no such procedures defined in the
	extensions can be selected and the correct features enabled. There		base LMP specification [RFC4204]. [RFC4209] defined a specific
	are no such procedures defined in the base LMP specification		mechanism to identify support for the functions defined in that
	[RFC4204], so this document defines how to handle LMP extensions		document. This document defines an LMP extension to support the
	both at legacy LSRs and at upgraded LSRs that would communicate with		identification of supported LMP functions in a generic fashion, as
	legacy LSRs.		well as how a node supporting these extensions would communicate
			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 [RCF4204], these behaviors		Test, LinkSummary, and ChannelStatus. Per [RCF4204], 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.		from 1 to 20 have been assigned by IANA for these messages. Support
			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. The Trace function has
	been extended for the support of OTNs (Optical Transport Networks)		been extended for the support of OTNs (Optical Transport Networks)
	in [LMP-TEST].		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.
	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 the behavior negotiation procedure to make		This document describes an LMP extension, which is referred to as
	sure both LSRs at the ends of each link understand the LMP messages		behavior negotiation, which enables nodes at the ends of a link to
	that they exchange.		identify the LMP messages and functions supported by the adjacent
			node. The extension makes use of a new CONFIG object. The use of
			this new object does not preclude the use of existing or yet to be
			defined CONFIG object.
	2. LMP Behavior Negotiation Procedure		This document also modifies the format of messages that carry CONFIG
			object to allow for multiple objects. Multiple CONFIG objects allow
			behavior negotiation concurrent with existing usage of the CONFIG
			object, i.e., HelloConfig C-Type defined in [RFC4204] and
			LMP_WDM_CONFIG C-Type defined in [RFC4209]. This document modifies
			the ConfigAck message to include CONFIG objects so that acceptable
			parameters are explicitly identified. It also describes how a node
			which supports the extensions defined in this document interacts
			with a legacy LMP node.
			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 on CONFIG
			object in [RFC4204]. The ConfigAck message, which was defined
			without carrying any CONFIG objects in [RFC4204], is modified to
			enable explicit identification of negotiated configuration
			parameters. The inclusion of CONFIG objects in ConfigAck messages is
			triggered by the use of the BehaviorConfig object (defined below) in
			a received Config message.
			2.1. Modified Message Formats
			The format of the Config message as updated by this document is as
			follows:
			<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
			<LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]
			The format of the ConfigAck message as updated by this document is
			as follows:
			<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
			<REMOTE_CCID> <MESSAGE_ID_ACK>
			<REMOTE_NODE_ID>[ <CONFIG> ... ]
			The format of the ConfigNack message as updated by this document is
			as follows:
			<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
			<LOCAL_NODE_ID> <REMOTE_CCID>
			<MESSAGE_ID_ACK> <REMOTE_NODE_ID>
			<CONFIG> [ <CONFIG> ... ]
			2.2. Processing
			Nodes which support the extensions defined in this document MAY
			include multiple CONFIG objects when sending a Config, ConfigAck and
			ConfigNack message. A maximum of a single object of any particular
			C-type SHALL be included. A node which receives a message with
			multiple CONFIG objects of the same C-type SHALL process the first
			object of a particular C-type and ignore any subsequent CONFIG
			objects of the same C-type. Unless specified as part of the CONFIG
			object definition, ordering of CONFIG objects is not significant.
			Nodes which support the extensions defined in this document MUST
			include a BehaviorConfig type object when sending a Config message
			to a neighbor whose support for the extensions is either known or
			unknown. (But not when the neighbor is known to not support the
			extensions.) Inclusion of other CONFIG objects in a Config message
			is at the discretion of the message sender, and is based on the
			rules defined by as part of CONFIG object definition. Nodes MAY
			include, HelloConfig, LMP_WDM_CONFIG, BehaviorConfig object types in
			a single message.
			Inclusion of multiple CONFIG objects in a ConfigNack message is
			based on the processing of a received Config message. Per [RFC4204]
			"Parameters where agreement was reached MUST NOT be included in the
			ConfigNack Message." As such, a ConfigNack message MUST NOT include
			CONFIG objects which are acceptable and MUST include any CONFIG
			objects which are not acceptable. When a CONFIG object is included
			in a ConfigNack message, per [RFC4204], the object is to include
			"acceptable alternate values for negotiable parameters".
			When sending a ConfigAck message, nodes supporting the extensions
			defined in this document MUST include all CONFIG objects received in
			the corresponding Config message when that message includes a CONFIG
			object of type BehaviorConfig.
			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		carries the CONFIG object (class name 6) as defined in Section 13.6
	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 with value 3 (TBD by IANA) to		This document defines a third C-Type to report and negotiate LMP
	report and negotiate currently defined LMP mechanisms and behaviors,		mechanisms and behaviors. Its usage indicates support for the
	and to allow future LMP extensions to be reported and negotiated.		extensions defined in this document.
	- C-Type = 3, BEHAVIOR_CONFIG		3.1. BehaviorConfig C-Type Format
	The format of the new type of CONFIG Class is defined as follows:		Class = 6
			- C-Type = (To be assigned by IANA), 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length |B|S|D|C| MUST_BE_ZERO |		|S|D|C| Must Be Zero (MBZ) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Length: 8 bits
	This field indicates the total length of the objects expressed in
	multiples of 4 bytes.
	Flags:		Flags:
	B: 1 bit
	This bit indicates support for the basic behaviors defined in
	[RFC4204].
	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
	This bit indicates support for the DWDM behavior defined in		This bit indicates support for the DWDM behavior defined in
	[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].
	Further bits may be defined in future documents.		Must Be Zero (MBZ): Variable length
	The MUST_BE_ZERO field MUST be sent as zero and MUST NOT be ignored		The remaining bits in the flags field MUST be set to zero (0).
	on receipt. This allows the detection of unsupported or unknown LMP		The number of bits present is based on the Length field of the
	behaviors when new bits are allocated to indicate further		LMP object header and MUST include enough bits so the Length
	capabilities and are sent as one.		field MUST be at least 8, and MUST be a multiple of 4.
	Upon receiving a bit set related to an unsupported or unknown		Other bits may be defined in future documents, in which case the
	behavior, a ConfigNack message MUST be sent with a <CONFIG> object,		number of MBZ bits field is expected to change.
	the BEHAVIOR_CONFIG C-Type representing the supported LMP behaviors.
	An LSR receiving such a ConfigNack SHOULD select a supported set of
	capabilities and send a further Config message, or MAY raise an
	alert to the management system (or log an error) and stop trying to
	perform LMP communications with its neighbor.
	Note that multiple <CONFIG> objects (each with a different Class		3.2. Processing
	Type) MAY be present on a Config message in which case all of the
	objects SHOULD be processed, but see the note on backward
	compatibility in the next section. However, if more than one
	<CONFIG> object with the same Class Type is present on a Config
	message, the message SHOULD be rejected.
	3. Backward Compatibility		The inclusion of a BehaviorConfig type object in a message is
			discussed above in Section 2.2.
	An LSR that receives a Config message containing a <CONFIG> object		When sending a BehaviorConfig type object, the N-bit (negotiable) in
	with a C-Type that it does not recognize should respond with a		the LMP object header must be set (N=1) in the LMP object header.
	ConfigNack message as described in [RFC4204]. Thus, legacy LMP nodes
	that do not support the BEHAVIOR_CONFIG C-Type defined in this
	document will respond with a ConfigNack message.
	Note that [RFC4204] does not describe how multiple <CONFIG> objects		When sending a BehaviorConfig type object in Config and ConfigNack
	with different C-Types should be processed. Thus it is possible that		messages, the flags field SHOULD be set based on the supported
	a legacy node receiving a BEHAVIOR_CONFIG object on a Config message		capabilities of the sending node. When sending a ConfigAck message,
	that also includes a HelloConfig or LMP_WDM_CONFIG object might		the flags field MUST be set to the value received in the
	react as follows:		corresponding Config message.
	- Reject the message because of the unknown BEHAVIOR_CONFIG object		When receiving a BehaviorConfig type object, the node compares the
	as described above.		flags field against its capacities. Any bit set in the MBZ portion
			of the flags field MUST be interpreted as unacceptable. Processing
			related to unacceptable values in CONFIG objects is defined in
			[RFC4204] and is not modified by this document.
	- Reject the message because of multiple <CONFIG> objects. This		4. Backward Compatibility
	achieves the same effective result.
	- Ignore the second <CONFIG> object. This would result in the		The required use of the BehaviorConfig type CONFIG object enables
	BEHAVIOR_CONFIG object being unprocessed and also not rejected.		nodes which support the extensions defined in this document to
			explicitly identify when a neighboring node does not. When a non-
			supporting node receives a Config message with the BehaviorConfig
			type CONFIG object or multiple CONFIG objects its behavior is likely
			to be one of the following behaviors:
	An LSR that receives a ConfigNack message rejecting a Config message		a) Reject the Config message because of the unknown BehaviorConfig
	that it sent containing the BEHAVIOR CONFIG C-Type because that		object type and send a ConfigNack message which includes the
	object variant is not supported by its peer MUST NOT draw any		unsupported C-type.
	conclusions about the level of support at the peer for LMP options
	described by bits B, S, D, and C. Instead, the LSR MUST revert to
	current practices of configuration or discovery through attempts to
	exercise the options.
	However, as future documents are published describing new LMP		b) Reject the message because of multiple CONFIG objects and send a
	features, and those documents require support of the BEHAVIOR CONFIG		ConfigNack message which includes all but one of the CONFIG
	C-Type, an LSR that receives a ConfigNack message rejecting a Config		objects.
	message that it sent containing the BEHAVIOR CONFIG C-Type because
	that object variant is not supported by its peer SHOULD conclude
	that the additional options it wants to use are not supported by the
	peer.
	4. Security Considerations		c) Silently ignore the one or more of the CONFIG object, and respond
			with a ConfigAck message that does not include any CONFIG objects.
			d) Treat the message as malformed, and discard it without any
			response.
			Behaviors (a) and (b) result in ConfigNack messages with a
			BehaviorConfig type object whose contents are identical to what was
			sent in the Config message. Behavior (c) results in a ConfigAck
			message without a BehaviorConfig type CONFIG object. In each of
			these cases, the node SHOULD explicitly identify that the LMP
			neighbor does not support the extensions defined in this document.
			Behavior (d) results in no response at all. When the node reaches
			the, [RFC4204] defined, "retry limit", the node SHOULD infer that
			the LMP neighbor does not support the extensions defined in this
			document.
			Once a node identifies a neighbor as not supporting the extensions
			defined in this document, the node SHOULD follow previously defined
			Config message usage.
			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 operation of the procedures described in this document does not		The procedures described in this document do not of itself
	of itself constitute a security risk since they do not cause any		constitute a security risk since they do not cause any change in
	change in network state. It would be possible, if the messages were		network state. It would be possible, if the messages were
	intercepted or spoofed to cause bogus alerts in the management plane,		intercepted or spoofed to cause bogus alerts in the management plane,
	or to cause LMP peers to consider that they could or could not		or to cause LMP peers to consider that they could or could not
	operate protocol extensions, and so the use of the LMP security		operate protocol extensions, and so the use of the LMP security
	measures are RECOMMENDED.		measures are RECOMMENDED.
	Note, however, that [RFC4204] refers to [RFC2401], which has been		Note, however, that [RFC4204] refers to [RFC2401], which has been
	replaced by [RFC4301]. Also, the reference to IKEv2 in [RFC4301] is		replaced by [RFC4301]. Also, the reference to IKEv2 in [RFC4301] is
	out of date, and the current reference for IKEv2 is [RFC5996].		out of date, and the current reference for IKEv2 is [RFC5996].
	5. IANA Considerations		6. IANA Considerations
	5.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)" registry which
	has a subregistry called "LMP Object Class name space and Class type		has a subregistry called "LMP Object Class name space and Class type
	(C-Type)".		(C-Type)".
	IANA is requested to make an assignment from this registry as		IANA is requested to make 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 BEHAVIOR_CONFIG [This.I-D]		3(suggested) BehaviorConfig [This.I-D]
	5.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 Behaviour
	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 Behaviour 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		limited by the length field of the CONFIG object which gives rise to
	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 | B | Basic LMP behavior support | [This.ID]		0 | S | SONET/SDH Test support | [This.ID]
	1 | S | SONET/SDH Test support | [This.ID]		1 | D | DWDM support | [This.ID]
	2 | D | DWDM support | [This.ID]		2 | C | Data Channel consistency check support | [This.ID]
	3 | C | Data Channel consistency check support | [This.ID]
	6. Contributors		7. Contributors
	Diego Caviglia		Diego Caviglia
	Ericsson		Ericsson
	Via A. Negrone 1/A 16153		Via A. Negrone 1/A 16153
	Genoa Italy		Genoa Italy
	Phone: +39 010 600 3736		Phone: +39 010 600 3736
	Email: diego.caviglia@ericsson.com		Email: diego.caviglia@ericsson.com
	7. Acknowledgments		8. Acknowledgments
	Thanks to Adrian Farrel, Lou Berger and Richard Graveman for their		Thanks to Adrian Farrel and Richard Graveman for their useful
	useful comments.		comments.
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[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, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the		[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005		Internet Protocol", RFC 4301, December 2005
	skipping to change at page 9, line 5		skipping to change at page 11, line 5
	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.
	8.2. Informative References		9.2. Informative References
	[LMP TEST] D. Ceccarelli, Ed., "Link Management Protocol (LMP) Test		[LMP TEST] D. Ceccarelli, Ed., "Link Management Protocol (LMP) Test
	Messages Extensions for Evolutive Optical Transport		Messages Extensions for Evolutive Optical Transport
	Networks (OTN)" draft-ceccarelli-ccamp-gmpls-g709-lmp-		Networks (OTN)" draft-ceccarelli-ccamp-gmpls-g709-lmp-
	test-02.txt, May, 2010.		test-02.txt, May, 2010.
	9. 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: 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
			LabN Consulting, L.L.C.
			Email: lberger@labn.net
End of changes. 50 change blocks.
	138 lines changed or deleted		228 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/