draft-ietf-dime-load-01.txt		draft-ietf-dime-load-02.txt
	Internet Engineering Task Force B. Campbell		Internet Engineering Task Force B. Campbell
	Internet-Draft S. Donovan, Ed.		Internet-Draft S. Donovan, Ed.
	Intended status: Informational Oracle		Intended status: Standards Track Oracle
	Expires: April 14, 2016 JJ. Trottin		Expires: September 19, 2016 JJ. Trottin
	Alcatel-Lucent		Nokia
	October 12, 2015		March 18, 2016
	Diameter Load Information Conveyance		Diameter Load Information Conveyance
	draft-ietf-dime-load-01		draft-ietf-dime-load-02
	Abstract		Abstract
	This document defines a mechanism for sharing of Diameter load		This document defines a mechanism for sharing of Diameter load
	information. RFC 7068 describes requirements for Overload Control in		information. [RFC7068] describes requirements for Overload Control
	Diameter. This includes a requirement to allow Diameter nodes to		in Diameter. This includes a requirement to allow Diameter nodes to
	send "load" information, even when the node is not overloaded. The		send "load" information, even when the node is not overloaded. The
	Diameter Overload Information Conveyance (DOIC) solution describes a		Diameter Overload Information Conveyance (DOIC) [RFC7683] solution
	mechanism meeting most of the requirements, but does not currently		describes a mechanism meeting most of the requirements, but does not
	include the ability to send load information.		currently include the ability to send load information.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 14, 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
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3		2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
	3. Conventions Used in This Document . . . . . . . . . . . . . . 4		3. Conventions Used in This Document . . . . . . . . . . . . . . 4
	4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Differences between Load and Overload information . . . . 4		4.1. Differences between Load and Overload information . . . . 4
	4.2. How is Load Information Used? . . . . . . . . . . . . . . 5		4.2. How is Load Information Used? . . . . . . . . . . . . . . 5
	5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6		5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 7		5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 7
	6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 9		6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 10
	6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 9		6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10
	6.1.1. End-point Reporting Node Behavior . . . . . . . . . . 10		6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 10
	6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 10		6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 11
	6.2. Receiving Node Behavior . . . . . . . . . . . . . . . . . 11		6.2. Receiving Node Behavior . . . . . . . . . . . . . . . . . 11
	6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12		6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
	7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 12		7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 13
	7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 12		7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 12		7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 13
	7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 13		7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 13
	7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 13		7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 14
	7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 13		7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 14		9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 14		9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Normative References . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . 15
	10.2. Informative References . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 15		Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 16
	A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 15		A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 16
	A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 15		A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 16
	A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 16		A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 17
	A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 17		A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 18
	A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 18		A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 19
	A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 18		A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 19
	A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 19		A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 20
	A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 19		A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 20
	A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 19		A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 20
	A.10. Addition and removal of Nodes . . . . . . . . . . . . . . 20		A.10. Addition and removal of Nodes . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	[RFC7068] describes requirements for Overload Control in Diameter		[RFC7068] describes requirements for Overload Control in Diameter
	[RFC6733]. At the time of this writing, the DIME working group is		[RFC6733]. The DIME working group has finished the Diameter Overload
	working on the Diameter Overload Information Conveyance (DOIC)		Information Conveyance (DOIC) mechanism [RFC7683]. As currently
	mechanism [I-D.ietf-dime-ovli] . As currently specified, DOIC		specified, DOIC fulfills some, but not all, of the requirements.
	fulfills some, but not all, of the requirements.
	In particular, DOIC does not fulfill Req 24, which requires a		In particular, DOIC does not fulfill Req 24, which requires a
	mechanism where Diameter nodes can indicate their current load, even		mechanism where Diameter nodes can indicate their current load, even
	if they are not currently overloaded. DOIC also does not fulfill Req		if they are not currently overloaded. DOIC also does not fulfill Req
	23, which requires that nodes that divert traffic away from		23, which requires that nodes that divert traffic away from
	overloaded nodes be provided with sufficient information to select		overloaded nodes be provided with sufficient information to select
	targets that are most likely to have sufficient capacity.		targets that are most likely to have sufficient capacity.
	There are several other requirements in RFC 7068 that mention both		There are several other requirements in [RFC7068] that mention both
	overload and load information that are only partially fulfilled by		overload and load information that are only partially fulfilled by
	DOIC.		DOIC.
	The DIME working group explicitly chose not to fulfill these		The DIME working group explicitly chose not to fulfill these
	requirements in DOIC due to several reasons. A principal reason was		requirements in DOIC due to several reasons. A principal reason was
	that the working group did not agree on a general approach for		that the working group did not agree on a general approach for
	conveying load information. It chose to progress the rest of DOIC,		conveying load information. It chose to progress the rest of DOIC,
	and defer load information conveyance to a DOIC extension or a		and deferred load information conveyance to a DOIC extension or a
	separate mechanism.		separate mechanism.
	This document defines a mechanism that addresses the load-related		This document defines a mechanism that addresses the load-related
	requirements from RFC 7068.		requirements from RFC 7068.
	2. Terminology and Abbreviations		2. Terminology and Abbreviations
	DOIC		DOIC
	Diameter Overload Information Conveyance		Diameter Overload Information Conveyance ([RFC7683])
	Load		Load
	The relative capacity of a Diameter node. A low value indicates		The relative capacity of a Diameter node. A low load level
	that the Diameter node is under utilized. A high value indicated		indicates that the Diameter node is under utilized. A high load
	that the node is closer to being fully utilized.		level indicates that the node is closer to being fully utilized.
	Offered Load		Offered Load
	The actual traffic sent to the reporting node after overload		The actual traffic sent to the reporting node after overload
	abatement and routing decisions are made.		abatement and routing decisions are made.
			Reporting, Reacting Node
			Reporting node and reacting node terminology is defined in
			[RFC7683].
			Routing Information
			Routing Information - Routing information referred to in this
			document can include the Routing and Peer tables defined in RFC
			6733. It can also include other implementation specific tables
			used to store load information. This document does not define the
			structure of such tables.
	3. Conventions Used in This Document		3. Conventions Used in This Document
	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].
	RFC 2119 [RFC2119] interpretation does not apply for the above listed		RFC 2119 [RFC2119] interpretation does not apply for the above listed
	words when they are not used in all-caps format.		words when they are not used in all-caps format.
	4. Background		4. Background
	4.1. Differences between Load and Overload information		4.1. Differences between Load and Overload information
	Previous discussions of how to solve the load-related requirements in		Previous discussions of how to solve the load-related requirements in
	[RFC7068] have shown that people have not had an agreed-upon concept		[RFC7068] have shown that people did not had an agreed-upon concept
	of how "load" information differs from "overload" information. While		of how "load" information differs from "overload" information. While
	the two concepts are highly interrelated, in the opinion of the		the two concepts are highly interrelated, in the opinion of the
	authors, there are two primary differences. First, a Diameter node		authors, there are two primary differences. First, a Diameter node
	always has a load. At any given time that load maybe effectively		always has a load. At any given time that load maybe effectively
	zero, effectively fully loaded, or somewhere in between. In		zero, effectively fully loaded, or somewhere in between. In
	contrast, overload is an exceptional condition. A node only has		contrast, overload is an exceptional condition. A node only has
	overload information when it is in an overloaded state. Furthermore,		overload information when it is in an overloaded state. Furthermore,
	the relationship between a node's load level and overload state at		the relationship between a node's load level and overload state at
	any given time may be vague. For example, a node may normally		any given time may be vague. For example, a node may normally
	operate at a "fully loaded" level, but still not be considered		operate at a "fully loaded" level, but still not be considered
	overloaded. Another node may declare itself to be "overloaded" even		overloaded. Another node may declare itself to be "overloaded" even
	though it might not be fully "loaded".		though it might not be fully "loaded".
	Second, Overload information, in the form of a DOIC Overload Report		Second, Overload information, in the form of a DOIC Overload Report
	(OLR) [I-D.ietf-dime-ovli] indicates an explicit request for action		(OLR) [RFC7683] indicates an explicit request for action on the part
	on the part of the reacting node. That is, the OLR requests that the		of the reacting node. That is, the OLR requests that the reacting
	reacting node reduce the offered load -- the actual traffic sent to		node reduce the offered load -- the actual traffic sent to the
	the reporting node after overload abatement and routing decisions are		reporting node after overload abatement and routing decisions are
	made -- by an indicated amount or to an indicated level.		made -- by an indicated amount or to an indicated level.
	Effectively, DOIC provides a contract between the reporting node and		Effectively, DOIC provides a contract between the reporting node and
	the reacting node.		the reacting node.
	In contrast, load is informational. That is, load information can be		In contrast, load is informational. That is, load information can be
	considered a hint to the recipient node. That node may use the load		considered a hint to the recipient node. That node may use the load
	information for load balancing purposes, as an input to certain		information for load balancing purposes, as an input to certain
	overload abatement techniques, to make inferences about the		overload abatement techniques, to make inferences about the
	likelihood that the sending node becomes overloaded in the immediate		likelihood that the sending node becomes overloaded in the immediate
	future, or for other purposes.		future, or for other purposes.
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 23 ¶
	offered load based on load information. The fundamental difference		offered load based on load information. The fundamental difference
	is that an overload report requires that reduction. It is also		is that an overload report requires that reduction. It is also
	reasonable for a Diameter node to decide to increase the offered load		reasonable for a Diameter node to decide to increase the offered load
	based on load information.		based on load information.
	4.2. How is Load Information Used?		4.2. How is Load Information Used?
	[RFC7068] contemplates two primary uses for load information. Req 23		[RFC7068] contemplates two primary uses for load information. Req 23
	discusses how load information might be used when performing		discusses how load information might be used when performing
	diversion as an overload abatement technique, as described in		diversion as an overload abatement technique, as described in
	[I-D.ietf-dime-ovli]. When a reacting node diverts traffic away from		[RFC7683]. When a reacting node diverts traffic away from an
	an overloaded node, it needs load information for the other		overloaded node, it needs load information for the other candidates
	candidates for that traffic in order to effectively load balance the		for that traffic in order to effectively load balance the diverted
	diverted load between potential candidates. Otherwise, diversion has		load between potential candidates. Otherwise, diversion has a
	a greater potential to drive other nodes into overload.		greater potential to drive other nodes into overload.
	Req 24 discusses how Diameter load information might be used when no		Req 24 discusses how Diameter load information might be used when no
	overload condition currently exists. Diameter nodes can use the load		overload condition currently exists. Diameter nodes can use the load
	information to make decisions to try to avoid overload conditions in		information to make decisions to try to avoid overload conditions in
	the first place. Normal load-balancing falls into this category. A		the first place. Normal load-balancing falls into this category. A
	node might also take other proactive steps to reduce offered load		node might also take other proactive steps to reduce offered load
	based on load information, so that the loaded node never goes into		based on load information, so that the loaded node never goes into
	overload in the first place.		overload in the first place.
	If the loaded nodes are Diameter servers (or clients in the case of		If the loaded nodes are Diameter servers (or clients in the case of
	skipping to change at page 5, line 46 ¶		skipping to change at page 6, line 9 ¶
	For example, a Diameter node (e.g. client) can use a redirect		For example, a Diameter node (e.g. client) can use a redirect
	agent to get candidate destination host addresses. The redirect		agent to get candidate destination host addresses. The redirect
	agent might return several destination host addresses, from which		agent might return several destination host addresses, from which
	the Diameter node selects one. The Diameter node can use load		the Diameter node selects one. The Diameter node can use load
	information received from these hosts to make the selection.		information received from these hosts to make the selection.
	Just as load information can be used as part of server selection, it		Just as load information can be used as part of server selection, it
	can also be used as input to the selection of the next-hop peer to		can also be used as input to the selection of the next-hop peer to
	which a request is to be routed.		which a request is to be routed.
	Editor's Note: One area that requires thought is how load		It should be noted that a Diameter node will need to process both
	information is used, if at all, in the presence of an overload		Load reports and Overload reports from the same Diameter node. The
	report from the same Diameter node. It might be that the load		reacting node for the Overload report always has the responsibility
	information from that Diameter node is ignored for the duration of		to reduce the amount of Diameter traffic sent to the overloaded node.
	the time that the overload report is in effect. It might also be		If, or how, the reacting node uses Load information to achieve this
	possible that the load information can aid in the diverting of		is left as an implementation decision.
	non-abated requests targeted for the overloaded Diameter node.
	5. Solution Overview		5. Solution Overview
	The mechanism defined here for the conveyance of load information is		The mechanism defined here for the conveyance of load information is
	similar in some says to the mechanism defined for DOIC and is		similar in some ways to the mechanism defined for DOIC and is
	different in other ways.		different in other ways.
	As with DOIC, load information is conveyed by piggy-backing the load		As with DOIC, load information is conveyed by piggy-backing the load
	AVPs on existing Diameter applications.		AVPs on existing Diameter applications.
	There are two primary differences. First, there is no capability		There are two primary differences. First, there is no capability
	negotiation process for load. The sender of the load information is		negotiation process for load. The sender of the load information is
	sending it with the expectation that any supporting nodes will use it		sending it with the expectation that any supporting nodes will use it
	when making routing decisions. If there are no nodes that support		when making routing decisions. If there are no nodes that support
	the load extension then the load information is ignored.		the Load mechanism then the load information is ignored.
	The second big difference between DOIC and Load is visibility of the		The second big difference between DOIC and Load is visibility of the
	DOIC or Load information within a Diameter network. DOIC information		DOIC or Load information within a Diameter network. DOIC information
	is sent end-to-end resulting in the ability of all nodes in the path		is sent end-to-end resulting in the ability of all nodes in the path
	of the answer message that carries the OC-OLR AVP to act on the		of the answer message that carries the OC-OLR AVP to act on the
	information. The DOIC overload reports much remain in the message		information. The DOIC overload reports much remain in the message
	all the way from the reporting node to the node that is the target		all the way from the reporting node to the node that is the target
	for the answer message.		for the answer message.
	For the Load mechanism there are two types of load reports.		For the Load mechanism there are two types of load reports.
	The first is the load of the end-point sending the answering the		The first is the load of the endpoint sending the answer message.
	message. This load report is carried end-to-end to enable any nodes		This load report is carried end-to-end to enable any nodes that make
	that make server selection decisions to use the load status of the		server selection decisions to use the load status of the sending
	sending end-point as part of the server selection decision.		endpoint as part of the server selection decision.
	The second type of load report is a peer report. This report is used		The second type of load report is a peer report. This report is used
	by Diameter nodes as part of the logic to select the next hop		by Diameter nodes as part of the logic to select the next hop
	Diameter node and, as such, do not have significance beyond the peer		Diameter node and, as such, do not have significance beyond the peer
	node. These load reports are removed by the first supporting		node. These load reports are removed by the first supporting
	Diameter node.		Diameter node to receive the report.
	Because load reports can traverse Diameter nodes that do not support		Because load reports can traverse Diameter nodes that do not support
	the load mechanism, it is necessary to include the identity of the		the Load mechanism, it is necessary to include the identity of the
	node to which the load report applies as part of the load report.		node to which the load report applies as part of the load report.
	This allows for a Diameter node to verify that the load report		This allows for a Diameter node to verify that a load report applies
	applies to its peer or if it should be ignored.		to its peer or if it should be ignored.
	The load report includes the relative load of the sending node. This		The load report includes the relative load of the sending node. This
	relative load is specified in a manner consistent with that defined		relative load is specified in a manner consistent with that defined
	for DNS SRV [RFC2782].		for DNS SRV [RFC2782].
			The goal is make it possible to use both the load values received as
			a part of the Diameter Load mechanism and weight values received as a
			result of a DNS SRV query. As a result, the Diameter load value has
			a range of 0-65535. This value and DNS SRV weight values are then
			used in a distribution algorithm similar to that specified in
			[RFC2782].
			The DNS SRV distribution algorithm results in more messages being
			sent to a node with a higher weight value. As a result, a higher
			Diameter load value indicates a LOWER load on the sending node. A
			node that is heavily loaded sends a lower Diameter load value.
			Stated another way, a node that has zero load would have a load value
			of 65535. A node that is 100% loaded would have a load value of 0.
			The distribution algorithm used by Diameter nodes supporting the
			Diameter Load mechanism is an implementation decision but it needs to
			result in similar behavior as the algorithm specified in [RFC2782].
	The method for calculating the load value included in the load report		The method for calculating the load value included in the load report
	is left as an implementation decision.		is also left as an implementation decision.
	The frequency for sending of load reports is also left as an		The frequency for sending of load reports is also left as an
	implementation decision. The sending node might choose to send load		implementation decision. The sending node might choose to send load
	reports in all messages or it might choose to only send load reports		reports in all messages or it might choose to only send load reports
	when the load value has changed by some implementation specific		when the load value has changed by some implementation specific
	value. The important consideration is that all nodes needing the		amount. The important consideration is that all nodes needing the
	load information have a sufficiently accurate view of the nodes load.		load information have a sufficiently accurate view of the nodes load.
	5.1. Theory of Operation		5.1. Theory of Operation
	This section outlines how the Diameter load mechanism is expected to		This section outlines how the Diameter Load mechanism is expected to
	work.		work.
	For this discussion, assume the following Diameter network		For this discussion, assume the following Diameter network
	configuration:		configuration:
	---A1---A3----S[1], S[2]...S[p]		---A1---A3----S[1], S[2]...S[p]
	/ | \ /		/ | \ /
	C | x		C | x
	\ | / \		\ | / \
	---A2---A4----S[p+1], S[p+2] ...S[n]		---A2---A4----S[p+1], S[p+2] ...S[n]
	Figure 1: Example Diameter Network		Figure 1: Example Diameter Network
			Note that in this diagram, S[1], S[2] through S[p] are peers to A3.
			S[p+1], S[p+2] through S[n] are peers to A4.
	Also assume that the request for a Diameter transaction takes the		Also assume that the request for a Diameter transaction takes the
	following path:		following path:
	C A1 A4 S[n]		C A1 A4 S[n]
	| | | |		| | | |
	|----->|----->|----->|		|----->|----->|----->|
	xxR xxR xxR		xxR xxR xxR
	Figure 2: Request Message Path		Figure 2: Request Message Path
	When sending the answer message, an end-point node that supports the		When sending the answer message, an endpoint node that supports the
	Diameter Load mechanism includes it's own load information in the		Diameter Load mechanism includes it's own load information in the
	answer message. Because it is a Diameter end-point it includes an		answer message. Because it is a Diameter endpoint it includes a HOST
	end-point load report.		load report.
	C A1 A4 S[n]		C A1 A4 S[n]
	| | | |		| | | |
	| | |<-----|		| | |<-----|
	| | xxA(Load type:host, source:S[n])		| | xxA(Load type:HOST, source:S[n])
	| | | |		| | | |
	Figure 3: Answer Message from S[n]		Figure 3: Answer Message from S[n]
	If Agent A4 supports the Load mechanism then it will verify that the		If Agent A4 supports the Load mechanism then it will verify that the
	load information received is valid. For a host load report this is		load information received is valid. For a HOST load report this is
	achieved by matching the identity included in the load information		achieved by matching the identity included in the load information
	with the identity of the host node from which the answer message was		with the identity of the host node from which the answer message was
	received.		received.
	Note: If A4 does not support the load mechanism then it will relay		Note: If A4 does not support the Load mechanism then it will relay
	the answer message without doing any processing on the load		the answer message without doing any processing on the load
	information. In this case the load AVPs will be relayed without		information. In this case the load information AVPs will be
	change.		relayed without change.
	If the identity included in the load information AVPs matches the		If the identity included in the load information AVPs matches the
	identity of the host from which the load information is received then		identity of the host from which the load information is received then
	Agent A4 stores the load information for S[n] in its routing tables.		Agent A4 stores the load information for S[n] in its routing
			information.
	Because the load report is an host load report, A4 leaves the load		Because the load report is an HOST load report, A4 leaves the load
	report in the message it relays.		report in the message it relays.
	A4 then calculates its own load information and inserts load		A4 then calculates its own load information and inserts load
	information AVPs in the message before sending the message to A1:		information AVPs of type PEER in the message before sending the
			message to A1:
	C A1 A4 S[n]		C A1 A4 S[n]
	| | | |		| | | |
	| |<-----| |		| |<-----| |
	| xxA(Load type:peer, source:A4)		| xxA(Load type:PEER, source:A4)
	| xxA(Load type:host, source:S[n])		| xxA(Load type:HOST, source:S[n])
	| | | |		| | | |
	Figure 4: Answer Message from A4		Figure 4: Answer Message from A4
	If A1 supports the Load mechanism then it processes each of the Load		If A1 supports the Load mechanism then it processes each of the Load
	reports it receives separately.		reports it receives separately.
	For the peer load report, A1 first determines if the source of the		For the PEER load report, A1 first determines if the source of the
	report indicated in the load report matches the DiameterID of the		report indicated in the load report matches the DiameterIdentity of
	Diameter node from which the request was received. If the identities		the Diameter node from which the request was received. If the
	do not match then the peer load report is discarded. If the		identities do not match then the PEER load report is discarded. If
	identities match then A1 saves the load information in its routing		the identities match then A1 saves the load information in its
	tables for routing of subsequent request messages. In both cases A1		routing information for routing of subsequent request messages. In
	strips the peer load report from the message.		both cases A1 strips the PEER load report from the message.
	For the host load report, A1's actions depend on whether A1 is		For the HOST load report, A1's actions depend on whether A1 is
	responsible for doing server selection. If A1 is not doing server		responsible for doing server selection. If A1 is not doing server
	selection then A1 ignores the host load report. If A1 is responsible		selection then A1 ignores the HOST load report. If A1 is responsible
	for doing server selection then it stores the load information for		for doing server selection then it stores the load information for
	S[n] in its routing tables for the handling of subsequent request		S[n] in its routing information for the handling of subsequent
	messages. In both cases A1 leaves the host report in the message.		request messages. In both cases A1 leaves the HOST report in the
			message.
	A1 then calculates its own load information and inserts load		A1 then calculates its own load information and inserts load
	information AVPs in the message before sending the message to A1:		information AVPs of type PEER in the message before sending the
			message to A1:
	C A1 A4 S[n]		C A1 A4 S[n]
	| | | |		| | | |
	|<-----| | |		|<-----| | |
	xxA(Load type:peer, source:A1)		xxA(Load type:PEER, source:A1)
	xxA(Load type:host, source:S[n])		xxA(Load type:HOST, source:S[n])
	Figure 5: Answer Message from A1		Figure 5: Answer Message from A1
	As with A1, C processes each load report separately.		As with A1, C processes each load report separately.
	For the peer load report, C follows the same procedure for		For the PEER load report, C follows the same procedure as A1 for
	determining if the Load report was received from the peer from which		determining if the Load report was received from the peer from which
	the report was sent and, when finding it does, stores the load		the report was sent and, when finding it does, stores the load
	information for use when making future routing decisions.		information for use when making future routing decisions.
	For the host load report, C saves the load information only if it is		For the HOST load report, C saves the load information only if it is
	responsible for doing server selection.		responsible for doing server selection.
	The Load information received by all nodes is then used for routing		The Load information received by all nodes is then used for routing
	of subsequent request messages.		of subsequent request messages.
	6. Load Mechanism Procedures		6. Load Mechanism Procedures
	This section defines the normative behaviors for the Load mechanism.		This section defines the normative behaviors for the Load mechanism.
	6.1. Reporting Node Behavior		6.1. Reporting Node Behavior
	This section defines the procedures of Diameter nodes that generate		This section defines the procedures of Diameter reporting nodes that
	load reports.		generate load reports.
	6.1.1. End-point Reporting Node Behavior		6.1.1. Endpoint Reporting Node Behavior
	A Diameter end-point that supports the Diameter Load mechanism MUST		A Diameter endpoint that supports the Diameter Load mechanism MUST
	include a load report of type HOST in sufficient answer messages to		include a load report of type HOST in sufficient answer messages to
	ensure that all consumers of the load information receive timely		ensure that all consumers of the load information receive timely
	updates.		updates.
	The Diameter end-point MUST include it's own DiameterID in the		The Diameter endpoint MUST include it's own DiameterIdentity in the
	Source-ID AVP included in the Load AVP.		Source-ID AVP included in the Load AVP.
	The Diameter end-point MUST include a Load-Type AVP of type HOST in		The Diameter endpoint MUST include a Load-Type AVP of type HOST in
	the Load AVP.		the Load AVP.
	The Diameter end-point MUST include its load value in the Value AVP		The Diameter endpoint MUST include its load value in the Value AVP in
	in the load AVP.		the load AVP.
	The method for determining the load value included in the load report		The method for determining the load value included in the load report
	is an implementation decision.		is an implementation decision.
	The value included MUST be consistant with DNS SRV....
	Editor's note: We need to elaborate on this.
	The frequency of sending load reports is an implementation decision.		The frequency of sending load reports is an implementation decision.
	For instance, if the only consumer of the load reports is the end-		For instance, if the only consumer of the load reports is the
	points peer then the end-point can choose to only include a load		endpoints peer then the endpoint can choose to only include a load
	report when the load of the end-point has changed by a significant		report when the load of the endpoint has changed by a meaningful
	percentage. If there are consumers of the end-point load report		percentage. If there are consumers of the endpoint load report
	other then the end-points peer (this will be the case if other		other then the endpoints peer (this will be the case if other
	nodes are responsible for server selection) then the end-point		nodes are responsible for server selection) then the endpoint
	might choose to include load reports in all answer messages as a		might choose to include load reports in all answer messages as a
	way of ensuring that all nodes doing server selection get accurate		way of ensuring that all nodes doing server selection get accurate
	load information.		load information.
	6.1.2. Agent Reporting Node Behavior		6.1.2. Agent Reporting Node Behavior
	A Diameter agent that supports the Diameter Load mechanism MUST		A Diameter agent that supports the Diameter Load mechanism MUST
	include a PEER load report in sufficient answer messages to ensure		include a PEER load report in sufficient answer messages to ensure
	that all users of the load information receive timely updates.		that all users of the load information receive timely updates.
	The Diameter agent MUST include it's own DiameterID in the Source-ID		The Diameter agent MUST include it's own DiameterIdentity in the
	AVP included in the Load AVP.		Source-ID AVP included in the Load AVP.
	The Diameter agent MUST include a Load-Type AVP of type PEER in the		The Diameter agent MUST include a Load-Type AVP of type PEER in the
	Load AVP.		Load AVP.
	The Diameter agent MUST include its load value in the Value AVP in		The Diameter agent MUST include its load value in the Value AVP in
	the load AVP.		the load AVP.
	The method for determining the load value included in the load report		The method for determining the load value included in the load report
	is an implementation decision.		is an implementation decision.
	The value included MUST be consistant with DNS SRV....
	Editor's note: We need to elaborate on this.
	The frequency of sending load reports is an implementation decision.		The frequency of sending load reports is an implementation decision.
	Note: In the case of peer load reports it is only necessary to		Note: In the case of peer load reports it is only necessary to
	include load reports when the load value has changed by some		include load reports when the load value has changed by some
	significant value. It is also acceptable to include the load		meaningful value, as long as the agent insures that all peers
			receive the report. It is also acceptable to include the load
	report in every answer message handled by the Diameter agent.		report in every answer message handled by the Diameter agent.
	6.2. Receiving Node Behavior		6.2. Receiving Node Behavior
	This section defines the behavior of Diameter nodes processing load		This section defines the behavior of Diameter nodes processing load
	reports.		reports.
	A Diameter node MUST be prepared to process both load reports of type		A Diameter node MUST be prepared to process load reports of type HOST
	HOST and of type PEER, as indicated in the Load-Type AVP included in		and of type PEER, as indicated in the Load-Type AVP included in the
	the Load AVP.		Load AVP received in the same answer message or from multiple answer
			messages.
	Note that the node needs to be able to handle messages with no		Note that the node needs to be able to handle messages with no
	load reports, messages with just a PEER load report, messages with		load reports, messages with just a PEER load report, messages with
	just an HOST load report and messages with both types of load		just an HOST load report and messages with both types of load
	reports.		reports.
	If the Diameter node is not responsible for doing server selection		If the Diameter node is not responsible for doing server selection
	then it SHOULD ignore load reports of type HOST.		then it SHOULD ignore load reports of type HOST.
	If the Diameter node is responsible for doing server selection then		If the Diameter node is responsible for doing server selection then
	it SHOULD save the load value included in the Value AVP included in		it SHOULD save the load value included in the Value AVP included in
	the Load AVP of type HOST in its routing tables.		the Load AVP of type HOST in its routing information.
	If the Diameter node receives a Load report of type PEER then the		If the Diameter node receives a Load report of type PEER then the
	Diameter node MUST determine if the Load report was inserted into the		Diameter node MUST determine if the Load report was inserted into the
	answer message by the peer from which the message was received. This		answer message by the peer from which the message was received. This
	is achieved by comparing the DiameterID associated with the		is achieved by comparing the DiameterIdentity associated with the
	connection from which the message was received with the DiameterID		connection from which the message was received with the
	included in the Source-ID AVP in the Load report.		DiameterIdentity included in the Source-ID AVP in the Load report.
	If the Diameter node determines that the Load report of type PEER was		If the Diameter node determines that the Load report of type PEER was
	not received from the peer that sent or relayed the answer message		not received from the peer that sent or relayed the answer message
	then the node MUST ignore the Load report.		then the node MUST ignore the Load report.
	If the Diameter node determines that the Load report of type PEER was		If the Diameter node determines that the Load report of type PEER was
	received from the peer that sent or relayed the answer message then		received from the peer that sent or relayed the answer message then
	the node SHOULD save the load information in its routing table.		the node SHOULD save the load information in its routing information.
	How a Diameter node uses load information for making routing		How a Diameter node uses load information for making routing
	decisions is an implememtation decision.		decisions is an implementation decision. However, the distribution
			algorithm MUST result in similar behavior as the algorithm described
			for the use of weigth values in [RFC2782].
	6.3. Extensibility		6.3. Extensibility
	The Load mechanism can be extended to include additional information		The Load mechanism can be extended to include additional information
	in the load reports.		in the load reports.
	Any extension may define new AVPs for use in Load reports. These new		Any extension may define new AVPs for use in Load reports. These new
	AVPs SHOULD be defined to be extensions to the Load AVPs defined in		AVPs SHOULD be defined to be extensions to the Load AVPs defined in
	this document.		this document.
	[RFC6733] defined Grouped AVP extension mechanisms apply. This		[RFC6733] defined Grouped AVP extension mechanisms apply. This
	allows, for example, defining a new feature that is mandatory to be		allows, for example, defining a new feature that is mandatory to be
	understood even when piggybacked on an existing application.		understood even when piggybacked on an existing application.
	As with any Diameter specification, RFC6733 requires all new AVPs to		As with any Diameter specification, [RFC6733] requires all new AVPs
	be registered with IANA. See Section 9 for the required procedures.		to be registered with IANA. See Section 9 for the required
			procedures.
	7. Attribute Value Pairs		7. Attribute Value Pairs
	The section defines the AVPs required for the Load mechanism.		The section defines the AVPs required for the Load mechanism.
	7.1. Load AVP		7.1. Load AVP
	The Load AVP (AVP code TBD1) is of type Grouped and is used to convey		The Load AVP (AVP code TBD1) is of type Grouped and is used to convey
	load information between Diameter nodes.		load information between Diameter nodes.
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 40 ¶
	HOST 0 The load report is for a host.		HOST 0 The load report is for a host.
	PEER 1 The load report is for a peer.		PEER 1 The load report is for a peer.
	7.3. Load-Value AVP		7.3. Load-Value AVP
	The Load-Value AVP (AVP code TBD3) is of type Unsigned64. It is used		The Load-Value AVP (AVP code TBD3) is of type Unsigned64. It is used
	to convey relative load information about the sender of the load		to convey relative load information about the sender of the load
	report.		report.
			The Load-Value AVP is specified in a manner similar to the weight
			value in DNS SRV ([RFC2782]).
			The Load-Value has a range of 0-65535.
			A higher value indicates a lower load on the sending node. A lower
			value indicates that the sending node is heavily loaded.
			Stated another way, a node that has zero load would have a load
			value of 65535. A node that is 100% loaded would have a load
			value of 0.
	7.4. SourceID AVP		7.4. SourceID AVP
	The SourceID AVP is defined in [I-D.ietf-dime-agent-overload]. It is		The SourceID AVP is defined in [I-D.ietf-dime-agent-overload]. It is
	used to identify the Diameter node that sent the Load report.		used to identify the Diameter node that sent the Load report.
	7.5. Attribute Value Pair flag rules		7.5. 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|
	+--------------------------------------------------+----+----+		+--------------------------------------------------------+----+----+
	|Load TBD1 x.1 Grouped | | V |		|Load TBD1 x.1 Grouped | | V |
	+--------------------------------------------------+----+----+		+--------------------------------------------------------+----+----+
	|Load-Type TBD2 x.2 Enumerated | | V |		|Load-Type TBD2 x.2 Enumerated | | V |
	+--------------------------------------------------+----+----+		+--------------------------------------------------------+----+----+
	|Load-Value TBD3 x.3 Unsigned64 | | V |		|Load-Value TBD3 x.3 Unsigned64 | | V |
	+--------------------------------------------------+----+----+		+------------------------------------------------------ -+----+----+
	|SourceID TBD4 x.4 DiameterID | | V |		|SourceID TBD4 x.4 DiameterIdentity | | V |
	+--------------------------------------------------+----+----+		+--------------------------------------------------------+----+----+
	As described in the Diameter base protocol [RFC6733], the M-bit usage		As described in the Diameter base protocol [RFC6733], the M-bit usage
	for a given AVP in a given command may be defined by the application.		for a given AVP in a given command may be defined by the application.
	8. Security Considerations		8. Security Considerations
	Load information may be sensitive information in some cases.		Load information may be sensitive information in some cases.
	Depending on the mechanism, an unauthorized recipient might be able		Depending on the mechanism, an unauthorized recipient might be able
	to infer the topology of a Diameter network from load information.		to infer the topology of a Diameter network from load information.
	Load information might be useful in identifying targets for Denial of		Load information might be useful in identifying targets for Denial of
	skipping to change at page 14, line 28 ¶		skipping to change at page 15, line 26 ¶
	This document makes no new registry requests of IANA.		This document makes no new registry requests of IANA.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-dime-agent-overload]		[I-D.ietf-dime-agent-overload]
	Donovan, S., "Diameter Agent Overload", draft-ietf-dime-		Donovan, S., "Diameter Agent Overload", draft-ietf-dime-
	agent-overload-02 (work in progress), August 2015.		agent-overload-02 (work in progress), August 2015.
	[I-D.ietf-dime-ovli]
	Korhonen, J., Donovan, S., Campbell, B., and L. Morand,
	"Diameter Overload Indication Conveyance", draft-ietf-
	dime-ovli-03 (work in progress), July 2014.
	[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>.
	[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>.
	10.2. Informative References		10.2. Informative References
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	DOI 10.17487/RFC2782, February 2000,		DOI 10.17487/RFC2782, February 2000,
	<http://www.rfc-editor.org/info/rfc2782>.		<http://www.rfc-editor.org/info/rfc2782>.
	Appendix A. Topology Scenarios		Appendix A. Topology Scenarios
	This section presents a number of Diameter topology scenarios, and		This section presents a number of Diameter topology scenarios, and
	skipping to change at page 15, line 34 ¶		skipping to change at page 16, line 29 ¶
	using the load information received from each server.		using the load information received from each server.
	------S1		------S1
	/		/
	C		C
	\		\
	------S2		------S2
	Figure 6: Basic Client Server Scenario		Figure 6: Basic Client Server Scenario
	Open Issue: Will a Diameter node include potential peers that it		If a node supports dynamic discovery, it will not obtain load
	is not currently connected to as part of the candidate set? It is		information from the nodes with which it has no Diameter
	unlikely the client would have load information from peers that it		connection established. Nevertheless it might take into account
	is not currently connected to.		the load information from the other nodes to decide to add
			connections to new nodes with the dynamic discovery mechanism.
	Note: The use of dynamic connections needs to be considered.		Note: The use of dynamic connections needs to be considered.
	A.2. Single Agent		A.2. Single Agent
	Figure 7 shows a client that sends requests to an agent. The agent		Figure 7 shows a client that sends requests to an agent. The agent
	selects the request destination from a set of candidate servers,		selects the request destination from a set of candidate servers,
	using load information received from each server. The client does		using load information received from each server. The client does
	not need to receive load information, since it does not select		not need to receive load information, since it does not select
	between multiple agents.		between multiple agents.
	skipping to change at page 16, line 29 ¶		skipping to change at page 17, line 29 ¶
	servers.		servers.
	This scenario adds a complication that one set of servers may be more		This scenario adds a complication that one set of servers may be more
	loaded than the other set. If, for example, S4 was the least loaded		loaded than the other set. If, for example, S4 was the least loaded
	server, C would need to know to select agent A2 to reach S4. This		server, C would need to know to select agent A2 to reach S4. This
	might require C to receive load information from the servers as well		might require C to receive load information from the servers as well
	as the agents. Alternatively, each agent might use the load of its		as the agents. Alternatively, each agent might use the load of its
	servers as an input into calculating its own load, in effect		servers as an input into calculating its own load, in effect
	aggregating upstream load.		aggregating upstream load.
	Similarly, if C sends a host-routed request [I-D.ietf-dime-ovli], it		Similarly, if C sends a host-routed request [RFC7683], it needs to
	needs to know which agent can deliver requests to the selected		know which agent can deliver requests to the selected server.
	server. Without some special, potentially proprietary, knowledge of		Without some special, potentially proprietary, knowledge of the
	the topology upstream of A1 and A2, C would select the agent based on		topology upstream of A1 and A2, C would select the agent based on the
	the normal peer selection procedures for the realm and application,		normal peer selection procedures for the realm and application, and
	and perhaps consider the load information from A1 and A2. If C sends		perhaps consider the load information from A1 and A2. If C sends a
	a request to A1 that contains a Destination-Host AVP with a value of		request to A1 that contains a Destination-Host AVP with a value of
	S4, A1 will not be able to deliver the request.		S4, A1 will not be able to deliver the request.
	-----S3		-----S3
	/		/
	---A1------S1		---A1------S1
	/		/
	C		C
	\		\
	---A2------S2		---A2------S2
	\		\
	skipping to change at page 19, line 30 ¶		skipping to change at page 20, line 30 ¶
	---A1---A3---S[1], S[2]...S[p]		---A1---A3---S[1], S[2]...S[p]
	/ | \ / |\ /		/ | \ / |\ /
	C | x | x		C | x | x
	\ | / \ |/ \		\ | / \ |/ \
	---A2---A4---S[p+1], S[p+2] ...S[n]		---A2---A4---S[p+1], S[p+2] ...S[n]
	Figure 13: Full Mesh		Figure 13: Full Mesh
	A.8. Partitions		A.8. Partitions
	A Diameter network with multiple is said to be "partitioned" when		A Diameter network with multiple servers is said to be "partitioned"
	only a subset of available servers can server a particular realm-		when only a subset of available servers can serve a particular realm-
	routed request. For example, one group of servers may handle users		routed request. For example, one group of servers may handle users
	whose names start with "A" through "M", and another group may handle		whose names start with "A" through "M", and another group may handle
	"N" through "Z".		"N" through "Z".
	In such a partitioned network, nodes cannot load-balance requests		In such a partitioned network, nodes cannot load-balance requests
	across partitions, since not all servers can handle the request. A		across partitions, since not all servers can handle the request. A
	client, or an intermediate agent, may still be able to load-balance		client, or an intermediate agent, may still be able to load-balance
	between servers inside a partition.		between servers inside a partition.
	A.9. Active-Standby Nodes		A.9. Active-Standby Nodes
	skipping to change at page 20, line 11 ¶		skipping to change at page 21, line 11 ¶
	active peers became unavailable. For example, requests might be		active peers became unavailable. For example, requests might be
	diverted to a stand-by peer if one or more active peers becomes		diverted to a stand-by peer if one or more active peers becomes
	overloaded.		overloaded.
	A.10. Addition and removal of Nodes		A.10. Addition and removal of Nodes
	When a Diameter node is added, the new node will start by advertising		When a Diameter node is added, the new node will start by advertising
	its load. Downstream nodes will need to factor the new load		its load. Downstream nodes will need to factor the new load
	information into load balancing decisions. The downstream nodes		information into load balancing decisions. The downstream nodes
	should attempt to ensure a smooth increase of the traffic to the new		should attempt to ensure a smooth increase of the traffic to the new
	node, avoiding an immediate spike of traffic to the new node. It		node, avoiding an immediate spike of traffic to the new node. The
	should be determined if this use case is in the scope of the load		handling of such a smooth increase is implementation specific but it
	control mechanism.		can rely on the evolution of load information received from the new
			node and from the other nodes.
	When removing a node in a controlled way (e.g. for maintenance		When removing a node in a controlled way (e.g. for maintenance
	purpose, so outside a failure case), it might be appropriate to		purpose, so outside a failure case), it might be appropriate to
	progressively reduce the traffic to this node by routing traffic to		progressively reduce the traffic to this node by routing traffic to
	other nodes. Simple load information (load percentage) would be not		other nodes. Simple load information (load percentage) would be not
	sufficient. It should be determined if this use case is in the scope		sufficient. The handling of the node removal is implementation
	of the load control mechanism.		specific but it can rely on the evolution of the load information
			received from the node to be removed
	Authors' Addresses		Authors' Addresses
	Ben Campbell		Ben Campbell
	Oracle		Oracle
	7460 Warren Parkway # 300		7460 Warren Parkway # 300
	Frisco, Texas 75034		Frisco, Texas 75034
	USA		USA
	Email: ben@nostrum.com		Email: ben@nostrum.com
	Steve Donovan (editor)		Steve Donovan (editor)
	Oracle		Oracle
	7460 Warren Parkway # 300		7460 Warren Parkway # 300
	Frisco, Texas 75034		Frisco, Texas 75034
	United States		United States
	Email: srdonovan@usdonovans.com		Email: srdonovan@usdonovans.com
	Jean-Jacques Trottin		Jean-Jacques Trottin
	Alcatel-Lucent		Nokia
	Route de Villejust		Route de Villejust
	91620 Nozay		91620 Nozay
	France		France
	Email: jean-jacques.trottin@alcatel-lucent.com		Email: jean-jacques.trottin@nokia.com
End of changes. 76 change blocks.
	184 lines changed or deleted		231 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/