draft-ietf-ccamp-lmp-behavior-negotiation-02.txt		draft-ietf-ccamp-lmp-behavior-negotiation-03.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: September 2011 March 14, 2011		Expires: October 2011 April 7, 2011
	Behavior Negotiation in The Link Management Protocol		Behavior Negotiation in The Link Management Protocol
	draft-ietf-ccamp-lmp-behavior-negotiation-02.txt		draft-ietf-ccamp-lmp-behavior-negotiation-03.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 September 13, 2011.		This Internet-Draft will expire on October 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
	skipping to change at page 2, line 30		skipping to change at page 2, line 30
	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. Backward Compatibility....................................... 5		3. Backward Compatibility....................................... 5
	4. Security Considerations...................................... 6		4. Security Considerations...................................... 6
	5. IANA Considerations ......................................... 6		5. IANA Considerations ......................................... 7
	5.1. New LMP Class Type...................................... 6		5.1. New LMP Class Type...................................... 7
	5.2. New Capabilities Registry............................... 7		5.2. New Capabilities Registry............................... 7
	6. Contributors ................................................ 7		6. Contributors ................................................ 8
	7. Acknowledgments ............................................. 8		7. Acknowledgments ............................................. 8
	8. References .................................................. 8		8. References .................................................. 8
	8.1. Normative References.................................... 8		8.1. Normative References.................................... 8
	8.2. Informative References.................................. 8		8.2. Informative References.................................. 9
	9. Authors' Addresses .......................................... 9		9. Authors' Addresses .......................................... 9
	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
	skipping to change at page 4, line 26		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| Reserved |		| Length |B|S|D|C| MUST_BE_ZERO |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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 12		skipping to change at page 5, line 12
	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.		Further bits may be defined in future documents.
	The Reserved field MUST be sent as zero and MUST NOT be ignored on		The MUST_BE_ZERO field MUST be sent as zero and MUST NOT be ignored
	receipt. This allows the detection of unsupported or unknown LMP		on 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.
	skipping to change at page 6, line 41		skipping to change at page 6, line 41
	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.
			Note, however, that [RFC4204] refers to [RFC2401], which has been
			replaced by [RFC4301]. Also, the reference to IKEv2 in [RFC4301] is
			out of date, and the current reference for IKEv2 is [RFC5996].
	5. IANA Considerations		5. IANA Considerations
	5.1. New LMP Class Type		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:
	skipping to change at page 8, line 7		skipping to change at page 8, line 16
	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		7. Acknowledgments
	Thanks to Adrian Farrel and Lou Berger for their useful comments.		Thanks to Adrian Farrel, Lou Berger and Richard Graveman for their
			useful comments.
	8. References		8. References
	8.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.
			[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
			Internet Protocol", RFC 2401, November 1998.
			[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
			Internet Protocol", RFC 4301, December 2005
			[RFC5996] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, "Internet Key
			Exchange Protocol: IKEv2", RFC 5996, September 2010.
	[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
End of changes. 11 change blocks.
	11 lines changed or deleted		25 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/