< draft-ietf-dime-load-03.txt		draft-ietf-dime-load-04.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: March 31, 2017 JJ. Trottin		Expires: June 4, 2017 JJ. Trottin
	Nokia		Nokia
	September 27, 2016		December 1, 2016
	Diameter Load Information Conveyance		Diameter Load Information Conveyance
	draft-ietf-dime-load-03		draft-ietf-dime-load-04
	Abstract		Abstract
	This document defines a mechanism for conveying 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
	in Diameter. This includes a requirement to allow Diameter nodes to		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.
	Diameter Overload Information Conveyance (DOIC) [RFC7683] solution		RFC7683 (Diameter Overload Information Conveyance (DOIC)) 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
	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 March 31, 2017.		This Internet-Draft will expire on June 4, 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 23 ¶		skipping to change at page 2, line 23 ¶
	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 . . . . . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . . . 12		6.2. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12
	6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13		6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13
	6.4. Addition and removal of Nodes . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 14		7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 14
	7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 14		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 . . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	skipping to change at page 3, line 46 ¶		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 he relative usage of the Diameter message processing capacity		The relative usage of the Diameter message processing capacity of
	of a Diameter node. A low load level indicates that the Diameter		a Diameter node. A low load level indicates that the Diameter
	node is under utilized. A high load level indicates that the node		node is under utilized. A high load level indicates that the node
	is closer to being fully utilized.		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
	skipping to change at page 12, line 11 ¶		skipping to change at page 12, line 11 ¶
	requirement is an implementation decision.		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. Reacting 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 load reports of type HOST		A Diameter node MUST be prepared to process load reports of type HOST
	and of type PEER, as indicated in the Load-Type AVP included in the		and of type PEER, as indicated in the Load-Type AVP included in the
	Load AVP received in the same answer message or from multiple answer		Load AVP received in the same answer message or from multiple answer
	messages.		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
	skipping to change at page 16, line 31 ¶		skipping to change at page 16, line 31 ¶
	[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>.
			[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>.
	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.
	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
End of changes. 10 change blocks.
	17 lines changed or deleted		17 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/