draft-ietf-ccamp-lmp-behavior-negotiation-06.txt		draft-ietf-ccamp-lmp-behavior-negotiation-07.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: January 2013 July 30, 2012		Expires: June 2013 December 5, 2012
	Link Management Protocol Behavior Negotiation and		Link Management Protocol Behavior Negotiation and
	Configuration Modifications		Configuration Modifications
	draft-ietf-ccamp-lmp-behavior-negotiation-06.txt		draft-ietf-ccamp-lmp-behavior-negotiation-07.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) networks. This document
	defines an extension to LMP to negotiate capabilities and indicate		defines an extension to LMP to negotiate capabilities and indicate
	support for LMP extensions. The defined extension is compatible		support for LMP extensions. The defined extension is compatible
	with non-supporting implementations.		with non-supporting implementations.
			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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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 5, 2013.
	This Internet-Draft will expire on January 29, 2013.
	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 4, line 29		skipping to change at page 4, line 29
	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 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 on 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.
	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
	skipping to change at page 5, line 27		skipping to change at page 5, line 27
	ConfigNack message. A maximum of a single object of any particular		ConfigNack message. A maximum of a single object of any particular
	C-type SHALL be included. A node which receives a message with		C-type SHALL be included. A node which receives a message with
	multiple CONFIG objects of the same C-type SHALL process the first		multiple CONFIG objects of the same C-type SHALL process the first
	object of a particular C-type and ignore any subsequent CONFIG		object of a particular C-type and ignore any subsequent CONFIG
	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. (But not when the neighbor is known to not support the		unknown. (When the neighbor is known to not support the extensions,
	extensions.) Inclusion of other CONFIG objects in a Config message		the object MUST NOT be sent.) Inclusion of other CONFIG objects in a
	is at the discretion of the message sender, and is based on the		Config message is at the discretion of the message sender, and is
	rules defined by as part of CONFIG object definition. Nodes MAY		based on the rules defined as part of CONFIG object definition.
	include, HelloConfig, LMP_WDM_CONFIG, BehaviorConfig object types in		Nodes MAY include, HelloConfig, LMP_WDM_CONFIG, BehaviorConfig
	a single message.		object 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".
End of changes. 6 change blocks.
	11 lines changed or deleted		12 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/