< draft-ietf-dime-agent-overload-03.txt		draft-ietf-dime-agent-overload-04.txt >
	Diameter Maintenance and Extensions (DIME) S. Donovan		Diameter Maintenance and Extensions (DIME) S. Donovan
	Internet-Draft Oracle		Internet-Draft Oracle
	Intended status: Standards Track October 14, 2015		Intended status: Standards Track March 18, 2016
	Expires: April 16, 2016		Expires: September 19, 2016
	Diameter Agent Overload and the Peer Overload Report		Diameter Agent Overload and the Peer Overload Report
	draft-ietf-dime-agent-overload-03.txt		draft-ietf-dime-agent-overload-04.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. The extension defines		Indication Conveyance (DOIC) [RFC7683] base solution. The extension
	the Peer overload report type. The initial use case for the Peer		defines the Peer overload report type. The initial use case for the
	report is the handling of occurrences of overload of a Diameter		Peer report is the handling of occurrences of overload of a Diameter
	agent.		agent.
	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
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 April 16, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3		2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
	3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4		3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4
	3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 4		3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 4
	3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 4		3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 4
	3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 5		3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 5
	3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 6		3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 6
	3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 7		3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 7
	3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 7		3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 7
	4. Interaction Between Host/Realm and Peer Overload Reports . . 8		4. Interaction Between Host/Realm and Peer Overload Reports . . 8
	5. Peer Report Behavior . . . . . . . . . . . . . . . . . . . . 8		5. Peer Report Behavior . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	5.2.1. Overload Control State . . . . . . . . . . . . . . . 10		5.2.1. Overload Control State . . . . . . . . . . . . . . . 10
	5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 11		5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 11
	5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 11		5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 11
	5.2.4. Peer Report Reporting Node Behavior . . . . . . . . . 13		5.2.4. Peer Report Reporting Node Behavior . . . . . . . . . 13
	5.2.5. Peer Report Reacting Node Behavior . . . . . . . . . 13		5.2.5. Peer Report Reacting Node Behavior . . . . . . . . . 13
	6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14		6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14
	6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14		6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14
	6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 14		6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 14
	6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 15		6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 15
	6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15		6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15
	6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 16		6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15
	6.3. OC-SourceID . . . . . . . . . . . . . . . . . . . . . . . 16		6.3. OC-SourceID . . . . . . . . . . . . . . . . . . . . . . . 16
	6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 16		6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 16
			7.2. New registries . . . . . . . . . . . . . . . . . . . . . 16
			8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	10. Normative References . . . . . . . . . . . . . . . . . . . . 17		10. Normative References . . . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	This document defines the behavior of Diameter nodes when Diameter		This document defines the behavior of Diameter nodes when Diameter
	agents enter an overload condition and send an overload report		agents enter an overload condition and send an overload report
	requesting a reduction of traffic. It also defines new overload		requesting a reduction of traffic. It also defines new overload
	report type, the Peer overload report type, that is used for handling		report type, the Peer overload report type, that is used for handling
	of agent overload conditions. The Peer overload report type is		of agent overload conditions. The Peer overload report type is
	defined in a generic fashion so that it can also be used for other		defined in a generic fashion so that it can also be used for other
	Diameter overload scenaios.		Diameter overload scenaios.
	The base Diameter overload specification [I-D.ietf-dime-ovli]		The base Diameter overload specification [RFC7683] addresses the
	addresses the handling of overload when a Diameter endpoint (a		handling of overload when a Diameter endpoint (a Diameter Client or
	Diameter Client or Diameter Server as defined in [RFC6733]) becomes		Diameter Server as defined in [RFC6733]) becomes overloaded.
	overloaded.
	In the base specification, the goal is to handle abatement of the		In the base specification, the goal is to handle abatement of the
	overload occurrence as close to the source of the Diameter traffic as		overload occurrence as close to the source of the Diameter traffic as
	is feasible. When possible this is done at the originator of the		is feasible. When possible this is done at the originator of the
	traffic, generally referred to as a Diameter Client. A Diameter		traffic, generally referred to as a Diameter Client. A Diameter
	Agent might also handle the overload mitigation. For instance, a		Agent might also handle the overload mitigation. For instance, a
	Diameter Agent might handle Diameter overload mitigation when it		Diameter Agent might handle Diameter overload mitigation when it
	knows that a Diameter Client does not support the DOIC extension.		knows that a Diameter Client does not support the DOIC extension.
	This document extends the base Diameter endpoint overload		This document extends the base Diameter endpoint overload
	specification to address the case when Diameter Agents become		specification to address the case when Diameter Agents become
	overloaded. Just as is the case with other Diameter nodes --		overloaded. Just as is the case with other Diameter nodes --
	Diameter Clients and Diameter Servers -- surges in Diameter traffic		Diameter Clients and Diameter Servers -- surges in Diameter traffic
	can cause a Diameter Agent to be asked to handle more Diameter		can cause a Diameter Agent to be asked to handle more Diameter
	traffic than it was configured to handle. For a more detailed		traffic than it was configured to handle. For a more detailed
	discussion of what can cause the overload of Diameter nodes, refer to		discussion of what can cause the overload of Diameter nodes, refer to
	the Diameter Overload Requirements [RFC7068].		the Diameter Overload Requirements [RFC7068].
	This document defines a new overload report type to communicate		This document defines a new overload report type to communicate
	occurrences of agent overload. This report type works for the "Loss"		occurrences of agent overload. This report type works for the "Loss"
	overload mitigation algorithm defined in [I-D.ietf-dime-ovli] and is		overload mitigation algorithm defined in [RFC7683] and is expected to
	expected to work for other overload abatement algorithms defined in		work for other overload abatement algorithms defined in extensions to
	extensions to the DOIC solution.		the DOIC solution.
	2. Terminology and Abbreviations		2. Terminology and Abbreviations
	Editors note - These definitions need to be made consistent with the
	base Diameter overload specification defined in [I-D.ietf-dime-ovli].
	Diameter Node		Diameter Node
	A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733		A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733
	Diameter Agent.		Diameter Agent.
	Diameter Endpoint		Diameter Endpoint
	An RFC6733 Diameter Client and RFC6733 Diameter Server.		An RFC6733 Diameter Client and RFC6733 Diameter Server.
	Reporting Node		Reporting Node
	skipping to change at page 4, line 14 ¶		skipping to change at page 4, line 17 ¶
	A DOIC Node that sends and overload report in a Diameter answer		A DOIC Node that sends and overload report in a Diameter answer
	message.		message.
	Reacting Node		Reacting Node
	A DOIC Node that receives and acts on a Diameter overload report.		A DOIC Node that receives and acts on a Diameter overload report.
	DIOC Node		DIOC 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].
	3. Peer Report Use Cases		3. Peer Report Use Cases
	This section outlines representative use cases for the peer report		This section outlines representative use cases for the peer report
	used to communicate agent overload.		used to communicate agent overload.
	There are two primary classes of use cases currently identified,		There are two primary classes of use cases currently identified,
	those involving the overload of agents and those involving overload		those involving the overload of agents and those involving overload
	of Diameter endpoints (Diameter Clients and Diameter Servers) that		of Diameter endpoints (Diameter Clients and Diameter Servers) that
	wish to use an overload algorithm suited controlling traffic sent		wish to use an overload algorithm suited controlling traffic sent
	skipping to change at page 5, line 22 ¶		skipping to change at page 5, line 22 ¶
	Figure 2		Figure 2
	In both of these cases, the occurrence of overload in the single		In both of these cases, the occurrence of overload in the single
	agent must by handled by the client in a similar fashion as if the		agent must by handled by the client in a similar fashion as if the
	client were handling the overload of a directly connected server.		client were handling the overload of a directly connected server.
	When the agent becomes overloaded it will insert an overload report		When the agent becomes overloaded it will insert an overload report
	in answer messages flowing to the client. This overload report will		in answer messages flowing to the client. This overload report will
	contain a requested reduction in the amount of traffic sent to the		contain a requested reduction in the amount of traffic sent to the
	agent. The client will apply overload abatement behavior as defined		agent. The client will apply overload abatement behavior as defined
	in the base Diameter overload specification [I-D.ietf-dime-ovli] or		in the base Diameter overload specification [RFC7683] or the
	the extension draft that defines the indicated overload abatement		extension draft that defines the indicated overload abatement
	algorithm. This will result in the throtting of the abated traffic		algorithm. This will result in the throtting of the abated traffic
	that would have been sent to the agent, as there is no alternative		that would have been sent to the agent, as there is no alternative
	route, with the appropriate indication given to the service request		route, with the appropriate indication given to the service request
	that resulted in the need for the Diameter transaction.		that resulted in the need for the Diameter transaction.
	3.1.2. Redundant Agents		3.1.2. Redundant Agents
	Figure 3 and Figure 4 illustrate a second, and more likely, type of		Figure 3 and Figure 4 illustrate a second, and more likely, type of
	deployment scenario involving agents. In both of these cases, the		deployment scenario involving agents. In both of these cases, the
	client has Diameter connections to two agents.		client has Diameter connections to two agents.
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 30 ¶
	mitigation logic when receiving an agent overload report from agents		mitigation logic when receiving an agent overload report from agents
	a21 and a22.		a21 and a22.
	The handling of peer overload reports is similar to that discussed in		The handling of peer overload reports is similar to that discussed in
	section 2.2. If the overload can be addressed using diversion then		section 2.2. If the overload can be addressed using diversion then
	this approach should be taken.		this approach should be taken.
	If both of the agents have requested a reduction in traffic then the		If both of the agents have requested a reduction in traffic then the
	previous hop agent must start throttling the appropriate number of		previous hop agent must start throttling the appropriate number of
	transactions. When throttling requests, an agent uses the same error		transactions. When throttling requests, an agent uses the same error
	responses as defined in the base DOIC specification		responses as defined in the base DOIC specification [RFC7683].
	[I-D.ietf-dime-ovli].
	3.2. Diameter Endpoint Use Cases		3.2. Diameter Endpoint Use Cases
	This section outlines use cases for the peer overload report		This section outlines use cases for the peer overload report
	involving Diameter Clients and Diameter Servers.		involving Diameter Clients and Diameter Servers.
	3.2.1. Hop-by-hop Abatement Algorithms		3.2.1. Hop-by-hop Abatement Algorithms
	It is envisioned that abatement algorithms will be defined that will		It is envisioned that abatement algorithms will be defined that will
	support the option for Diameter Endpoints to send peer reports. For		support the option for Diameter Endpoints to send peer reports. For
	instance, it is envisioned that one usage scenario for the rate		instance, it is envisioned that one usage scenario for the rate
	algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked		algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
	on by the DIME working group as this is written, will involve		on by the DIME working group as this document is being written, will
	abatement being done on a hop-by-hop basis.		involve abatement being done on a hop-by-hop basis.
	This rate deployment scenario would involve Diameter Endpoints		This rate deployment scenario would involve Diameter Endpoints
	generating peer reports and selecting the rate algorithm for		generating peer reports and selecting the rate algorithm for
	abatement of overload conditions.		abatement of overload conditions.
	4. Interaction Between Host/Realm and Peer Overload Reports		4. Interaction Between Host/Realm and Peer Overload Reports
	It is possible that both an agent and an end-point in the path of a		It is possible that both an agent and an end-point in the path of a
	transaction are overloaded at the same time. When this occurs,		transaction are overloaded at the same time. When this occurs,
	Diameter entities need to handle both overload reports. In this		Diameter entities need to handle both overload reports. In this
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 22 ¶
	to host or realm reports should then go through abatement for the		to host or realm reports should then go through abatement for the
	peer overload report.		peer overload report.
	5. Peer Report Behavior		5. Peer Report Behavior
	This section defines the normative behavior associated with the Peer		This section defines the normative behavior associated with the Peer
	Report extension to the DOIC solution.		Report extension to the DOIC solution.
	5.1. Capability Announcement		5.1. Capability Announcement
	Editor's Note: Issue - how does an agent indicate the selected
	abatement algorithm? It cannot use the OC-Feature-Vector in the OC-
	Supported-Features AVP as that applies to host and realm report
	types. A new AVP in the OC-Supported-Features AVP has been added.
	5.1.1. Reacting Node Behavior		5.1.1. Reacting Node Behavior
	When sending a Diameter request a DOIC node that supports the Peer		When sending a Diameter request a DOIC node that supports the
	Report feature MUST include an OC-Supported-Features AVP with an OC-		OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with
	Feature-Vector AVP with the OLR_PEER_REPORT bit set.		an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.
	Note: The sender of a request can be a Diameter Client or Diameter		Note: The sender of a request can be a Diameter Client or Diameter
	Server that originates the Diamter request or a Diameter Agent		Server that originates the Diamter request or a Diameter Agent
	that relays the request.		that relays the request.
	Support for the peer report feature does not impact the logic for		Support for the OC_PEER_REPORT feature does not impact the logic for
	setting of other feature bits in the OC-Feature-Vector AVP.		setting of other feature bits in the OC-Feature-Vector AVP.
	When sending a request a DOIC node that supports the Peer Report		When sending a request a DOIC node that supports the OC_PEER_REPORT
	feature MUST include an OC-SourceID AVP in the OC-Supported-Features		feature MUST include an OC-SourceID AVP in the OC-Supported-Features
	AVP with its own DiameterID.		AVP with its own DiameterIdentity.
	Note: This allows the DOIC nodes in the path of the request to		Note: This allows the DOIC nodes in the path of the request to
	determine if the indication of support came from a Diameter peer		determine if the indication of support came from a Diameter peer
	or if the request traversed a node that does not support the peer		or if the request traversed a node that does not support the
	feature.		OC_PEER_REPORT feature.
	When relaying a request that includes an OC-SourceID AVP in the OC-		When relaying a request that includes an OC-SourceID AVP in the OC-
	Supported-Features AVP, a DOIC node that supuports the Peer Report		Supported-Features AVP, a DOIC node that supuports the OC_PEER_REPORT
	feature must remove the received OC-SourceID AVP and replace it with		feature must remove the received OC-SourceID AVP and replace it with
	an OC-SourceID AVP containing its own Diameter identity.		an OC-SourceID AVP containing its own Diameter identity.
	5.1.2. Reporting Node Behavior		5.1.2. Reporting Node Behavior
	When receiving a request a DOIC node that supports the Peer Report		When receiving a request a DOIC node that supports the OC_PEER_REPORT
	feature MUST update transaction state with an indication of whether		feature MUST update transaction state with an indication of whether
	or not the peer from which the request was received supports the Peer		or not the peer from which the request was received supports the
	Report feature.		OC_PEER_REPORT feature.
	Note: The transaction state is used when the DOIC node is acting		Note: The transaction state is used when the DOIC node is acting
	as a peer-report reporting node and needs send OC-OLR reports of		as a peer-report reporting node and needs send OC-OLR reports of
	type PEER_REPORT in answer messages. The peer overload reports		type PEER_REPORT in answer messages. The peer overload reports
	are only included in answer messages being sent to peers that		are only included in answer messages being sent to peers that
	support the OLR_PEER_REPORT feature.		support the OC_PEER_REPORT feature.
	The following are indications that the peer does not support the		The following are indications that the peer does not support the
	OLR_PEER_REPORT feature:		OC_PEER_REPORT feature:
	The request does not contain an OC-Supported-Features AVP.		The request does not contain an OC-Supported-Features AVP.
	The received request contains an OC-Supported-Features AVP with no		The received request contains an OC-Supported-Features AVP with no
	OC-Feature-Vector.		OC-Feature-Vector.
	The received request contains an OC-Supported-Features AVP with a		The received request contains an OC-Supported-Features AVP with a
	OC-Feature-Vector with the OLR_PEER_REPORT feature bit cleared.		OC-Feature-Vector with the OC_PEER_REPORT feature bit cleared.
	The received request contains an OC-Supported-Features AVP with a		The received request contains an OC-Supported-Features AVP with a
	OC-Feature-Vector with the OLR_PEER_REPORT feature bit set but		OC-Feature-Vector with the OC_PEER_REPORT feature bit set but with
	with an OC-SourceID AVP with a DiameterID that does not match the		an OC-SourceID AVP with a DiameterIdentity that does not match the
	DiameterID of the peer from which the request was received.		DiameterIdentity of the peer from which the request was received.
	The peer supports the OLR_PEER_REPORT feature if the received request		The peer supports the OC_PEER_REPORT feature if the received request
	contains an OC-Supported-Features AVP with the OC-Feature-Vector with		contains an OC-Supported-Features AVP with the OC-Feature-Vector with
	the OLR_PEER_REPORT feature bit set and with an OC-SourceID AVP with		the OC_PEER_REPORT feature bit set and with an OC-SourceID AVP with a
	a Diameter ID that matches the DiameterID of the peer from which the		Diameter ID that matches the DiameterIdentity of the peer from which
	request was received.		the request was received.
	When relaying an answer message, a reporting node that supports the		When relaying an answer message, a reporting node that supports the
	OLR_PEER_REPORT feature MUST strip any SourceID AVP from the OC-		OC_PEER_REPORT feature MUST strip any SourceID AVP from the OC-
	Supported-Features AVP.		Supported-Features AVP.
	When sending an answer message, a reporting node that supports the		When sending an answer message, a reporting node that supports the
	OLR_PEER_REPORT feature MUST determine if the peer to which the		OC_PEER_REPORT feature MUST determine if the peer to which the answer
	answer is to be sent supports the OLR_PEER_REPORT feature.		is to be sent supports the OC_PEER_REPORT feature.
	If the peer supports the OLR_PEER_REPORT feature then the reporting		If the peer supports the OC_PEER_REPORT feature then the reporting
	node MUST indicate support for the feature in the Supported-Features		node MUST indicate support for the feature in the Supported-Features
	AVP.		AVP.
	If the peer supports the OLR_PEER_REPORT feature then the reporting		If the peer supports the OC_PEER_REPORT feature then the reporting
	node MUST insert the OC-SourceID AVP in the OC-Supported-Features AVP		node MUST insert the OC-SourceID AVP in the OC-Supported-Features AVP
	in the answer message.		in the answer message.
	If the peer supports the OLR_PEER_REPORT feature then the reporting		If the peer supports the OC_PEER_REPORT feature then the reporting
	node MUST insert the OC-Peer-Algo AVP in the OC-Supported-Features		node MUST insert the OC-Peer-Algo AVP in the OC-Supported-Features
	AVP. The OC-Peer-Algo AVP MUST indicate the overload abatement		AVP. The OC-Peer-Algo AVP MUST indicate the overload abatement
	algorithm that the reporting node wants the reacting nodes to use		algorithm that the reporting node wants the reacting nodes to use
	should the reporting node send a peer overload report as a result of		should the reporting node send a peer overload report as a result of
	becoming overloaded.		becoming overloaded.
	5.2. Peer Report Overload Report Handling		5.2. Peer Report Overload Report Handling
	This section defines the behavior for the handling of overload		This section defines the behavior for the handling of overload
	reports of type peer.		reports of type peer.
	5.2.1. Overload Control State		5.2.1. Overload Control State
	This section describes the Overload Control State (OCS) that might be		This section describes the Overload Control State (OCS) that might be
	maintained by both the peer report reporting node and the peer report		maintained by both the peer report reporting node and the peer report
	reacting node.		reacting node.
	5.2.1.1. Reporting Node Peer Report OCS		5.2.1.1. Reporting Node Peer Report OCS
	A DOIC Node that supports the Peer Report feature SHOULD maintain		A DOIC Node that supports the OC_PEER_REPORT feature SHOULD maintain
	Reporting Node Peer Report OCS. This is used to record overload		Reporting Node Peer Report OCS. This is used to record overload
	events and build overload reports at the reporting node.		events and build overload reports at the reporting node.
	If different abatement specific contents are sent to each peer then		If different abatement specific contents are sent to each peer then
	the reporting node MUST maintain a separate peer node peer report OCS		the reporting node MUST maintain a separate peer node peer report OCS
	entry per peer to which a peer overload report is sent.		entry per peer to which a peer overload report is sent.
	Note: The rate overload abatement algorithm allows for different		Note: The rate overload abatement algorithm allows for different
	rates to be sent to each peer.		rates to be sent to each peer.
	skipping to change at page 11, line 9 ¶		skipping to change at page 11, line 9 ¶
	o Validity Duration		o Validity Duration
	o Expiration Time		o Expiration Time
	o Abatement Algorithm		o Abatement Algorithm
	o Algorithm specific input data (for example, the Reduction		o Algorithm specific input data (for example, the Reduction
	Percentage for the Loss Abatement Algorithm)		Percentage for the Loss Abatement Algorithm)
	5.2.1.2. Reacting Node Peer Report OCS		5.2.1.2. Reacting Node Peer Report OCS
	A DOIC node that supports the Peer Report feature SHOULD maintain		A DOIC node that supports the OC_PEER_REPORT feature SHOULD maintain
	Reacting Node Peer Report OCS for each peer with which it		Reacting Node Peer Report OCS for each peer with which it
	communicates. This is used to record overload reports received from		communicates. This is used to record overload reports received from
	peer nodes.		peer nodes.
	A Reacting Node Peer Report OCS entry is identified by the DiameterID		A Reacting Node Peer Report OCS entry is identified by the
	of the peer as communicated during the RFC6733 defined Capability		DiameterIdentity of the peer as communicated during the RFC6733
	Exchange procedure.		defined Capability Exchange procedure.
	The Reacting Node Peer Report OCS entry MAY include the following		The Reacting Node Peer Report OCS entry MAY include the following
	information (the actual information stored is an implementation		information (the actual information stored is an implementation
	decision):		decision):
	o Sequence number		o Sequence number
	o Expiration Time		o Expiration Time
	o Abatement Algorithm		o Abatement Algorithm
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 38 ¶
	o Algorithm specific input data (for example, the Reduction		o Algorithm specific input data (for example, the Reduction
	Percentage for the Loss Abatement Algorithm)		Percentage for the Loss Abatement Algorithm)
	5.2.2. Reporting Node Maintenance of Peer Report OCS		5.2.2. Reporting Node Maintenance of Peer Report OCS
	A reporting node SHOULD create a new Reporting Node Peer Report OCS		A reporting node SHOULD create a new Reporting Node Peer Report OCS
	entry Section 5.2.1.1 in an overload condition and sending a peer		entry Section 5.2.1.1 in an overload condition and sending a peer
	overload report to a peer for the first time.		overload report to a peer for the first time.
	If the reporting node knows that there are no reacting nodes		If the reporting node knows that there are no reacting nodes
	supporting the Peer Report feature then the reporting node can		supporting the OC_PEER_REPORT feature then the reporting node can
	choose to not create OCS entries.		choose to not create OCS entries.
	All rules for managing the reporting node OCS entries defined in		All rules for managing the reporting node OCS entries defined in
	[I-D.ietf-dime-ovli] apply to the peer report.		[RFC7683] apply to the peer report.
	5.2.3. Reacting Node Maintenance of Peer Report OCS		5.2.3. Reacting Node Maintenance of Peer Report OCS
	When a reacting node receives an OC-OLR AVP with a report type of		When a reacting node receives an OC-OLR AVP with a report type of
	peer it MUST determine if the report was generated by the Diameter		peer it MUST determine if the report was generated by the Diameter
	peer from which the report was received.		peer from which the report was received.
	If the DiameterID in the SourceID contained in the OLR matches the		If the DiameterID in the SourceID contained in the OLR matches the
	DiameterID of the peer from which the request was received then the		DiameterIdentity of the peer from which the request was received then
	report was received from a Diameter peer.		the report was received from a Diameter peer.
	If a reacting node receives an OC-OLR AVP of type peer and the OC-		If a reacting node receives an OC-OLR AVP of type peer and the OC-
	SourceID does not match the ID of the Diameter peer from which the		SourceID does not match the ID of the Diameter peer from which the
	request was received then the reacting node MUST ignore the overload		request was received then the reacting node MUST ignore the overload
	report.		report.
	In all cases, if the reacting node is a relay then it MUST strip the		In all cases, if the reacting node is a relay then it MUST strip the
	OC-OLR AVP from the message.		OC-OLR AVP from the message.
	If the Peer Report OLR was received from a Diameter peer then the		If the Peer Report OLR was received from a Diameter peer then the
	reacting node MUST determine if it is for an existing or new overload		reacting node MUST determine if it is for an existing or new overload
	condition.		condition.
	The OLR is for an existing overload condition if the reacting node		The OLR is for an existing overload condition if the reacting node
	has an OCS that matches the received OLR. For a peer report-type		has an OCS that matches the received OLR. For a peer report-type
	this means the DiameterID received in the SourceID AVP matches the		this means the DiameterIdentity received in the SourceID AVP matches
	DiameterID of an existing peer report OLR.		the DiameterIdentity of an existing peer report OLR.
	If the OLR is for an existing overload condition then it MUST		If the OLR is for an existing overload condition then it MUST
	determine if the OLR is a retransmission or an update to the existing		determine if the OLR is a retransmission or an update to the existing
	OLR.		OLR.
	If the sequence number for the received OLR is greater than the		If the sequence number for the received OLR is greater than the
	sequence number stored in the matching OCS entry then the reacting		sequence number stored in the matching OCS entry then the reacting
	node MUST update the matching OCS entry.		node MUST update the matching OCS entry.
	If the sequence number for the received OLR is less than or equal to		If the sequence number for the received OLR is less than or equal to
	skipping to change at page 13, line 14 ¶		skipping to change at page 13, line 14 ¶
	The reacting node sets the abatement algorithm based on the OC-Peer-		The reacting node sets the abatement algorithm based on the OC-Peer-
	Algo AVP in the received OC-Supported-Features AVP.		Algo AVP in the received OC-Supported-Features AVP.
	5.2.4. Peer Report Reporting Node Behavior		5.2.4. Peer Report Reporting Node Behavior
	When there is an existing reporting node peer report OCS entry, the		When there is an existing reporting node peer report OCS entry, the
	reporting node MUST include an OC-OLR AVP with a report type of peer		reporting node MUST include an OC-OLR AVP with a report type of peer
	using the contents of the reporting node peer report OCS entry in all		using the contents of the reporting node peer report OCS entry in all
	answer messages sent by the reporting node to peers that support the		answer messages sent by the reporting node to peers that support the
	peer report feature.		OC_PEER_REPORT feature.
	The reporting node determines if a peer supports the peer report		The reporting node determines if a peer supports the
	feature based on the indication recorded in the reporting nodes		OC_PEER_REPORT feature based on the indication recorded in the
	transaction state.		reporting nodes transaction state.
	The reporting node MUST include its DiameterID in the OC-SourceID AVP		The reporting node MUST include its DiameterIdentity in the OC-
	in the OC-OLR AVP. This is used by DOIC nodes that support the peer		SourceID AVP in the OC-OLR AVP. This is used by DOIC nodes that
	report feature to determine if the report was received from a		support the OC_PEER_REPORT feature to determine if the report was
	Diameter peer.		received from a Diameter peer.
	The reporting agent must follow all other overload reporting node		The reporting agent must follow all other overload reporting node
	behaviors outlined in the DOIC specification.		behaviors outlined in the DOIC specification.
	5.2.5. Peer Report Reacting Node Behavior		5.2.5. Peer Report Reacting Node Behavior
	A reacting node supporting this extension MUST support the receipt of		A reacting node supporting this extension MUST support the receipt of
	multiple overload reports in a single message. The message might		multiple overload reports in a single message. The message might
	include a host overload report, a realm overload report and/or a peer		include a host overload report, a realm overload report and/or a peer
	overload report.		overload report.
	skipping to change at page 13, line 52 ¶		skipping to change at page 13, line 52 ¶
	For peer overload reports, the preferred abatement treatment is		For peer overload reports, the preferred abatement treatment is
	diversion. As such, the reacting node SHOULD attempt to divert		diversion. As such, the reacting node SHOULD attempt to divert
	requests identified as needing abatement to other peers.		requests identified as needing abatement to other peers.
	If there is not sufficient capacity to divert abated traffic then the		If there is not sufficient capacity to divert abated traffic then the
	reacting node MUST throttle the necessary requests to fit within the		reacting node MUST throttle the necessary requests to fit within the
	available capacity of the peers able to handle the requests.		available capacity of the peers able to handle the requests.
	If the abatement treatment results in throttling of the request and		If the abatement treatment results in throttling of the request and
	if the reacting node is an agent then the agent MUST send an		if the reacting node is an agent then the agent MUST send an
	appropriate error as defined in [I-D.ietf-dime-ovli].		appropriate error as defined in [RFC7683].
	In the case that the OCS entry validity duration expires or has a		In the case that the OCS entry validity duration expires or has a
	validity duration of zero ("0"), meaning that it the reporting node		validity duration of zero ("0"), meaning that it the reporting node
	has explicitly signaled the end of the overload condition then		has explicitly signaled the end of the overload condition then
	abatement associated with the overload abatement MUST be ended in a		abatement associated with the overload abatement MUST be ended in a
	controlled fashion.		controlled fashion.
	6. Peer Report AVPs		6. Peer Report AVPs
	6.1. OC-Supported-Features AVP		6.1. OC-Supported-Features AVP
	This extension adds a new feature to the OC-Feature-Vector AVP. This		This extension adds a new feature to the OC-Feature-Vector AVP. This
	feature indication shows support for handling of peer overload		feature indication shows support for handling of peer overload
	reports. Peer overload reports are used by agents to indicate the		reports. Peer overload reports are used by agents to indicate the
	need for overload abatement handling by the agents peer.		need for overload abatement handling by the agents peer.
	A supporting node must also include the OC-SourceID AVP in the OC-		A supporting node must also include the OC-SourceID AVP in the OC-
	Supported-Features capability AVP.		Supported-Features capability AVP.
	This AVP contains the Diameter Identity of the node that supports the		This AVP contains the Diameter Identity of the node that supports the
	OLR_PEER_REPORT feature. This AVP is used to determine if support		OC_PEER_REPORT feature. This AVP is used to determine if support for
	for the peer overload report is in an adjacent node. The value of		the peer overload report is in an adjacent node. The value of this
	this AVP should be the same Diameter identity used as part of the		AVP should be the same Diameter identity used as part of the CER/CEA
	CER/CEA base Diameter capabilities exchange.		base Diameter capabilities exchange.
	This extension also adds the OC-Peer-Algo AVP to the OC-Supported-		This extension also adds the OC-Peer-Algo AVP to the OC-Supported-
	Features AVP. This AVP is used by a reporting node to indicate the		Features AVP. This AVP is used by a reporting node to indicate the
	abatement algorithm it will use for peer overload reports.		abatement algorithm it will use for peer overload reports.
	OC-Supported-Features ::= < AVP Header: TBD1 >		OC-Supported-Features ::= < AVP Header: TBD1 >
	[ OC-Feature-Vector ]		[ OC-Feature-Vector ]
	[ OC-SourceID ]		[ OC-SourceID ]
	[ OC-Peer-Algo]		[ OC-Peer-Algo]
	* [ AVP ]		* [ AVP ]
	6.1.1. OC-Feature-Vector		6.1.1. OC-Feature-Vector
	The peer report feature defines a new feature bit is added for the		The peer report feature defines a new feature bit is added for the
	OC-Feature-Vector AVP.		OC-Feature-Vector AVP.
	OLR_PEER_REPORT (0x0000000000000010)		OC_PEER_REPORT (0x0000000000000010)
	When this flag is set by a DOIC node it indicates that the DOIC		When this flag is set by a DOIC node it indicates that the DOIC
	node supports the peer overload report type.		node supports the peer overload report type.
	6.1.2. OC-Peer-Algo		6.1.2. OC-Peer-Algo
	The OC-Peer-Algo AVP (AVP code TBD1) is of type Unsigned64 and		The OC-Peer-Algo AVP (AVP code TBD1) is of type Unsigned64 and
	contains a 64 bit flags field of announced capabilities of a DOIC		contains a 64 bit flags field of announced capabilities of a DOIC
	node. The value of zero (0) is reserved.		node. The value of zero (0) is reserved.
	Feature bits defined for the OC-Feature-Vector AVP and associated		Feature bits defined for the OC-Feature-Vector AVP and associated
	with overload abatement algorithms are reused in for this AVP.		with overload abatement algorithms are reused in for this AVP.
	Editor's node: This is to avoid the need for an additional IANA
	registry.
	6.2. OC-OLR AVP		6.2. OC-OLR AVP
	This extension makes no changes to the SequenceNumber or		This extension makes no changes to the SequenceNumber or
	ValidityDuration AVPs in the OC-OLR AVP. These AVPs are also be used		ValidityDuration AVPs in the OC-OLR AVP. These AVPs are also be used
	in peer overload reports.		in peer overload reports.
	The peer report feature extends the base Diameter overload		The OC_PEER_REPORT feature extends the base Diameter overload
	specification by defining a new overload report type of "peer". See		specification by defining a new overload report type of "peer". See
	section [7.6] in [I-D.ietf-dime-ovli] for a description of the OC-		section [7.6] in [RFC7683] for a description of the OC-Report-Type
	Report-Type AVP.		AVP.
	The overload report must also include the Diameter identity of the		The overload report must also include the Diameter identity of the
	agent that generated the report. This is necessary to handle the		agent that generated the report. This is necessary to handle the
	case where there is a non supporting agent between the reporting node		case where there is a non supporting agent between the reporting node
	and the reacting node. Without the indication of the agent that		and the reacting node. Without the indication of the agent that
	generated the overload request, the reacting node could erroneously		generated the overload request, the reacting node could erroneously
	assume that the report applied to the non supporting node. This		assume that the report applied to the non supporting node. This
	could, in turn, result in unnecessary traffic being either		could, in turn, result in unnecessary traffic being either
	redistributed or throttled.		redistributed or throttled.
	The OC-SourceID AVP is used in the OC-OLR AVP to carry this		The OC-SourceID AVP is used in the OC-OLR AVP to carry this
	DiameterID.		DiameterIdentity.
	OC-OLR ::= < AVP Header: TBD2 >		OC-OLR ::= < AVP Header: TBD2 >
	< OC-Sequence-Number >		< OC-Sequence-Number >
	< OC-Report-Type >		< OC-Report-Type >
	[ OC-Reduction-Percentage ]		[ OC-Reduction-Percentage ]
	[ OC-Validity-Duration ]		[ OC-Validity-Duration ]
	[ OC-Source-ID ]		[ OC-Source-ID ]
	* [ AVP ]		* [ AVP ]
	6.2.1. OC-Report-Type AVP		6.2.1. OC-Report-Type AVP
	skipping to change at page 16, line 35 ¶		skipping to change at page 16, line 27 ¶
	6.4. Attribute Value Pair flag rules		6.4. 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-SourceID TBD1 x.x Unsigned64 | | V |		|OC-SourceID TBD1 x.x DiameterIdentity | | V |
	|OC-Peer-Algo TBD2 x.x Unsigned64 | | V |		|OC-Peer-Algo TBD2 x.x Unsigned64 | | V |
	+--------------------------------------------------------+----+----+		+--------------------------------------------------------+----+----+
	7. IANA Considerations		7. IANA Considerations
	Editors note: This section will be completed once the base overload		7.1. AVP codes
	document has finished the definition of extension IANA requirements.
			New AVPs defined by this specification are listed in Section 6. All
			AVP codes are allocated from the 'Authentication, Authorization, and
			Accounting (AAA) Parameters' AVP Codes registry.
			7.2. New registries
			There are no new IANA registries introduced by this document.
			The values used for the OC-Peer-Algo AVP are the subset of the "OC-
			Feature-Vector AVP Values (code 622)" registry. Only the values in
			that registry that apply to overload abatement algorithms apply to
			the OC-Peer-Algo AVP.
	8. Security Considerations		8. Security Considerations
	Agent overload is an extension to the base Diameter overload		Agent overload is an extension to the base Diameter overload
	mechanism. As such, all of the security considerations outlined in		mechanism. As such, all of the security considerations outlined in
	[I-D.ietf-dime-ovli] apply to the agent overload scenarios.		[RFC7683] apply to the agent overload scenarios.
	It is possible that the malicious insertion of an agent overload		It is possible that the malicious insertion of an agent overload
	report could have a bigger impact on a Diameter network as agents can		report could have a bigger impact on a Diameter network as agents can
	be concentration points in a Diameter network. Where an end-point		be concentration points in a Diameter network. Where an end-point
	report would impact the traffic sent to a single Diameter server, for		report would impact the traffic sent to a single Diameter server, for
	example, a peer report could throttle all traffic to the Diameter		example, a peer report could throttle all traffic to the Diameter
	network.		network.
	This impact is amplified in an agent that sits at the edge of a		This impact is amplified in an agent that sits at the edge of a
	Diameter network that serves as the entry point from all other		Diameter network that serves as the entry point from all other
	skipping to change at page 17, line 32 ¶		skipping to change at page 17, line 38 ¶
	Ben Campbell for his insights and review of early versions of this		Ben Campbell for his insights and review of early versions of this
	document.		document.
	10. Normative References		10. Normative References
	[I-D.ietf-dime-doic-rate-control]		[I-D.ietf-dime-doic-rate-control]
	Donovan, S. and E. Noel, "Diameter Overload Rate Control",		Donovan, S. and E. Noel, "Diameter Overload Rate Control",
	draft-ietf-dime-doic-rate-control-01 (work in progress),		draft-ietf-dime-doic-rate-control-01 (work in progress),
	March 2015.		March 2015.
	[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>.
	[RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control		[RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control
	Requirements", RFC 7068, DOI 10.17487/RFC7068, November		Requirements", RFC 7068, DOI 10.17487/RFC7068, November
	2013, <http://www.rfc-editor.org/info/rfc7068>.		2013, <http://www.rfc-editor.org/info/rfc7068>.
			[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>.
	Author's Address		Author's Address
	Steve Donovan		Steve Donovan
	Oracle		Oracle
	7460 Warren Parkway, Suite 300		7460 Warren Parkway, Suite 300
	Frisco, Texas 75034		Frisco, Texas 75034
	United States		United States
	Email: srdonovan@usdonovans.com		Email: srdonovan@usdonovans.com
End of changes. 57 change blocks.
	102 lines changed or deleted		103 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/