draft-ietf-ccamp-lmp-behavior-negotiation-01.txt		draft-ietf-ccamp-lmp-behavior-negotiation-02.txt
	Network Working Group Dan Li		Network Working Group Dan Li
	Internet Draft Huawei		Internet Draft Huawei
	Updates: RFC4204 D. Ceccarelli		Updates: RFC4204 D. Ceccarelli
	Category: Standards Track Ericsson		Category: Standards Track Ericsson
	Expires: April 2011 October 11, 2010		Expires: September 2011 March 14, 2011
	Behavior Negotiation in The Link Management Protocol		Behavior Negotiation in The Link Management Protocol
	draft-ietf-ccamp-lmp-behavior-negotiation-01.txt		draft-ietf-ccamp-lmp-behavior-negotiation-02.txt
	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 34
	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 April 11, 2011.		This Internet-Draft will expire on September 13, 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
	skipping to change at page 2, line 13		skipping to change at page 2, line 13
	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		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. Various proposals		Multiprotocol Label Switching (GMPLS) networks. Various proposals
	have been advanced to provide extensions to the base LMP		have been advanced to provide extensions to the base LMP
	specification. This document defines an extension to negotiated		specification. This document defines an extension to negotiate
	capabilities and provides a generic procedure for LMP		capabilities and support for those extensions, and provides a
	implementations that do not recognize or do not support any one of		generic procedure for LMP implementations that do not recognize or
	these extensions.		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 ................................................ 2
	2. LMP Behavior Negotiation Procedure ........................... 3		2. LMP Behavior Negotiation Procedure........................... 3
	3. Backwards Compatibility ...................................... 5		3. Backward Compatibility....................................... 5
	4. Security Considerations ...................................... 5		4. Security Considerations...................................... 6
	5. IANA Considerations .......................................... 6		5. IANA Considerations ......................................... 6
	5.1. New LMP Class Type ...................................... 6		5.1. New LMP Class Type...................................... 6
	5.2. New Capabilities Registry ............................... 6		5.2. New Capabilities Registry............................... 7
	6. Contributors ................................................. 7		6. Contributors ................................................ 7
	7. Acknowledgments .............................................. 7		7. Acknowledgments ............................................. 8
	8. References ................................................... 7		8. References .................................................. 8
	8.1. Normative References .................................... 7		8.1. Normative References.................................... 8
	8.2. Informative References .................................. 8		8.2. Informative References.................................. 8
	9. Authors' Addresses ........................................... 8		9. Authors' Addresses .......................................... 9
	1. Introduction		1. Introduction
	The Link Management Protocol (LMP) [RFC4204] is being 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. New LMP behaviors and protocol extensions are		controlled networks.
	being introduced in a number of IETF documents.
			New LMP behaviors and protocol extensions have been introduced in a
			number of IETF documents as set out later in this section. It is
			likely that future extensions will be made to support additional
			functions.
	In the network, if one GMPLS Label Switch Router (LSR) supports a		In the network, if one GMPLS Label Switch Router (LSR) supports a
	new behavior or protocol extension, but its peer LSR does not, it is		new behavior or protocol extension, but its peer LSR does not, it is
	necessary to have a protocol mechanism for resolving issues that may		necessary to have a protocol mechanism for resolving issues that may
	arise. It is also beneficial to have a protocol mechanism to		arise. It is also beneficial to have a protocol mechanism to
	discover the capabilities of peer LSRs. There is no such procedure		discover the capabilities of peer LSRs so that the right protocol
	defined in the base LMP specification [RFC4204], so this document		extensions can be selected and the correct features enabled. There
	defines how to handle LMP extensions both at legacy LSRs and at		are no such procedures defined in the base LMP specification
	upgraded LSRs that would communicate with legacy LSRs.		[RFC4204], so this document defines how to handle LMP extensions
			both at legacy LSRs and at upgraded LSRs that would communicate with
			legacy LSRs.
	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.
	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 the behavior negotiation procedure to make
	sure both LSRs at the ends of each link understand the LMP messages		sure both LSRs at the ends of each link understand the LMP messages
	that they exchange.		that they exchange.
	2. LMP Behavior Negotiation Procedure		2. LMP Behavior Negotiation Procedure
	The Config message is used in the control channel negotiation phase		The Config message is used in the control channel negotiation phase
	of LMP [RC4204]. 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 of [RFC4204].		13.6 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]
	skipping to change at page 4, line 22		skipping to change at page 4, line 26
	report and negotiate currently defined LMP mechanisms and behaviors,		report and negotiate currently defined LMP mechanisms and behaviors,
	and to allow future LMP extensions to be reported and negotiated.		and to allow future LMP extensions to be reported and negotiated.
	- C-Type = 3, BEHAVIOR_CONFIG		- C-Type = 3, BEHAVIOR_CONFIG
	The format of the new type of CONFIG Class is defined as follows:		The format of the new type of CONFIG Class is defined as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length |B|S|D|C|O| Reserved |		| Length |B|S|D|C| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Length: 8 bits		Length: 8 bits
	This field indicates the total length of the objects expressed in		This field indicates the total length of the objects expressed in
	multiples of 4 bytes.		multiples of 4 bytes.
	Flags:		Flags:
	B: 1 bit		B: 1 bit
	skipping to change at page 5, line 5		skipping to change at page 5, line 10
	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].
	O: 1 bit
	This bit indicates support for the TEST behavior of OTN
	technology-specific defined in [LMP TEST].
	Further bits may be defined in future documents.		Further bits may be defined in future documents.
	The Reserved field MUST be sent as zero and MUST NOT be ignored on		The Reserved field MUST be sent as zero and MUST NOT be ignored on
	receipt. This allows the detection of unsupported or unknown LMP		receipt. This allows the detection of unsupported or unknown LMP
	behaviors when new bits are allocated to indicate further		behaviors when new bits are allocated to indicate further
	capabilities and are sent as one.		capabilities and are sent as one.
	Upon receiving a bit set related to an unsupported or unknown		Upon receiving a bit set related to an unsupported or unknown
	behavior, a ConfigNack message MUST be sent with a <CONFIG> object,		behavior, a ConfigNack message MUST be sent with a <CONFIG> object,
	the BEHAVIOR_CONFIG C-Type representing the supported LMP behaviors.		the BEHAVIOR_CONFIG C-Type representing the supported LMP behaviors.
	An LSR receiving such a ConfigNack SHOULD select a supported set of		An LSR receiving such a ConfigNack SHOULD select a supported set of
	capabilities and send a further Config message, or MAY raise an		capabilities and send a further Config message, or MAY raise an
	alert to the management system (or log an error) and stop trying to		alert to the management system (or log an error) and stop trying to
	perform LMP communications with its neighbor.		perform LMP communications with its neighbor.
	3. Backwards Compatibility		Note that multiple <CONFIG> objects (each with a different Class
			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
	An LSR that receives a Config message containing a <CONFIG> object		An LSR that receives a Config message containing a <CONFIG> object
	with a C-Type that it does not recognize MUST respond with a		with a C-Type that it does not recognize should respond with a
	ConfigNack message as described in [RFC4204]. Thus, legacy LMP nodes		ConfigNack message as described in [RFC4204]. Thus, legacy LMP nodes
	that do not support the BEHAVIOR_CONFIG C-Type defined in this		that do not support the BEHAVIOR_CONFIG C-Type defined in this
	document will respond with a ConfigNack message.		document will respond with a ConfigNack message.
	It's not explicitly stated in [RFC4204] that a Config Message could		Note that [RFC4204] does not describe how multiple <CONFIG> objects
	include multiple <CONFIG> objects. But with new CONFIG C-Types are		with different C-Types should be processed. Thus it is possible that
	defined, multiple <CONFIG> objects (each with a different Class Type)		a legacy node receiving a BEHAVIOR_CONFIG object on a Config message
	MAY be present on a Config message in which case all of the objects		that also includes a HelloConfig or LMP_WDM_CONFIG object might
	MUST be processed.		react as follows:
			- Reject the message because of the unknown BEHAVIOR_CONFIG object
			as described above.
			- Reject the message because of multiple <CONFIG> objects. This
			achieves the same effective result.
			- Ignore the second <CONFIG> object. This would result in the
			BEHAVIOR_CONFIG object being unprocessed and also not rejected.
			An LSR that receives a ConfigNack message rejecting a Config message
			that it sent containing the BEHAVIOR CONFIG C-Type because that
			object variant is not supported by its peer MUST NOT draw any
			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
			features, and those documents require support of the BEHAVIOR CONFIG
			C-Type, an LSR that receives a ConfigNack message rejecting a Config
			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		4. 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 operation of the procedures described in this document does not
	of itself constitute a security risk since they do not cause any		of itself constitute a security risk since they do not cause any
	change in network state. It would be possible, if the messages were		change in network state. It would be possible, if the messages were
	skipping to change at page 6, line 26		skipping to change at page 7, line 14
	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 BEHAVIOR_CONFIG [This.I-D]
	5.2. New Capabilities Registry		5.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.
	skipping to change at page 7, line 12		skipping to change at page 7, line 41
	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 | B | Basic LMP behavior support | [This.ID]
	1 | S | SONET/SDH Test support | [This.ID]		1 | S | SONET/SDH Test support | [This.ID]
	2 | D | DWDM support | [This.ID]		2 | D | DWDM support | [This.ID]
	3 | C | Data Channel consistency check support | [This.ID]		3 | C | Data Channel consistency check support | [This.ID]
	4 | O | OTN TEST behavior | [This.ID]
	6. Contributors		6. 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
End of changes. 19 change blocks.
	46 lines changed or deleted		78 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/