draft-ietf-dime-load-02.txt		draft-ietf-dime-load-03.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: Standards Track Oracle		Intended status: Standards Track Oracle
	Expires: September 19, 2016 JJ. Trottin		Expires: March 31, 2017 JJ. Trottin
	Nokia		Nokia
	March 18, 2016		September 27, 2016
	Diameter Load Information Conveyance		Diameter Load Information Conveyance
	draft-ietf-dime-load-02		draft-ietf-dime-load-03
	Abstract		Abstract
	This document defines a mechanism for sharing of Diameter load		This document defines a mechanism for conveying of Diameter load
	information. [RFC7068] describes requirements for Overload Control		information. [RFC7068] describes requirements for Overload Control
	in 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) [RFC7683] solution		Diameter Overload Information Conveyance (DOIC) [RFC7683] solution
	describes a mechanism meeting most of the requirements, but does not		describes a mechanism meeting most of the requirements, but does not
	currently 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
	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 September 19, 2016.		This Internet-Draft will expire on March 31, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	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 . . . . . . . . . . . . . . . . . . . 8
	6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 10		6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 10
	6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10		6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10
	6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 10		6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 10
	6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 11		6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 11
	6.2. Receiving Node Behavior . . . . . . . . . . . . . . . . . 11		6.2. Receiving Node Behavior . . . . . . . . . . . . . . . . . 12
	6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12		6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13
			6.4. Addition and removal of Nodes . . . . . . . . . . . . . . 13
	7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 13		7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 13
	7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 13		7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 13		7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 14
	7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 13		7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 14
	7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 14		7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 14
	7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 14		7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 15		9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 15		9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . 15		10.1. Normative References . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . 16
	Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 16		Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 16
	A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 16		A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 16
	A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 16		A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 17
	A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 17		A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 17
	A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 18		A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 18
	A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 19		A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 19
	A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 19		A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 20
	A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 20		A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 20
	A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 20		A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 21
	A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 20		A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 21
	A.10. Addition and removal of Nodes . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	[RFC7068] describes requirements for Overload Control in Diameter		[RFC7068] describes requirements for Overload Control in Diameter
	[RFC6733]. The DIME working group has finished the Diameter Overload		[RFC6733]. The DIME working group has finished the Diameter Overload
	Information Conveyance (DOIC) mechanism [RFC7683]. As currently		Information Conveyance (DOIC) mechanism [RFC7683]. As currently
	specified, DOIC fulfills some, but not all, of the requirements.		specified, DOIC 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 23 and Req 24:
	mechanism where Diameter nodes can indicate their current load, even
	if they are not currently overloaded. DOIC also does not fulfill Req		REQ 23: The solution MUST provide sufficient information to enable
	23, which requires that nodes that divert traffic away from		a load-balancing node to divert messages that are rejected or
	overloaded nodes be provided with sufficient information to select		otherwise throttled by an overloaded upstream node to other
	targets that are most likely to have sufficient capacity.		upstream nodes that are the most likely to have sufficient
			capacity to process them.
			REQ 24: The solution MUST provide a mechanism for indicating load
			levels, even when not in an overload condition, to assist nodes in
			making decisions to prevent overload conditions from occurring.
	There are several other requirements in [RFC7068] 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 deferred load information conveyance to a DOIC extension or a		and deferred load information conveyance to a DOIC extension or a
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 46 ¶
	requirements from RFC 7068.		requirements from RFC 7068.
	2. Terminology and Abbreviations		2. Terminology and Abbreviations
	DOIC		DOIC
	Diameter Overload Information Conveyance ([RFC7683])		Diameter Overload Information Conveyance ([RFC7683])
	Load		Load
	The relative capacity of a Diameter node. A low load level		The he relative usage of the Diameter message processing capacity
	indicates that the Diameter node is under utilized. A high load		of a Diameter node. A low load level indicates that the Diameter
	level indicates that the node is closer to being fully utilized.		node is under utilized. A high load 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, Reacting Node
	Reporting node and reacting node terminology is defined in		Reporting node and reacting node terminology is defined in
	[RFC7683].		[RFC7683].
	Routing Information		Routing Information
	Routing Information - Routing information referred to in this		Routing Information referred to in this document can include the
	document can include the Routing and Peer tables defined in RFC		Routing and Peer tables defined in RFC 6733. It can also include
	6733. It can also include other implementation specific tables		other implementation specific tables used to store load
	used to store load information. This document does not define the		information. This document does not define the structure of such
	structure of such tables.		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 did 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 may be 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) [RFC7683] indicates an explicit request for action on the part		(OLR) [RFC7683] indicates an explicit request for action on the part
	of the reacting node. That is, the OLR requests that the reacting		of the reacting node. That is, the OLR requests that the reacting
	node reduce the offered load -- the actual traffic sent to the		node reduce the offered load -- the actual traffic sent to 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 (by default), or as prescribed by the
	Effectively, DOIC provides a contract between the reporting node and		selected abatement algorithm. Effectively, DOIC provides a contract
	the reacting node.		between the reporting node and 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.
	None of this prevents a Diameter node from deciding to reduce the		None of this prevents a Diameter node from deciding to reduce the
	offered load based on load information. The fundamental difference		offered load based on load information. The fundamental difference
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 36 ¶
	diversion as an overload abatement technique, as described in		diversion as an overload abatement technique, as described in
	[RFC7683]. When a reacting node diverts traffic away from an		[RFC7683]. When a reacting node diverts traffic away from an
	overloaded node, it needs load information for the other candidates		overloaded node, it needs load information for the other candidates
	for that traffic in order to effectively load balance the diverted		for that traffic in order to effectively load balance the diverted
	load between potential candidates. Otherwise, diversion has a		load between potential candidates. Otherwise, diversion has 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, but
	node might also take other proactive steps to reduce offered load		the diameter node can take other proactive steps as well.
	based on load information, so that the loaded node never goes into
	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
	server-to-client transactions), both of these uses are most		server-to-client transactions), both of these uses of load
	effectively accomplished by a Diameter node that performs server		information should be accomplished by a Diameter node that performs
	selection. Typically, server selection is performed by a node (a		server selection. Typically, server selection is performed by a node
	client or an agent) that is an immediate peer of the server.		(a client or an agent) that is an immediate peer of the server.
	However, there are scenarios (see Appendix A) where a client or proxy		However, there are scenarios (see Appendix A) where a client or proxy
	that is not the immediate peer to the selected servers performs		that is not the immediate peer to the selected servers performs
	server selection. In this case, the client or proxy enforces the		server selection. In this case, the client or proxy enforces the
	server selection by inserting a Destination-Host AVP.		server selection by inserting a Destination-Host AVP.
	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.
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 37 ¶
	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 mechanism 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, although only one node actually comsumes and reacts to
	all the way from the reporting node to the node that is the target		the report. The DOIC overload reports remain in the message all the
	for the answer message.		way from the reporting node to the node that is the target 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 and only
			the first one is transmitted end-to-end.
	The first is the load of the endpoint sending the answer message.		The first is the load of the endpoint sending the answer message.
	This load report is carried end-to-end to enable any nodes that make		This load report is carried end-to-end to enable any nodes that make
	server selection decisions to use the load status of the sending		server selection decisions to use the load status of the sending
	endpoint as part of the server selection decision.		endpoint as part of the server selection decision. Unlike with DOIC,
			more than one node may make use of the load information received.
	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, does not have significance beyond the
	node. These load reports are removed by the first supporting		peer node. These load reports are removed by the first supporting
	Diameter node to receive the report.		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 a load report applies		This allows for a Diameter node to verify that a load report 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 a value indicating the load of the sending
	relative load is specified in a manner consistent with that defined		node relative load of the sending node, specified in a manner
	for DNS SRV [RFC2782].		consistent with that defined for DNS SRV [RFC2782].
	The goal is make it possible to use both the load values received as		The goal is to make it possible to use both the load values received
	a part of the Diameter Load mechanism and weight values received as a		as a part of the Diameter Load mechanism and weight values received
	result of a DNS SRV query. As a result, the Diameter load value has		as a result of a DNS SRV query. As a result, the Diameter load value
	a range of 0-65535. This value and DNS SRV weight values are then		has a range of 0-65535. This value and DNS SRV weight values are
	used in a distribution algorithm similar to that specified in		then used in a distribution algorithm similar to that specified in
	[RFC2782].		[RFC2782].
	The DNS SRV distribution algorithm results in more messages being		The DNS SRV distribution algorithm results in more messages being
	sent to a node with a higher weight value. As a result, a higher		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		Diameter load value indicates a LOWER load on the sending node. A
	node that is heavily loaded sends a lower Diameter load value.		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		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.		of 65535. A node that is 100% loaded would have a load value of 0.
	The distribution algorithm used by Diameter nodes supporting the		The distribution algorithm used by Diameter nodes supporting the
	Diameter Load mechanism is an implementation decision but it needs to		Diameter Load mechanism is an implementation decision but it needs to
	result in similar behavior as the algorithm specified in [RFC2782].		result in similar behavior to the algorithm described for the use of
			weigh values 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 also 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
	amount. 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 node's
			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]
	skipping to change at page 8, line 27 ¶		skipping to change at page 8, line 35 ¶
	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 endpoint 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 its own load information in the
	answer message. Because it is a Diameter endpoint it includes a HOST		answer message. Because it is a Diameter endpoint it includes a HOST
	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 A4's actions depend on
	load information received is valid. For a HOST load report this is		whether A4 is responsible for doing server selection. If A4 is not
	achieved by matching the identity included in the load information		doing server selection then A4 ignores the HOST load report. If A4
	with the identity of the host node from which the answer message was		is responsible for doing server selection then it stores the load
	received.		information for S[n] in its routing information for the handling of
			subsequent request messages. In both cases A4 leaves the HOST report
			in the message.
	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 information AVPs will be		information. In this case the load information AVPs will be
	relayed without change.		relayed without change.
	If the identity included in the load information AVPs matches the
	identity of the host from which the load information is received then
	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
	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 of type PEER in the message before sending the		information AVPs of type PEER in the message before sending the
	message to A1:		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
	skipping to change at page 9, line 47 ¶		skipping to change at page 9, line 49 ¶
	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 information for the handling of subsequent		S[n] in its routing information for the handling of subsequent
	request messages. In both cases A1 leaves the HOST report in the		request messages. In both cases A1 leaves the HOST report in the
	message.		message.
	A1 then calculates its own load information and inserts load		A1 then calculates its own load information and inserts load
	information AVPs of type PEER in the message before sending the		information AVPs of type PEER in the message before sending the
	message to A1:		message to C:
	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.
	skipping to change at page 10, line 42 ¶		skipping to change at page 10, line 42 ¶
	This section defines the procedures of Diameter reporting nodes that		This section defines the procedures of Diameter reporting nodes that
	generate load reports.		generate load reports.
	6.1.1. Endpoint Reporting Node Behavior		6.1.1. Endpoint Reporting Node Behavior
	A Diameter endpoint 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 endpoint MUST include it's own DiameterIdentity in the		The Diameter endpoint MUST include its own DiameterIdentity in the
	Source-ID AVP included in the Load AVP.		SourceID AVP included in the Load AVP.
	The Diameter endpoint 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 endpoint MUST include its load value in the Value AVP in		The Diameter endpoint 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 LOAD value should be calculated in a way that reflects the
	is an implementation decision.		available load independently of the weight of each server, in order
			to accurately compare LOAD values from different nodes. Any specific
			LOAD value needs to identify the same amount of available capacity,
			regardless the Diameter node that calculates the value.
			The mechanism used to calculate the LOAD value that fulfils this
			requirement is an implementation decision.
	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		For instance, if the only consumer of the load reports is the
	endpoints peer then the endpoint can choose to only include a load		endpoint's peer then the endpoint can choose to only include a
	report when the load of the endpoint has changed by a meaningful		load report when the load of the endpoint has changed by a
	percentage. If there are consumers of the endpoint load report		meaningful percentage. If there are consumers of the endpoint
	other then the endpoints peer (this will be the case if other		load report other then the endpoint's peer (this will be the case
	nodes are responsible for server selection) then the endpoint		if other nodes are responsible for server selection) then the
	might choose to include load reports in all answer messages as a		endpoint might choose to include load reports in all answer
	way of ensuring that all nodes doing server selection get accurate		messages as a way of ensuring that all nodes doing server
	load information.		selection get accurate 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 DiameterIdentity in the		The Diameter agent MUST include its own DiameterIdentity in the
	Source-ID AVP included in the Load AVP.		SourceID 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 Load-Value AVP
	the load AVP.		in the load AVP.
	The method for determining the load value included in the load report		The LOAD value should be calculated in a way that reflects the
	is an implementation decision.		available load independently of the weight of each agent, in order to
			accurately compare LOAD values from different nodes. Any specific
			LOAD value needs to identify the same amount of available capacity,
			regardless the Diameter node that calculates the value.
			The mechanism used to calculate the LOAD value that fulfils this
			requirement is an implementation decision.
	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
	meaningful value, as long as the agent insures that all peers		meaningful value, as long as the agent insures that all peers
	receive the report. It is also acceptable to include the load		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
	skipping to change at page 12, line 16 ¶		skipping to change at page 12, line 30 ¶
	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 Load-Value AVP included
	the Load AVP of type HOST in its routing information.		in 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 DiameterIdentity associated with the		is achieved by comparing the DiameterIdentity associated with the
	connection from which the message was received with the		connection from which the message was received with the
	DiameterIdentity included in the Source-ID AVP in the Load report.		DiameterIdentity included in the SourceID 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 information.		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
	skipping to change at page 13, line 9 ¶		skipping to change at page 13, line 22 ¶
	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		As with any Diameter specification, [RFC6733] requires all new AVPs
	to be registered with IANA. See Section 9 for the required		to be registered with IANA. See Section 9 for the required
	procedures.		procedures.
			6.4. Addition and removal of Nodes
			When a Diameter node is added, the new node will start by advertising
			its load. Downstream nodes will need to factor the new load
			information into load balancing decisions. The downstream nodes can
			attempt to ensure a smooth increase of the traffic to the new node,
			avoiding an immediate spike of traffic to the new node. The method
			for handling of such a smooth increase is implementation specific but
			it 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
			purpose, so outside a failure case), it might be appropriate to
			progressively reduce the traffic to this node by routing traffic to
			other nodes. Simple load information (load percentage) would not be
			sufficient. The method for handling of the node removal is
			implementation specific but it can rely on the evolution of the load
			information received from the node to be removed.
	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.
	Load ::= < AVP Header: TBD1 >		Load ::= < AVP Header: TBD1 >
	skipping to change at page 16, line 9 ¶		skipping to change at page 16, line 47 ¶
	[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
	discusses how load information might be used in each scenario.		discusses how load information might be used in each scenario.
	Nothing in this section should be construed to mean that a given
	scenario is in scope for this effort, or even a good idea. Some
	scenarios might be considered as not relevant in practice and
	subsequently discarded.
	A.1. No Agent		A.1. No Agent
	Figure 6 shows a simple client-server scenario, where a client picks		Figure 6 shows a simple client-server scenario, where a client picks
	from a set of candidate servers available for a particular realm and		from a set of candidate servers available for a particular realm and
	application. The client selects the server for a given transaction		application. The client selects the server for a given transaction
	using the load information received from each server.		using the load information received from each server.
	------S1		------S1
	/		/
	skipping to change at page 21, line 5 ¶		skipping to change at page 21, line 29 ¶
	The previous scenarios assume that traffic can be load balanced among		The previous scenarios assume that traffic can be load balanced among
	all peers that are eligible to handle a request. That is, the peers		all peers that are eligible to handle a request. That is, the peers
	operate in an "active-active" configuration. In an "active-standby"		operate in an "active-active" configuration. In an "active-standby"
	configuration, traffic would be load-balanced among active peers.		configuration, traffic would be load-balanced among active peers.
	Requests would only be sent to peers in a "standby" state if the		Requests would only be sent to peers in a "standby" state if the
	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
	When a Diameter node is added, the new node will start by advertising
	its load. Downstream nodes will need to factor the new load
	information into load balancing decisions. The downstream nodes
	should attempt to ensure a smooth increase of the traffic to the new
	node, avoiding an immediate spike of traffic to the new node. The
	handling of such a smooth increase is implementation specific but it
	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
	purpose, so outside a failure case), it might be appropriate to
	progressively reduce the traffic to this node by routing traffic to
	other nodes. Simple load information (load percentage) would be not
	sufficient. The handling of the node removal is implementation
	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
End of changes. 46 change blocks.
	125 lines changed or deleted		136 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/