draft-ietf-ccamp-gmpls-alarm-spec-02.txt		draft-ietf-ccamp-gmpls-alarm-spec-03.txt
	Internet Draft Lou Berger - Editor (Movaz Networks)		Internet Draft Lou Berger - Editor (Movaz Networks)
	Updates: 3473		Updates: 3473
	Category: Standards Track		Category: Standards Track
	Expiration Date: May 2005		Expiration Date: March 2006
	November 2004		September 2005
	GMPLS - Communication of Alarm Information		GMPLS - Communication of Alarm Information
	draft-ietf-ccamp-gmpls-alarm-spec-02.txt		draft-ietf-ccamp-gmpls-alarm-spec-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	or will be disclosed, and any of which I become aware will be		have been or will be disclosed, and any of which he or she becomes
	disclosed, in accordance with RFC 3668.		aware will be disclosed, in accordance with Section 6 of 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 months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than a "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/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	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
	Abstract		Abstract
	This document describes an extension to Generalized MPLS (Multi-		This document describes an extension to Generalized MPLS (Multi-
	Protocol Label Switching) signaling to support communication of alarm		Protocol Label Switching) signaling to support communication of alarm
	information. GMPLS signaling already supports the control of alarm		information. GMPLS signaling already supports the control of alarm
	reporting, but not the communication of alarm information. This		reporting, but not the communication of alarm information. This
	document presents both a functional description and GMPLS-RSVP		document presents both a functional description and GMPLS-RSVP
	specifics of such an extension. This document also proposes		specifics of such an extension. This document also proposes
	modification of the RSVP ERROR_SPEC object.		modification of the RSVP ERROR_SPEC object.
			This document updates RFC 3473 "Generalized Multi-Protocol Label
			Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
			Engineering (RSVP-TE) Extensions" through the addition of new,
			optional protocol elements. It does not change, and is fully backward
			compatible with the procedures specified in RFC 3473.
	Contents		Contents
	1 Introduction .............................................. 3		1 Introduction .............................................. 3
	1.1 Background ................................................ 3		1.1 Background ................................................ 3
	2 Alarm Information Communication ........................... 4		2 Alarm Information Communication ........................... 4
	3 GMPLS-RSVP Details ........................................ 5		3 GMPLS-RSVP Details ........................................ 5
	3.1 ALARM_SPEC Objects ........................................ 5		3.1 ALARM_SPEC Objects ........................................ 5
	3.1.1 IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs .................... 6		3.1.1 IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs .................... 6
	3.1.2 Procedures ................................................ 9		3.1.2 Procedures ................................................ 9
	3.1.3 Error Codes and Values .................................... 10		3.1.3 Error Codes and Values .................................... 10
	3.1.4 Backwards Compatibility ................................... 10		3.1.4 Backwards Compatibility ................................... 10
	3.2 Controlling Alarm Communication ........................... 11		3.2 Controlling Alarm Communication ........................... 11
	3.2.1 Updated Admin Status Object ............................... 11		3.2.1 Updated Admin Status Object ............................... 11
	3.2.2 Procedures ................................................ 11		3.2.2 Procedures ................................................ 11
	3.3 Message Formats ........................................... 12		3.3 Message Formats ........................................... 12
	3.4 Relationship to GMPLS UNI ................................. 13		3.4 Relationship to GMPLS UNI ................................. 13
	3.5 Relationship to GMPLS E-NNI .............................. 14		3.5 Relationship to GMPLS E-NNI .............................. 14
	4 Security Considerations ................................... 14		4 Security Considerations ................................... 14
	5 IANA Considerations ....................................... 15		5 IANA Considerations ....................................... 15
	6 References ................................................ 15		6 References ................................................ 16
	6.1 Normative References ...................................... 15		6.1 Normative References ...................................... 16
	6.2 Informative References .................................... 16		6.2 Informative References .................................... 16
	7 Contributors .............................................. 17		7 Contributors .............................................. 17
	8 Contact Address ........................................... 17		8 Contact Address ........................................... 17
	9 Full Copyright Statement .................................. 18		9 Full Copyright Statement .................................. 17
	10 Intellectual Property ..................................... 18		10 Intellectual Property ..................................... 18
	1. Introduction		1. Introduction
	GMPLS Signaling provides mechanisms that can be used to control the		GMPLS Signaling provides mechanisms that can be used to control the
	reporting of alarms associated with an LSP. This support is provided		reporting of alarms associated with an LSP. This support is provided
	via Administrative Status Information [RFC3471] and the Admin_Status		via Administrative Status Information [RFC3471] and the Admin_Status
	object [RFC3473]. These mechanisms only control if alarm reporting		object [RFC3473]. These mechanisms only control if alarm reporting
	is inhibited. No provision is made for communication of alarm		is inhibited. No provision is made for communication of alarm
	information within GMPLS.		information within GMPLS.
	skipping to change at page 4, line 16		skipping to change at page 4, line 16
	down. Further, there may be a desire, particularly in optical		down. Further, there may be a desire, particularly in optical
	transport networks, to retain an LSP and communicate relevant alarm		transport networks, to retain an LSP and communicate relevant alarm
	information even when the data plane state has failed completely.		information even when the data plane state has failed completely.
	Although error information can be reported using PathErr, ResvErr and		Although error information can be reported using PathErr, ResvErr and
	Notify messages, these messages typically indicate a problem in		Notify messages, these messages typically indicate a problem in
	signaling state and can only report one problem at at a time. This		signaling state and can only report one problem at at a time. This
	makes it hard to correlate all of the problems that may be associated		makes it hard to correlate all of the problems that may be associated
	with a single LSP and to allow an operator examining the status of an		with a single LSP and to allow an operator examining the status of an
	LSP to view a full list of current problems. This situation is		LSP to view a full list of current problems. This situation is
	exa		exacerbated by the absence of any way to communicate that a problem
	cerbated by the absence of any way to communicate that a problem
	has been resolved and a corresponding alarm cleared.		has been resolved and a corresponding alarm cleared.
	The extensions defined in this document allow an operator or a		The extensions defined in this document allow an operator or a
	software component to obtain a full list of current alarms associated		software component to obtain a full list of current alarms associated
	with all of the resources used to support an LSP. The extensions		with all of the resources used to support an LSP. The extensions
	also ensure that this list is kept up-to-date and synchronized with		also ensure that this list is kept up-to-date and synchronized with
	the real alarm status in the network. Finally, the extensions make		the real alarm status in the network. Finally, the extensions make
	the list available at every node traversed by an LSP.		the list available at every node traversed by an LSP.
	2. Alarm Information Communication		2. Alarm Information Communication
	skipping to change at page 7, line 48		skipping to change at page 8, line 4
	The Global Timestamp TLV has the following format:		The Global Timestamp TLV has the following format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Global Timestamp |		| Global Timestamp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Berger, et. al.
	Global Timestamp: 32 bits		Global Timestamp: 32 bits
	The number of seconds since 0000 UT on 1 January 1970,		The number of seconds since 0000 UT on 1 January 1970,
	according to the clock on the node that originates this TLV.		according to the clock on the node that originates this TLV.
	Only one Global Timestamp TLV may be included in an object.		Only one Global Timestamp TLV may be included in an object.
	The Local Timestamp TLV has the following format:		The Local Timestamp TLV has the following format:
	0 1 2 3		0 1 2 3
	skipping to change at page 8, line 26		skipping to change at page 8, line 25
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Timestamp |		| Local Timestamp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Local Timestamp: 32 bits		Local Timestamp: 32 bits
	Number of seconds reported by the local system clock at the		Number of seconds reported by the local system clock at the
	time the associated alarm was detected on the node that		time the associated alarm was detected on the node that
	originates this TLV.		originates this TLV. This number is expected to be meaningful
			in the context of the originating node. For example, it may
			indicate the number of seconds since the node rebooted or may
			be a local representation of an unsynchronized real-time clock.
	Only one Local Timestamp TLV may be included in an object.		Only one Local Timestamp TLV may be included in an object.
	The Error String TLV has the following format:		The Error String TLV has the following format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// Error String (NULL padded display string) //		// Error String (NULL padded display string) //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Error String: 32 bits minimum (variable)		Error String: 32 bits minimum (variable)
	A string of characters, representing the type of error/alarm.		A string of characters in US-ASCII, representing the type of
	This string is padded to the next largest 4 byte boundary using		error/alarm. This string is padded to the next largest 4 byte
	null characters. Null padding is not required when the string		boundary using null characters. Null padding is not required
	is 32-bit aligned. The contents of error string are		when the string is 32-bit aligned. The contents of error
	implementation dependent. See the condition types listed in		string are implementation dependent. See the condition types
	Appendices of [GR833] for a list of example strings. Note		listed in Appendices of [GR833] for a list of example strings.
	length includes padding.		Note length includes padding.
	Multiple Error String TLVs may be included in an object.		Multiple Error String TLVs may be included in an object.
	3.1.2. Procedures		3.1.2. Procedures
	This section applies to nodes that support the communication of alarm		This section applies to nodes that support the communication of alarm
	information. ALARM_SPEC objects are carried in Path and Resv		information. ALARM_SPEC objects are carried in Path and Resv
	messages. Multiple ALARM_SPEC objects MAY be present.		messages. Multiple ALARM_SPEC objects MAY be present.
	Nodes that support the communication of alarm information, SHOULD		Nodes that support the communication of alarm information, SHOULD
	skipping to change at page 9, line 36		skipping to change at page 9, line 36
	ALARM_SPEC objects received in Resv messages SHOULD be passed		ALARM_SPEC objects received in Resv messages SHOULD be passed
	unmodified upstream in the corresponding Resv messages. ALARM_SPEC		unmodified upstream in the corresponding Resv messages. ALARM_SPEC
	objects are merged in transmitted Resv messages by including a copy		objects are merged in transmitted Resv messages by including a copy
	of all ALARM_SPEC objects received in corresponding Resv Messages.		of all ALARM_SPEC objects received in corresponding Resv Messages.
	To advertise local alarm information, a node generates an ALARM_SPEC		To advertise local alarm information, a node generates an ALARM_SPEC
	object for each alarm and adds it to both the Path and Resv messages		object for each alarm and adds it to both the Path and Resv messages
	for the effected LSP. In all cases, appropriate Error Node Address,		for the effected LSP. In all cases, appropriate Error Node Address,
	Error Code and Error Values MUST be set, see below for a discussion		Error Code and Error Values MUST be set, see below for a discussion
	on Error Code and Error Values. The InPlace and NotGuilty flags		on Error Code and Error Values. The InPlace and NotGuilty flags
	SHOULD NOT be set. TLVs SHOULD be included to identify the		SHOULD NOT be set. TLVs SHOULD be included in the ALARM_SPEC object
	interface, if any, the severity, the time and a (brief) string		to identify the interface, if any, associated with the alarm - the
			TLVs defined in [RFC3471] for identifying interfaces in the IF_ID
			ERROR_SPEC object [RCF3473] SHOULD be used for this purpose, but note
			that TLVs type 4 and 5 (component interfaces) are deprecated by
			[BUNDLE] and SHOULD NOT be used. TLVs SHOULD also be included to
			indicate the severity (Severity TLV), the time (Global Timestamp
			and/or Local Timestamp TLVs), and a (brief) string (Error String TLV)
	associated with the alarm. The reference count TLV MAY also be		associated with the alarm. The reference count TLV MAY also be
	included. ALARM_SPEC objects received from other nodes are not		included. ALARM_SPEC objects received from other nodes are not
	effected by the addition of local ALARM_SPEC objects, i.e., they		effected by the addition of local ALARM_SPEC objects, i.e., they
	continue to be processed as described above. The choice of which		continue to be processed as described above. The choice of which
	alarm or alarms to advertise and which to omit is a local policy		alarm or alarms to advertise and which to omit is a local policy
	matter, and may configurable by the user.		matter, and may configurable by the user.
	There are two ways to indicate time. A global timestamp TLV is used		There are two ways to indicate time. A global timestamp TLV is used
	to provide an absolute time reference for the occurrence of an alarm.		to provide an absolute time reference for the occurrence of an alarm.
	The local timestamp TLV is used to provide time reference for the		The local timestamp TLV is used to provide time reference for the
	skipping to change at page 11, line 30		skipping to change at page 11, line 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num(196)| C-Type (1) |		| Length | Class-Num(196)| C-Type (1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Reserved |I| |T|A|D|		|R| Reserved |I| |T|A|D|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Inhibit Alarm Communication (I): 1 bit		Inhibit Alarm Communication (I): 1 bit
	When set, indicates that alarm communication is disabled for		When set, indicates that alarm communication is disabled for
	the LSP and that nodes SHOULD NOT add local alarm information.		the LSP and that nodes SHOULD NOT add local alarm information.
	See [RFC3471] for the definition of the remaining bits.		See section 7.1 of [RFC3473] for the definition of the remaining
			bits.
	3.2.2. Procedures		3.2.2. Procedures
	The I bit may be set and cleared using the procedures defined in		The I bit may be set and cleared using the procedures defined in
	Sections 7.2 and 7.3 of [RFC3473]. A node that receives (or		Sections 7.2 and 7.3 of [RFC3473]. A node that receives (or
	generates) an Admin_Status object with the A or I bits set (1),		generates) an Admin_Status object with the A or I bits set (1),
	SHOULD remove all locally generated alarm information from the		SHOULD remove all locally generated alarm information from the
	matching LSP's outgoing Path and Resv messages. When a node receives		matching LSP's outgoing Path and Resv messages. When a node receives
	(or generates) an Admin_Status object with the A and I bits clear		(or generates) an Admin_Status object with the A and I bits clear (0)
	(0), it SHOULD add any local alarm information to the matching LSP's		and there is local alarm information present, it SHOULD add the local
	outgoing Path and Resv messages.		alarm information to the matching LSP's outgoing Path and Resv
			messages.
	The processing of non-locally generated ALARM_SPEC objects MUST NOT		The processing of non-locally generated ALARM_SPEC objects MUST NOT
	be impacted by the contents of the Admin_Status object, that is,		be impacted by the contents of the Admin_Status object, that is,
	received ALARM_SPEC objects MUST be forwarded unchanged regardless of		received ALARM_SPEC objects MUST be forwarded unchanged regardless of
	the received or transmitted settings of the I and A-bits. Note, per		the received or transmitted settings of the I and A-bits. Note, per
	[RFC3473], the absence of the Admin_Status object is equivalent to		[RFC3473], the absence of the Admin_Status object is equivalent to
	receiving an object containing values all set to zero (0).		receiving an object containing values all set to zero (0).
	I bit related processing behavior MAY be overridden locally based on		I bit related processing behavior MAY be overridden locally based on
	configuration.		configuration.
	skipping to change at page 15, line 5		skipping to change at page 14, line 46
	4. Security Considerations		4. Security Considerations
	Some operators may consider alarm information as sensitive. To		Some operators may consider alarm information as sensitive. To
	support environments where this is the case, implementations SHOULD		support environments where this is the case, implementations SHOULD
	allow the user to disable the generation of ALARM_SPEC objects, or to		allow the user to disable the generation of ALARM_SPEC objects, or to
	filter or correlate them at domain boundaries.		filter or correlate them at domain boundaries.
	This document introduces no additional security considerations. See		This document introduces no additional security considerations. See
	[RFC3473] for relevant security considerations.		[RFC3473] for relevant security considerations.
			It may be noted that if the security considerations of [RFC3473] are
			breached, alarm information may be spoofed. Such spoofing would be at
			most annoying and cause slight degradation of control plane
			performance since the details are provided for information only and
			do not result in protocol actions beyond the exchange of messages to
			convey the information. If the protocol security is able to be
			breached sufficiently to allow spoofing of alarm information then
			considerably more interesting and exciting damage can be caused by
			spoofing other elements of the protocol messages.
	5. IANA Considerations		5. IANA Considerations
	IANA is requested to administer assignment of new values for		IANA is requested to administer assignment of new values for
	namespaces defined in this document. This section uses the		namespaces defined in this document and reviewed in this section.
	terminology of BCP 26 "Guidelines for Writing an IANA Considerations		This section uses the terminology of BCP 26 "Guidelines for Writing
	Section in RFCs" [BCP26].		an IANA Considerations Section in RFCs" [BCP26].
	This document defines a new RSVP "ALARM_SPEC object" with a Class-Num		This document defines a new RSVP "ALARM_SPEC object" with a Class-Num
	of the form 11bbbbbb, see section 3.1. The value 197 is suggested.		of the form 11bbbbbb, see section 3.1. The value 197 is suggested.
	The C-type values associated with this object should read "Same		The C-type values associated with this object should read "Same
	values as ERROR_SPEC (C-Num 6), with the exception of C-Types 1 and 2		values as ERROR_SPEC (C-Num 6), with the exception of C-Types 1 and 2
	which are reserved". The text associated with ALARM_SPEC object		which are reserved". The text associated with ALARM_SPEC object
	should also read "The ALARM_SPEC objec		should also read "The ALARM_SPEC object uses the Error Code and
	t uses the Error Code and
	Values from the ERROR_SPEC object."		Values from the ERROR_SPEC object."
	Additionally, Section 3.1.3 defines a new Error Code. The Error Code		Additionally, Section 3.1.3 defines a new RSVP Error Code. The Error
	is "Alarms" and uses Error Values defined in the Alarm MIB [RFC3877].		Code is "Alarms" and uses Error Values defined in the Alarm MIB
	The suggested Error code value is 28.		[RFC3877]. The suggested Error Code value is 28.
	This document also defines the TLVs for use with the IF_ID ERROR_SPEC		This document also defines the TLVs for use with the RSVP IF_ID
	objects defined in [RFC3473]. Please see Section 3.1.1 for a list of		ERROR_SPEC objects defined in [RFC3473]. Please see Section 3.1.1
	TLV description and (suggested) type values.		for a list of TLV descriptions and (suggested) type values.
	Note that the type values are not sequential with existing ERROR_SPEC		Note that the type values are not sequential with existing RSVP IF_ID
	object TLV assignments. This is intentional and is intended to		ERROR_SPEC object TLV assignments. This is intentional and is
	provide space for future error TLVs.		intended to provide space for future error TLVs.
	This document also defines the I bit in the Admin Status Object, see		This document also defines the I bit in the Admin Status Object, see
	Section 3.2.1. This bit field was originally defined in Section 7.1		Section 3.2.1. This bit field was originally defined in Section 7.1
	of [RFC3473]. We recommend that IANA begin managing assignment of		of [RFC3473]. We request IANA to begin managing assignment of bits
	bits in the Admin Status Object, and that the bits be allocated		in the Admin Status Object, and that the bits be allocated through
	through IETF Consensus actions.		IETF Consensus actions. Within the 32 bit field in the Admin Status
			Object, the defined bits are:
			Value Name Reference
			---------- --------------------------------- -----------------
			0x80000000 Reflect (R) [RFC3473/RFC3471]
			0x00000010 Inhibit Alarm Communication (I) [This document]
			0x00000004 Testing (T) [RFC3473/RFC3471]
			0x00000002 Administratively down (A) [RFC3473/RFC3471]
			0x00000001 Deletion in progress (D) [RFC3473/RFC3471]
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol		[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol
	Label Switching (GMPLS) Signaling Functional		Label Switching (GMPLS) Signaling Functional
	Description", RFC 3471, January 2003.		Description", RFC 3471, January 2003.
	[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label		[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
	skipping to change at page 17, line 13		skipping to change at page 17, line 13
	work in progress.		work in progress.
	7. Contributors		7. Contributors
	Contributors are listed in alphabetical order:		Contributors are listed in alphabetical order:
	Lou Berger Deborah Brungard		Lou Berger Deborah Brungard
	Movaz Networks, Inc. AT&T Labs, Room MT D1-3C22		Movaz Networks, Inc. AT&T Labs, Room MT D1-3C22
	7926 Jones Branch Drive 200 Laurel Avenue		7926 Jones Branch Drive 200 Laurel Avenue
	Suite 615		Suite 615
	McLean VA, 22102 Middletown, NJ 07748, USA		McLean VA, 22102, USA Middletown, NJ 07748, USA
	Phone: +1 703 847-1801 Phone: (732) 420-1573		Phone: +1 703 847-1801 Phone: (732) 420-1573
	Email: lberger@movaz.com Email: dbrungard@att.com		Email: lberger@movaz.com Email: dbrungard@att.com
	Igor Bryskin Adrian Farrel		Igor Bryskin Adrian Farrel
	Movaz Networks, Inc. Old Dog Consulting		Movaz Networks, Inc. Old Dog Consulting
	7926 Jones Branch Drive		7926 Jones Branch Drive
	Suite 615		Suite 615
	McLean VA, 22102 Phone: +44 (0) 1978 860944		McLean VA, 22102, USA Phone: +44 (0) 1978 860944
	Email: ibryskin@movaz.com Email: adrian@olddog.co.uk		Email: ibryskin@movaz.com Email: adrian@olddog.co.uk
	Dimitri Papadimitriou (Alcatel) Arun Satyanarayana		Dimitri Papadimitriou (Alcatel) Arun Satyanarayana
	Francis Wellesplein 1 Movaz Networks, Inc.		Francis Wellesplein 1 Cisco Systems, Inc
	B-2018 Antwerpen, Belgium 7926 Jones Branch Drive		B-2018 Antwerpen, Belgium 170 West Tasman Dr.
	Suite 615		San Jose, CA 95134 USA
	McLean VA, 22102		Phone: +32 3 240-8491 Phone: +1 408 853-3206
	Phone: +32 3 240-8491 Phone: +1 703 847-1785		Email: dimitri.papadimitriou@alcatel.be Email: asatyana@cisco.com
	Email: dimitri.papadimitriou@alcatel.be Email: aruns@movaz.com
	8. Contact Address		8. Contact Address
	Lou Berger		Lou Berger
	Movaz Networks, Inc.		Movaz Networks, Inc.
	7926 Jones Branch Drive		7926 Jones Branch Drive
	Suite 615		Suite 615
	McLean VA, 22102		McLean VA, 22102
	Phone: +1 703 847-1801		Phone: +1 703 847-1801
	Email: lberger@movaz.com		Email: lberger@movaz.com
	9. Full Copyright Statement		9. Full Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	skipping to change at line 738		skipping to change at line 768
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
			Generated on: Fri Sep 9 11:00:37 EDT 2005
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/