draft-ietf-ccamp-lmp-behavior-negotiation-00.txt		draft-ietf-ccamp-lmp-behavior-negotiation-01.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 8, 2010		Expires: April 2011 October 11, 2010
	Behavior Negotiation in Link Management Protocol		Behavior Negotiation in The Link Management Protocol
	draft-ietf-ccamp-lmp-behavior-negotiation-00.txt		draft-ietf-ccamp-lmp-behavior-negotiation-01.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 8, 2011.		This Internet-Draft will expire on April 11, 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 provides a generic procedure for LMP		specification. This document defines an extension to negotiated
			capabilities and provides a generic procedure for LMP
	implementations that do not recognize or do not support any one of		implementations that do not recognize or do not support any one of
	these extensions.		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. Security Considerations...................................... 6		3. Backwards Compatibility ...................................... 5
	4. IANA Considerations ......................................... 6		4. Security Considerations ...................................... 5
	5. Contributors ................................................ 6		5. IANA Considerations .......................................... 6
	6. Acknowledgments ............................................. 7		5.1. New LMP Class Type ...................................... 6
	7. References .................................................. 7		5.2. New Capabilities Registry ............................... 6
	7.1. Normative References.................................... 7		6. Contributors ................................................. 7
	7.2. Informative References.................................. 7		7. Acknowledgments .............................................. 7
	8. Authors' Address ............................................ 8		8. References ................................................... 7
			8.1. Normative References .................................... 7
			8.2. Informative References .................................. 8
			9. Authors' Addresses ........................................... 8
	1. Introduction		1. Introduction
	The Link Management Protocol (LMP) [RFC4204] is being successfully		The Link Management Protocol (LMP) [RFC4204] is being successfully
	deployed in Generalized Multiprotocol Label Switching (GMPLS)		deployed in Generalized Multiprotocol Label Switching (GMPLS)-
	networks in the field. New LMP behaviors and protocol extensions are		controlled networks. New LMP behaviors and protocol extensions are
	being introduced in a number of IETF documents.		being introduced in a number of IETF documents.
	In the network, if one GMPLS Label Switching 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. There is no such procedure
	defined in the base LMP specification [RFC4204], so this document		defined in the base LMP specification [RFC4204], so this document
	defines how to handle LMP extensions both at legacy LSRs and at		defines how to handle LMP extensions both at legacy LSRs and at
	upgraded LSRs that communicate with legacy LSRs.		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 message, which includes Config, Hello, Verify,		of the standard LMP messages, which include Config, Hello, Verify,
	Test, LinkSummary, ChannelStatus. Per [RCF4204], these behaviors		Test, LinkSummary, and ChannelStatus. Per [RCF4204], these behaviors
	MUST be supported when the LMP is implemented, and the message types		MUST be supported when LMP is implemented, and the message types
	from 1 to 20 are used for these behaviors.		from 1 to 20 have been assigned by IANA for these messages.
	In [RFC4207], the SONET/SDH technology-specific information for LMP		In [RFC4207], the SONET/SDH technology-specific behavior and
	is defined. The TRACE behavior is added to LMP, and the message		information for LMP is defined. The TRACE behavior is added to LMP,
	types from 21 to 31 were defined for the TRACE function. The TRACE		and the message types from 21 to 31 were assigned by IANA for the
	function has been extended for the support of OTNs (Optical		messages that provide the TRACE function. The TRACE function has
	Transport Networks) in [LMP TEST].		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,
	the message types from 32 to 34 are used for this behavior.		and the message types from 32 to 34 have been assigned by IANA for
			messages that provide this behavior.
			It is likely that future extensions to LMP for other functions or
			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 of each link understand the LMP messages being		sure both LSRs at the ends of each link understand the LMP messages
	exchanged between peers.		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 [RC4204]. The LMP behavior negotiation procedure is defined
	in this document as an addition at 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]. Multiple <CONFIG> objects (each with a different		13.6 of [RFC4204].
	Class Type) MAY be present on a Config message in which case all of
	the objects MUST be processed.
	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
	report and negotiate new and future LMP extensions and behaviors.
	- C-Type = 3, ENHANCED_BEHAVIOR_CONFIG
	Two different types of flag are defined in this object: Architecture
	Flags and Capability Flags. The first set of flags indicates the
	network architecture supported by the node (e.g. OTN, SDH/SONET,
	DWDM), while the second one all the optional capabilities supported
	by the protocol implementation (e.g. Link Verification, Fault
	Management). The existing RFCs define the following capabilities:
	- Control Channel Management (Mandatory)
	- Link Property Correlation (Mandatory)
	- Link Verification (Optional)		This document defines a third C-Type with value 3 (TBD by IANA) to
			report and negotiate currently defined LMP mechanisms and behaviors,
	- Fault Management (Optional)		and to allow future LMP extensions to be reported and negotiated.
	- Trace Monitoring (Optional)
	- Data Channel Status Confirmation (Optional)
	Due to the fact that Control Channel Management and Link Property		- C-Type = 3, BEHAVIOR_CONFIG
	Correlation are mandatory capabilities, no capability flag is
	defined for their configuration. When an architecture flag is set,
	automatically these two capabilities are implicitly supported. With
	respect to the other ones, a flag for each of them is defined.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |M|O|W|S| Reserved |D|T|F|V|		| Length |B|S|D|C|O| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|<----- Architecture Flags ---->|<----- Capability Flags ----->|
	Architecture Flags:
	S: 1 bit
	This bit indicates support for the SONET/SDH.
	W: 1 bit
	This bit indicates support for WDM.
	O: 1 bit		Length: 8 bits
	This bit indicates support for OTN.		This field indicates the total length of the objects expressed in
			multiples of 4 bytes.
	M: 1 bit		Flags:
	This bit indicates support for MPLS-TP		B: 1 bit
	Capability Flags:		This bit indicates support for the basic behaviors defined in
			[RFC4204].
	V: 1 bit		S: 1 bit
	This bit indicates support for the Link Verification capability		This bit indicates support for the Trace behavior of SONET/SDH
	defined in [RFC4204].		technology-specific defined in [RFC4207].
	F: 1 bit		D: 1 bit
	This bit indicates support for the Fault Management capability		This bit indicates support for the DWDM behavior defined in
	defined in [RFC4204].		[RFC4209].
	T: 1 bit		C: 1 bit
	This bit indicates support for the Trace Monitoring defined in		This bit indicates support for the data channel consistency check
	[RFC4204], [RFC4207] and [LMP TEST].		behavior defined in [RFC5818].
	D: 1 bit		O: 1 bit
	This bit indicates support for the Data Channel Status Confirmation		This bit indicates support for the TEST behavior of OTN
	messages defined in [RFC5818].		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 supported/unsupported LMP		receipt. This allows the detection of unsupported or unknown LMP
	behaviors.		behaviors when new bits are allocated to indicate further
			capabilities and are sent as one.
	Upon receiving a bit set related to a non supported behavior, a		Upon receiving a bit set related to an unsupported or unknown
	ConfigNack message MUST be sent with a <CONFIG> object representing		behavior, a ConfigNack message MUST be sent with a <CONFIG> object,
	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
			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.
			3. Backwards 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 MUST 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 ENHANCED_BEHAVIOR_CONFIG C-Type defined in		that do not support the BEHAVIOR_CONFIG C-Type defined in this
	this document will respond with a ConfigNack message.		document will respond with a ConfigNack message.
	3. Security Considerations		It's not explicitly stated in [RFC4204] that a Config Message could
			include multiple <CONFIG> objects. But with new CONFIG C-Types are
			defined, multiple <CONFIG> objects (each with a different Class Type)
			MAY be present on a Config message in which case all of the objects
			MUST be processed.
			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
	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.
	4. IANA Considerations		5. IANA Considerations
			5.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 ENHANCED_BEHAVIOR_CONFIG [This.I-D]		3 BEHAVIOR_CONFIG [This.I-D]
	5. Contributors		5.2. New Capabilities Registry
			IANA is requested to create a new subregistry of the "Link
			Management Protocol (LMP)" registry to track the Behaviour
			Configuration bits defined in Section 2 of this document. It is
			suggested that this registry be called "LMP Behaviour Configuration
			Flags".
			Allocations from this registry are by Standards Action.
			Bits in this registry are numbered from zero as the most significant
			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 (255 x 32)-8 = 8152. IANA is strongly recommended to allocate new
			bits with the lowest available unused number.
			The registry is initially populated as follows:
			Bit | Bit | Meaning | Reference
			Number | Name | |
			-------+------+----------------------------------------+----------
			0 | B | Basic LMP behavior support | [This.ID]
			1 | S | SONET/SDH Test support | [This.ID]
			2 | D | DWDM support | [This.ID]
			3 | C | Data Channel consistency check support | [This.ID]
			4 | O | OTN TEST behavior | [This.ID]
			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
	6. Acknowledgments		7. Acknowledgments
	Thanks to Adrian Farrel and Lou Berger for their useful comments.		Thanks to Adrian Farrel and Lou Berger for their useful comments.
	7. References		8. References
	7.1. Normative References		8.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.
	[RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204,		[RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204,
	October 2005.		October 2005.
	[RFC4207] J. Lang, Ed., "Synchronous Optical Network (SONET)/		[RFC4207] J. Lang, Ed., "Synchronous Optical Network (SONET)/
	Synchronous Digital Hierarchy (SDH) Encoding for Link		Synchronous Digital Hierarchy (SDH) Encoding for Link
	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.
	7.2. Informative References		8.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.
	8. Authors' Address		9. 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
End of changes. 46 change blocks.
	107 lines changed or deleted		125 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/