< draft-ietf-dime-overload-reqs-03.txt		draft-ietf-dime-overload-reqs-04.txt >
	Network Working Group E. McMurry		Network Working Group E. McMurry
	Internet-Draft B. Campbell		Internet-Draft B. Campbell
	Intended status: Standards Track Tekelec		Intended status: Standards Track Tekelec
	Expires: July 19, 2013 January 15, 2013		Expires: August 26, 2013 February 22, 2013
	Diameter Overload Control Requirements		Diameter Overload Control Requirements
	draft-ietf-dime-overload-reqs-03		draft-ietf-dime-overload-reqs-04
	Abstract		Abstract
	When a Diameter server or agent becomes overloaded, it needs to be		When a Diameter server or agent becomes overloaded, it needs to be
	able to gracefully reduce its load, typically by informing clients to		able to gracefully reduce its load, typically by informing clients to
	reduce sending traffic for some period of time. Otherwise, it must		reduce sending traffic for some period of time. Otherwise, it must
	continue to expend resources parsing and responding to Diameter		continue to expend resources parsing and responding to Diameter
	messages, possibly resulting in congestion collapse. The existing		messages, possibly resulting in congestion collapse. The existing
	Diameter mechanisms, listed in Section 3 are not sufficient for this		Diameter mechanisms, listed in Section 3 are not sufficient for this
	purpose. This document describes the limitations of the existing		purpose. This document describes the limitations of the existing
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 July 19, 2013.		This Internet-Draft will expire on August 26, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 30 ¶		skipping to change at page 2, line 30 ¶
	2.3. Interconnect Scenario . . . . . . . . . . . . . . . . . . 12		2.3. Interconnect Scenario . . . . . . . . . . . . . . . . . . 12
	3. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 13		3. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 13
	4. Issues with the Current Mechanisms . . . . . . . . . . . . . . 14		4. Issues with the Current Mechanisms . . . . . . . . . . . . . . 14
	4.1. Problems with Implicit Mechanism . . . . . . . . . . . . . 15		4.1. Problems with Implicit Mechanism . . . . . . . . . . . . . 15
	4.2. Problems with Explicit Mechanisms . . . . . . . . . . . . 15		4.2. Problems with Explicit Mechanisms . . . . . . . . . . . . 15
	5. Diameter Overload Case Studies . . . . . . . . . . . . . . . . 16		5. Diameter Overload Case Studies . . . . . . . . . . . . . . . . 16
	5.1. Overload in Mobile Data Networks . . . . . . . . . . . . . 16		5.1. Overload in Mobile Data Networks . . . . . . . . . . . . . 16
	5.2. 3GPP Study on Core Network Overload . . . . . . . . . . . 17		5.2. 3GPP Study on Core Network Overload . . . . . . . . . . . 17
	6. Extensibility and Application Independence . . . . . . . . . . 18		6. Extensibility and Application Independence . . . . . . . . . . 18
	7. Solution Requirements . . . . . . . . . . . . . . . . . . . . 19		7. Solution Requirements . . . . . . . . . . . . . . . . . . . . 19
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 24		9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	9.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 24		9.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 24
	9.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 24		9.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 24
	9.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 25		9.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 24
	9.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 25		9.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 25
	9.5. Compromised Hosts . . . . . . . . . . . . . . . . . . . . 25		9.5. Compromised Hosts . . . . . . . . . . . . . . . . . . . . 25
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 26		10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
	10.2. Informative References . . . . . . . . . . . . . . . . . . 26		10.2. Informative References . . . . . . . . . . . . . . . . . . 26
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 27		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 27		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	When a Diameter [RFC6733] server or agent becomes overloaded, it		When a Diameter [RFC6733] server or agent becomes overloaded, it
	needs to be able to gracefully reduce its load, typically by		needs to be able to gracefully reduce its load, typically by
	informing clients to reduce sending traffic for some period of time.		informing clients to reduce sending traffic for some period of time.
	Otherwise, it must continue to expend resources parsing and		Otherwise, it must continue to expend resources parsing and
	responding to Diameter messages, possibly resulting in congestion		responding to Diameter messages, possibly resulting in congestion
	collapse. The existing mechanisms provided by Diameter are not		collapse. The existing mechanisms provided by Diameter are not
	sufficient for this purpose. This document describes the limitations		sufficient for this purpose. This document describes the limitations
	of the existing mechanisms, and provides requirements for new		of the existing mechanisms, and provides requirements for new
	overload management mechanisms.		overload management mechanisms.
	This document draws on the work done on SIP overload control		This document draws on the work done on SIP overload control
	([RFC5390], [RFC6357]) as well as on experience gained via overload		([RFC5390], [RFC6357]) as well as on experience gained via overload
	handling in Signaling System No. 7 (SS7) networks and studies done by		handling in Signaling System No. 7 (SS7) networks and studies done by
	the Third Generation Partnersip Project (3GPP) (Section 5).		the Third Generation Partnership Project (3GPP) (Section 5).
	Diameter is not typically an end-user protocol; rather it is		Diameter is not typically an end-user protocol; rather it is
	generally used as one component in support of some end-user activity.		generally used as one component in support of some end-user activity.
	For example, a SIP server might use Diameter to authenticate and		For example, a SIP server might use Diameter to authenticate and
	authorize user access. Overload in the Diameter backend		authorize user access. Overload in the Diameter backend
	infrastructure will likely impact the experience observed by the end		infrastructure will likely impact the experience observed by the end
	user in the SIP application.		user in the SIP application.
	The impact of Diameter overload on the client application (a client		The impact of Diameter overload on the client application (a client
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	server 1, but should not divert any application B requests. This		server 1, but should not divert any application B requests. This
	requires server 2 to be able to distinguish between applications when		requires server 2 to be able to distinguish between applications when
	it indicates an overload condition to the client.		it indicates an overload condition to the client.
	On the other hand, it's possible that the servers host many		On the other hand, it's possible that the servers host many
	applications. If server 2 becomes overloaded for all applications,		applications. If server 2 becomes overloaded for all applications,
	it would be undesirable for it to have to notify the client		it would be undesirable for it to have to notify the client
	separately for each application. Therefore it also needs a way to		separately for each application. Therefore it also needs a way to
	indicate that it is overloaded for all possible applications.		indicate that it is overloaded for all possible applications.
	+----------------------------------------------+		+---------------------------------------------+
	| Application A +------------------------+----------------------+		| Application A +----------------------+----------------------+
	|+------------------+ | +------------------+ | +------------------+|		|+------------------+ | +----------------+ | +------------------+|
	|| | | | | | | ||		|| | | | | | | ||
	|| | | | | | | ||		|| | | | | | | ||
	|| Server 1 | | | Server 2 | | | Server 3 ||		|| Server 1 | | | Server 2 | | | Server 3 ||
	|| | | | | | | ||		|| | | | | | | ||
	|+--------+---------+ | +--------+---------+ | +-+----------------+|		|+--------+---------+ | +-------+--------+ | +-+----------------+|
	| | | | | | |		| | | | | | |
	+---------+-----------+-----------+------------+ | |		+---------+-----------+----------+-----------+ | |
	| | | | |		| | | | |
	| | | | Application B |		| | | | Application B |
	| +-----------+-----------------+-----------------+		| +----------+----------------+-----------------+
	``-.._ | |		``-.._ | |
	`-..__ | _.-''		`-..__ | _.-''
	`--._ | _.-''		`--._ | _.-''
	``-.__ | _.-''		``-._ | _.-''
	+------`-.-''------+		+-----`-.-''-----+
	| |		| |
	| |		| |
	| Client |		| Client |
	| |		| |
	+------------------+		+----------------+
	Figure 3: Multiple Application Peer to Peer Scenario		Figure 3: Multiple Application Peer to Peer Scenario
	2.2. Agent Scenarios		2.2. Agent Scenarios
	This section describes scenarios that include a Diameter agent,		This section describes scenarios that include a Diameter agent,
	either in the form of a Diameter relay or Diameter proxy. These		either in the form of a Diameter relay or Diameter proxy. These
	scenarios do not consider Diameter redirect agents, since they are		scenarios do not consider Diameter redirect agents, since they are
	more readily modeled as end-servers.		more readily modeled as end-servers.
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	Figure 5: Multiple Server Agent Scenario		Figure 5: Multiple Server Agent Scenario
	Figure 6 shows a scenario where an agent routes requests to a set of		Figure 6 shows a scenario where an agent routes requests to a set of
	servers for more than one Diameter realm and application. In this		servers for more than one Diameter realm and application. In this
	scenario, if server 1 becomes overloaded or unavailable, the agent		scenario, if server 1 becomes overloaded or unavailable, the agent
	may effectively operate at reduced capacity for application A, but at		may effectively operate at reduced capacity for application A, but at
	full capacity for application B. Therefore, the agent needs to be		full capacity for application B. Therefore, the agent needs to be
	able to report that it is overloaded for one application, but not for		able to report that it is overloaded for one application, but not for
	another.		another.
	+----------------------------------------------+		+--------------------------------------------+
	| Application A +------------------------+----------------------+		| Application A +----------------------+----------------------+
	|+------------------+ | +------------------+ | +------------------+|		|+------------------+ | +----------------+ | +------------------+|
	|| | | | | | | ||		|| | | | | | | ||
	|| | | | | | | ||		|| | | | | | | ||
	|| Server 1 | | | Server 2 | | | Server 3 ||		|| Server 1 | | | Server 2 | | | Server 3 ||
	|| | | | | | | ||		|| | | | | | | ||
	|+---------+--------+ | +--------+---------+ | +--+---------------+|		|+---------+--------+ | +-------+--------+ | +--+---------------+|
	| | | | | | |		| | | | | | |
	+----------+----------+-----------+------------+ | |		+----------+----------+----------+-----------+ | |
	| | | | |		| | | | |
	| | | | Application B |		| | | | Application B |
	| +-----------+------------------+----------------+		| +----------+-----------------+----------------+
	| | |		| | |
	``--.__ | _.		``--.__ | _.
	``-.__ | __.--''		``-.__ | __.--''
	`--.._ | _..--'		`--.._ | _..--'
	+-----``-+.-''-----+		+----``-+.''-----+
	| |		| |
	| |		| |
	| Agent |		| Agent |
	| |		| |
	+--------+---------+		+-------+--------+
	|		|
	|		|
	+--------+---------+		+-------+--------+
	| |		| |
	| |		| |
	| Client |		| Client |
	| |		| |
	+------------------+		+----------------+
	Figure 6: Multiple Application Agent Scenario		Figure 6: Multiple Application Agent Scenario
	2.3. Interconnect Scenario		2.3. Interconnect Scenario
	Another scenario to consider when looking at Diameter overload is		Another scenario to consider when looking at Diameter overload is
	that of multiple network operators using Diameter components		that of multiple network operators using Diameter components
	connected through an interconnect service, e.g. using IPX. IPX (IP		connected through an interconnect service, e.g. using IPX. IPX (IP
	eXchange) [IR.34] is an Inter-Operator IP Backbone that provides		eXchange) [IR.34] is an Inter-Operator IP Backbone that provides
	roaming interconnection network between mobile operators and service		roaming interconnection network between mobile operators and service
	providers. The IPX is also used to transport Diameter signaling		providers. The IPX is also used to transport Diameter signaling
	between operators [IR.88]. Figure 7 shows two network operators with		between operators [IR.88]. Figure 7 shows two network operators with
	an interconnect network in-between. There could be any number of		an interconnect network in-between. There could be any number of
	these networks between any two network operator's networks.		these networks between any two network operator's networks.
	+-------------------------------------------+		+-------------------------------------------+
	| Interconnect |		| Interconnect |
	| |		| |
	| +--------------+ +--------------+ |		| +--------------+ +--------------+ |
	| | Server 3 |------| Server 4 | |		| | Server 3 |------| Server 4 | |
	| +--------------+ +--------------+ |		| +--------------+ +--------------+ |
	| .' `. |		| .' `. |
	+------.-'--------------------------`.------+		+------.-'--------------------------`.------+
	.' `.		.' `.
	.-' `.		.-' `.
	------------.'-----+ +----`.---------------		------------.'-----+ +----`.-------------
	+----------+ | | +----------+		+----------+ | | +----------+
	| Server 1 | | | | Server 2 |		| Server 1 | | | | Server 2 |
	+----------+ | | +----------+		+----------+ | | +----------+
	| |		| |
	Network Operator 1 | | Network Operator 2		Network Operator 1 | | Network Operator 2
	-------------------+ +---------------------		-------------------+ +-------------------
	Figure 7: Two Network Interconnect Scenario		Figure 7: Two Network Interconnect Scenario
	The characteristics of the information that an operator would want to		The characteristics of the information that an operator would want to
	share over such a connection are different from the information		share over such a connection are different from the information
	shared between components within a network operator's network.		shared between components within a network operator's network.
	Network operators may not want to convey topology or operational		Network operators may not want to convey topology or operational
	information, which limits how much overload and loading information		information, which limits how much overload and loading information
	can be sent. For the interconnect scenario shown, Server 2 may want		can be sent. For the interconnect scenario shown, Server 2 may want
	to signal overload to Server 1, to affect traffic coming from Network		to signal overload to Server 1, to affect traffic coming from Network
	skipping to change at page 19, line 44 ¶		skipping to change at page 19, line 44 ¶
	discovery or manual configuration. The mechanism MUST work		discovery or manual configuration. The mechanism MUST work
	consistently without regard to how peers are determined.		consistently without regard to how peers are determined.
	REQ 6: The mechanism designers SHOULD seek to minimize the amount		REQ 6: The mechanism designers SHOULD seek to minimize the amount
	of new configuration required in order to work. For		of new configuration required in order to work. For
	example, it is better to allow peers to advertise or		example, it is better to allow peers to advertise or
	negotiate support for the mechanism, rather than to require		negotiate support for the mechanism, rather than to require
	this knowledge to be configured at each node.		this knowledge to be configured at each node.
	REQ 7: The overload control mechanism and any associated default		REQ 7: The overload control mechanism and any associated default
	algorithm(s) MUST ensure that the system remains stable.		algorithm(s) MUST ensure that the system remains stable. At
	When the offered load drops from above the overall capacity		some point after an overload condition has ended, the
	of the network to below the overall capacity, the throughput		mechanism MUST enable capacity to stabilize and become equal
	MUST stabilize and become equal to the offered load. Note		to what it would be in the absence of an overload condition.
	that this also requires that the mechanism MUST allow nodes		Note that this also requires that the mechanism MUST allow
	to shed load without introducing oscillations.		nodes to shed load without introducing oscillations during
			or after an overload condition.
	REQ 8: Supporting nodes MUST be able to distinguish current		REQ 8: Supporting nodes MUST be able to distinguish current
	overload information from stale information, and SHOULD make		overload information from stale information, and SHOULD make
	decisions using the most currently available information.		decisions using the most currently available information.
	REQ 9: The mechanism MUST function across fully loaded as well as		REQ 9: The mechanism MUST function across fully loaded as well as
	quiescent transport connections. This is partially derived		quiescent transport connections. This is partially derived
	from the requirements for stability and hysteresis control		from the requirement for stability in REQ 7.
	above.
	REQ 10: Consumers of overload state indications MUST be able to		REQ 10: Consumers of overload information MUST be able to determine
	determine when the overload condition improves or ends.		when the overload condition improves or ends.
	REQ 11: The overload control mechanism MUST be able to operate in		REQ 11: The overload control mechanism MUST be able to operate in
	networks of different sizes.		networks of different sizes.
	REQ 12: When a single network node fails, goes into overload, or		REQ 12: When a single network node fails, goes into overload, or
	suffers from reduced processing capacity, the mechanism MUST		suffers from reduced processing capacity, the mechanism MUST
	make it possible to limit the impact of this on other nodes		make it possible to limit the impact of this on other nodes
	in the network. This helps to prevent a small-scale failure		in the network. This helps to prevent a small-scale failure
	from becoming a widespread outage.		from becoming a widespread outage.
	skipping to change at page 20, line 46 ¶		skipping to change at page 20, line 45 ¶
	increase of traffic with little time between normal levels		increase of traffic with little time between normal levels
	and overload inducing levels. The mechanism SHOULD provide		and overload inducing levels. The mechanism SHOULD provide
	for rapid feedback when traffic levels increase.		for rapid feedback when traffic levels increase.
	REQ 15: The mechanism MUST NOT interfere with the congestion control		REQ 15: The mechanism MUST NOT interfere with the congestion control
	mechanisms of underlying transport protocols. For example,		mechanisms of underlying transport protocols. For example,
	a mechanism that opened additional TCP connections when the		a mechanism that opened additional TCP connections when the
	network is congested would reduce the effectiveness of the		network is congested would reduce the effectiveness of the
	underlying congestion control mechanisms.		underlying congestion control mechanisms.
	REQ 16: The mechanism MUST operate without malfunction in an		REQ 16: The overload control mechanism is likely to be deployed
	environment with a mix of nodes that do, and nodes that do		incrementally. The mechanism MUST support a mixed
	not, support the mechanism.		environment where some, but not all, nodes implement it.
	REQ 17: In a mixed environment with nodes that support the overload		REQ 17: In a mixed environment with nodes that support the overload
	control mechanism and that do not, the mechanism MUST result		control mechanism and that do not, the mechanism MUST result
	in at least as much useful throughput as would have resulted		in at least as much useful throughput as would have resulted
	if the mechanism were not present. It SHOULD result in less		if the mechanism were not present. It SHOULD result in less
	severe congestion in this environment.		severe congestion in this environment.
	REQ 18: In a mixed environment of nodes that support the overload		REQ 18: In a mixed environment of nodes that support the overload
	control mechanism and that do not, the mechanism MUST NOT		control mechanism and that do not, the mechanism MUST NOT
	preclude elements that support overload control from		preclude elements that support overload control from
	skipping to change at page 21, line 32 ¶		skipping to change at page 21, line 32 ¶
	different realms and in different administrative domains.		different realms and in different administrative domains.
	REQ 20: Any explicit overload indication MUST distinguish between		REQ 20: Any explicit overload indication MUST distinguish between
	actual overload, as opposed to other, non-overload related		actual overload, as opposed to other, non-overload related
	failures.		failures.
	REQ 21: In cases where a network node fails, is so overloaded that		REQ 21: In cases where a network node fails, is so overloaded that
	it cannot process messages, or cannot communicate due to a		it cannot process messages, or cannot communicate due to a
	network failure, it may not be able to provide explicit		network failure, it may not be able to provide explicit
	indications of the nature of the failure or its levels of		indications of the nature of the failure or its levels of
	congestion. The mechanism MUST properly function in these		congestion. The mechanism MUST result in at least as much
	cases.		useful throughput as would have resulted if the overload
			control mechanism was not in place.
	REQ 22: The mechanism MUST provide a way for an node to throttle the		REQ 22: The mechanism MUST provide a way for an node to throttle the
	amount of traffic it receives from an peer node. This		amount of traffic it receives from an peer node. This
	throttling SHOULD be graded so that it can be applied		throttling SHOULD be graded so that it can be applied
	gradually as offered load increases. Overload is not a		gradually as offered load increases. Overload is not a
	binary state; there may be degrees of overload.		binary state; there may be degrees of overload.
	REQ 23: The mechanism MUST enable a supporting node to minimize the		REQ 23: REMOVED
	chance that retries due to an overloaded or failed node
	result in additional traffic to other overloaded nodes, or
	cause additional nodes to become overloaded. Moreover, the
	mechanism SHOULD provide unambiguous directions to clients
	on when they should retry a request and when they should not
	considering the various causes of overload such as avalanche
	restart.
	REQ 24: The mechanism MUST provide sufficient information to enable		REQ 24: The mechanism MUST provide sufficient information to enable
	a load balancing node to divert messages that are rejected		a load balancing node to divert messages that are rejected
	or otherwise throttled by an overloaded upstream node to		or otherwise throttled by an overloaded upstream node to
	other upstream nodes that are the most likely to have		other upstream nodes that are the most likely to have
	sufficient capacity to process them.		sufficient capacity to process them.
	REQ 25: The mechanism MUST provide a mechanism for indicating load		REQ 25: The mechanism MUST provide a mechanism for indicating load
	levels even when not in an overloaded condition, to assist		levels even when not in an overloaded condition, to assist
	nodes making decisions to prevent overload conditions from		nodes making decisions to prevent overload conditions from
	occurring.		occurring.
	REQ 26: The base specification for the overload control mechanism		REQ 26: The base specification for the overload control mechanism
	SHOULD offer general guidance on which message types might		SHOULD offer general guidance on which message types might
	be desirable to send or process over others during times of		be desirable to send or process over others during times of
	overload, based on application-specific considerations. For		overload, based on application-specific considerations. For
	example, it may be more beneficial to process messages for		example, it may be more beneficial to process messages for
	existing sessions ahead of new sessions, or to give priority		existing sessions ahead of new sessions. Some networks may
	to requests associated with emergency sessions or with high		have a requirement to give priority to requests associated
	priority users. Any normative or otherwise detailed		with emergency sessions. Any normative or otherwise
	definition of the relative priorities of message types		detailed definition of the relative priorities of message
	during an overload condition will be the responsibility of		types during an overload condition will be the
	the application specification.		responsibility of the application specification.
	REQ 27: The mechanism MUST NOT prevent a node from prioritizing		REQ 27: The mechanism MUST NOT prevent a node from prioritizing
	requests based on any local policy, so that certain requests		requests based on any local policy, so that certain requests
	are given preferential treatment, given additional		are given preferential treatment, given additional
	retransmission, not throttled, or processed ahead of others.		retransmission, not throttled, or processed ahead of others.
	REQ 28: The overload control mechanism MUST NOT provide new		REQ 28: The overload control mechanism MUST NOT provide new
	vulnerabilities to malicious attack, or increase the		vulnerabilities to malicious attack, or increase the
	severity of any existing vulnerabilities. This includes		severity of any existing vulnerabilities. This includes
	vulnerabilities to DoS and DDoS attacks as well as replay		vulnerabilities to DoS and DDoS attacks as well as replay
	and man-in-the middle attacks. Note that the Diameter base		and man-in-the middle attacks. Note that the Diameter base
	specification [RFC6733] lacks end to end security and this		specification [RFC6733] lacks end to end security and this
	must be considered.		must be considered.
	REQ 29: The mechanism MUST provide a means to match an overload		REQ 29: REMOVED
	indication with the node that originated it. In particular,
	the mechanism MUST allow a node to distinguish between
	overload at a next-hop peer from overload at a node upstream
	of the peer. For example, in Figure 5, the client must not
	mistake overload at server 1 for overload at the agent,
	whether or not the agent supports the mechanism.( see REQ
	4).
	REQ 30: The mechanism MUST NOT depend on being deployed in		REQ 30: The mechanism MUST NOT depend on being deployed in
	environments where all Diameter nodes are completely		environments where all Diameter nodes are completely
	trusted. It SHOULD operate as effectively as possible in		trusted. It SHOULD operate as effectively as possible in
	environments where other nodes are malicious; this includes		environments where other nodes are malicious; this includes
	preventing malicious nodes from obtaining more than a fair		preventing malicious nodes from obtaining more than a fair
	share of service. Note that this does not imply any		share of service. Note that this does not imply any
	responsibility on the mechanism to detect, or take		responsibility on the mechanism to detect, or take
	countermeasures against, malicious nodes.		countermeasures against, malicious nodes.
	skipping to change at page 23, line 36 ¶		skipping to change at page 23, line 19 ¶
	attacks.		attacks.
	REQ 33: There are multiple situations where a Diameter node may be		REQ 33: There are multiple situations where a Diameter node may be
	overloaded for some purposes but not others. For example,		overloaded for some purposes but not others. For example,
	this can happen to an agent or server that supports multiple		this can happen to an agent or server that supports multiple
	applications, or when a server depends on multiple external		applications, or when a server depends on multiple external
	resources, some of which may become overloaded while others		resources, some of which may become overloaded while others
	are fully available. The mechanism MUST allow Diameter		are fully available. The mechanism MUST allow Diameter
	nodes to indicate overload with sufficient granularity to		nodes to indicate overload with sufficient granularity to
	allow clients to take action based on the overloaded		allow clients to take action based on the overloaded
	resources without forcing available capacity to go unused.		resources without unreasonably forcing available capacity to
	The mechanism MUST support specification of overload		go unused. The mechanism MUST support specification of
	information with granularities of at least "Diameter node",		overload information with granularities of at least
	"realm", "Diameter application", and "Diameter session", and		"Diameter node", "realm", and "Diameter application", and
	SHOULD allow extensibility for others to be added in the		MUST allow extensibility for others to be added in the
	future.		future.
	REQ 34: The mechanism MUST provide a method for extending the		REQ 34: The mechanism MUST provide a method for extending the
	information communicated and the algorithms used for		information communicated and the algorithms used for
	overload control.		overload control.
	REQ 35: The mechanism SHOULD provide a method for exchanging		REQ 35: The mechanism SHOULD provide a method for exchanging
	overload and load information between elements that are		overload and load information between elements that are
	connected by intermediaries that do not support the		connected by intermediaries that do not support the
	mechanism.		mechanism.
			REQ 36: The mechanism MUST provide a default algorithm that is
			mandatory to implement.
	8. IANA Considerations		8. IANA Considerations
	This document makes no requests of IANA.		This document makes no requests of IANA.
	9. Security Considerations		9. Security Considerations
	A Diameter overload control mechanism is primarily concerned with the		A Diameter overload control mechanism is primarily concerned with the
	load and overload related behavior of nodes in a Diameter network,		load and overload related behavior of nodes in a Diameter network,
	and the information used to affect that behavior. Load and overload		and the information used to affect that behavior. Load and overload
	skipping to change at page 27, line 24 ¶		skipping to change at page 27, line 11 ¶
	Appendix A. Contributors		Appendix A. Contributors
	Significant contributions to this document were made by Adam Roach		Significant contributions to this document were made by Adam Roach
	and Eric Noel.		and Eric Noel.
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	Review of, and contributions to, this specification by Martin Dolly,		Review of, and contributions to, this specification by Martin Dolly,
	Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert		Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert
	Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent		Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent
	Thiebaut, and Lionel Morand were most appreciated. We would like to		Thiebaut, Andrew Booth, and Lionel Morand were most appreciated. We
	thank them for their time and expertise.		would like to thank them for their time and expertise.
	Authors' Addresses		Authors' Addresses
	Eric McMurry		Eric McMurry
	Tekelec		Tekelec
	17210 Campbell Rd.		17210 Campbell Rd.
	Suite 250		Suite 250
	Dallas, TX 75252		Dallas, TX 75252
	US		US
End of changes. 22 change blocks.
	125 lines changed or deleted		114 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/