< draft-ietf-dime-agent-overload-06.txt		draft-ietf-dime-agent-overload-07.txt >
	Diameter Maintenance and Extensions (DIME) S. Donovan		Diameter Maintenance and Extensions (DIME) S. Donovan
	Internet-Draft Oracle		Internet-Draft Oracle
	Intended status: Standards Track June 21, 2016		Updates: RFC7683 (if approved) December 1, 2016
	Expires: December 23, 2016		Intended status: Standards Track
			Expires: June 4, 2017
	Diameter Agent Overload and the Peer Overload Report		Diameter Agent Overload and the Peer Overload Report
	draft-ietf-dime-agent-overload-06.txt		draft-ietf-dime-agent-overload-07.txt
	Abstract		Abstract
	This specification documents an extension to the Diameter Overload		This specification documents an extension to RFC 7683 (Diameter
	Indication Conveyance (DOIC) [RFC7683] base solution. The extension		Overload Indication Conveyance (DOIC)) base solution. The extension
	defines the Peer overload report type. The initial use case for the		defines the Peer overload report type. The initial use case for the
	Peer report is the handling of occurrences of overload of a Diameter		Peer report is the handling of occurrences of overload of a Diameter
	agent.		agent.
	Requirements		Requirements
	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].
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 41 ¶
	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 December 23, 2016.		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 46 ¶		skipping to change at page 2, line 47 ¶
	6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 14		6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 14
	6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14		6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14
	6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15		6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15
	6.3. SourceID . . . . . . . . . . . . . . . . . . . . . . . . 15		6.3. SourceID . . . . . . . . . . . . . . . . . . . . . . . . 15
	6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 15		6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
	7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 16		7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.2. New registries . . . . . . . . . . . . . . . . . . . . . 16		7.2. New registries . . . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	10. Normative References . . . . . . . . . . . . . . . . . . . . 16		10. Normative References . . . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This specification documents an extension to the Diameter Overload		This specification documents an extension to the Diameter Overload
	Indication Conveyance (DOIC) [RFC7683] base solution. The extension		Indication Conveyance (DOIC) [RFC7683] base solution. The extension
	defines the Peer overload report type. The initial use case for the		defines the Peer overload report type. The initial use case for the
	Peer report is the handling of occurrences of overload of a Diameter		Peer report is the handling of occurrences of overload of a Diameter
	agent.		agent.
	skipping to change at page 7, line 9 ¶		skipping to change at page 7, line 9 ¶
	In the case where both agents are reporting overload, the client may		In the case where both agents are reporting overload, the client may
	need to start decreasing the total traffic sent to the agents. This		need to start decreasing the total traffic sent to the agents. This
	would be done in a similar fashion as discussed in Section 3.1.1 The		would be done in a similar fashion as discussed in Section 3.1.1 The
	amount of traffic depends on the combined reduction requested by the		amount of traffic depends on the combined reduction requested by the
	two agents.		two agents.
	3.1.3. Agent Chains		3.1.3. Agent Chains
	There are also deployment scenarios where there can be multiple		There are also deployment scenarios where there can be multiple
	Diameter Agents between Diameter Clients and Diameter Servers. An		Diameter Agents between Diameter Clients and Diameter Servers. An
	example of this type of deployment include when there are edge agents		example of this type of deployment include when there are Diameter
	between Diameter networks.		agents between administrative domains.
	Figure 5 illustrates one such network deployment case. Note that		Figure 5 illustrates one such network deployment case. Note that
	while this figure shows a maximum of two agents being involved in a		while this figure shows a maximum of two agents being involved in a
	Diameter transaction, it is possible that more than two agents could		Diameter transaction, it is possible that more than two agents could
	be in the path of a transaction.		be in the path of a transaction.
	+---+ +---+ +-+		+---+ +---+ +-+
	--|a11|-----|a21|---|s|		--|a11|-----|a21|---|s|
	+-+ / +---+ \ / +---+\ /+-+		+-+ / +---+ \ / +---+\ /+-+
	|c|- x x		|c|- x x
	skipping to change at page 8, line 46 ¶		skipping to change at page 8, line 46 ¶
	5. Peer Report Behavior		5. Peer Report Behavior
	This section defines the normative behavior associated with the Peer		This section defines the normative behavior associated with the Peer
	Report extension to the DOIC solution.		Report extension to the DOIC solution.
	5.1. Capability Announcement		5.1. Capability Announcement
	5.1.1. Reacting Node Behavior		5.1.1. Reacting Node Behavior
	When sending a Diameter request a DOIC node that supports the		When sending a Diameter request a DOIC node that supports the
	OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with		OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP
	an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.		an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.
	When sending a request a DOIC node that supports the OC_PEER_REPORT		When sending a request a DOIC node that supports the OC_PEER_REPORT
	feature MUST include a SourceID AVP in the OC-Supported-Features AVP		feature MUST include a SourceID AVP in the OC-Supported-Features AVP
	with its own DiameterIdentity.		with its own DiameterIdentity.
	Note: This allows the DOIC nodes in the path of the request to
	determine if the indication of support came from a Diameter peer
	or if the request traversed a node that does not support the
	OC_PEER_REPORT feature.
	When an agent relays a request that includes a SourceID AVP in the		When an agent relays a request that includes a SourceID AVP in the
	OC-Supported-Features AVP, a DOIC node that supports the		OC-Supported-Features AVP, a DOIC node that supports the
	OC_PEER_REPORT feature MUST remove the received SourceID AVP and		OC_PEER_REPORT feature MUST remove the received SourceID AVP and
	replace it with a SourceID AVP containing its own Diameter identity.		replace it with a SourceID AVP containing its own Diameter identity.
	5.1.2. Reporting Node Behavior		5.1.2. Reporting Node Behavior
	When receiving a request a DOIC node that supports the OC_PEER_REPORT		When receiving a request a DOIC node that supports the OC_PEER_REPORT
	feature MUST update transaction state with an indication of whether		feature MUST update transaction state with an indication of whether
	or not the peer from which the request was received supports the		or not the peer from which the request was received supports the
	skipping to change at page 16, line 9 ¶		skipping to change at page 16, line 9 ¶
	Attribute Name Code Defined Value Type |MUST| NOT|		Attribute Name Code Defined Value Type |MUST| NOT|
	+--------------------------------------------------------+----+----+		+--------------------------------------------------------+----+----+
	|OC-Peer-Algo TBD1 x.x Unsigned64 | | V |		|OC-Peer-Algo TBD1 x.x Unsigned64 | | V |
	|SourceID TBD2 x.x DiameterIdentity | | V |		|SourceID TBD2 x.x DiameterIdentity | | V |
	+--------------------------------------------------------+----+----+		+--------------------------------------------------------+----+----+
	7. IANA Considerations		7. IANA Considerations
	7.1. AVP codes		7.1. AVP codes
	New AVPs defined by this specification are listed in Section 6. All		New AVPs defined by this specification are listed in Section 6.4.
	AVP codes are allocated from the 'Authentication, Authorization, and		All AVP codes are allocated from the 'Authentication, Authorization,
	Accounting (AAA) Parameters' AVP Codes registry.		and Accounting (AAA) Parameters' AVP Codes registry.
			One new OC-Report-Type AVP value is defined in Section 6.2.1
	7.2. New registries		7.2. New registries
	There are no new IANA registries introduced by this document.		There are no new IANA registries introduced by this document.
	The values used for the OC-Peer-Algo AVP are the subset of the "OC-		The values used for the OC-Peer-Algo AVP are the subset of the "OC-
	Feature-Vector AVP Values (code 622)" registry. Only the values in		Feature-Vector AVP Values (code 622)" registry. Only the values in
	that registry that apply to overload abatement algorithms apply to		that registry that apply to overload abatement algorithms apply to
	the OC-Peer-Algo AVP.		the OC-Peer-Algo AVP.
End of changes. 9 change blocks.
	18 lines changed or deleted		16 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/