draft-ietf-dime-agent-overload-10.txt		draft-ietf-dime-agent-overload-11.txt
	Diameter Maintenance and Extensions (DIME) S. Donovan		Diameter Maintenance and Extensions (DIME) S. Donovan
	Internet-Draft Oracle		Internet-Draft Oracle
	Updates: RFC7683 (if approved) March 7, 2017		Updates: RFC7683 (if approved) March 22, 2017
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 8, 2017		Expires: September 23, 2017
	Diameter Agent Overload and the Peer Overload Report		Diameter Agent Overload and the Peer Overload Report
	draft-ietf-dime-agent-overload-10.txt		draft-ietf-dime-agent-overload-11.txt
	Abstract		Abstract
	This specification documents an extension to RFC 7683 (Diameter		This specification documents an extension to RFC 7683 (Diameter
	Overload Indication Conveyance (DOIC)) base solution. The extension		Overload Indication Conveyance (DOIC)) base solution. The extension
	defines the Peer overload report type. The initial use case for the		defines the Peer overload report type. The initial use case for the
	Peer 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
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 September 8, 2017.		This Internet-Draft will expire on September 23, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 5
	3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 5		3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6
	3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7		3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7
	3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 7		3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 8
	3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8		3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8
	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
	5.1. Capability Announcement . . . . . . . . . . . . . . . . . 8		5.1. Capability Announcement . . . . . . . . . . . . . . . . . 9
	5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 8		5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 9
	5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9		5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9
	5.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10		5.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10
	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 . . . . . . . . . 12		5.2.4. Peer-Report Reporting Node Behavior . . . . . . . . . 12
	5.2.5. Peer-Report Reacting Node Behavior . . . . . . . . . 12		5.2.5. Peer-Report Reacting Node Behavior . . . . . . . . . 13
	6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 13		6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14
	6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 13		6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14
	6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 14		6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 14
	6.1.2. OC-Peer-Algo AVP . . . . . . . . . . . . . . . . . . 14		6.1.2. OC-Peer-Algo AVP . . . . . . . . . . . . . . . . . . 14
	6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14		6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15
	6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15		6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15
	6.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15		6.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15
	6.4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 15		6.4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
	7.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16		7.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.2. New Registries . . . . . . . . . . . . . . . . . . . . . 16		7.2. New Registries . . . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Informative References . . . . . . . . . . . . . . . . . 17		10.1. Informative References . . . . . . . . . . . . . . . . . 17
	10.2. Normative References . . . . . . . . . . . . . . . . . . 17		10.2. Normative References . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	This specification documents an extension to the Diameter Overload		This specification documents an extension to the Diameter Overload
	Indication Conveyance (DOIC) [RFC7683] base solution. The extension		Indication Conveyance (DOIC) [RFC7683] base solution. The extension
	defines the Peer overload report type. The initial use case for the		defines the Peer overload report type. The initial use case for the
	Peer 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.
	This document defines the behavior of Diameter nodes when Diameter		This document defines the behavior of Diameter nodes when Diameter
	skipping to change at page 3, line 50 ¶		skipping to change at page 3, line 50 ¶
	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 [RFC7683] and is expected to		overload mitigation algorithm defined in [RFC7683] and is expected to
	work for other overload abatement algorithms defined in extensions to		work for other overload abatement algorithms defined in extensions to
	the DOIC solution.		the DOIC solution.
	2. Terminology and Abbreviations		2. Terminology and Abbreviations
			AVP
			Attribute Value Pair
	Diameter Node		Diameter Node
	A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733
	Diameter Agent.		A [RFC7683] Diameter Client, an [RFC7683] Diameter Server, and
			[RFC7683] Diameter Agent.
	Diameter Endpoint		Diameter Endpoint
	An RFC6733 Diameter Client and RFC6733 Diameter Server.		An [RFC7683] Diameter Client and [RFC7683] Diameter Server.
	Diameter Agent		Diameter Agent
	An RFC6733 Diameter Agent.		An [RFC7683] Diameter Agent.
	Reporting Node		Reporting Node
	A DOIC Node that sends an overload report in a Diameter answer		A DOIC Node that sends an overload report in a Diameter answer
	message.		message.
	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.
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 46 ¶
	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. In both cases the goal is to use an overload		of Diameter endpoints. In both cases the goal is to use an overload
	algorithm that controls traffic sent towards peers.		algorithm that controls traffic sent towards peers.
	3.1. Diameter Agent Overload Use Cases		3.1. Diameter Agent Overload Use Cases
	The peer report needs to support the following use cases.		The peer report needs to support the following use cases.
			In the figures in this section, elements labeled "c" are Diameter
			Clients, elements labeled "a" are Diameter Agents and elements
			labeled "s" are Diameter Servers.
	3.1.1. Single Agent		3.1.1. Single Agent
	This use case is illustrated in Figure 1. In this case, the client		This use case is illustrated in Figure 1. In this case, the client
	sends all traffic through the single agent. If there is a failure in		sends all traffic through the single agent. If there is a failure in
	the agent then the client is unable to send Diameter traffic toward		the agent then the client is unable to send Diameter traffic toward
	the server.		the server.
	+-+ +-+ +-+		+-+ +-+ +-+
	|c|----|a|----|s|		|c|----|a|----|s|
	+-+ +-+ +-+		+-+ +-+ +-+
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 42 ¶
	+--+ +-+		+--+ +-+
	--|a1|---|s|		--|a1|---|s|
	+-+ / +--+\ /+-+		+-+ / +--+\ /+-+
	|c|- x		|c|- x
	+-+ \ +--+/ \+-+		+-+ \ +--+/ \+-+
	--|a2|---|s|		--|a2|---|s|
	+--+ +-+		+--+ +-+
	Figure 4		Figure 4
	In the case where one of the agents in the above scenario becomes		In the case where one of the agents in the above scenarios become
	overloaded, the client should reduce the amount of traffic sent to		overloaded, the client should reduce the amount of traffic sent to
	the overloaded agent by the amount requested. This traffic should		the overloaded agent by the amount requested. This traffic should
	instead be routed through the non-overloaded agent. For example,		instead be routed through the non-overloaded agent. For example,
	assume that the overloaded agent requests a reduction of 10 percent.		assume that the overloaded agent requests a reduction of 10 percent.
	The client should send 10 percent of the traffic that would have been		The client should send 10 percent of the traffic that would have been
	routed to the overloaded agent through the non-overloaded agent.		routed to the overloaded agent through the non-overloaded agent.
	When the client has an active and a standby connection to the two		When the client has an active and a standby connection to the two
	agents then an alternative strategy for responding to an overload		agents then an alternative strategy for responding to an overload
	report from an agent is to change the standby connection to active		report from an agent is to change the standby connection to active.
	and route all traffic through the new active connection.		This will result in all traffic being routed through the new active
			connection.
	In the case where both agents are reporting overload, the client may		In the case where both agents are reporting overload, the client may
	need to start decreasing the total traffic sent to the agents. This		need to start decreasing the total traffic sent to the agents. This
	would be done in a similar fashion as discussed in Section 3.1.1 The		would be done in a similar fashion as discussed in Section 3.1.1 The
	amount of traffic depends on the combined reduction requested by the		amount of traffic depends on the combined reduction requested by the
	two agents.		two agents.
	3.1.3. Agent Chains		3.1.3. Agent Chains
	There are also deployment scenarios where there can be multiple		There are also deployment scenarios where there can be multiple
	skipping to change at page 17, line 5 ¶		skipping to change at page 17, line 16 ¶
	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
	Diameter networks.		Diameter networks.
			The impacts of this attack, as well as the mitigation strategies, are
			the same as outlined in [RFC7683].
	9. Acknowledgements		9. Acknowledgements
	Adam Roach and Eric McMurry for the work done in defining a		Adam Roach and Eric McMurry for the work done in defining a
	comprehensive Diameter overload solution in draft-roach-dime-		comprehensive Diameter overload solution in draft-roach-dime-
	overload-ctrl-03.txt.		overload-ctrl-03.txt.
	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. References		10. References
End of changes. 19 change blocks.
	22 lines changed or deleted		35 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/