draft-ietf-dime-agent-overload-11.txt   rfc8581.txt 
Diameter Maintenance and Extensions (DIME) S. Donovan Internet Engineering Task Force (IETF) S. Donovan
Internet-Draft Oracle Request for Comments: 8581 Oracle
Updates: RFC7683 (if approved) March 22, 2017 Updates: 7683 August 2019
Intended status: Standards Track Category: Standards Track
Expires: September 23, 2017 ISSN: 2070-1721
Diameter Agent Overload and the Peer Overload Report Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-11.txt
Abstract Abstract
This specification documents an extension to RFC 7683 (Diameter This specification documents an extension to the Diameter Overload
Overload Indication Conveyance (DOIC)) base solution. The extension Indication Conveyance (DOIC), a base solution for Diameter overload
defines the Peer overload report type. The initial use case for the defined in RFC 7683. The extension defines the Peer Overload report
Peer report is the handling of occurrences of overload of a Diameter type. The initial use case for the peer report is the handling of
agent. occurrences of overload of a Diameter Agent.
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 23, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8581.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4 3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 4 4. Peer-Report Use Cases . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 5 4.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 5
3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6 4.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 5
3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6
3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 8 4.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8 4.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 8
4. Interaction Between Host/Realm and Peer Overload Reports . . 8 4.2.1. Hop-by-Hop Abatement Algorithms . . . . . . . . . . . 8
5. Peer Report Behavior . . . . . . . . . . . . . . . . . . . . 8 5. Interaction Between Host/Realm and Peer Overload Reports . . 9
5.1. Capability Announcement . . . . . . . . . . . . . . . . . 9 6. Peer-Report Behavior . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 9 6.1. Capability Announcement . . . . . . . . . . . . . . . . . 9
5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9 6.1.1. Reacting-Node Behavior . . . . . . . . . . . . . . . 9
5.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10 6.1.2. Reporting-Node Behavior . . . . . . . . . . . . . . . 9
5.2.1. Overload Control State . . . . . . . . . . . . . . . 10 6.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10
5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 11 6.2.1. Overload Control State . . . . . . . . . . . . . . . 10
5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 11 6.2.2. Reporting-Node Maintenance of Peer-Report OCS . . . . 11
5.2.4. Peer-Report Reporting Node Behavior . . . . . . . . . 12 6.2.3. Reacting-Node Maintenance of Peer-Report OCS . . . . 12
5.2.5. Peer-Report Reacting Node Behavior . . . . . . . . . 13 6.2.4. Peer-Report Reporting-Node Behavior . . . . . . . . . 13
6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14 6.2.5. Peer-Report Reacting-Node Behavior . . . . . . . . . 13
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14 7. Peer-Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 14 7.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14
6.1.2. OC-Peer-Algo AVP . . . . . . . . . . . . . . . . . . 14 7.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 15
6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15 7.1.2. OC-Peer-Algo AVP . . . . . . . . . . . . . . . . . . 15
6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15 7.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15 7.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 16
6.4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 16 7.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 7.4. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . 16
7.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.2. New Registries . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18
10.1. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Normative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
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), a base solution for Diameter overload
defines the Peer overload report type. The initial use case for the [RFC7683]. The extension defines the Peer Overload report type. The
Peer report is the handling of occurrences of overload of a Diameter initial use case for the peer report is the handling of occurrences
agent. of overload of a Diameter Agent.
This document defines the behavior of Diameter nodes when Diameter This document defines the behavior of Diameter nodes when Diameter
agents enter an overload condition and send an overload report Agents enter an overload condition and send an Overload report
requesting a reduction of traffic. It also defines new overload requesting a reduction of traffic. It also defines a new Overload
report type, the Peer overload report type, that is used for handling report type, the Peer Overload report type, which is used for
of agent overload conditions. The Peer overload report type is handling agent overload conditions. The Peer Overload report type is
defined in a generic fashion so that it can also be used for other defined in a generic fashion so that it can also be used for other
Diameter overload scenarios. Diameter overload scenarios.
The base Diameter overload specification [RFC7683] addresses the The base Diameter overload specification [RFC7683] addresses the
handling of overload when a Diameter endpoint (a Diameter Client or handling of overload when a Diameter endpoint (a Diameter Client or
Diameter Server as defined in [RFC6733]) becomes overloaded. Diameter Server as defined in [RFC6733]) becomes overloaded.
In the base specification, the goal is to handle abatement of the In the base specification, the goal is to handle abatement of the
overload occurrence as close to the source of the Diameter traffic as overload occurrence as close to the source of the Diameter traffic as
feasible. When possible this is done at the originator of the feasible. When possible, this is done at the originator of the
traffic, generally referred to as a Diameter Client. A Diameter traffic, generally referred to as a Diameter Client. A Diameter
Agent might also handle the overload mitigation. For instance, a Agent might also handle the overload mitigation. For instance, a
Diameter Agent might handle Diameter overload mitigation when it Diameter Agent might handle Diameter overload mitigation when it
knows that a Diameter Client does not support the DOIC extension. knows that a Diameter Client does not support the DOIC extension.
This document extends the base Diameter endpoint overload This document extends the base Diameter endpoint overload
specification to address the case when Diameter Agents become specification to address the case when Diameter Agents become
overloaded. Just as is the case with other Diameter nodes -- overloaded. Just as is the case with other Diameter nodes, i.e.,
Diameter Clients and Diameter Servers -- surges in Diameter traffic Diameter Clients and Diameter Servers, surges in Diameter traffic can
can cause a Diameter Agent to be asked to handle more Diameter cause a Diameter Agent to be asked to handle more Diameter traffic
traffic than it was configured to handle. For a more detailed than it was configured to handle. For a more detailed discussion of
discussion of what can cause the overload of Diameter nodes, refer to what can cause the overload of Diameter nodes, refer to the Diameter
the Diameter Overload Requirements [RFC7068]. overload requirements [RFC7068].
This document defines a new overload report type to communicate This document defines a new Overload report type to communicate
occurrences of agent overload. This report type works for the "Loss" occurrences of agent overload. This report type works for the
overload mitigation algorithm defined in [RFC7683] and is expected to Diameter overload loss abatement algorithm defined in [RFC7683] and
work for other overload abatement algorithms defined in extensions to is expected to work for other overload abatement algorithms defined
the DOIC solution. in extensions to the DOIC solution.
2. Terminology and Abbreviations 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology and Abbreviations
AVP AVP
Attribute Value Pair Attribute-Value Pair
Diameter Node Diameter Node
A [RFC7683] Diameter Client, an [RFC7683] Diameter Server, and A Diameter Client, Diameter Server, or Diameter Agent [RFC6733]
[RFC7683] Diameter Agent.
Diameter Endpoint Diameter Endpoint
An [RFC7683] Diameter Client and [RFC7683] Diameter Server. A Diameter Client or Diameter Server [RFC6733]
Diameter Agent Diameter Agent
An [RFC7683] Diameter Agent. A Diameter node that provides relay, proxy, redirect, or
translation services [RFC6733]
Reporting Node Reporting Node
A DOIC Node that sends an overload report in a Diameter answer A DOIC node that sends an Overload report in a Diameter answer
message. message
Reacting Node Reacting Node
A DOIC Node that receives and acts on a DOIC overload report. A DOIC node that receives and acts on a DOIC Overload report
DOIC Node DOIC Node
A Diameter Node that supports the DOIC solution defined in A Diameter node that supports the DOIC solution defined in
[RFC7683]. [RFC7683]
3. Peer Report Use Cases 4. Peer-Report Use Cases
This section outlines representative use cases for the peer report This section outlines representative use cases for the peer report
used to communicate agent overload. used to communicate agent overload.
There are two primary classes of use cases currently identified, There are two primary classes of use cases currently identified:
those involving the overload of agents and those involving overload those involving the overload of agents, and those involving the
of Diameter endpoints. In both cases the goal is to use an overload overload of Diameter endpoints. In both cases, the goal is to use an
algorithm that controls traffic sent towards peers. overload algorithm that controls traffic sent towards peers.
3.1. Diameter Agent Overload Use Cases 4.1. Diameter Agent Overload Use Cases
The peer report needs to support the following use cases. The peer report needs to support the use cases described below.
In the figures in this section, elements labeled "c" are Diameter In the figures in this section, elements labeled "c" are Diameter
Clients, elements labeled "a" are Diameter Agents and elements Clients, elements labeled "a" are Diameter Agents, and elements
labeled "s" are Diameter Servers. labeled "s" are Diameter Servers.
3.1.1. Single Agent 4.1.1. Single Agent
This use case is illustrated in Figure 1. In this case, the client This use case is illustrated in Figure 1. In this case, the client
sends all traffic through the single agent. If there is a failure in sends all traffic through the single agent. If there is a failure in
the agent then the client is unable to send Diameter traffic toward the agent, then the client is unable to send Diameter traffic toward
the server. the server.
+-+ +-+ +-+ +-+ +-+ +-+
|c|----|a|----|s| |c|----|a|----|s|
+-+ +-+ +-+ +-+ +-+ +-+
Figure 1 Figure 1
A more likely case for the use of agents is illustrated in Figure 2. A more likely case for the use of agents is illustrated in Figure 2.
In this case, there are multiple servers behind the single agent. In this case, there are multiple servers behind the single agent.
The client sends all traffic through the agent and the agent The client sends all traffic through the agent, and the agent
determines how to distribute the traffic to the servers based on determines how to distribute the traffic to the servers based on
local routing and load distribution policy. local routing and load distribution policy.
+-+ +-+
--|s| --|s|
+-+ +-+ / +-+ +-+ +-+ / +-+
|c|----|a|- ... |c|----|a|- ...
+-+ +-+ \ +-+ +-+ +-+ \ +-+
--|s| --|s|
+-+ +-+
Figure 2 Figure 2
In both of these cases, the occurrence of overload in the single In both of these cases, the occurrence of overload in the single
agent must by handled by the client in a similar fashion as if the agent must by handled by the client similarly to as if the client
client were handling the overload of a directly connected server. were handling the overload of a directly connected server. When the
When the agent becomes overloaded it will insert an overload report agent becomes overloaded, it will insert an Overload report in answer
in answer messages flowing to the client. This overload report will messages flowing to the client. This Overload report will contain a
contain a requested reduction in the amount of traffic sent to the requested reduction in the amount of traffic sent to the agent. The
agent. The client will apply overload abatement behavior as defined client will apply overload abatement behavior as defined in the base
in the base Diameter overload specification [RFC7683] or the Diameter overload specification [RFC7683] or in the extension
extension draft that defines the indicated overload abatement document that defines the indicated overload abatement algorithm.
algorithm. This will result in the throttling of the abated traffic This will result in the throttling of the abated traffic that would
that would have been sent to the agent, as there is no alternative have been sent to the agent, as there is no alternative route. The
route. The client sends an appropriate error response to the client sends an appropriate error response to the originator of the
originator of the request. request.
3.1.2. Redundant Agents 4.1.2. Redundant Agents
Figure 3 and Figure 4 illustrate a second, and more likely, type of Figure 3 and Figure 4 illustrate a second, and more likely, type of
deployment scenario involving agents. In both of these cases, the deployment scenario involving agents. In both of these cases, the
client has Diameter connections to two agents. client has Diameter connections to two agents.
Figure 3 illustrates a client that has a primary connection to one of Figure 3 illustrates a client that has a primary connection to one of
the agents (agent a1) and a secondary connection to the other agent the agents (agent a1) and a secondary connection to the other agent
(agent a2). In this scenario, under normal circumstances, the client (agent a2). In this scenario, under normal circumstances, the client
will use the primary connection for all traffic. The secondary will use the primary connection for all traffic. The secondary
connection is used when there is a failure scenario of some sort. connection is used when there is a failure scenario of some sort.
skipping to change at page 7, line 5 skipping to change at page 7, line 28
Figure 4 Figure 4
In the case where one of the agents in the above scenarios become In the case where one of the agents in the above scenarios become
overloaded, the client should reduce the amount of traffic sent to overloaded, the client should reduce the amount of traffic sent to
the overloaded agent by the amount requested. This traffic should the overloaded agent by the amount requested. This traffic should
instead be routed through the non-overloaded agent. For example, instead be routed through the non-overloaded agent. For example,
assume that the overloaded agent requests a reduction of 10 percent. assume that the overloaded agent requests a reduction of 10 percent.
The client should send 10 percent of the traffic that would have been The client should send 10 percent of the traffic that would have been
routed to the overloaded agent through the non-overloaded agent. routed to the overloaded agent through the non-overloaded agent.
When the client has an active and a standby connection to the two When the client has both an active and a standby connection to the
agents then an alternative strategy for responding to an overload two agents, then an alternative strategy for responding to an
report from an agent is to change the standby connection to active. Overload report from an agent is to change the standby connection to
This will result in all traffic being routed through the new active active. This will result in all traffic being routed through the new
connection. active connection.
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 that discussed in
amount of traffic depends on the combined reduction requested by the Section 4.1.1. The amount of traffic depends on the combined
two agents. reduction requested by the two agents.
3.1.3. Agent Chains 4.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 includes when there are Diameter example of this type of deployment is when there are Diameter Agents
agents between administrative domains. 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 for more than two agents to be
be in the path of a transaction. in the path of a transaction.
+---+ +---+ +-+ +---+ +---+ +-+
--|a11|-----|a21|---|s| --|a11|-----|a21|---|s|
+-+ / +---+ \ / +---+\ /+-+ +-+ / +---+ \ / +---+\ /+-+
|c|- x x |c|- x x
+-+ \ +---+ / \ +---+/ \+-+ +-+ \ +---+ / \ +---+/ \+-+
--|a12|-----|a22|---|s| --|a12|-----|a22|---|s|
+---+ +---+ +-+ +---+ +---+ +-+
Figure 5 Figure 5
Handling of overload of one or both of agents a11 or a12 in this case The handling of overload for one or both agents, a11 or a12 in this
is equivalent to that discussed in Section 3.1.2. case, is equivalent to that discussed in Section 4.1.2.
Overload of agents a21 and a22 must be handled by the previous hop The overload of agents a21 and a22 must be handled by the previous-
agents. As such, agents a11 and a12 must handle the overload hop agents. As such, agents a11 and a12 must handle the overload
mitigation logic when receiving an agent overload report from agents mitigation logic when receiving an Agent Overload report from agents
a21 and a22. a21 and a22.
The handling of peer overload reports is similar to that discussed in The handling of Peer Overload reports is similar to that discussed in
Section 3.1.2. If the overload can be addressed using diversion then Section 4.1.2. If the overload can be addressed using diversion,
this approach should be taken. then this approach should be taken.
If both of the agents have requested a reduction in traffic then the If both of the agents have requested a reduction in traffic, then the
previous hop agent must start throttling the appropriate number of previous-hop agent must start throttling the appropriate number of
transactions. When throttling requests, an agent uses the same error transactions. When throttling requests, an agent uses the same error
responses as defined in the base DOIC specification [RFC7683]. responses as defined in the base DOIC specification [RFC7683].
3.2. Diameter Endpoint Use Cases 4.2. Diameter Endpoint Use Cases
This section outlines use cases for the peer overload report This section outlines use cases for the Peer Overload report
involving Diameter Clients and Diameter Servers. involving Diameter Clients and Diameter Servers.
3.2.1. Hop-by-hop Abatement Algorithms 4.2.1. Hop-by-Hop Abatement Algorithms
It is envisioned that abatement algorithms will be defined that will It is envisioned that abatement algorithms will be defined that will
support the option for Diameter Endpoints to send peer reports. For support the option for Diameter endpoints to send peer reports. For
instance, it is envisioned that one usage scenario for the rate instance, it is envisioned that one usage scenario for the rate
algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked algorithm [RFC8582] will involve abatement being done on a hop-by-hop
on by the DIME working group as this document is being written, will basis.
involve abatement being done on a hop-by-hop basis.
This rate deployment scenario would involve Diameter Endpoints This rate-deployment scenario would involve Diameter endpoints
generating peer reports and selecting the rate algorithm for generating peer reports and selecting the rate algorithm for
abatement of overload conditions. abatement of overload conditions.
4. Interaction Between Host/Realm and Peer Overload Reports 5. Interaction Between Host/Realm and Peer Overload Reports
It is possible that both an agent and an end-point in the path of a It is possible for both an agent and an endpoint in the path of a
transaction are overloaded at the same time. When this occurs, transaction to be overloaded at the same time. When this occurs,
Diameter entities need to handle both overload reports. In this Diameter entities need to handle multiple Overload reports. In this
scenario the reacting node should first handle the throttling of the scenario, the reacting node should first handle the throttling of the
overloaded host or realm. Any messages that survive throttling due overloaded Host or Realm. Any messages that survive throttling due
to host or realm reports should then go through abatement for the to Host or Realm reports should then go through abatement for the
peer overload report. In this scenario, when doing abatement on the Peer Overload report. In this scenario, when doing abatement on the
PEER report, the reacting node SHOULD take into consideration the peer report, the reacting node SHOULD take into consideration the
number of messages already throttled by the handling of the HOST/ number of messages already throttled by the handling of the host/
REALM report abatement. realm report abatement.
Note: The goal is to avoid traffic oscillations that might result Note: The goal is to avoid traffic oscillations that might result
from throttling of messages for both the HOST/REALM overload from throttling of messages for both the host/realm Overload
reports and the PEER overload reports. This is especially a reports and the PEER Overload reports. This is especially a
concern if both reports indicate the LOSS abatement algorithm. concern if both reports indicate the loss abatement algorithm.
5. Peer Report Behavior 6. 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 6.1. Capability Announcement
5.1.1. Reacting Node Behavior 6.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 (as defined in Section 6.1.1) feature MUST include in OC_PEER_REPORT feature (as defined in Section 7.1.1) MUST include in
the OC-Supported-Features AVP an OC-Feature-Vector AVP with the the OC-Supported-Features AVP an OC-Feature-Vector AVP with the
OC_PEER_REPORT bit set. 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.
When a Diameter Agent relays a request that includes a SourceID AVP When a Diameter Agent relays a request that includes a SourceID AVP
in the OC-Supported-Features AVP, if the Diameter Agent supports the in the OC-Supported-Features AVP, if the Diameter Agent supports the
OC_PEER_REPORT feature then it MUST remove the received SourceID AVP OC_PEER_REPORT feature, then it MUST remove the received SourceID AVP
and replace it with a SourceID AVP containing its own and replace it with a SourceID AVP containing its own
DiameterIdentity. DiameterIdentity.
5.1.2. Reporting Node Behavior 6.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
feature MUST update transaction state with an indication of whether OC_PEER_REPORT feature MUST update transaction state with an
or not the peer from which the request was received supports the indication of whether or not the peer from which the request was
OC_PEER_REPORT feature. received supports the OC_PEER_REPORT feature.
Note: The transaction state is used when the DOIC Node is acting Note: The transaction state is used when the DOIC node is acting
as a peer-report reporting node and needs send OC-OLR reports of as a peer-report reporting node and needs to send OC-OLR AVP
type peer in answer messages. The peer overload reports are only reports of type "PEER-REPORT" in answer messages. The Peer
included in answer messages being sent to peers that support the Overload reports are only included in answer messages being sent
OC_PEER_REPORT feature. to peers that support the OC_PEER_REPORT feature.
The peer supports the OC_PEER_REPORT feature if the received request The peer supports the OC_PEER_REPORT feature if the received request
contains an OC-Supported-Features AVP with the OC-Feature-Vector with contains an OC-Supported-Features AVP with the OC-Feature-Vector with
the OC_PEER_REPORT feature bit set and with a SourceID AVP with a the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
value that matches the DiameterIdentity of the peer from which the value that matches the DiameterIdentity of the peer from which the
request was received. request was received.
When an agent relays an answer message, a reporting node that When an agent relays an answer message, a reporting node that
supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
the OC-Supported-Features AVP. the OC-Supported-Features AVP.
When sending an answer message, a reporting node that supports the When sending an answer message, a reporting node that supports the
OC_PEER_REPORT feature MUST determine if the peer to which the answer OC_PEER_REPORT feature MUST determine if the peer to which the answer
is to be sent supports the OC_PEER_REPORT feature. is to be sent supports the OC_PEER_REPORT feature.
If the peer supports the OC_PEER_REPORT feature then the reporting If the peer supports the OC_PEER_REPORT feature, then the reporting
node MUST indicate support for the feature in the OC-Supported- node MUST indicate support for the feature in the OC-Supported-
Features AVP. Features AVP.
If the peer supports the OC_PEER_REPORT feature then the reporting If the peer supports the OC_PEER_REPORT feature, then the reporting
node MUST insert the SourceID AVP in the OC-Supported-Features AVP in node MUST insert the SourceID AVP in the OC-Supported-Features AVP in
the answer message. the answer message.
If the peer supports the OC_PEER_REPORT feature then the reporting If the peer supports the OC_PEER_REPORT feature, then the reporting
node MUST insert the OC-Peer-Algo AVP in the OC-Supported-Features node MUST insert the OC-Peer-Algo AVP in the OC-Supported-Features
AVP. The OC-Peer-Algo AVP MUST indicate the overload abatement AVP. The OC-Peer-Algo AVP MUST indicate the overload abatement
algorithm that the reporting node wants the reacting nodes to use algorithm that the reporting node wants the reacting nodes to use
should the reporting node send a peer overload report as a result of should the reporting node send a Peer Overload report as a result of
becoming overloaded. becoming overloaded.
5.2. Peer Overload Report Handling 6.2. Peer Overload Report Handling
This section defines the behavior for the handling of overload This section defines the behavior for the handling of Overload
reports of type peer. reports of type "PEER-REPORT".
5.2.1. Overload Control State 6.2.1. Overload Control State
This section describes the Overload Control State (OCS) that might be This section describes the Overload Control State (OCS) that might be
maintained by both the peer-report reporting node and the peer-report maintained by both the peer-report reporting node and the peer-report
reacting node. reacting node.
This is an extension of the OCS handling defined in [RFC7683]. This is an extension of the OCS handling defined in [RFC7683].
5.2.1.1. Reporting Node Peer Report OCS 6.2.1.1. Reporting-Node Peer-Report OCS
A DOIC Node that supports the OC_PEER_REPORT feature SHOULD maintain A DOIC node that supports the OC_PEER_REPORT feature SHOULD maintain
Reporting Node OCS, as defined in [RFC7683] and extended here. Reporting-Node OCS, as defined in [RFC7683] and extended here.
If different abatement specific contents are sent to each peer then If different abatement-specific contents are sent to each peer, then
the reporting node MUST maintain a separate reporting node peer the reporting node MUST maintain a separate reporting-node peer-
report OCS entry per peer to which a peer overload report is sent. report OCS entry per peer, to which a Peer Overload report is sent.
Note: The rate overload abatement algorithm allows for different Note: The rate-overload abatement algorithm allows for different
rates to be sent to each peer. rates to be sent to each peer.
5.2.1.2. Reacting Node Peer Report OCS 6.2.1.2. Reacting-Node Peer-Report OCS
In addition to OCS maintained as defined in [RFC7683], a reacting In addition to OCS maintained as defined in [RFC7683], a reacting
node that supports the OC_PEER_REPORT feature maintains the following node that supports the OC_PEER_REPORT feature maintains the following
OCS per supported Diameter application: OCS per supported Diameter application:
A peer-type OCS entry for each peer to which it sends requests. A peer-report OCS entry for each peer to which it sends requests
A peer-type OCS entry is identified by the pair of Application-ID and A peer-report OCS entry is identified by both the Application-ID and
the peer's DiameterIdentity. the peer's DiameterIdentity.
The peer-type OCS entry include the following information (the actual The peer-report OCS entry includes the following information (the
information stored is an implementation decision): actual information stored is an implementation decision):
Sequence number (as received in the OC-OLR AVP). Sequence number (as received in the OC-OLR AVP)
Time of expiry (derived from OC-Validity-Duration AVP received in Time of expiry (derived from the OC-Validity-Duration AVP received
the OC-OLR AVP and time of reception of the message carrying OC- in the OC-OLR AVP and time of reception of the message carrying
OLR AVP). the OC-OLR AVP)
Selected abatement algorithm (as received in the OC-Supported- Selected abatement algorithm (as received in the OC-Supported-
Features AVP). Features AVP)
Input data that is abatement algorithm specific (as received in Input data that is specific to the abatement algorithm (as
the OC-OLR AVP -- for example, OC-Reduction-Percentage for the received in the OC-OLR AVP, e.g., OC-Reduction-Percentage for the
loss abatement algorithm). loss abatement algorithm)
5.2.2. Reporting Node Maintenance of Peer Report OCS 6.2.2. Reporting-Node Maintenance of Peer-Report OCS
All rules for managing the reporting node OCS entries defined in All rules for managing the reporting-node OCS entries defined in
[RFC7683] apply to the peer report. [RFC7683] apply to the peer report.
5.2.3. Reacting Node Maintenance of Peer Report OCS 6.2.3. Reacting-Node Maintenance of Peer-Report OCS
When a reacting node receives an OC-OLR AVP with a report type of When a reacting node receives an OC-OLR AVP with a report type of
peer it MUST determine if the report was generated by the Diameter "PEER-REPORT", it MUST determine if the report was generated by the
peer from which the report was received. Diameter peer from which the report was received.
If a reacting node receives an OC-OLR AVP of type peer and the If a reacting node receives an OC-OLR AVP of type "PEER-REPORT" and
SourceID matches the DiameterIdentity of the Diameter peer from which the SourceID matches the DiameterIdentity of the Diameter peer from
the response message was received then the report was generated by a which the response message was received, then the report was
Diameter peer. generated by a Diameter peer.
If a reacting node receives an OC-OLR AVP of type peer and the If a reacting node receives an OC-OLR AVP of type "PEER-REPORT" and
SourceID does not match the DiameterIdentity of the Diameter peer the SourceID does not match the DiameterIdentity of the Diameter peer
from which the response message was received then the reacting node from which the response message was received, then the reacting node
MUST ignore the overload report. MUST ignore the Overload report.
Note: Under normal circumstances, a Diameter node will not add a Note: Under normal circumstances, a Diameter node will not add a
peer report when sending to a peer that does not support this peer report when sending to a peer that does not support this
extension. This requirement is to handle the case where peer extension. This requirement is to handle the case where peer
reports are erroneously or maliciously inserted into response reports are erroneously or maliciously inserted into response
messages. messages.
If the peer report was received from a Diameter peer then the If the peer report was received from a Diameter peer, then the
reacting node MUST determine if it is for an existing or new overload reacting node MUST determine if it is for an existing or new overload
condition. condition.
The peer report is for an existing overload condition if the reacting The peer report is for an existing overload condition if the reacting
node has an OCS that matches the received peer report. For a peer node has an OCS that matches the received peer report. For a peer
report, this means it matches the Application-ID and the peer's report, this means it matches the Application-ID and the peer's
DiameterIdentity in an existing OCS entry. DiameterIdentity in an existing OCS entry.
If the peer report is for an existing overload condition then it MUST If the peer report is for an existing overload condition, then it
determine if the peer report is a retransmission or an update to the MUST determine if the peer report is a retransmission or an update to
existing OLR. the existing OLR.
If the sequence number for the received peer report is greater than If the sequence number for the received peer report is greater than
the sequence number stored in the matching OCS entry then the the sequence number stored in the matching OCS entry, then the
reacting node MUST update the matching OCS entry. reacting node MUST update the matching OCS entry.
If the sequence number for the received peer report is less than or If the sequence number for the received peer report is less than or
equal to the sequence number in the matching OCS entry then the equal to the sequence number in the matching OCS entry, then the
reacting node MUST silently ignore the received peer report. The reacting node MUST silently ignore the received peer report. The
matching OCS MUST NOT be updated in this case. matching OCS MUST NOT be updated in this case.
If the received peer report is for a new overload condition then the If the received peer report is for a new overload condition, then the
reacting node MUST generate a new OCS entry for the overload reacting node MUST generate a new OCS entry for the overload
condition. condition.
For a peer report this means it creates an OCS entry with a For a peer report, this means it creates an OCS entry with a
DiameterIdentity from the SourceID AVP in the received OC-OLR AVP. DiameterIdentity from the SourceID AVP in the received OC-OLR AVP.
If the received peer report contains a validity duration of zero If the received peer report contains a validity duration of zero
("0") then the reacting node MUST update the OCS entry as being ("0"), then the reacting node MUST update the OCS entry as being
expired. expired.
The reacting node does not delete an OCS when receiving an answer The reacting node does not delete an OCS when receiving an answer
message that does not contain an OC-OLR AVP (i.e. absence of OLR message that does not contain an OC-OLR AVP (i.e., the absence of OLR
means "no change"). means "no change").
The reacting node sets the abatement algorithm based on the OC-Peer- The reacting node sets the abatement algorithm based on the OC-Peer-
Algo AVP in the received OC-Supported-Features AVP. Algo AVP in the received OC-Supported-Features AVP.
5.2.4. Peer-Report Reporting Node Behavior 6.2.4. Peer-Report Reporting-Node Behavior
When there is an existing reporting node peer report OCS entry, the When there is an existing reporting-node peer-report OCS entry, the
reporting node MUST include an OC-OLR AVP with a report type of peer reporting node MUST include an OC-OLR AVP with a report type of
using the contents of the reporting node peer report OCS entry in all "PEER-REPORT" using the contents of the reporting-node peer-report
answer messages sent by the reporting node to peers that support the OCS entry in all answer messages sent by the reporting node to peers
OC_PEER_REPORT feature. that support the OC_PEER_REPORT feature.
The reporting node determines if a peer supports the Note: The reporting node determines if a peer supports the
OC_PEER_REPORT feature based on the indication recorded in the OC_PEER_REPORT feature based on the indication recorded in the
reporting node's transaction state. reporting node's transaction state.
The reporting node MUST include its DiameterIdentity in the SourceID The reporting node MUST include its DiameterIdentity in the SourceID
AVP in the OC-OLR AVP. This is used by DOIC Nodes that support the AVP in the OC-OLR AVP. This is used by DOIC nodes that support the
OC_PEER_REPORT feature to determine if the report was received from a OC_PEER_REPORT feature to determine if the report was received from a
Diameter peer. Diameter peer.
The reporting agent must follow all other overload reporting node The reporting agent must follow all other overload reporting-node
behaviors outlined in the DOIC specification. behaviors outlined in the DOIC specification.
5.2.5. Peer-Report Reacting Node Behavior 6.2.5. Peer-Report Reacting-Node Behavior
A reacting node supporting this extension MUST support the receipt of A reacting node supporting this extension MUST support the receipt of
multiple overload reports in a single message. The message might multiple Overload reports in a single message. The message might
include a host overload report, a realm overload report and/or a peer include a Host Overload report, a Realm Overload report, and/or a
overload report. Peer Overload report.
When a reacting node sends a request it MUST determine if that When a reacting node sends a request, it MUST determine if that
request matches an active OCS. request matches an active OCS.
In all cases, if the reacting node is an agent then it MUST strip the In all cases, if the reacting node is an agent, then it MUST strip
Peer Report OC-OLR AVP from the message. the Peer-Report OC-OLR AVP from the message.
If the request matches an active OCS then the reacting node MUST If the request matches an active OCS, then the reacting node MUST
apply abatement treatment to the request. The abatement treatment apply abatement treatment to the request. The abatement treatment
applied depends on the abatement algorithm indicated in the OCS. applied depends on the abatement algorithm indicated in the OCS.
For peer overload reports, the preferred abatement treatment is For Peer Overload Reports, the preferred abatement treatment is
diversion. As such, the reacting node SHOULD attempt to divert diversion. As such, the reacting node SHOULD attempt to divert
requests identified as needing abatement to other peers. requests identified as needing abatement to other peers.
If there is not sufficient capacity to divert abated traffic then the If there is not sufficient capacity to divert abated traffic, then
reacting node MUST throttle the necessary requests to fit within the the reacting node MUST throttle the necessary requests to fit within
available capacity of the peers able to handle the requests. the available capacity of the peers able to handle the requests.
If the abatement treatment results in throttling of the request and If the abatement treatment results in throttling of the request and
if the reacting node is an agent then the agent MUST send an if the reacting node is an agent, then the agent MUST send an
appropriate error response as defined in [RFC7683]. appropriate error response as defined in [RFC7683].
In the case that the OCS entry validity duration expires or has a In the case that the OCS entry validity duration expires or has a
validity duration of zero ("0"), meaning that if the reporting node validity duration of zero ("0"), meaning that if the reporting node
has explicitly signaled the end of the overload condition then has explicitly signaled the end of the overload condition, then
abatement associated with the OCS entry MUST be ended in a controlled abatement associated with the OCS entry MUST be ended in a controlled
fashion. fashion.
6. Peer Report AVPs 7. Peer-Report AVPs
6.1. OC-Supported-Features AVP 7.1. OC-Supported-Features AVP
This extension adds a new feature to the OC-Feature-Vector AVP. This This extension adds a new feature to the OC-Feature-Vector AVP. This
feature indication shows support for handling of peer overload feature indication shows support for handling of Peer Overload
reports. Peer overload reports are used by agents to indicate the reports. Peer Overload reports are used by agents to indicate the
need for overload abatement handling by the agent's peer. need for overload abatement handling by the agent's peer.
A supporting node must also include the SourceID AVP in the OC- A supporting node must also include the SourceID AVP in the
Supported-Features capability AVP. OC-Supported-Features capability AVP.
This AVP contains the DiameterIdentity of the node that supports the This AVP contains the DiameterIdentity of the node that supports the
OC_PEER_REPORT feature. This AVP is used to determine if support for OC_PEER_REPORT feature. This AVP is used to determine if support for
the peer overload report is in an adjacent node. The value of this the Peer Overload report is in an adjacent node. The value of this
AVP should be the same Diameter identity used as part of the Diameter AVP should be the same Diameter identity used as part of the Diameter
Capabilities Exchange procedure defined in [RFC7683]. Capabilities Exchange procedure defined in [RFC7683].
This extension also adds the OC-Peer-Algo AVP to the OC-Supported- This extension also adds the OC-Peer-Algo AVP to the OC-Supported-
Features AVP. This AVP is used by a reporting node to indicate the Features AVP. This AVP is used by a reporting node to indicate the
abatement algorithm it will use for peer overload reports. abatement algorithm it will use for Peer Overload reports.
OC-Supported-Features ::= < AVP Header: 621 > OC-Supported-Features ::= < AVP Header: 621 >
[ OC-Feature-Vector ] [ OC-Feature-Vector ]
[ SourceID ] [ SourceID ]
[ OC-Peer-Algo] [ OC-Peer-Algo]
* [ AVP ] * [ AVP ]
6.1.1. OC-Feature-Vector AVP 7.1.1. OC-Feature-Vector AVP
The peer report feature defines a new feature bit for the OC-Feature- The Peer-Report feature defines a new feature bit for the OC-Feature-
Vector AVP. Vector AVP.
OC_PEER_REPORT (0x0000000000000010) OC_PEER_REPORT (0x0000000000000010)
When this flag is set by a DOIC Node it indicates that the DOIC When this flag is set by a DOIC node, it indicates that the DOIC
Node supports the peer overload report type. node supports the Peer Overload report type.
6.1.2. OC-Peer-Algo AVP 7.1.2. OC-Peer-Algo AVP
The OC-Peer-Algo AVP (AVP code TBD1) is of type Unsigned64 and The OC-Peer-Algo AVP (AVP code 648) is of type Unsigned64 and
contains a 64 bit flags field of announced capabilities of a DOIC contains a 64-bit flags field of announced capabilities for a DOIC
Node. The value of zero (0) is reserved. node. The value of zero ("0") is reserved.
Feature bits defined for the OC-Feature-Vector AVP and associated Feature bits defined for the OC-Feature-Vector AVP and associated
with overload abatement algorithms are reused for this AVP. with overload abatement algorithms are reused for this AVP.
6.2. OC-OLR AVP 7.2. OC-OLR AVP
This extension makes no changes to the OC_Sequence_Number or This extension makes no changes to the OC_Sequence_Number or
OC_Validity_Duration AVPs in the OC-OLR AVP. These AVPs are also be OC_Validity_Duration AVPs in the OC-OLR AVP. These AVPs can also be
used in peer overload reports. used in Peer Overload reports.
The OC_PEER_REPORT feature extends the base Diameter overload The OC_PEER_REPORT feature extends the base Diameter overload
specification by defining a new overload report type of "peer". See specification by defining a new Overload report type of "PEER-
section [7.6] in [RFC7683] for a description of the OC-Report-Type REPORT". See Section 7.6 of [RFC7683] for a description of the
AVP. OC-Report-Type AVP.
The overload report MUST also include the Diameter identity of the The peer report MUST also include the Diameter identity of the agent
agent that generated the report. This is necessary to handle the that generated the report. This is necessary to handle the case
case where there is a non supporting agent between the reporting node where there is a non-supporting agent between the reporting node and
and the reacting node. Without the indication of the agent that the reacting node. Without the indication of the agent that
generated the overload report, the reacting node could erroneously generated the peer report, the reacting node could erroneously assume
assume that the report applied to the non-supporting node. This that the report applied to the non-supporting node. This could, in
could, in turn, result in unnecessary traffic being either diverted turn, result in unnecessary traffic being either diverted or
or throttled. throttled.
The SourceID AVP is used in the OC-OLR AVP to carry this The SourceID AVP is used in the OC-OLR AVP to carry this
DiameterIdentity. DiameterIdentity.
OC-OLR ::= < AVP Header: 623 > OC-OLR ::= < AVP Header: 623 >
< OC-Sequence-Number > < OC-Sequence-Number >
< OC-Report-Type > < OC-Report-Type >
[ OC-Reduction-Percentage ] [ OC-Reduction-Percentage ]
[ OC-Validity-Duration ] [ OC-Validity-Duration ]
[ SourceID ] [ SourceID ]
* [ AVP ] * [ AVP ]
6.2.1. OC-Report-Type AVP 7.2.1. OC-Report-Type AVP
The following new report type is defined for the OC-Report-Type AVP. The following new report type is defined for the OC-Report-Type AVP.
PEER_REPORT 2 The overload treatment should apply to all requests PEER_REPORT 2: The overload treatment should apply to all requests
bound for the peer identified in the overload report. If the peer bound for the peer identified in the Overload report. If the peer
identified in the overload report is not a peer to the reacting identified in the peer report is not a peer to the reacting
endpoint then the overload report should be stripped and not acted endpoint, then the peer report should be stripped and not acted
upon. upon.
6.3. SourceID AVP 7.3. SourceID AVP
The SourceID AVP (AVP code TBD2) is of type DiameterIdentity and is The SourceID AVP (AVP code 649) is of type DiameterIdentity and is
inserted by a Diameter node to indicate the source of the AVP in inserted by a Diameter node to indicate the source of the AVP in
which it is a part. which it is a part.
In the case of peer reports, the SourceID AVP indicates the node that In the case of peer reports, the SourceID AVP indicates the node that
supports this feature (in the OC-Supported-Features AVP) or the node supports this feature (in the OC-Supported-Features AVP) or the node
that generates an overload with a report type of peer (in the OC-OLR that generates an overload report with a report type of "PEER-REPORT"
AVP). (in the OC-OLR AVP).
It contains the DiameterIdentity of the inserting node. This is used It contains the DiameterIdentity of the inserting node. This is used
by other Diameter nodes to determine the node that inserted the by other Diameter nodes to determine the node that inserted the
enclosing AVP that contains the SourceID AVP. enclosing AVP that contains the SourceID AVP.
6.4. Attribute Value Pair Flag Rules 7.4. Attribute-Value Pair Flag Rules
+---------+ +---------+
|AVP flag | |AVP flag |
|rules | |rules |
+----+----+ +----+----+
AVP Section | |MUST| AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|OC-Peer-Algo TBD1 6.1.2 Unsigned64 | | V | |OC-Peer-Algo 648 7.1.2 Unsigned64 | | V |
|SourceID TBD2 6.3 DiameterIdentity | | V | |SourceID 649 7.3 DiameterIdentity | | V |
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
7. IANA Considerations 8. IANA Considerations
7.1. AVP Codes
New AVPs defined by this specification are listed in Section 6.4. IANA has registered the following values in the "Authentication,
All AVP codes are allocated from the 'Authentication, Authorization, Authorization, and Accounting (AAA) Parameters" registry:
and Accounting (AAA) Parameters' AVP Codes registry.
One new OC-Report-Type AVP value is defined in Section 6.2.1 Two new AVP codes are defined in Section 7.4.
7.2. New Registries Note that the values used for the OC-Peer-Algo AVP are a subset of
the "OC-Feature-Vector AVP Values (code 622)" registry. Only the
values in that registry that apply to overload abatement
algorithms apply to the OC-Peer-Algo AVP.
There are no new IANA registries introduced by this document. A new OC-Feature-Vector AVP value is defined in Section 7.1.1.
The values used for the OC-Peer-Algo AVP are the subset of the "OC- A new OC-Report-Type AVP value is defined in Section 7.2.1.
Feature-Vector AVP Values (code 622)" registry. Only the values in
that registry that apply to overload abatement algorithms apply to
the OC-Peer-Algo AVP.
8. Security Considerations 9. Security Considerations
Agent overload is an extension to the base Diameter overload Agent overload is an extension to the base Diameter Overload
mechanism. As such, all of the security considerations outlined in mechanism. As such, all of the security considerations outlined in
[RFC7683] apply to the agent overload scenarios. [RFC7683] apply to the agent overload scenarios.
It is possible that the malicious insertion of an agent overload It is possible that the malicious insertion of an peer report could
report could have a bigger impact on a Diameter network as agents can have a bigger impact on a Diameter network as agents can be
be concentration points in a Diameter network. Where an end-point concentration points in a Diameter network. Where an endpoint report
report would impact the traffic sent to a single Diameter server, for would impact the traffic sent to a single Diameter Server, for
example, a peer report could throttle all traffic to the Diameter example, a peer report could throttle all traffic to the Diameter
network. network.
This impact is amplified in an agent that sits at the edge of a This impact is amplified in a Diameter agent that sits at the edge of
Diameter network that serves as the entry point from all other a Diameter network that serves as the entry point from all other
Diameter networks. Diameter networks.
The impacts of this attack, as well as the mitigation strategies, are The impacts of this attack, as well as the mitigation strategies, are
the same as outlined in [RFC7683]. the same as those outlined in [RFC7683].
9. Acknowledgements 10. References
Adam Roach and Eric McMurry for the work done in defining a 10.1. Normative References
comprehensive Diameter overload solution in draft-roach-dime-
overload-ctrl-03.txt.
Ben Campbell for his insights and review of early versions of this [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
document. Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>.
10. References [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015,
<https://www.rfc-editor.org/info/rfc7683>.
10.1. Informative References [RFC8582] Donovan, S., Ed. and E. Noel, "Diameter Overload Rate
Control", RFC 8582, DOI 10.17487/RFC8582, August 2019,
<https://www.rfc-editor.org/info/rfc8582>.
10.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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, <https://www.rfc-editor.org/info/rfc7068>.
10.2. Normative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-dime-doic-rate-control] Acknowledgements
Donovan, S. and E. Noel, "Diameter Overload Rate Control",
draft-ietf-dime-doic-rate-control-03 (work in progress),
March 2016.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, The author would like to thank Adam Roach and Eric McMurry for the
Ed., "Diameter Base Protocol", RFC 6733, work done in defining a comprehensive Diameter overload solution in
DOI 10.17487/RFC6733, October 2012, draft-roach-dime-overload-ctrl-03.txt.
<http://www.rfc-editor.org/info/rfc6733>.
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. The author would also like to thank Ben Campbell for his insights and
Morand, "Diameter Overload Indication Conveyance", review of early versions of this document.
RFC 7683, DOI 10.17487/RFC7683, October 2015,
<http://www.rfc-editor.org/info/rfc7683>.
Author's Address Author's Address
Steve Donovan Steve Donovan
Oracle Oracle
7460 Warren Parkway, Suite 300 7460 Warren Parkway, Suite 300
Frisco, Texas 75034 Frisco, Texas 75034
United States United States of America
Email: srdonovan@usdonovans.com Email: srdonovan@usdonovans.com
 End of changes. 152 change blocks. 
347 lines changed or deleted 343 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/