draft-ietf-pce-monitoring-06.txt		draft-ietf-pce-monitoring-07.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: June 17, 2010 France Telecom		Expires: June 19, 2010 France Telecom
	Y. Ikejiri		Y. Ikejiri
	NTT Communications Corporation		NTT Communications Corporation
	December 14, 2009		December 16, 2009
	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-06.txt		draft-ietf-pce-monitoring-07.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 June 17, 2010.		This Internet-Draft will expire on June 19, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 17		skipping to change at page 3, line 17
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Path Computation Monitoring messages . . . . . . . . . . . . . 6		3. Path Computation Monitoring messages . . . . . . . . . . . . . 6
	3.1. Path Computation Monitoring Request message (PCMonReq) . . 6		3.1. Path Computation Monitoring Request message (PCMonReq) . . 6
	3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 9		3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 9
	4. Path Computation Monitoring Objects . . . . . . . . . . . . . 11		4. Path Computation Monitoring Objects . . . . . . . . . . . . . 11
	4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12		4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12
	4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 14		4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 14
	4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 15		4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 15
	4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 17		4.4. OVERLOAD Object . . . . . . . . . . . . . . . . . . . . . 17
	5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 18		6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 18
	7. Manageability Considerations . . . . . . . . . . . . . . . . . 20		7. Manageability Considerations . . . . . . . . . . . . . . . . . 20
	7.1. Control of Function and Policy . . . . . . . . . . . . . . 20		7.1. Control of Function and Policy . . . . . . . . . . . . . . 20
	7.2. Information and Data Models . . . . . . . . . . . . . . . 20		7.2. Information and Data Models . . . . . . . . . . . . . . . 20
	7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20		7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20
	7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20		7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20
	7.5. Requirements On Other Protocols . . . . . . . . . . . . . 20		7.5. Requirements On Other Protocols . . . . . . . . . . . . . 20
	7.6. Impact On Network Operations . . . . . . . . . . . . . . . 21		7.6. Impact On Network Operations . . . . . . . . . . . . . . . 21
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 21		8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 21
	8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 21		8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 21
	8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 21		8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 21
	8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 22		8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 22
	8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 22		8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 22
	8.6. CONGESTION Object Flag field . . . . . . . . . . . . . . . 23		8.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 23
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 23		9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 24		11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
	11.2. Informative References . . . . . . . . . . . . . . . . . . 24		11.2. Informative References . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	The Path Computation Element (PCE) based architecture has been		The Path Computation Element (PCE) based architecture has been
	skipping to change at page 10, line 25		skipping to change at page 10, line 25
	<MONITORING>		<MONITORING>
	[<RP>]		[<RP>]
	[<metric-pce-list>]		[<metric-pce-list>]
	where:		where:
	<metric-pce-list>::=<metric-pce>[<metric-pce-list>]		<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
	<metric-pce>::=<PCE-ID>		<metric-pce>::=<PCE-ID>
	[<PROC-TIME>]		[<PROC-TIME>]
	[<CONGESTION>]		[<OVERLOAD>]
	Format of a PCRep message with monitoring data (in band):		Format of a PCRep message with monitoring data (in band):
	<PCRep Message> ::= <Common Header>		<PCRep Message> ::= <Common Header>
	<response-list>		<response-list>
	where:		where:
	<response-list>::=<response>[<response-list>]		<response-list>::=<response>[<response-list>]
	<response>::=<RP>		<response>::=<RP>
	<MONITORING>		<MONITORING>
	skipping to change at page 11, line 36		skipping to change at page 11, line 36
	[<BANDWIDTH>]		[<BANDWIDTH>]
	[<metric-list>]		[<metric-list>]
	[<IRO>]		[<IRO>]
	<metric-list>::=<METRIC>[<metric-list>]		<metric-list>::=<METRIC>[<metric-list>]
	<metric-pce-list>::=<metric-pce>[<metric-pce-list>]		<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
	<metric-pce>::=<PCE-ID>		<metric-pce>::=<PCE-ID>
	[<PROC-TIME>]		[<PROC-TIME>]
	[<CONGESTION>]		[<OVERLOAD>]
	The RP and the NO-PATH objects are defined in [RFC5440].		The RP and the NO-PATH objects are defined in [RFC5440].
	4. Path Computation Monitoring Objects		4. Path Computation Monitoring Objects
	The PCEP objects defined in the document are compliant with the PCEP		The PCEP objects defined in the document are compliant with the PCEP
	object format defined in [RFC5440]. The P flag and the I flag of the		object format defined in [RFC5440]. The P flag and the I flag of the
	PCEP objects defined in this document SHOULD always be set to 0 on		PCEP objects defined in this document SHOULD always be set to 0 on
	transmission and MUST be ignored on receipt since these flags are		transmission and MUST be ignored on receipt since these flags are
	exclusively related to path computation requests.		exclusively related to path computation requests.
	skipping to change at page 13, line 38		skipping to change at page 13, line 38
	performance metric is specific, the G bit MUST be cleared. The G bit		performance metric is specific, the G bit MUST be cleared. The G bit
	MUST always be ignored in a PCMonRep or PCRep message.		MUST always be ignored in a PCMonRep or PCRep message.
	P (Processing Time) - 1 bit: the P bit of the MONITORING object		P (Processing Time) - 1 bit: the P bit of the MONITORING object
	carried in a PCMonReq or a PCReq message is set to indicate that the		carried in a PCMonReq or a PCReq message is set to indicate that the
	processing times is a metric of interest. If allowed by policy, a		processing times is a metric of interest. If allowed by policy, a
	PROC-TIME object MUST be inserted in the corresponding PCMonRep or		PROC-TIME object MUST be inserted in the corresponding PCMonRep or
	PCRep message. The P bit MUST always be ignored in a PCMonRep or		PCRep message. The P bit MUST always be ignored in a PCMonRep or
	PCRep message.		PCRep message.
	C (Congestion) - 1 bit: The C bit of the MONITORING object carried in		C (Overload) - 1 bit: The C bit of the MONITORING object carried in a
	a PCMonReq or a PCReq message is set to indicate that the congestion		PCMonReq or a PCReq message is set to indicate that the overload
	status is a metric of interest, in which case a CONGESTION object		status is a metric of interest, in which case a OVERLOAD object MUST
	MUST be inserted in the corresponding PCMonRep or PCRep message. The		be inserted in the corresponding PCMonRep or PCRep message. The C
	C bit MUST always be ignored in a PCMonRep or PCRep message.		bit MUST always be ignored in a PCMonRep or PCRep message.
	I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message		I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message
	and that message does not trigger any policy violation, but the PCE		and that message does not trigger any policy violation, but the PCE
	cannot provide any of the set of requested performance metrics for		cannot provide any of the set of requested performance metrics for
	unspecified reasons, the PCE MUST set the I bit. The I bit has no		unspecified reasons, the PCE MUST set the I bit. The I bit has no
	meaning in a request and SHOULD be ignored on receipt.		meaning in a request and SHOULD be ignored on receipt.
	Monitoring-id-number (32 bits): The monitoring-id-number value		Monitoring-id-number (32 bits): The monitoring-id-number value
	combined with the PCEP-ID of the PCC identifies the monitoring		combined with the PCEP-ID of the PCC identifies the monitoring
	request context. The monitoring-id-number MUST start at a non-zero		request context. The monitoring-id-number MUST start at a non-zero
	skipping to change at page 17, line 24		skipping to change at page 17, line 24
	Max-processing-time: This field indicates in milliseconds the maximum		Max-processing-time: This field indicates in milliseconds the maximum
	processing time.		processing time.
	Average-processing-time: This field indicates in milliseconds the		Average-processing-time: This field indicates in milliseconds the
	average processing time.		average processing time.
	Variance-processing-time: This field indicates in milliseconds the		Variance-processing-time: This field indicates in milliseconds the
	variance of the processing times.		variance of the processing times.
	4.4. CONGESTION Object		4.4. OVERLOAD Object
	The CONGESTION object is used to report a PCE processing congestion		The OVERLOAD object is used to report a PCE processing congestion
	state. Note that "congestion" as indicated by this object refers to		state. Note that "overload" as indicated by this object refers to
	the processing state of the PCE and its ability to handle new PCEP		the processing state of the PCE and its ability to handle new PCEP
	requests. A PCE is congested when it has a backlog of PCEP requests		requests. A PCE is overloaded when it has a backlog of PCEP requests
	such that it cannot immediately start to process a new request thus		such that it cannot immediately start to process a new request thus
	leading to waiting times. The congestion duration is quantified as		leading to waiting times. The overload duration is quantified as
	being the (estimated) time until the PCE expects to be able to		being the (estimated) time until the PCE expects to be able to
	immediately process a new PCEP request.		immediately process a new PCEP request.
	The CONGESTION object MUST be present within a PCMonRep or a PCRep		The OVERLOAD object MUST be present within a PCMonRep or a PCRep
	message if the C bit of the MONITORING object carried within the		message if the C bit of the MONITORING object carried within the
	corresponding PCMonReq or PCReq message is set and the PCE is		corresponding PCMonReq or PCReq message is set and the PCE is
	experiencing a congested state. The CONGESTION Object-Class is to be		experiencing a congested state. The OVERLOAD Object-Class is to be
	assigned by IANA (recommended value=22). The CONGESTION Object-Type		assigned by IANA (recommended value=22). The OVERLOAD Object-Type is
	is to be assigned by IANA (recommended value=1)		to be assigned by IANA (recommended value=1)
	The format of the CONGESTION object body is as follows:		The format of the CONGESTION object body is 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Reserved | Congestion Duration |		| Flags | Reserved | Overload Duration |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Flags: 8 bits - No flag is currently defined.		Flags: 8 bits - No flag is currently defined.
	Congestion duration - 16 bits: This field indicates in the amount of		Overload duration - 16 bits: This field indicates in the amount of
	time in seconds that the responding PCE expects that it may continue		time in seconds that the responding PCE expects that it may continue
	to be congested from the time that the response message was		to be overloaded from the time that the response message was
	generated. The receiver MAY use this value to decide whether or not		generated. The receiver MAY use this value to decide whether or not
	so send further requests to the same PCE.		so send further requests to the same PCE.
	It is worth noting that a PCE along a PCE chain involved in the		It is worth noting that a PCE along a PCE chain involved in the
	monitoring request may decide to learn from the congestion		monitoring request may decide to learn from the overload information
	information received by one of downstream PCE in the chain.		received by one of downstream PCE in the chain.
	5. Policy		5. Policy
	The receipt of a PCMonReq message may trigger a policy violation on		The receipt of a PCMonReq message may trigger a policy violation on
	some PCE in which case the PCE MUST send a PCErr message with Error-		some PCE in which case the PCE MUST send a PCErr message with Error-
	Type=5 and Error-value=3 (To be Confirmed by IANA).		Type=5 and Error-value=3 (To be Confirmed by IANA).
	6. Elements of Procedure		6. Elements of Procedure
	I bit processing: as indicated in section Section 4.1, if a PCE		I bit processing: as indicated in section Section 4.1, if a PCE
	skipping to change at page 20, line 23		skipping to change at page 20, line 23
	7. Manageability Considerations		7. Manageability Considerations
	7.1. Control of Function and Policy		7.1. Control of Function and Policy
	It MUST be possible to configure the activation/deactivation of PCEP		It MUST be possible to configure the activation/deactivation of PCEP
	monitoring on a PCEP speaker. In addition to the parameters already		monitoring on a PCEP speaker. In addition to the parameters already
	listed in section 8.1 of [RFC5440], a PCEP implementation SHOULD		listed in section 8.1 of [RFC5440], a PCEP implementation SHOULD
	allow configuring on a PCE whether specific, generic, in band and out		allow configuring on a PCE whether specific, generic, in band and out
	of band monitoring requests are allowed or not. Also a PCEP		of band monitoring requests are allowed or not. Also a PCEP
	implementation SHOULD allow configuring on a PCE a list of authorized		implementation SHOULD allow configuring on a PCE a list of authorized
	state metrics (aliveness, congestion, processing time, etc). This		state metrics (aliveness, overload, processing time, etc). This may
	may apply to any session the PCEP speaker participates in, to a		apply to any session the PCEP speaker participates in, to a specific
	specific session with a given PCEP peer or to a specific group of		session with a given PCEP peer or to a specific group of sessions
	sessions with a specific group of PCEP peers, for instance the PCEP		with a specific group of PCEP peers, for instance the PCEP peers of a
	peers of a neighbor AS.		neighbor AS.
	7.2. Information and Data Models		7.2. Information and Data Models
	A new MIB Module may be defined that provides local PCE state		A new MIB Module may be defined that provides local PCE state
	metrics, as well as state metrics of other PCEs gathered using		metrics, as well as state metrics of other PCEs gathered using
	mechanisms defined in this document.		mechanisms defined in this document.
	7.3. Liveness Detection and Monitoring		7.3. Liveness Detection and Monitoring
	This document provides mechanisms to monitor the liveliness and		This document provides mechanisms to monitor the liveliness and
	skipping to change at page 21, line 43		skipping to change at page 21, line 43
	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 PCE-ID 1: IPv4 addresses This document		20 PCE-ID 1: IPv4 addresses This document
	2: IPv6 addresses This document		2: IPv6 addresses This document
	21 PROC-TIME 1 This document		21 PROC-TIME 1 This document
	22 CONGESTION 1 This document		22 OVERLOAD 1 This document
	8.3. New Error-Values		8.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).
	skipping to change at page 22, line 41		skipping to change at page 22, line 41
	o Defining RFC		o Defining RFC
	Several bits are defined for the MONITORING Object flag field in this		Several bits are defined for the MONITORING Object flag field in this
	document:		document:
	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 Congestion 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		8.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
	skipping to change at page 23, line 20		skipping to change at page 23, line 20
	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. CONGESTION Object Flag field		8.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 CONGESTION 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 CONGESTION 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 (CONGESTION Object)		Codespace of the Flag field (OVERLOAD Object)
	Bit Description Reference		Bit Description Reference
	0-7 Unassigned		0-7 Unassigned
	9. Security Considerations		9. 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
	congestion during field of the CONGESTION 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), or from		received from a specific peer are processed (input shaping), or from
	another domain (see also section 7.6).		another domain (see also section 7.6).
	10. Acknowledgments		10. Acknowledgments
End of changes. 27 change blocks.
	39 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/