draft-ietf-pce-monitoring-08.txt		draft-ietf-pce-monitoring-09.txt
	Networking Working Group JP. Vasseur, Ed.		Networking Working Group JP. Vasseur, Ed.
	Internet-Draft Cisco Systems, Inc		Internet-Draft Cisco Systems, Inc
	Intended status: Standards Track JL. Le Roux		Intended status: Standards Track JL. Le Roux
	Expires: July 24, 2010 France Telecom		Expires: September 22, 2010 France Telecom
	Y. Ikejiri		Y. Ikejiri
	NTT Communications Corporation		NTT Communications Corporation
	January 20, 2010		March 21, 2010
	A set of monitoring tools for Path Computation Element based		A set of monitoring tools for Path Computation Element based
	Architecture		Architecture
	draft-ietf-pce-monitoring-08.txt		draft-ietf-pce-monitoring-09.txt
	Abstract		Abstract
	A Path Computation Element (PCE) based architecture has been		A Path Computation Element (PCE) based architecture has been
	specified for the computation of Traffic Engineering (TE) Label		specified for the computation of Traffic Engineering (TE) Label
	Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and		Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and
	Generalized MPLS (GMPLS) networks in the context of single or		Generalized MPLS (GMPLS) networks in the context of single or
	multiple domains (where a domain refers to a collection of network		multiple domains (where a domain refers to a collection of network
	elements within a common sphere of address management or path		elements within a common sphere of address management or path
	computational responsibility such as IGP areas and Autonomous		computational responsibility such as IGP areas and Autonomous
	skipping to change at page 2, line 12		skipping to change at page 2, line 12
	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 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 July 24, 2010.		This Internet-Draft will expire on September 22, 2010.
	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 3, line 28		skipping to change at page 3, line 28
	4.5. OVERLOAD Object . . . . . . . . . . . . . . . . . . . . . 18		4.5. OVERLOAD Object . . . . . . . . . . . . . . . . . . . . . 18
	5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19		6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19
	7. Manageability Considerations . . . . . . . . . . . . . . . . . 21		7. Manageability Considerations . . . . . . . . . . . . . . . . . 21
	7.1. Control of Function and Policy . . . . . . . . . . . . . . 21		7.1. Control of Function and Policy . . . . . . . . . . . . . . 21
	7.2. Information and Data Models . . . . . . . . . . . . . . . 21		7.2. Information and Data Models . . . . . . . . . . . . . . . 21
	7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21		7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21
	7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 21		7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 21
	7.5. Requirements On Other Protocols . . . . . . . . . . . . . 22		7.5. Requirements On Other Protocols . . . . . . . . . . . . . 22
	7.6. Impact On Network Operations . . . . . . . . . . . . . . . 22		7.6. Impact On Network Operations . . . . . . . . . . . . . . . 22
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		8. Guidelines to Avoid Overload Thrashing . . . . . . . . . . . . 22
	8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 22		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 22		9.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 23
	8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 23		9.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 23
	8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 23		9.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 24
	8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 24		9.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 24
	8.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 24		9.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 25
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 25		9.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 25
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25		10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 25		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	11.2. Informative References . . . . . . . . . . . . . . . . . . 26		12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26		12.2. Informative References . . . . . . . . . . . . . . . . . . 27
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	The Path Computation Element (PCE) based architecture has been		The Path Computation Element (PCE) based architecture has been
	specified in [RFC4655] for the computation of Traffic Engineering		specified in [RFC4655] for the computation of Traffic Engineering
	(TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching		(TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching
	(MPLS) and Generalized MPLS (GMPLS) networks in the context of single		(MPLS) and Generalized MPLS (GMPLS) networks in the context of single
	or multiple domains where a domain refers to a collection of network		or multiple domains where a domain refers to a collection of network
	elements within a common sphere of address management or path		elements within a common sphere of address management or path
	computational responsibility such Interior Gateway Protocol (IGP)		computational responsibility such Interior Gateway Protocol (IGP)
	skipping to change at page 22, line 21		skipping to change at page 22, line 21
	The frequency of PCMonReq messages may impact the operations of PCEs.		The frequency of PCMonReq messages may impact the operations of PCEs.
	An implementation SHOULD allow a limit to be placed on the rate of		An implementation SHOULD allow a limit to be placed on the rate of
	PCMonReq messages sent by a PCEP speaker and processed from a peer.		PCMonReq messages sent by a PCEP speaker and processed from a peer.
	It SHOULD also allow sending a notification when a rate threshold is		It SHOULD also allow sending a notification when a rate threshold is
	reached. An implementation SHOULD allow handling PCReq messages with		reached. An implementation SHOULD allow handling PCReq messages with
	a higher priority than PCMonReq messages. An implementation SHOULD		a higher priority than PCMonReq messages. An implementation SHOULD
	allow the configuration of a second limit for the PCReq message		allow the configuration of a second limit for the PCReq message
	requesting monitoring data.		requesting monitoring data.
	8. IANA Considerations		8. Guidelines to Avoid Overload Thrashing
	8.1. New PCEP Message		An important concern while processing overload information is to
			prevent the overload condition on one PCE simply being moved to
			another PCE. Indeed, there is a risk that the reaction to an
			indication of overload will act to increase the amount of overload
			within the network. Furthermore, this may lead to oscillations
			between PCEs if the overload information is not handled properly.
			This section presents some brief guidance on how a PCC (which term
			includes a PCE making requests of another PCE) should react when it
			receives an indication that a PCE is overloaded.
			When an overload indication is received (on a PCRep message or on a
			PCMonRep message), it identifies that new PCReq messages sent to the
			PCE might be subject to a delay equal to the value in the Overload
			Duration field (when present).
			It also indicates that PCReq messages already queued at the PCE might
			be subject to a delay. The PCC must decide how to handle new PCReq
			messages, and what to do about PCReq messages already queued at the
			PCE.
			It is RECOMMENDED that a PCC does not cancel a queued PCReq and re-
			issue it to another PCE because of the PCE being overloaded.
			Such behavior is likely to result in overload thrashing as multiple
			PCCs move the PCE queue to another PCE. This would simply introduce
			additional delay in the processing of all requests. A PCC MAY choose
			to cancel a queued PCE request if it is willing to sacrifice the
			request, maybe re-issuing it later (after the overload condition has
			been determined to have cleared by use of a PCMonReq/Rep exchange).
			It is then RECOMMENDED to send the cancellation request with a higher
			priority in order for the PCE overloaded PCE to detect the request
			cancellation before processing the related request.
			A PCC that is aware of PCE overload at one PCE MAY select a different
			PCE to service its next PCReq message. In doing so it is RECOMMENDED
			that the PCC consider whether the other PCE is overloaded or might be
			likely to become overloaded by other PCCs similarly directing new
			PCReq messages.
			Furthermore, should the second PCE be also overloaded, it is
			RECOMMENDED not to make any attempt to switch back to the other PCE
			without knowing that the first PCE is no longer overloaded.
			9. IANA Considerations
			9.1. New PCEP Message
	Each PCEP message has a message type value.		Each PCEP message has a message type value.
	Two new PCEP (specified in [RFC5440]) messages are defined in this		Two new PCEP (specified in [RFC5440]) messages are defined in this
	document:		document:
	Value Description Reference		Value Description Reference
	8 Path Computation Monitoring Request (PCMonReq) This document		8 Path Computation Monitoring Request (PCMonReq) This document
	9 Path Computation Monitoring Reply (PCMonRep) This document		9 Path Computation Monitoring Reply (PCMonRep) This document
	8.2. New PCEP Objects		9.2. New PCEP Objects
	Each PCEP object has an Object-Class and an Object-Type. The		Each PCEP object has an Object-Class and an Object-Type. The
	following new PCEP objects are defined in this document:		following new PCEP objects are defined in this document:
	Object-Class Value Name Object-Type Reference		Object-Class Value Name Object-Type Reference
	19 MONITORING 1 This document		19 MONITORING 1 This document
	20 PCC-REQ-ID 1: IPv4 addresses This document		20 PCC-REQ-ID 1: IPv4 addresses This document
	2: IPv6 addresses		2: IPv6 addresses
	21 PCE-ID 1: IPv4 addresses This document		21 PCE-ID 1: IPv4 addresses This document
	2: IPv6 addresses This document		2: IPv6 addresses This document
	22 PROC-TIME 1 This document		22 PROC-TIME 1 This document
	23 OVERLOAD 1 This document		23 OVERLOAD 1 This document
	8.3. New Error-Values		9.3. New Error-Values
	A registry was created for the Error-type and Error-value of the PCEP		A registry was created for the Error-type and Error-value of the PCEP
	Error Object.		Error Object.
	A new Error-value for the PCErr message Error-types=5 (Policy		A new Error-value for the PCErr message Error-types=5 (Policy
	Violation) (see [RFC5440]) is defined in this document (Error-value		Violation) (see [RFC5440]) is defined in this document (Error-value
	to be assigned by IANA).		to be assigned by IANA).
	Error-Type Meaning Error-value Reference		Error-Type Meaning Error-value Reference
	5 Policy violation 3 This document		5 Policy violation 3 This document
	skipping to change at page 23, line 42		skipping to change at page 24, line 42
	policy violation		policy violation
	A new Error-value for the PCErr message Error-types=6 (Mandatory		A new Error-value for the PCErr message Error-types=6 (Mandatory
	Object missing) (see [RFC5440]) is defined in this document (Error-		Object missing) (see [RFC5440]) is defined in this document (Error-
	Type and Error-value to be assigned by IANA).		Type and Error-value to be assigned by IANA).
	Error-type Meaning Error-value Reference		Error-type Meaning Error-value Reference
	6 Mandatory Object missing 4 This document		6 Mandatory Object missing 4 This document
	MONITORING Object missing		MONITORING Object missing
	8.4. MONITORING Object Flag Field		9.4. MONITORING Object Flag Field
	IANA is requested to create a registry to manage the Flag field of		IANA is requested to create a registry to manage the Flag field of
	the MONITORING object.		the MONITORING object.
	New bit numbers may be allocated only by an IETF review. Each bit		New bit numbers may be allocated only by an IETF review. Each bit
	should be tracked with the following qualities:		should be tracked with the following qualities:
	o Bit number (counting from bit 0 as the most significant bit)		o Bit number (counting from bit 0 as the most significant bit)
	o Capability Description		o Capability Description
	skipping to change at page 24, line 20		skipping to change at page 25, line 20
	Codespace of the Flag field (MONITORING Object)		Codespace of the Flag field (MONITORING Object)
	Bit Description Reference		Bit Description Reference
	0-18 Unassigned		0-18 Unassigned
	19 Incomplete This document		19 Incomplete This document
	20 Overload This document		20 Overload This document
	21 Processing Time This document		21 Processing Time This document
	22 General This document		22 General This document
	23 Liveness This document		23 Liveness This document
	8.5. PROC-TIME Object Flag Field		9.5. PROC-TIME Object Flag Field
	IANA is requested to create a registry to manage the Flag field of		IANA is requested to create a registry to manage the Flag field of
	the PROC-TIME object.		the PROC-TIME object.
	New bit numbers may be allocated only by an IETF review. Each bit		New bit numbers may be allocated only by an IETF review. Each bit
	should be tracked with the following qualities:		should be tracked with the following qualities:
	o Bit number (counting from bit 0 as the most significant bit)		o Bit number (counting from bit 0 as the most significant bit)
	o Capability Description		o Capability Description
	skipping to change at page 24, line 42		skipping to change at page 25, line 42
	o Defining RFC		o Defining RFC
	One bit is defined for the PROC-TIME Object flag field in this		One bit is defined for the PROC-TIME Object flag field in this
	document:		document:
	Codespace of the Flag field (PROC-TIME Object)		Codespace of the Flag field (PROC-TIME Object)
	Bit Description Reference		Bit Description Reference
	0-14 Unassigned		0-14 Unassigned
	15 Estimated This document		15 Estimated This document
	8.6. OVERLOAD Object Flag field		9.6. OVERLOAD Object Flag field
	IANA is requested to create a registry to manage the Flag field of		IANA is requested to create a registry to manage the Flag field of
	the OVERLOAD object.		the OVERLOAD object.
	New bit numbers may be allocated only by an IETF review. Each bit		New bit numbers may be allocated only by an IETF review. Each bit
	should be tracked with the following qualities:		should be tracked with the following qualities:
	o Bit number (counting from bit 0 as the most significant bit)		o Bit number (counting from bit 0 as the most significant bit)
	o Capability Description		o Capability Description
	o Defining RFC		o Defining RFC
	No Flag are currently defined for the OVERLOAD Object flag field in		No Flag are currently defined for the OVERLOAD Object flag field in
	this document.		this document.
	Codespace of the Flag field (OVERLOAD Object)		Codespace of the Flag field (OVERLOAD Object)
	Bit Description Reference		Bit Description Reference
	0-7 Unassigned		0-7 Unassigned
	9. Security Considerations		10. Security Considerations
	The use of monitoring data can be used for various attacks such as		The use of monitoring data can be used for various attacks such as
	denial of service attacks (for example by setting the C bit and		denial of service attacks (for example by setting the C bit and
	overload duration field of the OVERLOAD object to stop PCCs from		overload duration field of the OVERLOAD object to stop PCCs from
	using a PCE). Thus it is recommended to make use of the security		using a PCE). Thus it is recommended to make use of the security
	mechanisms discussed in [RFC5440] to secure a PCEP session		mechanisms discussed in [RFC5440] to secure a PCEP session
	(authenticity, integrity, privacy, DoS protection, etc) to secure the		(authenticity, integrity, privacy, DoS protection, etc) to secure the
	PCMonReq, PCMonRep messages and PCE state metric objects defined in		PCMonReq, PCMonRep messages and PCE state metric objects defined in
	this document. An implementation SHOULD allow limiting the rate at		this document. An implementation SHOULD allow limiting the rate at
	which PCMonReq or PCReq messages carrying monitoring requests		which PCMonReq or PCReq messages carrying monitoring requests
	received from a specific peer are processed (input shaping) as		received from a specific peer are processed (input shaping) as
	discussed in section 10.7.2 of [RFC5440], or from another domain (see		discussed in section 10.7.2 of [RFC5440], or from another domain (see
	also section 7.6).		also section 7.6).
	10. Acknowledgments		11. Acknowledgments
	The authors would like to thank Eiji Oki, Mach Chen, Fabien		The authors would like to thank Eiji Oki, Mach Chen, Fabien
	Verhaeghe, Dimitri Papadimitriou and Francis Dupont for their useful		Verhaeghe, Dimitri Papadimitriou and Francis Dupont for their useful
	comments. Special thank to Adrian Farrel for his detailed review.		comments. Special thank to Adrian Farrel for his detailed review.
	11. References		12. References
	11.1. Normative References		12.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.
	[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element		[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
	(PCE) Communication Protocol (PCEP)", RFC 5440,		(PCE) Communication Protocol (PCEP)", RFC 5440,
	March 2009.		March 2009.
	[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax		[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
	Used to Form Encoding Rules in Various Routing Protocol		Used to Form Encoding Rules in Various Routing Protocol
	Specifications", RFC 5511, April 2009.		Specifications", RFC 5511, April 2009.
	[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the		[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
	Path Computation Element Communication Protocol (PCEP) for		Path Computation Element Communication Protocol (PCEP) for
	Route Exclusions", RFC 5521, April 2009.		Route Exclusions", RFC 5521, April 2009.
	[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of		[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
	Objective Functions in the Path Computation Element		Objective Functions in the Path Computation Element
	Communication Protocol (PCEP)", RFC 5541, June 2009.		Communication Protocol (PCEP)", RFC 5541, June 2009.
	11.2. Informative References		12.2. Informative References
	[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation		[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
	Element (PCE)-Based Architecture", RFC 4655, August 2006.		Element (PCE)-Based Architecture", RFC 4655, August 2006.
	[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,		[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
	"OSPF Protocol Extensions for Path Computation Element		"OSPF Protocol Extensions for Path Computation Element
	(PCE) Discovery", RFC 5088, January 2008.		(PCE) Discovery", RFC 5088, January 2008.
	[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,		[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
	"IS-IS Protocol Extensions for Path Computation Element		"IS-IS Protocol Extensions for Path Computation Element
End of changes. 17 change blocks.
	29 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/