draft-ietf-dime-load-00.txt		draft-ietf-dime-load-01.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: Informational Oracle
	Expires: January 7, 2016 JJ. Trottin		Expires: April 14, 2016 JJ. Trottin
	Alcatel-Lucent		Alcatel-Lucent
	July 6, 2015		October 12, 2015
	Diameter Load Information Conveyance		Diameter Load Information Conveyance
	draft-ietf-dime-load-00		draft-ietf-dime-load-01
	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. RFC 7068 describes requirements for Overload Control 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. The
	Diameter Overload Information Conveyance (DOIC) solution describes a		Diameter Overload Information Conveyance (DOIC) solution describes a
	mechanism meeting most of the requirements, but does not currently		mechanism meeting most of the requirements, but does not currently
	include the ability to send load information.		include the ability to send load information.
	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 January 7, 2016.		This Internet-Draft will expire on April 14, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3		2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
	3. Conventions Used in This Document . . . . . . . . . . . . . . 3		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. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 8		6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 9
	6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 8		6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 9
	6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 8		6.1.1. End-point Reporting Node Behavior . . . . . . . . . . 10
	6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 9		6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 10
	6.2. Receiving Node Behavior . . . . . . . . . . . . . . . . . 9		6.2. Receiving Node Behavior . . . . . . . . . . . . . . . . . 11
	6.2.1. Endpoint Receiving Node Behavior . . . . . . . . . . 9		6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
	6.2.2. Agent Receiving Node Behavior . . . . . . . . . . . . 9		7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 12
	6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9		7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 9		7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 12
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 10		9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 14
	A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 10		9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 14
	A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . 14
	A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . 14
	A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 13		Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 15
	A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 13		A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 15
	A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 14		A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 15
	A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 14		A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 16
	A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 14		A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 17
	A.10. Addition and removal of Nodes . . . . . . . . . . . . . . 15		A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 18
			A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 19
			A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 19
			A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 19
			A.10. Addition and removal of Nodes . . . . . . . . . . . . . . 20
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	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]. At the time of this writing, the DIME working group is
	working on the Diameter Overload Information Conveyance (DOIC)		working on the Diameter Overload Information Conveyance (DOIC)
	mechanism [I-D.ietf-dime-ovli] . As currently specified, DOIC		mechanism [I-D.ietf-dime-ovli] . As currently 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
	skipping to change at page 6, line 20		skipping to change at page 6, line 22
	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 extension then the load information is ignored.
	The second big difference between DOIC and Load is that DOIC		The second big difference between DOIC and Load is visibility of the
	information is sent end-to-end. The DOIC overload reports much		DOIC or Load information within a Diameter network. DOIC information
	remain in the message all the way from the reporting node to the node		is sent end-to-end resulting in the ability of all nodes in the path
	that is the target for the answer message. For the Load mechanism,		of the answer message that carries the OC-OLR AVP to act on the
	the load information is targeted for the peer of the sender of the		information. The DOIC overload reports much remain in the message
	Load AVPs.		all the way from the reporting node to the node that is the target
			for the answer message.
	Editor's note: It is still being discussed whether a second type		For the Load mechanism there are two types of load reports.
	of Load report can be included that is the load of the end-point
	and is carried end-to-end.
	The Load report applies to an individual node. The Diameter identity		The first is the load of the end-point sending the answering the
	of the node to which it applies is included in the Load report.		message. 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 end-point as part of the server selection decision.
	Note, this is necessary so that supporting nodes can determine if		The second type of load report is a peer report. This report is used
	the load report came from a peer node. If the identity is for a		by Diameter nodes as part of the logic to select the next hop
	non peer node than the peer load report can be ignored.		Diameter node and, as such, do not have significance beyond the peer
			node. These load reports are removed by the first supporting
			Diameter node.
	In addition to the identity of the node to which the report applies,		Because load reports can traverse Diameter nodes that do not support
	the load report includes the relative load of the sending node. This		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.
			This allows for a Diameter node to verify that the load report
			applies to its peer or if it should be ignored.
			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 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 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
	skipping to change at page 7, line 31		skipping to change at page 7, line 41
	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, a sending node that supports the		When sending the answer message, an end-point 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:		answer message. Because it is a Diameter end-point it includes an
			end-point load report.
	C A1 A4 S[n]		C A1 A4 S[n]
	| | | |		| | | |
	| | |<-----|		| | |<-----|
	xxA(Load 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 was from its peer. This is achieved by		load information received is valid. For a host load report this is
	matching the identity included in the load information with the		achieved by matching the identity included in the load information
	identity of the peer node from which the answer message was received.		with the identity of the host node from which the answer message was
			received.
	If the load information does not match then the agent will strip the		Note: If A4 does not support the load mechanism then it will relay
	load AVPs from the message.		the answer message without doing any processing on the load
			information. In this case the load AVPs will be 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 peer 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 tables.
	In all cases, A4 strips the load AVPs from the message.		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 in the message before sending the message to A1:		information AVPs in the message before sending the message to A1:
	C A1 A4 S[n]		C A1 A4 S[n]
	| | | |		| | | |
	| |<-----| |		| |<-----| |
	xxA(Load A4)		| xxA(Load type:peer, source:A4)
			| xxA(Load type:host, source:S[n])
			| | | |
	Figure 4: Answer Message from A4		Figure 4: Answer Message from A4
	A1 follows the same procedures as A4, resulting in the following		If A1 supports the Load mechanism then it processes each of the Load
	message sent to C:		reports it receives separately.
			For the peer load report, A1 first determines if the source of the
			report indicated in the load report matches the DiameterID of the
			Diameter node from which the request was received. If the identities
			do not match then the peer load report is discarded. If the
			identities match then A1 saves the load information in its routing
			tables for routing of subsequent request messages. In both cases A1
			strips the peer load report from the message.
			For the host load report, A1's actions depend on whether A1 is
			responsible for doing server selection. If A1 is not doing server
			selection then A1 ignores the host load report. If A1 is responsible
			for doing server selection then it stores the load information for
			S[n] in its routing tables for the handling of subsequent request
			messages. In both cases A1 leaves the host report in the message.
			A1 then calculates its own load information and inserts load
			information AVPs in the message before sending the message to A1:
	C A1 A4 S[n]		C A1 A4 S[n]
	| | | |		| | | |
	|<-----| | |		|<-----| | |
	xxA(Load A1)		xxA(Load type:peer, source:A1)
			xxA(Load type:host, source:S[n])
	Figure 5: Answer Message from A1		Figure 5: Answer Message from A1
	C follows the same procedure for determining if the Load report was		As with A1, C processes each load report separately.
	received from the peer from which the report was sent and, when
	finding it does, stores the load information for use when making		For the peer load report, C follows the same procedure for
	future routing decisions.		determining if the Load report was received from the peer from which
			the report was sent and, when finding it does, stores the load
			information for use when making future routing decisions.
			For the host load report, C saves the load information only if it is
			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.
	Editor's note: The above needs to be updated if there is agreement		6. Load Mechanism Procedures
	to support end-point Load reports.
	6. Solution Procedures		This section defines the normative behaviors for the Load mechanism.
	6.1. Reporting Node Behavior		6.1. Reporting Node Behavior
	6.1.1. Endpoint Reporting Node Behavior		This section defines the procedures of Diameter nodes that generate
			load reports.
			6.1.1. End-point Reporting Node Behavior
			A Diameter end-point that supports the Diameter Load mechanism MUST
			include a load report of type HOST in sufficient answer messages to
			ensure that all consumers of the load information receive timely
			updates.
			The Diameter end-point MUST include it's own DiameterID in the
			Source-ID AVP included in the Load AVP.
			The Diameter end-point MUST include a Load-Type AVP of type HOST in
			the Load AVP.
			The Diameter end-point MUST include its load value in the Value AVP
			in the load AVP.
			The method for determining the load value included in the load report
			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.
			For instance, if the only consumer of the load reports is the end-
			points peer then the end-point can choose to only include a load
			report when the load of the end-point has changed by a significant
			percentage. If there are consumers of the end-point load report
			other then the end-points peer (this will be the case if other
			nodes are responsible for server selection) then the end-point
			might choose to include load reports in all answer messages as a
			way of ensuring that all nodes doing server 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
			include a PEER load report in sufficient answer messages to ensure
			that all users of the load information receive timely updates.
			The Diameter agent MUST include it's own DiameterID in the Source-ID
			AVP included in the Load AVP.
			The Diameter agent MUST include a Load-Type AVP of type PEER in the
			Load AVP.
			The Diameter agent MUST include its load value in the Value AVP in
			the load AVP.
			The method for determining the load value included in the load report
			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.
			Note: In the case of peer load reports it is only necessary to
			include load reports when the load value has changed by some
			significant value. It is also acceptable to include the load
			report in every answer message handled by the Diameter agent.
	6.2. Receiving Node Behavior		6.2. Receiving Node Behavior
	6.2.1. Endpoint Receiving Node Behavior		This section defines the behavior of Diameter nodes processing load
			reports.
	6.2.2. Agent Receiving Node Behavior		A Diameter node MUST be prepared to process both load reports of type
			HOST and of type PEER, as indicated in the Load-Type AVP included in
			the Load AVP.
			Note that the node needs to be able to handle messages with no
			load reports, messages with just a PEER load report, messages with
			just an HOST load report and messages with both types of load
			reports.
			If the Diameter node is not responsible for doing server selection
			then it SHOULD ignore load reports of type HOST.
			If the Diameter node is responsible for doing server selection then
			it SHOULD save the load value included in the Value AVP included in
			the Load AVP of type HOST in its routing tables.
			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
			answer message by the peer from which the message was received. This
			is achieved by comparing the DiameterID associated with the
			connection from which the message was received with the DiameterID
			included in the Source-ID AVP in the Load report.
			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
			then the node MUST ignore the Load report.
			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
			the node SHOULD save the load information in its routing table.
			How a Diameter node uses load information for making routing
			decisions is an implememtation decision.
	6.3. Extensibility		6.3. Extensibility
			The Load mechanism can be extended to include additional information
			in the load reports.
			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
			this document.
			[RFC6733] defined Grouped AVP extension mechanisms apply. This
			allows, for example, defining a new feature that is mandatory to be
			understood even when piggybacked on an existing application.
			As with any Diameter specification, RFC6733 requires all new AVPs 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.
			7.1. Load AVP
			The Load AVP (AVP code TBD1) is of type Grouped and is used to convey
			load information between Diameter nodes.
			Load ::= < AVP Header: TBD1 >
			[ Load-Type ]
			[ Load-Value ]
			[ SourceID ]
			* [ AVP ]
			7.2. Load-Type AVP
			The Load-Type AVP (AVP code TBD2) is of type Enumerated. It is used
			to convey the type of Diameter node that sent the load information.
			The following values are defined:
			HOST 0 The load report is for a host.
			PEER 1 The load report is for a peer.
			7.3. Load-Value AVP
			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
			report.
			7.4. SourceID AVP
			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.
			7.5. Attribute Value Pair flag rules
			+---------+
			|AVP flag |
			|rules |
			+----+----+
			AVP Section | |MUST|
			Attribute Name Code Defined Value Type |MUST| NOT|
			+--------------------------------------------------+----+----+
			|Load TBD1 x.1 Grouped | | V |
			+--------------------------------------------------+----+----+
			|Load-Type TBD2 x.2 Enumerated | | V |
			+--------------------------------------------------+----+----+
			|Load-Value TBD3 x.3 Unsigned64 | | V |
			+--------------------------------------------------+----+----+
			|SourceID TBD4 x.4 DiameterID | | V |
			+--------------------------------------------------+----+----+
			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.
	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
	Service (DoS) attacks, where a node known to be already heavily		Service (DoS) attacks, where a node known to be already heavily
	loaded might be a tempting target. Load information might also be		loaded might be a tempting target. Load information might also be
	useful as feedback about the success of an ongoing DoS attack.		useful as feedback about the success of an ongoing DoS attack.
	Any load information conveyance mechanism will need to allow		Any load information conveyance mechanism will need to allow
	operators to avoid sending load information to nodes that are not		operators to avoid sending load information to nodes that are not
	authorized to receive it. Since Diameter currently only offers		authorized to receive it. Since Diameter currently only offers
	authentication of nodes at the transport level, any solution that		authentication of nodes at the transport level, any solution that
	sends load information to non-peer nodes might require a transitive-		sends load information to non-peer nodes might require a transitive-
	trust model.		trust model.
	9. IANA Considerations		9. IANA Considerations
	This document makes no requests of IANA.		9.1. AVP Codes
			New AVPs defined by this specification are listed in
			Section Section 7. All AVP codes are allocated from the
			'Authentication, Authorization, and Accounting (AAA) Parameters' AVP
			Codes registry.
			9.2. New Registries
			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]
			Donovan, S., "Diameter Agent Overload", draft-ietf-dime-
			agent-overload-02 (work in progress), August 2015.
	[I-D.ietf-dime-ovli]		[I-D.ietf-dime-ovli]
	Korhonen, J., Donovan, S., Campbell, B., and L. Morand,		Korhonen, J., Donovan, S., Campbell, B., and L. Morand,
	"Diameter Overload Indication Conveyance", draft-ietf-		"Diameter Overload Indication Conveyance", draft-ietf-
	dime-ovli-03 (work in progress), July 2014.		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, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,		[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
	"Diameter Base Protocol", RFC 6733, October 2012.		Ed., "Diameter Base Protocol", RFC 6733,
			DOI 10.17487/RFC6733, October 2012,
			<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, November 2013.		Requirements", RFC 7068, DOI 10.17487/RFC7068, November
			2013, <http://www.rfc-editor.org/info/rfc7068>.
	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,
	February 2000.		DOI 10.17487/RFC2782, February 2000,
			<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		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		scenario is in scope for this effort, or even a good idea. Some
	scenarios might be considered as not relevant in practice and		scenarios might be considered as not relevant in practice and
	subsequently discarded.		subsequently discarded.
End of changes. 37 change blocks.
	78 lines changed or deleted		307 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/