< draft-ietf-dime-doic-rate-control-02.txt		draft-ietf-dime-doic-rate-control-03.txt >
	Diameter Maintenance and Extensions (DIME) S. Donovan, Ed.		Diameter Maintenance and Extensions (DIME) S. Donovan, Ed.
	Internet-Draft Oracle		Internet-Draft Oracle
	Intended status: Standards Track E. Noel		Intended status: Standards Track E. Noel
	Expires: March 3, 2016 AT&T Labs		Expires: September 19, 2016 AT&T Labs
	August 31, 2015		March 18, 2016
	Diameter Overload Rate Control		Diameter Overload Rate Control
	draft-ietf-dime-doic-rate-control-02.txt		draft-ietf-dime-doic-rate-control-03.txt
	Abstract		Abstract
	This specification documents an extension to the Diameter Overload		This specification documents an extension to the Diameter Overload
	Indication Conveyance (DOIC) base solution. This extension adds a		Indication Conveyance (DOIC) [RFC7683] base solution. This extension
	new overload control abatement algorithm. This abatement algorithm		adds a new overload control abatement algorithm. This abatement
	allows for a DOIC reporting node to specify a maximum rate at which a		algorithm allows for a DOIC reporting node to specify a maximum rate
	DOIC reacting node sends Diameter requests to the DOIC reporting		at which a DOIC reacting node sends Diameter requests to the DOIC
	node.		reporting node.
	Requirements		Requirements
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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 as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 3, 2016.		This Internet-Draft will expire on September 19, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4		2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
	3. Interaction with DOIC report types . . . . . . . . . . . . . 5		3. Interaction with DOIC report types . . . . . . . . . . . . . 4
	4. Capability Announcement . . . . . . . . . . . . . . . . . . . 5		4. Capability Announcement . . . . . . . . . . . . . . . . . . . 5
	5. Overload Report Handling . . . . . . . . . . . . . . . . . . 6		5. Overload Report Handling . . . . . . . . . . . . . . . . . . 6
	5.1. Reporting Node Overload Control State . . . . . . . . . . 6		5.1. Reporting Node Overload Control State . . . . . . . . . . 6
	5.2. Reacting Node Overload Control State . . . . . . . . . . 7		5.2. Reacting Node Overload Control State . . . . . . . . . . 6
	5.3. Reporting Node Maintenance of Overload Control State . . 7		5.3. Reporting Node Maintenance of Overload Control State . . 7
	5.4. Reacting Node Maintenance of Overload Control State . . . 7		5.4. Reacting Node Maintenance of Overload Control State . . . 7
	5.5. Reporting Node Behavior for Rate Abatement Algorithm . . 8		5.5. Reporting Node Behavior for Rate Abatement Algorithm . . 7
	5.6. Reacting Node Behavior for Rate Abatement Algorithm . . . 8		5.6. Reacting Node Behavior for Rate Abatement Algorithm . . . 8
	6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 8		6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 8
	6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 9		6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 8
	6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 9		6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 8
	6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 9		6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 8
	6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 10		6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 9
	6.3. Attribute Value Pair flag rules . . . . . . . . . . . . . 10		6.3. Attribute Value Pair flag rules . . . . . . . . . . . . . 9
	7. Rate Based Abatement Algorithm . . . . . . . . . . . . . . . 10		7. Rate Based Abatement Algorithm . . . . . . . . . . . . . . . 9
	7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10		7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 11		7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10
	7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12		7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 11
	7.3.1. Default algorithm . . . . . . . . . . . . . . . . . . 12		7.3.1. Default algorithm . . . . . . . . . . . . . . . . . . 11
	7.3.2. Priority treatment . . . . . . . . . . . . . . . . . 15		7.3.2. Priority treatment . . . . . . . . . . . . . . . . . 14
	7.3.3. Optional enhancement: avoidance of resonance . . . . 17		7.3.3. Optional enhancement: avoidance of resonance . . . . 16
	8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 18		8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 18		9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . 19		11.1. Normative References . . . . . . . . . . . . . . . . . . 18
	11.2. Informative References . . . . . . . . . . . . . . . . . 19		11.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	This document defines a new Diameter overload control abatement		This document defines a new Diameter overload control abatement
	algorithm.		algorithm.
	The base Diameter overload specification [I-D.ietf-dime-ovli] defines		The base Diameter overload specification [RFC7683] defines the loss
	the loss algorithm as the default Diameter overload abatement		algorithm as the default Diameter overload abatement algorithm. The
	algorithm. The loss algorithm allows a reporting node to instruct a		loss algorithm allows a reporting node to instruct a reacting node to
	reacting node to reduce the amount of traffic sent to the reporting		reduce the amount of traffic sent to the reporting node by abating
	node by abating (diverting or throttling) a percentage of requests		(diverting or throttling) a percentage of requests sent to the
	sent to the server. While this can effectively decrease the load		server. While this can effectively decrease the load handled by the
	handled by the server, it does not directly address cases where the		server, it does not directly address cases where the rate of arrival
	rate of arrival of service requests increase quickly. If the service		of service requests increase quickly. If the service requests that
	requests that result in Diameter transactions increases quickly then		result in Diameter transactions increases quickly then the loss
	the loss algorithm cannot guarantee the load presented to the server		algorithm cannot guarantee the load presented to the server remains
	remains below a specific rate level. The loss algorithm can be slow		below a specific rate level. The loss algorithm can be slow to
	to protect the stability of reporting nodes when subject with rapidly		protect the stability of reporting nodes when subjected with rapidly
	changing loads.		changing loads.
	Consider the case where a reacting node is handling 100 service		Consider the case where a reacting node is handling 100 service
	requests per second, where each of these service requests results in		requests per second, where each of these service requests results in
	one Diameter transaction being sent to a reacting node. If the		one Diameter transaction being sent to a reacting node. If the
	reacting node is approaching an overload state, or is already in an		reacting node is approaching an overload state, or is already in an
	overload state, it will send a Diameter overload report requesting a		overload state, it will send a Diameter overload report requesting a
	percentage reduction in traffic sent. Assume for this discussion		percentage reduction in traffic sent. Assume for this discussion
	that the reporting node requests a 10% reduction. The reacting node		that the reporting node requests a 10% reduction. The reacting node
	will then abate (diverting or throttling) ten Diameter transactions a		will then abate (diverting or throttling) ten Diameter transactions a
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 15 ¶
	One of the benefits of a rate based algorithm is that it better		One of the benefits of a rate based algorithm is that it better
	handles spikes in traffic. Instead of sending a request to reduce		handles spikes in traffic. Instead of sending a request to reduce
	traffic by a percentage, the rate approach allows the reporting node		traffic by a percentage, the rate approach allows the reporting node
	to specify the maximum number of Diameter requests per second that		to specify the maximum number of Diameter requests per second that
	can be sent to the reporting node. For instance, in this example,		can be sent to the reporting node. For instance, in this example,
	the reporting node could send a rate based request specifying the		the reporting node could send a rate based request specifying the
	maximum transactions per second to be 90. The reacting node will		maximum transactions per second to be 90. The reacting node will
	send the 90 regardless of whether it is receiving 100 or 1000 service		send the 90 regardless of whether it is receiving 100 or 1000 service
	requests per second.		requests per second.
	This document extends the base DOIC solution [I-D.ietf-dime-ovli] to		This document extends the base DOIC solution [RFC7683] to add support
	add support for the rate based overload abatement algorithm.		for the rate based overload abatement algorithm.
	This document draws heavily on work in the RIA SIP Overload Control		This document draws heavily on work in the RIA SIP Overload Control
	working group. The definition of the rate abatement algorithm is		working group. The definition of the rate abatement algorithm is
	copied almost verbatim from the SOC document [RFC7415], with changes		copied almost verbatim from the SOC document [RFC7415], with changes
	focused on making the wording consistent with the DOIC solution and		focused on making the wording consistent with the DOIC solution and
	the Diameter protocol.		the Diameter protocol.
	Editor's Note: Need to verify that the latest text from the SOC
	document is currently being used.
	2. Terminology and Abbreviations		2. Terminology and Abbreviations
	Diameter Node		Diameter Node
	A RFC6733 Diameter Client, RFC6733 Diameter Server, or RFC6733		A RFC6733 Diameter Client, RFC6733 Diameter Server, or RFC6733
	Diameter Agent.		Diameter Agent.
	Diameter Endpoint		Diameter Endpoint
	An RFC6733 Diameter Client or RFC6733 Diameter Server.		An RFC6733 Diameter Client or RFC6733 Diameter Server.
	DOIC Node		DOIC Node
	A Diameter Node that supports the DOIC solution defined in		A Diameter Node that supports the DOIC solution defined in
	[I-D.ietf-dime-ovli].		[RFC7683].
	Reporting Node		Reporting Node
	A DOIC Node that sends a DOIC overload report.		A DOIC Node that sends a DOIC overload report.
	Reacting Node		Reacting Node
	A DOIC Node that receives and acts on a DOIC overload report.		A DOIC Node that receives and acts on a DOIC overload report.
	3. Interaction with DOIC report types		3. Interaction with DOIC report types
	As of the publication of this specification there are two DOIC report		As of the publication of this specification there are two DOIC report
	types defined with the specification of a third in progress:		types defined with the specification of a third in progress:
	1. Host - Overload of a specific Diameter Application at a specific		1. Host - Overload of a specific Diameter Application at a specific
	Diameter Node as defined in [I-D.ietf-dime-ovli].		Diameter Node as defined in [RFC7683].
	2. Realm - Overload of a specific Diameter Application at a specific		2. Realm - Overload of a specific Diameter Application at a specific
	Diameter Realm as defined in [I-D.ietf-dime-ovli].		Diameter Realm as defined in [RFC7683].
	3. Peer - Overload of a specific Diameter peer as defined in		3. Peer - Overload of a specific Diameter peer as defined in
	[I-D.ietf-dime-agent-overload].		[I-D.ietf-dime-agent-overload].
	The rate algorithm MAY be selected by reporting nodes for any of		The rate algorithm MAY be selected by reporting nodes for any of
	these report types.		these report types.
	Editor's note: It needs to be validated that use of the rate
	algorithm applies to the host and realm report types.
	It is expected that all report types defined in the future will		It is expected that all report types defined in the future will
	indicate whether or not the rate algorithm can be used with that		indicate whether or not the rate algorithm can be used with that
	report type.		report type.
	4. Capability Announcement		4. Capability Announcement
	This extension defines the rate abatement algorithm (referred to as		This extension defines the rate abatement algorithm (referred to as
	rate in this document) feature. Support for the rate feature will be		rate in this document) feature. Support for the rate feature will be
	reflected by use of a new value, as defined in Section 6.1.1, in the		reflected by use of a new value, as defined in Section 6.1.1, in the
	OC-Feature-Vector AVP per the rules defined in [I-D.ietf-dime-ovli].		OC-Feature-Vector AVP per the rules defined in [RFC7683].
	Note that Diameter nodes that support the rate feature will, by		Note that Diameter nodes that support the rate feature will, by
	definition, support both the loss and rate based abatement		definition, support both the loss and rate based abatement
	algorithms. DOIC reacting nodes SHOULD indicate support for both the		algorithms. DOIC reacting nodes SHOULD indicate support for both the
	loss and rate algorithms in the OC-Feature-Vector AVP.		loss and rate algorithms in the OC-Feature-Vector AVP.
	There may be local policy reasons that cause a DOIC node that		There may be local policy reasons that cause a DOIC node that
	supports the rate abatement algorithm to not include it in the OC-		supports the rate abatement algorithm to not include it in the OC-
	Feature-Vector. All reacting nodes, however, must continue to		Feature-Vector. All reacting nodes, however, must continue to
	include loss in the OC-Feature-Vector in order to remain compliant		include loss in the OC-Feature-Vector in order to remain compliant
	with [I-D.ietf-dime-ovli].		with [RFC7683].
	A reporting node MAY select one abatement algorithm to apply to host		A reporting node MAY select one abatement algorithm to apply to host
	and realm reports and a different algorithm to apply to peer reports.		and realm reports and a different algorithm to apply to peer reports.
	For host or realm reports the selected algorithm is reflected in		For host or realm reports the selected algorithm is reflected in
	the OC-Feature-Vector AVP sent as part of the OC-Selected-Features		the OC-Feature-Vector AVP sent as part of the OC-Selected-Features
	AVP included in answer messages for transaction where the request		AVP included in answer messages for transaction where the request
	contained an OC-Supported-Features AVP. This is per the		contained an OC-Supported-Features AVP. This is per the
	procedures defined in [I-D.ietf-dime-ovli].		procedures defined in [RFC7683].
	For peer reports the selected algorithm is reflected in the OC-		For peer reports the selected algorithm is reflected in the OC-
	Peer-Algo AVP sent as part of the OC-Supported-Features AVP		Peer-Algo AVP sent as part of the OC-Supported-Features AVP
	included answer messages for transaction where the request		included answer messages for transactions where the request
	contained an OC-Supported-Features AVP. This is per the		contained an OC-Supported-Features AVP. This is per the
	procedures defined in [I-D.ietf-dime-agent-overload].		procedures defined in [I-D.ietf-dime-agent-overload].
	Editor's Node: The peer report specification is still under		Editor's Node: The peer report specification is still under
	development and, as such, the above paragraph is subject to		development and, as such, the above paragraph is subject to
	change.		change.
	5. Overload Report Handling		5. Overload Report Handling
	This section describes any changes to the behavior defined in		This section describes any changes to the behavior defined in
	[I-D.ietf-dime-ovli] for handling of overload reports when the rate		[RFC7683] for handling of overload reports when the rate overload
	overload abatement algorithm is used.		abatement algorithm is used.
	5.1. Reporting Node Overload Control State		5.1. Reporting Node Overload Control State
	A reporting node that uses the rate abatement algorithm SHOULD		A reporting node that uses the rate abatement algorithm SHOULD
	maintain reporting node OCS for each reacting node to which it sends		maintain reporting node OCS for each reacting node to which it sends
	a rate OLR.		a rate OLR.
	This is different from the behavior defines in		This is different from the behavior defines in [RFC7683] where a
	[I-D.ietf-dime-ovli] where a single loss percentage sent to all		single loss percentage sent to all reacting nodes.
	reacting nodes.
	A reporting node SHOULD maintain OCS entries when using the rate		A reporting node SHOULD maintain OCS entries when using the rate
	abatement algorithm per supported Diameter application, per targeted		abatement algorithm per supported Diameter application, per targeted
	reacting node and per report-type.		reacting node and per report-type.
	A rate OCS entry is identified by the tuple of Application-Id,		A rate OCS entry is identified by the tuple of Application-Id,
	report-type and DiameterID of the target of the rate OLR.		report-type and DiameterID of the target of the rate OLR.
	A reporting node that supports the rate abatement algorithm MUST be		A reporting node that supports the rate abatement algorithm MUST
	able to include the specified rate in the abatement algorithm		include the specified rate in the abatement algorithm specific
	specific portion of the reporting node rate OCS.		portion of the reporting node rate OCS when sending a rate OLR.
	All other elements for the OCS defined in [I-D.ietf-dime-ovli] and		All other elements for the OCS defined in [RFC7683] and
	[I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS		[I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS
	when using the rate abatement algorithm.		when using the rate abatement algorithm.
	5.2. Reacting Node Overload Control State		5.2. Reacting Node Overload Control State
	A reacting node that supports the rate abatement algorithm MUST be		A reacting node that supports the rate abatement algorithm MUST
	able to include rate as the selected abatement algorithm in the		indicate rate as the selected abatement algorithm in the reacting
	reacting node OCS.		node OCS when receiving a rate OLR.
	A reacting node that supports the rate abatement algorithm MUST be		A reacting node that supports the rate abatement algorithm MUST
	able to include the rate specified in the OC-Maximum-Rate AVP		include the rate specified in the OC-Maximum-Rate AVP included in the
	included in the OC-OLR AVP as an element of the abatement algorithm		OC-OLR AVP as an element of the abatement algorithm specific portion
	specific portion of reacting node OCS entries.		of reacting node OCS entries.
	All other elements for the OCS defined in [I-D.ietf-dime-ovli] and		All other elements for the OCS defined in [RFC7683] and
	[I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS		[I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS
	when using the rate abatement algorithm.		when using the rate abatement algorithm.
	5.3. Reporting Node Maintenance of Overload Control State		5.3. Reporting Node Maintenance of Overload Control State
	A reporting node that has selected the rate overload abatement		A reporting node that has selected the rate overload abatement
	algorithm and enters an overload condition MUST indicate rate as the		algorithm and enters an overload condition MUST indicate rate as the
	abatement algorithm in the resulting reporting node OCS entries.		abatement algorithm in the resulting reporting node OCS entries.
	A reporting node that has selected the rate abatement algorithm and		A reporting node that has selected the rate abatement algorithm and
	enters an overload condition MUST indicate the selected rate in the		enters an overload condition MUST indicate the selected rate in the
	resulting reporting node OCS entries.		resulting reporting node OCS entries.
	When selecting the rate algorithm in the response to a request that		When selecting the rate algorithm in the response to a request that
	contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP		contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP
	indicating support for the rate feature, a reporting node MUST ensure		indicating support for the rate feature, a reporting node MUST ensure
	that a reporting node OCS entry exists for the target of the overload		that a reporting node OCS entry exists for the target of the overload
	report. The target is defined as follows:		report. The target is defined as follows:
	o For Host reports the target is the DiameterID contained in the		o For Host reports the target is the DiameterIdentity contained in
	Origin-Host AVP received in the request.		the Origin-Host AVP received in the request.
	o For Realm reports the target is the DiameterID contained in the		o For Realm reports the target is the DiameterIdentity contained in
	Origin-Realm AVP received in the request.		the Origin-Realm AVP received in the request.
	o For Peer reports the target is the DiameterID of the Diameter Peer		o For Peer reports the target is the DiameterIdentity of the
	from which the request was received.		Diameter Peer from which the request was received.
	5.4. Reacting Node Maintenance of Overload Control State		5.4. Reacting Node Maintenance of Overload Control State
	When receiving an answer message indicating that the reacting node		When receiving an answer message indicating that the reacting node
	has selected the rate algorithm, a reaction node MUST indicate the		has selected the rate algorithm, a reaction node MUST indicate the
	rate abatement algorithm in the reacting node OCS entry for the		rate abatement algorithm in the reacting node OCS entry for the
	reporting node.		reporting node.
	A reacting node receiving an overload report for the rate abatement		A reacting node receiving an overload report for the rate abatement
	algorithm MUST save the rate received in the OC-Maximum-Rate AVP		algorithm MUST save the rate received in the OC-Maximum-Rate AVP
	skipping to change at page 8, line 18 ¶		skipping to change at page 7, line 50 ¶
	5.5. Reporting Node Behavior for Rate Abatement Algorithm		5.5. Reporting Node Behavior for Rate Abatement Algorithm
	When in an overload condition with rate selected as the overload		When in an overload condition with rate selected as the overload
	abatement algorithm and when handling a request that contained an OC-		abatement algorithm and when handling a request that contained an OC-
	Supported-Features AVP that indicated support for the rate abatement		Supported-Features AVP that indicated support for the rate abatement
	algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate		algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate
	algorithm using the parameters stored in the reporting node OCS for		algorithm using the parameters stored in the reporting node OCS for
	the target of the overload report.		the target of the overload report.
	Editor's Note: The above is a pretty complicated way of saying
	that the reporting node should include an OC-OLR in the
	appropriate answer messages. The basic requirement isn't rate
	feature specific but rather that in all cases the reporting node
	generates an OC-OLR according to the parameters of the appropriate
	OCS entry. This wording probably can be improved based on the
	generic behavior definition.
	When sending an overload report for the Rate algorithm, the OC-		When sending an overload report for the Rate algorithm, the OC-
	Maximum-Rate AVP is included and the OC-Reduction-Percentage AVP is		Maximum-Rate AVP is included and the OC-Reduction-Percentage AVP is
	not included.		not included.
	5.6. Reacting Node Behavior for Rate Abatement Algorithm		5.6. Reacting Node Behavior for Rate Abatement Algorithm
	When determining if abatement treatment should be applied to a		When determining if abatement treatment should be applied to a
	request being sent to a reporting node that has selected the rate		request being sent to a reporting node that has selected the rate
	overload abatement algorithm, the reacting node MAY use the algorithm		overload abatement algorithm, the reacting node MAY use the algorithm
	detailed in Section 6.		detailed in Section 6.
	Note: Other algorithms for controlling the rate can be implemented		Note: Other algorithms for controlling the rate can be implemented
	by the reacting node as long as they result in the correct rate of		by the reacting node as long as they result in the correct rate of
	traffic being sent to the reporting node.		traffic being sent to the reporting node.
	Once a determination is made by the reacting node that an individual		Once a determination is made by the reacting node that an individual
	Diameter request is to be subjected to abatement treatment then the		Diameter request is to be subjected to abatement treatment then the
	procedures for throttling and diversion defined in		procedures for throttling and diversion defined in [RFC7683] and
	[I-D.ietf-dime-ovli] and [I-D.ietf-dime-agent-overload] apply.		[I-D.ietf-dime-agent-overload] apply.
	6. Rate Abatement Algorithm AVPs		6. Rate Abatement Algorithm AVPs
	Editors Note: This section depends upon the completion of the base
	DOIC specification. As such, it cannot be complete until the data
	model and extension mechanism are finalized. Details for any new
	AVPs or modifications to existing AVPs will be finalized in a future
	version of the draft after the base DOC specification has stabilized.
	6.1. OC-Supported-Features AVP		6.1. OC-Supported-Features AVP
	The rate algorithm does not add any AVPs to the OC-Supported-Features		The rate algorithm does not add any new AVPs to the OC-Supported-
	AVP.		Features AVP.
	The rate algorithm does add a new feature bit to be carried in the		The rate algorithm does add a new feature bit to be carried in the
	OC-Feature-Vector AVP.		OC-Feature-Vector AVP.
	6.1.1. OC-Feature-Vector AVP		6.1.1. OC-Feature-Vector AVP
	This extension adds the following capabilities to the OC-Feature-		This extension adds the following capabilities to the OC-Feature-
	Vector AVP.		Vector AVP.
	OLR_RATE_ALGORITHM (0x0000000000000004)		OLR_RATE_ALGORITHM (0x0000000000000004)
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 19 ¶
	[ OC-Validity-Duration ]		[ OC-Validity-Duration ]
	[ OC-Source-ID ]		[ OC-Source-ID ]
	[ OC-Abatement-Algorithm ]		[ OC-Abatement-Algorithm ]
	[ OC-Maximum-Rate ]		[ OC-Maximum-Rate ]
	* [ AVP ]		* [ AVP ]
	This extension makes no changes to the other AVPs that are part of		This extension makes no changes to the other AVPs that are part of
	the OC-OLR AVP.		the OC-OLR AVP.
	This extension does not define new overload report types. The		This extension does not define new overload report types. The
	existing report types of host and realm defined in		existing report types of host and realm defined in [RFC7683] apply to
	[I-D.ietf-dime-ovli] apply to the rate control algorithm. The peer		the rate control algorithm. The peer report type defined in
	report type defined in [I-D.ietf-dime-agent-overload] also applies to		[I-D.ietf-dime-agent-overload] also applies to the rate control
	the rate control algorithm.		algorithm.
	6.2.1. OC-Maximum-Rate AVP		6.2.1. OC-Maximum-Rate AVP
	The OC-Maximum-Rate AVP (AVP code TBD1) is type of Unsigned32 and		The OC-Maximum-Rate AVP (AVP code TBD1) is type of Unsigned32 and
	describes the maximum rate that that the sender is requested to send		describes the maximum rate that that the sender is requested to send
	traffic. This is specified in terms of requests per second.		traffic. This is specified in terms of requests per second.
	Editor's note: Do we need to specify a maximum value?
	A value of zero indicates that no traffic is to be sent.		A value of zero indicates that no traffic is to be sent.
	6.3. Attribute Value Pair flag rules		6.3. Attribute Value Pair flag rules
	+---------+		+---------+
	|AVP flag |		|AVP flag |
	|rules |		|rules |
	+----+----+		+----+----+
	AVP Section | |MUST|		AVP Section | |MUST|
	Attribute Name Code Defined Value Type |MUST| NOT|		Attribute Name Code Defined Value Type |MUST| NOT|
	+--------------------------------------------------------+----+----+		+---------------------------------------------------------+----+----+
	|OC-Maximum-Rate TBD1 x.x Unsigned64 | | V |		|OC-Maximum-Rate TBD1 x.x Unsigned64 | | V |
	+--------------------------------------------------------+----+----+		+---------------------------------------------------------+----+----+
	7. Rate Based Abatement Algorithm		7. Rate Based Abatement Algorithm
	This section is pulled from [RFC7415], with minor changes needed to		This section is pulled from [RFC7415], with minor changes needed to
	make it apply to the Diameter protocol.		make it apply to the Diameter protocol.
	7.1. Overview		7.1. Overview
	The reporting node is the one protected by the overload control		The reporting node is the one protected by the overload control
	algorithm defined here. The reacting node is the one that abates		algorithm defined here. The reacting node is the one that abates
	skipping to change at page 18, line 41 ¶		skipping to change at page 17, line 41 ¶
	o At high load randomization rarely occurs, so there is no loss of		o At high load randomization rarely occurs, so there is no loss of
	precision of the admitted rate, even though the randomized		precision of the admitted rate, even though the randomized
	'phasing' of the buckets remains.		'phasing' of the buckets remains.
	8. IANA Consideration		8. IANA Consideration
	TBD		TBD
	9. Security Considerations		9. Security Considerations
	Agent overload is an extension to the based Diameter overload		The rate overload abatement mechanism is an extension to the based
	mechanism. As such, all of the security considerations outlined in		Diameter overload mechanism. As such, all of the security
	[I-D.ietf-dime-ovli] apply to the agent overload scenarios.		considerations outlined in [RFC7683] apply to the rate overload
			abatement mechanism.
	10. Acknowledgements		10. Acknowledgements
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-dime-agent-overload]		[I-D.ietf-dime-agent-overload]
	Donovan, S., "Diameter Agent Overload", draft-ietf-dime-		Donovan, S., "Diameter Agent Overload", draft-ietf-dime-
	agent-overload-00 (work in progress), December 2014.		agent-overload-00 (work in progress), December 2014.
	[I-D.ietf-dime-ovli]
	Korhonen, J., Donovan, S., Campbell, B., and L. Morand,
	"Diameter Overload Indication Conveyance", draft-ietf-
	dime-ovli-08 (work in progress), February 2015.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,		[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
	Ed., "Diameter Base Protocol", RFC 6733,		Ed., "Diameter Base Protocol", RFC 6733,
	DOI 10.17487/RFC6733, October 2012,		DOI 10.17487/RFC6733, October 2012,
	<http://www.rfc-editor.org/info/rfc6733>.		<http://www.rfc-editor.org/info/rfc6733>.
			[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
			Morand, "Diameter Overload Indication Conveyance",
			RFC 7683, DOI 10.17487/RFC7683, October 2015,
			<http://www.rfc-editor.org/info/rfc7683>.
	11.2. Informative References		11.2. Informative References
	[RFC7415] Noel, E. and P. Williams, "Session Initiation Protocol		[RFC7415] Noel, E. and P. Williams, "Session Initiation Protocol
	(SIP) Rate Control", RFC 7415, DOI 10.17487/RFC7415,		(SIP) Rate Control", RFC 7415, DOI 10.17487/RFC7415,
	February 2015, <http://www.rfc-editor.org/info/rfc7415>.		February 2015, <http://www.rfc-editor.org/info/rfc7415>.
	Authors' Addresses		Authors' Addresses
	Steve Donovan (editor)		Steve Donovan (editor)
	Oracle		Oracle
End of changes. 44 change blocks.
	122 lines changed or deleted		100 lines changed or added
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/