RFC 7683
Diameter Overload Indication Conveyance
RFC 7683 · Part 1 of 9 🎀
Diameter Overload Indication Conveyance 🦋
Okay bestie, the title block is giving official. This is an IETF (Internet Engineering Task Force) doc on the Standards Track, so it's a real spec, not just vibes 💅. It's dated October 2015 and its ISSN is 2070-1721 ✨.
The authors are J. Korhonen (Ed.) from Broadcom Corporation, S. Donovan (Ed.), B. Campbell from Oracle, and L. Morand from Orange Labs 👑. (Ed. just means editor, iykyk 🙈.) It doesn't obsolete or update any other RFCs, since the title block doesn't list any 🫶.
Abstract 🌸
This spec lays out the base solution for Diameter overload control, which they call Diameter Overload Indication Conveyance (DOIC). So DOIC is the core plan for handling overload in Diameter 💖.
Status of This Memo 📜
This is an Internet Standards Track document 🔥. It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🦋.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7683 ✨.
Copyright Notice ©️
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read these carefully, because they spell out your rights and restrictions for this document 📖. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 5
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 6
4.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7
4.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9
4.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 11
4.5. Simplified Example Architecture . . . . . . . . . . . . . 12
5. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 12
5.1. Capability Announcement . . . . . . . . . . . . . . . . . 12
5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 13
5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 13
5.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 14
5.2. Overload Report Processing . . . . . . . . . . . . . . . 15
5.2.1. Overload Control State . . . . . . . . . . . . . . . 15
5.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 19
5.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 20
5.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 22
6. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 24
6.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 24
7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 25
7.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 25
7.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 25
7.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 26
7.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 26
7.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 26
7.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 27
7.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 27
7.8. AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . 28
8. Error Response Codes . . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 30
10.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . 31
10.3. Noncompliant Nodes . . . . . . . . . . . . . . . . . . . 32
10.4. End-to-End Security Issues . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Issues Left for Future Specifications . . . . . . . 35
A.1. Additional Traffic Abatement Algorithms . . . . . . . . . 35
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 35
A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 35
Appendix B. Deployment Considerations . . . . . . . . . . . . . 35
Appendix C. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . 36
C.1. Application Classification . . . . . . . . . . . . . . . 36
C.2. Implications of Application Type Overload . . . . . . . . 37
C.3. Request Transaction Classification . . . . . . . . . . . 38
C.4. Request Type Overload Implications . . . . . . . . . . . 39
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 421. Introduction ✨
This spec lays out the base solution for Diameter overload control, which they call Diameter Overload Indication Conveyance (DOIC). It's built on the requirements identified in [RFC7068] 💅.
It covers Diameter overload control between Diameter nodes that support the DOIC solution. The solution is designed for existing and future Diameter applications, and it needs no changes to the Diameter base protocol [RFC6733]. It can also be deployed in environments where some Diameter nodes don't implement the overload control solution defined here 🦋.
A new application spec can bring in this overload control mechanism by making it mandatory to implement for that application and referencing this spec normatively. It's up to the Diameter application designers to define how overload control mechanisms work on their application 🫶.
Heads up, though: this spec doesn't cover every requirement in [RFC7068]. A bunch of overload control features are left for future specs. Appendix A has the list of extensions being considered right now 👀.
2. Terminology and Abbreviations 📖
Abatement 💫 A reaction to receiving an overload report that reduces the traffic sent to the reporting node. Abatement actions include diversion and throttling.
Abatement Algorithm 💫 An extensible method that reporting nodes request and reacting nodes use to reduce the amount of traffic sent during an overload control occurrence.
Diversion 💫 An overload abatement treatment where the reacting node selects alternate destinations or paths for requests.
Host-Routed Requests 💫 Requests that a reacting node knows will be served by a particular host, either because of the presence of a Destination-Host Attribute Value Pair (AVP) or because of some other local knowledge the reacting node has.
Overload Control State (OCS) 💫 Internal state kept by a reporting or reacting node that describes overload control occurrences.
Overload Report (OLR) 💫 Overload control information for a particular overload occurrence, sent by a reporting node.
Reacting Node 💫 A Diameter node that acts upon an overload report.
Realm-Routed Requests 💫 Requests sent by a reacting node when it doesn't know which host the request will be routed to.
Reporting Node 💫 A Diameter node that generates an overload report. (This may or may not be the overloaded node 🙈.)
Throttling 💫 An abatement treatment that limits the number of requests sent by the reacting node. Throttling can include a Diameter Client choosing not to send requests, or a Diameter Agent or Server rejecting requests with appropriate error responses. In both cases, the result of throttling is a permanent rejection of the transaction 💀.
3. Conventions Used in This Document 🔑
Here's the key-words bit. In this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] 🌈.
That RFC 2119 interpretation only applies to those words when they're in all caps. If they show up in lowercase, they don't carry that meaning 🧚.
4. Solution Overview ✨
Okay so the Diameter Overload Information Conveyance (DOIC) solution lets Diameter nodes ask other Diameter nodes to do overload abatement 🫶. That just means anything that reduces the load being sent to an overloaded node or realm. It's giving "please slow down, bestie" 💅
A Diameter node that supports DOIC is called a "DOIC node" 🦋. Any Diameter node can be one, including Diameter Clients, Diameter Servers, and Diameter Agents. DOIC nodes split further into "Reporting Nodes" and "Reacting Nodes." A reporting node asks for overload abatement by sending Overload Reports (OLRs) 📣.
A reacting node listens to OLRs and does whatever is needed to fulfill the abatement requests inside them 🫧. A reporting node can report overload for itself or for other nodes, and a reacting node can abate on its own behalf or on behalf of other nodes. Main character energy for everyone 👑
A node's DOIC role is independent of its Diameter role ✨. So Diameter Agents can be DOIC nodes even though they aren't endpoints in the Diameter sense 🧚. Diameter supports bidirectional applications, where Diameter Servers can send requests towards Diameter Clients, so one node can be a reporting node and a reacting node at the same time 🔥. Honestly so iconic.
Likewise, a Diameter Agent can be a reacting node from the point of view of upstream nodes, and a reporting node from the point of view of downstream nodes 🌈.
DOIC nodes don't make brand new messages to carry DOIC info 🙅♀️. Instead they "piggyback" DOIC info onto existing Diameter messages by sticking new AVPs into existing requests and responses 🎀. Nodes say they support DOIC, plus any DOIC parameters, by adding an OC-Supported-Features AVP (Section 7.1) to existing requests and responses. Reporting nodes send OLRs by adding OC-OLR AVPs (Section 7.3) 💖.
An OLR applies to the Diameter realm and application of the message that carries it 💜. If a reporting node supports more than one realm and/or application, it reports separately for each realm-and-application combo 🍓. The same goes for OC-Supported-Features, which applies to the realm and application of the message it's in ✨. So a node can do DOIC for one application and/or realm but not another, and it can advertise different DOIC parameters for each realm and application where it does DOIC 💅.
Reacting nodes abate according to an agreed-upon abatement algorithm 🤝. An abatement algorithm defines what some OLR parameters mean, plus the procedures needed for overload abatement 📖. It splits Diameter requests into two groups 👯. The first group gets overload abatement treatment, which is either throttling or diversion. The second group gets normal routing treatment. This document specifies one "must-support" algorithm, the "loss" algorithm (Section 6) 🌸. Future specifications may add new algorithms 🔮.
Overload can have different scopes 🌍. A single Diameter node might be overloaded, in which case reacting nodes might try sending requests to other destinations. But if an entire Diameter realm is overloaded, those attempts would actually do harm 😬. DOIC OLRs have a "report type" (Section 7.6) that defines these behaviors 🎯. Report types are extensible, and this document defines report types for overload of a specific host and for overload of an entire realm 🏠.
DOIC works through non-supporting Diameter Agents that properly pass unknown AVPs unchanged 🫶.
4.1. Piggybacking
There's no new Diameter application defined to carry overload-related AVPs 🙅. The overload control AVPs in this specification were designed to be piggybacked onto existing application messages. This works by adding the optional overload control AVPs OC-OLR and OC-Supported-Features into existing commands 🧁.
Reacting nodes indicate support for DOIC by including OC-Supported-Features in all request messages they originate or relay 📨.
Reporting nodes indicate support for DOIC by including OC-Supported-Features in all answer messages they originate or relay, as long as those answers respond to a request that contained OC-Supported-Features 💌. Reporting nodes may include overload reports using OC-OLR in answer messages 📬.
Note: The overload control solution doesn't have fixed server and client roles 🙃. The DOIC node role is determined by the message type: whether the message is a request (sent by a "reacting node") or an answer (sent by a "reporting node") 🔄. So in a typical client-server deployment, the Diameter Client may report its overload condition to the Diameter Server for any Diameter-Server-initiated message exchange 🫨. An example is the Diameter Server requesting a re-authentication from a Diameter Client 🔐.
4.2. DOIC Capability Announcement
DOIC lets Diameter nodes figure out whether other nodes in the path of a request support the solution 🕵️. This is called DOIC Capability Announcement (DCA), and it's separate from the Diameter Capability Exchange 🙌.
The DCA mechanism uses OC-Supported-Features AVPs to indicate which Diameter overload features are supported 📋.
The first node in the path of a Diameter request that supports the DOIC solution inserts OC-Supported-Features into the request message 🥇.
The individual features supported by DOIC nodes are indicated in the OC-Feature-Vector AVP. Any semantics associated with the features will be defined in extension specifications that introduce them 🧩.
Note: As discussed elsewhere in the document, agents in the path of the request can modify OC-Supported-Features 📝.
Note: The DOIC solution must support deployments where Diameter Clients and/or Diameter Servers do not support the DOIC solution 🥺. In this scenario, Diameter Agents that support the DOIC solution may handle overload abatement for the non-supporting Diameter nodes. In this case, the DOIC agent will insertOC-Supported-Featuresinto requests that do not already contain one, telling the reporting node that there is a DOIC node that will handle overload abatement. For transactions where there was anOC-Supporting-FeaturesAVP in the request, the agent will insertOC-Supported-Featuresinto answers, telling the reacting node that there is a reporting node.
The OC-Feature-Vector AVP will always contain an indication of support for the loss overload abatement algorithm defined in this specification (see Section 6) 💜. This ensures that a reporting node always supports at least one of the advertised abatement algorithms received in request messages 🛡️.
The reporting node inserts OC-Supported-Features in all answer messages to requests that contained OC-Supported-Features 📬. The contents of the reporting node's OC-Supported-Features AVP indicate the set of Diameter overload features it supports. This specification defines one exception: the reporting node only includes an indication of support for one overload abatement algorithm, no matter how many algorithms the reacting node actually supports 🫣. The algorithm indicated is the one the reporting node intends to use should it enter an overload condition. Reacting nodes can use the indicated algorithm to prepare for possible overload reports, and they must use the indicated algorithm if traffic reduction is actually requested 🎯.
Note: The loss algorithm defined in this document is a stateless abatement algorithm 🧘. As a result, it doesn't require any actions by reacting nodes before receiving an overload report. Stateful abatement algorithms that base their logic on a history of sent request messages might require reacting nodes to maintain state before receiving an overload report, so that the overload reports can be properly handled 📚.
While it should only be done in exceptional circumstances and not during an active occurrence of overload, a reacting node that wants to switch to a different abatement algorithm can stop advertising support for the algorithm indicated by the reporting node 🔀. It can do this as long as support for the loss algorithm is always advertised 💖.
The DCA mechanism must also allow for the scenario where the set of features supported by the sender of a request differs from the set supported by agents in the path of that request 🌗. In this case, the agent can update OC-Supported-Features to reflect a mixture of the two sets of supported features 🎨.
Note: The logic to determine whether the content ofOC-Supported-Featuresshould be changed is out of scope for this document, and so is the logic to determine the content of a modifiedOC-Supported-FeaturesAVP 🙈. These are left to implementation decisions. Care must be taken not to introduce interoperability issues for downstream or upstream DOIC nodes. As such, the agent must act as a fully compliant reporting node to the downstream reacting node, and as a fully compliant reacting node to the upstream reporting node 🫶.
4.3. DOIC Overload Condition Reporting 📢
okay so, just like capability announcement, overload condition reporting uses brand new AVPs (Section 7.3) to say "hey, we're overloaded!" 🚨
The OC-OLR AVP is called an overload report 💌. It carries the type of report, a sequence number, how long the report stays valid, and AVPs that are specific to the abatement algorithm.
There are two types of overload reports in this doc: host reports and realm reports 🎀.
A report of type "HOST_REPORT" says that a specific host is overloaded. That host is identified by the Origin-Host AVP of the message containing the OLR, for the Application-ID in the transaction. When a reacting node gets an OLR of type "HOST_REPORT", it applies overload abatement treatment to the host-routed requests that were sent for this application to the overloaded host. Those requests are identified by the overload abatement algorithm (as defined in Section 2). 🫶
A report of type "REALM_REPORT" says that a realm is overloaded for the Application-ID in the transaction. The overloaded realm is identified by the Destination-Realm AVP of the message containing the OLR. When a reacting node gets an OLR of type "REALM_REPORT", it applies overload abatement treatment to the realm-routed requests that were sent for this application to the overloaded realm. Those requests are identified by the overload abatement algorithm (as defined in Section 2). 🌸
This document assumes there is a single source for realm reports for a given realm. If multiple nodes can send realm reports, it assumes that each of those nodes has full knowledge of the overload state of the entire realm. A reacting node cannot tell whether realm reports came from one node or from several 🤷♀️.
Note: Known issues exist if there are multiple sources for overload reports that apply to the same Diameter entity. Reacting nodes have no way of determining the source and, as such, will treat them as coming from a single source. Variance in sequence numbers between the two sources can then cause incorrect overload abatement treatment to be applied for indeterminate periods of time. 😬
Reporting nodes are responsible for figuring out when traffic needs to be reduced 🧠. How they do that is implementation specific, and it depends on the type of overload report being generated. A host report might be generated by tracking the use of resources that the host needs to handle transactions for the Diameter application. A realm report generally affects the traffic sent to multiple hosts, so it requires tracking the capacity of all servers that can handle realm-routed requests for the application and realm. It's a whole vibe 💅.
Once a reporting node decides traffic needs to go down, it uses the DOIC-defined AVPs to report the condition ✨. These AVPs are included in answer messages that are sent or relayed by the reporting node. The reporting node names the overload abatement algorithm that should handle the traffic reduction in the OC-Supported-Features AVP. The OC-OLR AVP is used to communicate the details of the requested reduction.
When reacting nodes receive an overload report, they apply the overload abatement algorithm to the traffic that the report affects 🦋. Which requests get abatement treatment depends on the algorithm. The loss abatement algorithm is defined in this document (Section 6). Other abatement algorithms can be defined in extensions to the DOIC solution.
There are two types of overload abatement treatment: diversion and throttling. Reacting nodes decide which treatment is right for each individual request 💜.
As the conditions behind an overload report change, the reporting node can send new overload reports. If things get worse, it can ask for a greater reduction. If things get better, it can ask for a smaller one 📉📈. The reporting node sends an overload report with a duration of zero to say the overload has ended and abatement is no longer needed 🥳.
The reacting node also works out when an overload report expires, based on the OC-Validity-Duration AVP in that report. Once the report expires, it stops applying the abatement algorithm 🕰️.
Note that erroneous overload reports can be used for DoS attacks. This includes the ability to indicate that a significant reduction in traffic, up to and including a request for no traffic, should be sent to a reporting node. As such, care should be taken to verify the sender of overload reports. 🚨🛡️ This one is seriously important, bestie, so please double-check who is actually sending you these reports!
4.4. DOIC Extensibility 🧩
The DOIC solution is built to be extensible 🌈. This extensibility is based on existing Diameter-based extensibility mechanisms, along with the DOIC capability announcement mechanism.
There are multiple categories of extensions that are expected. These include defining new overload abatement algorithms, defining new report types, and defining new scopes of messages that an overload report can affect 🍓.
A DOIC node communicates its supported features by including them in the OC-Feature-Vector AVP, as a sub-AVP of OC-Supported-Features. Any DOIC extension that is not backwards compatible defines new values for the OC-Feature-Vector AVP. DOIC extensions can also add new AVPs to the OC-Supported-Features AVP, if they need extra information about the new feature 🎁.
Overload reports can also be extended by adding new sub-AVPs to the OC-OLR AVP. That lets reporting nodes share extra info about how to handle an overload condition 🧁.
If it's necessary, new extensions can also define new AVPs that are not part of the OC-Supported-Features and OC-OLR group AVPs. That said, it is recommended that DOIC extensions use the OC-Supported-Features AVP and OC-OLR AVP to carry all DOIC-related AVPs 💖.
4.5. Simplified Example Architecture 🗺️
Figure 1 shows the simplified architecture for Diameter overload information conveyance 👀.
Realm X Same or other Realms
<--------------------------------------> <---------------------->
+--------+ : (optional) :
|Diameter| : :
|Server A|--+ .--. : +--------+ : .--.
+--------+ | _( `. : |Diameter| : _( `. +--------+
+--( )--:-| Agent |-:--( )--|Diameter|
+--------+ | ( ` . ) ) : +--------+ : ( ` . ) ) | Client |
|Diameter|--+ `--(___.-' : : `--(___.-' +--------+
|Server B| : :
+--------+ : :
End-to-end Overload Indication
1) <----------------------------------------------->
Diameter Application Y
Overload Indication A Overload Indication A'
2) <----------------------> <---------------------->
Diameter Application Y Diameter Application Y
Figure 1: Simplified Architecture Choices for Overload Indication
DeliveryIn Figure 1, the Diameter overload indication can be conveyed (1) end-to-end between servers and clients, or (2) between servers and the Diameter Agent inside the realm, and then between the Diameter Agent and the clients 🦋✨.
5. Solution Procedures 📜
This section outlines the normative behavior for the DOIC solution 💅.
5.1. Capability Announcement 📣
This section defines DOIC Capability Announcement (DCA) behavior 🎀.
Note: This specification assumes that changes in DOIC node capabilities are relatively rare events that occur as a result of administrative action. Reacting nodes ought to minimize changes that force the reporting node to change the features being used, especially during active overload conditions. But even if reacting nodes avoid such changes, reporting nodes still have to be prepared for them to occur. For example, differing capabilities between multiple reacting nodes may still force a reporting node to select different features on a per-transaction basis. 🙈
5.1.1. Reacting Node Behavior 🤖
A reacting node MUST include the OC-Supported-Features AVP in all requests 🫶. It MAY include the OC-Feature-Vector AVP, as a sub-AVP of OC-Supported-Features. If it does so, it MUST indicate support for the "loss" algorithm. If the reacting node is configured to support features (including other algorithms) in addition to the loss algorithm, it MUST indicate such support in an OC-Feature-Vector AVP.
An OC-Supported-Features AVP in answer messages indicates there is a reporting node for the transaction. Based on the features indicated in the OC-Feature-Vector AVP, the reacting node MAY take action. For example, it might create state for some stateful abatement algorithm 🧚.
Note: The loss abatement algorithm does not require stateful behavior when there is no active overload report.
Reacting nodes need to be prepared for the reporting node to change selected algorithms. This can happen at any time, including when the reporting node has sent an active overload report 😭. The reacting node can minimize the potential for changes by modifying the advertised abatement algorithms sent to an overloaded reporting node. It can change them to the currently selected algorithm and loss (or just loss, if loss is already the currently selected algorithm). This limits the potential change in abatement algorithm from the currently selected algorithm to loss, and it avoids changes to more complex abatement algorithms that require state to operate properly 👑.
5.1.2. Reporting Node Behavior ✨
okay bestie, so this is where the reporting node gets to be the hype person 📣 when a request comes in, it checks whether there's a reacting node for that transaction by looking for the OC-Supported-Features AVP in the request 🔍
if the request has an OC-Supported-Features AVP, then the reporting node MUST include the OC-Supported-Features AVP in the answer for that transaction 💖
Note: capability announcement happens on a per-transaction basis 🦋 so the reporting node CANNOT assume the capabilities a reacting node announced will be the same from one transaction to the next. no assumptions, babe 🙅♀️
and if the request does NOT have an OC-Supported-Features AVP, the reporting node MUST NOT put the OC-Supported-Features AVP, the OC-OLR AVP, or any other overload control AVPs from extension documents in the response 🚫 because no OC-Supported-Features AVP in the request means there's no reacting node for that transaction. that's the whole vibe 🌸
the reporting node figures out what overload control stuff the reacting node supports by looking at what's in (or not in) the OC-Feature-Vector AVP inside the OC-Supported-Features AVP of the request 🎀
now the big choice: the reporting node MUST select a single abatement algorithm in the OC-Feature-Vector AVP 👑 and that algorithm MUST tell the reacting node which abatement algorithm the reporting node wants used once it enters an overload condition 🔥
the selected abatement algorithm MUST come from the set of abatement algorithms in the request message's OC-Feature-Vector AVP. no picking outside the list, periodt 💅
a reporting node that picks the loss algorithm can either include the OC-Feature-Vector AVP with an explicit indication of the loss algorithm, OR it MAY just leave the OC-Feature-Vector AVP out 🧚 but if it picks a different algorithm, it MUST include the OC-Feature-Vector AVP with an explicit indication of that selected algorithm 💜
the reporting node SHOULD also flag support for other DOIC features from extension documents that it supports and that apply to the transaction, using the OC-Feature-Vector AVP ✨
Note: not every DOIC feature applies to every Diameter application or deployment scenario 🙈 the features in the OC-Feature-Vector AVP depend on the reporting node's local policy.
5.1.3. Agent Behavior 🦋
okay now the Diameter Agents get their moment 🫶 agents that support DOIC can make sure every message they relay contains the OC-Supported-Features AVP 💅
a Diameter Agent MAY take on reacting node behavior for Diameter endpoints that don't support the DOIC solution 🌈 it can tell a non-supporting endpoint apart because there's no OC-Supported-Features AVP in the request message 👀
for the agent to be a reacting node for a non-supporting endpoint, the Diameter Agent MUST include the OC-Supported-Features AVP in request messages it relays that don't already have one 💖
a Diameter Agent MAY also take on reporting node behavior for Diameter endpoints that don't support the DOIC solution 👑 but the agent MUST have visibility to all traffic going to that non-supporting host in order to be the reporting node for it 🔍 it spots a non-supporting endpoint for reporting node purposes when there's no OC-Supported-Features AVP in an answer message for a transaction whose request DID contain one 🙀
if a request already has the OC-Supported-Features AVP, a Diameter Agent MAY modify it to reflect the features that fit the transaction 🎀 otherwise, the agent relays the OC-Supported-Features AVP without any change 🧚
Example: if the agent supports a superset of the features reported by the reacting node, then the agent might choose, based on local policy, to advertise that superset of features to the reporting node 🌸
if the Diameter Agent changes the OC-Supported-Features AVP in a request message, then it's likely it will also need to change the OC-Supported-Features AVP in the answer for that transaction 🔥 and a Diameter Agent MAY modify the OC-Supported-Features AVP carried in answer messages ✨
when the agent makes changes to the OC-Supported-Features or OC-OLR AVPs, it needs to keep its behavior consistent with both upstream and downstream DOIC nodes 🫶 no one left on read, bestie 💜
5.2. Overload Report Processing 💌
5.2.1. Overload Control State 🧠
both reacting and reporting nodes keep track of Overload Control State (OCS) for active overload conditions 🌈 the sections that follow define the behavior that goes with that OCS 💅
the OCS contents in the reporting node and the reacting node are logical constructs 🦋 how the internal physical structure of the state actually looks is an implementation decision, so do your thing 🎀
5.2.1.1. Overload Control State for Reacting Nodes 🐣
a reacting node keeps the following OCS per supported Diameter application 👑
- a host-type OCS entry for each Destination-Host it sends host-type requests to, and
- a realm-type OCS entry for each Destination-Realm it sends realm-type requests to.
a host-type OCS entry is identified by the pair of Application-ID and the node's DiameterIdentity 🔍
a realm-type OCS entry is identified by the pair of Application-ID and realm 💜
the host-type and realm-type OCS entries include the following info (what's actually stored is an implementation decision 🙈):
- Sequence number (as received in OC-OLR; see Section 7.3) 🔢
- Time of expiry (derived from the OC-Validity-Duration AVP received in the OC-OLR AVP and the time of reception of the message carrying the OC-OLR AVP) ⏰
- Selected abatement algorithm (as received in the OC-Supported-Features AVP) 🧚
- Input data that is abatement algorithm specific (as received in the OC-OLR AVP -- for example, OC-Reduction-Percentage for the loss abatement algorithm) 🍓
5.2.1.2. Overload Control State for Reporting Nodes 🎀
a reporting node keeps OCS entries per supported Diameter application, per supported (and eventually selected) abatement algorithm, and per report type 🌸
an OCS entry is identified by the tuple of Application-ID, report type, and abatement algorithm, and it includes the following info (what's actually stored is an implementation decision 💅):
- Sequence number 🔢
- Validity duration ⏳
- Expiration time 📅
- Input data that is algorithm specific (for example, the reduction percentage for the loss abatement algorithm) 🍓
5.2.1.3. Reacting Node's Maintenance of Overload Control State 🛠️
when a reacting node receives an OC-OLR AVP, it MUST determine if it's for an existing or new overload condition 👀
Note: for the rest of this section, the term "OLR" refers to the combination of the contents of the received OC-OLR AVP and the abatement algorithm indicated in the received OC-Supported-Features AVP 🧠
when receiving an answer message with multiple OLRs of different supported report types, a reacting node MUST process each received OLR 💖
the OLR is for an existing overload condition if a reacting node has an OCS that matches the received OLR ✨
for a host report, this means it matches the Application-ID and the host's DiameterIdentity in an existing host OCS entry 🔍
for a realm report, this means it matches the Application-ID and the realm in an existing realm OCS entry 🗺️
if the OLR is for an existing overload condition, then a reacting node MUST determine if the OLR is a retransmission or an update to the existing OLR 🔁
if the sequence number for the received OLR is greater than the sequence number stored in the matching OCS entry, then a reacting node MUST update the matching OCS entry 🚀
if the sequence number for the received OLR is less than or equal to the sequence number in the matching OCS entry, then a reacting node MUST silently ignore the received OLR 🤫 the matching OCS MUST NOT be updated in this case 🙅♀️
if the reacting node determines that the sequence number has rolled over, then the reacting node MUST update the matching OCS entry 🔄 this can be determined by recognizing that the number has changed from a value within 1% of the maximum value in the OC-Sequence-Number AVP to a value within 1% of the minimum value in the OC-Sequence-Number AVP 🧮
if the received OLR is for a new overload condition, then a reacting node MUST generate a new OCS entry for the overload condition 🐣
for a host report, this means a reacting node creates an OCS entry with the Application-ID in the received message and the DiameterIdentity of the Origin-Host in the received message 🏠
Note: this solution assumes that the Origin-Host AVP in the answer message included by the reporting node is not changed along the path to the reacting node 🛣️
for a realm report, this means a reacting node creates an OCS entry with the Application-ID in the received message and the realm of the Origin-Realm in the received message 🌍
if the received OLR contains a validity duration of zero ("0"), then a reacting node MUST update the OCS entry as being expired 🛑
Note: it's not necessarily appropriate to delete the OCS entry 🙅♀️ because the recommended behavior is that the reacting node slowly returns to full traffic when ending an overload abatement period 🐢✨
the reacting node does NOT delete an OCS when receiving an answer message that doesn't contain an OC-OLR AVP 🫶 (absence of OLR means "no change") 💜
5.2.1.4. Reporting Node's Maintenance of Overload Control State ✨
A reporting node SHOULD create a new OCS entry when it enters an overload condition, bestie. That's how it keeps track of what it told everyone 📝
Note: If a reporting node knows, because the OC-Supported-Features AVP is missing from the messages it receives, that there are no reacting nodes supporting DOIC, then the reporting node can choose to not create OCS entries. Tiny detail, but it's a whole vibe 🌸
When a new OCS entry gets generated, its sequence number SHOULD be set to zero ("0") 🔢
When generating sequence numbers for new overload conditions, the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report for the same application and report type that the reporting node sent earlier. This property MUST hold over a reboot of the reporting node. Non-negotiable, no cap 🙅♀️💅
Note: One way to handle this across a reboot of a reporting node is to use a timestamp for the first overload condition that occurs after the report, and then to start using sequences beginning with zero for subsequent overload conditions. Smart, right? 🧠🎀
A reporting node MUST update an OCS entry whenever it needs to adjust the validity duration of the overload condition at reacting nodes. Main character energy for the timers ⏰
Example: If a reporting node wants reacting nodes to keep doing overload abatement for a longer period of time than it originally said, it updates the entry. This also applies if the reporting node wants that period to be shorter. Both directions, periodt 🦋
A reporting node MUST update an OCS entry when it wants to change any parameters specific to the abatement algorithm. That includes, for example, the reduction percentage used by the loss abatement algorithm 🍓
Example: If a reporting node wants to change the reduction percentage higher (because the overload condition has gotten worse) or lower (because it has improved), then the reporting node updates the appropriate OCS entry. Adjusting the dial as the vibes shift 🎚️✨
A reporting node MUST increment the sequence number associated with the OCS entry any time the contents of that OCS entry change. This is what tells reacting nodes to go ahead and process the OC-OLR AVP, because they're getting a new sequence number 🫶
A reporting node SHOULD update an OCS entry with a validity duration of zero ("0") when the overload condition ends. That's the official "we're done here" signal 💜
Note: If a reporting node knows that the OCS entries in the reacting nodes are close to expiring, then the reporting node might decide not to send an OLR with a validity duration of zero. Efficiency is iconic 🧚
A reporting node MUST keep an OCS entry with a validity duration of zero ("0") for long enough to make sure that any unexpired OCS entry on a reacting node, created because of the overload condition, gets deleted. Don't ghost the cleanup step 👻🧹
5.2.2. Reacting Node Behavior 🦋
When a reacting node sends a request, it MUST determine whether that request matches an active OCS. The check comes first, bestie 🔍
If the request matches an active OCS, then the reacting node MUST use the overload abatement algorithm indicated in that OCS to decide whether the request gets overload abatement treatment. The algorithm does the judging 👩⚖️
For the loss abatement algorithm defined in this specification, see Section 6 for the overload abatement algorithm logic that gets applied. Go check Section 6, it's the good stuff 📖
If the overload abatement algorithm selects the request for overload abatement treatment, then the reacting node MUST apply overload abatement treatment to that request. Which treatment applies depends on the context of the request, so it's not one-size-fits-all 💅
If diversion abatement treatment is possible (meaning a different path for the request can be selected where the overloaded node is not part of that different path), then the reacting node SHOULD apply diversion abatement treatment to the request. Reroute it if you can 🛣️✨ The reacting node MUST apply throttling abatement treatment to requests identified for abatement treatment when diversion treatment is not possible or was not applied. Throttling is the backup plan, and it's a must 🫡
Note: This only covers the case where there are two defined abatement treatments, diversion and throttling. Any extension that defines a new abatement treatment must also define how it interacts with the existing treatments. Plot twists need rules 📜
If the overload abatement treatment results in throttling of the request, and the reacting node is an agent, then the agent MUST send an appropriate error as defined in Section 8. Agents don't just ghost the client, they send the error 💌
Diameter endpoints that throttle requests need to do so according to the rules of the client application. Those rules vary by application, and they're beyond the scope of this document, so this one isn't on me 🙈
In the case that the OCS entry indicated that no traffic was to be sent to the overloaded entity, and the validity duration expires, then the overload abatement associated with the overload report MUST be ended in a controlled fashion. Wind it down gracefully, no drama 🌈
5.2.3. Reporting Node Behavior 👑
If there is an active OCS entry, then a reporting node SHOULD include the OC-OLR AVP in all answers to requests that contain the OC-Supported-Features AVP and that match the active OCS entry. Keep the reacting nodes in the loop 📣
Note: A request matches 1) if the Application-ID in the request matches the Application-ID in any active OCS entry, and 2) if the report type in the OCS entry matches a report type that the reporting node supports, as indicated in the OC-Supported-Features AVP. Two checks, both have to pass ✅
The contents of the OC-OLR AVP depend on the selected algorithm, so it's algorithm-dependent 🧩
A reporting node MAY choose not to resend an overload report to a reacting node if it can guarantee that this overload report is already active in that reacting node. If it's already active, no need to repeat yourself 🙃
Note: In some cases (for example, when there are one or more agents in the path between the reporting and reacting nodes, or when overload reports get discarded by reacting nodes), a reporting node may not be able to guarantee that the reacting node has received the report. It's giving "trust but verify" 🕵️♀️
A reporting node MUST NOT send overload reports of a type that the reacting node has not advertised as supported. Don't send it something it can't handle, obviously 🚫
Note: A reacting node implicitly advertises support for the host and realm report types by including theOC-Supported-FeaturesAVP in the request. Support for other report types gets explicitly indicated by new feature bits in theOC-Feature-VectorAVP. Implicit for host and realm, explicit for everything else 🎯
A reporting node SHOULD explicitly indicate the end of an overload occurrence by sending a new OLR with OC-Validity-Duration set to a value of zero ("0"). The reporting node SHOULD ensure that all reacting nodes receive the updated overload report. Clear closure for everyone, fr fr 🌸
A reporting node MAY rely on the OC-Validity-Duration AVP values for the implicit cleanup of overload control state on the reacting node. The timer does the cleaning for you 🧹✨
Note: All OLRs sent have an expiration time, calculated by adding the validity duration contained in the OLR to the time the message was sent. Transit time for the OLR can safely be ignored. The reporting node can make sure that all reacting nodes have received the OLR by continuing to send it in answer messages until the expiration time for all OLRs sent for that overload condition has passed. Math, but make it iconic 🧮💖
When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes. If the reporting node also locally throttles the same set of messages, the overall number of throttled requests may end up higher than intended. So, before applying local message throttling, a reporting node needs to check whether those messages match existing OCS entries. A match means those messages already survived throttling from the downstream nodes that got the related OLR. Don't double-dip on the throttling 🥄
However, even if the messages do match existing OCS entries, the reporting node can still apply other abatement methods, such as diversion. The reporting node might also need to throttle requests for reasons other than overload. For example, an agent or server might have a configured rate limit for each client, and it might throttle requests that exceed that limit, even if those requests had already been candidates for throttling by downstream nodes. The reporting node also has the option to send new OLRs that ask for greater reductions in traffic, which cuts down on the need for local throttling. Options are your friend 🦋
A reporting node SHOULD decrease requested overload abatement treatment in a controlled fashion to avoid oscillations in traffic. No whiplash allowed 🎢
Example: A reporting node might wait some time after the overload ends before terminating the OLR, or it might send a series of OLRs that indicate progressively less overload severity. Easing off like a pro 🌈
5.3. Protocol Extensibility 🧚
The DOIC solution can be extended. The types of potential extensions include new traffic abatement algorithms, new report types, or other new functionality. The possibilities are kinda endless 💜
When defining a new extension that requires new normative behavior, the specification must define a new feature for the OC-Feature-Vector AVP. That feature bit is what communicates support for the new feature. New feature, new bit, new flex 🎀
The extension may define new AVPs for use in the DOIC Capability Announcement and for use in DOIC overload reporting. These new AVPs SHOULD be defined as extensions to the OC-Supported-Features or OC-OLR AVPs defined in this document. Build on what's already there 🧱
The Grouped AVP extension mechanisms defined in [RFC6733] apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing application. Mandatory means mandatory, bestie 🔒
When defining new report type values, the corresponding specification must define the semantics of the new report types and how they affect the OC-OLR AVP handling. Define your terms, babe 📚
The OC-Supported-Feature and OC-OLR AVPs can be expanded with optional sub-AVPs only if a legacy DOIC implementation can safely ignore them without breaking backward compatibility for the given OC-Report-Type AVP value. Any new sub-AVPs must not require that the M-bit be set. Backward compatibility is non-negotiable 🫶
Documents that introduce new report types must describe any limitations on their use across non-supporting agents. Be upfront about the limits 💅
As with any Diameter specification, RFC 6733 requires all new AVPs to be registered with IANA. See Section 9 for the required procedures. New features (feature bits in the OC-Feature-Vector AVP) and report types (in the OC-Report-Type AVP) MUST be registered with IANA. Paperwork, but make it cute 📋🌸
6. Loss Algorithm 🌈
This section documents the Diameter overload loss abatement algorithm. Let's get into the loss math, it's the main event 🍿
6.1. Overview 🦋
okay so DOIC supports multiple overload abatement algorithms, which is giving main character energy. Whichever algorithm handles a given overload gets picked during the DOIC Capability Announcement process in Section 5.1. 💅
The loss algorithm in this section is the default one, and every Diameter node that supports DOIC must support it. ✨
The loss algorithm is super straightforward and stateless. Reporting nodes use it to ask for a percentage cut in the traffic they receive, and which traffic gets cut depends on the type of overload report. 🌸
Reporting nodes ask for a stateless cut in the number of requests, by a percentage they name. That percentage is measured against how many messages the node would otherwise send, and it doesn't matter how many requests it sent in the past. 🍓
Conceptually, the reacting node's logic looks something like this:
- An overload report comes in, and the reacting node either saves its OCS or updates it (if needed). 💖
- The application running on the reacting node generates a new Diameter request. 🧚
- The reacting node sees that an active overload report applies to the request, based on the matching OCS entry. 👑
- The reacting node decides whether the request should get abatement treatment. One way to do this for each request is to pick a uniformly selected random number between 1 and 100. If that number is less than or equal to the indicated reduction percentage, the request gets abatement treatment. Otherwise it gets normal routing treatment. 🎲
6.2. Reporting Node Behavior 🌈
How a reporting node figures out how much traffic it needs to cut to fix an overload is up to the implementation. 🙈
When a reporting node that picked the loss abatement algorithm decides it needs a traffic cut, it puts an OC-OLR AVP in answer messages, as described in Section 5.2.3. 💜
When it sends the OC-OLR AVP, the reporting node MUST include a percentage reduction in the OC-Reduction-Percentage AVP. 🔥
The reporting node MAY change the reduction percentage in later overload reports. If it does, it must follow the overload report handling rules in Section 5.2.3. ✨
6.3. Reacting Node Behavior 🫶
How a reacting node decides which request messages get abatement treatment is also up to the implementation. 🦋
When a reacting node gets an OC-OLR in an answer message, and the algorithm in the OC-Supported-Features AVP is the loss algorithm, it MUST apply abatement treatment to the requested percentage of request messages it sends. 💅
Note: The loss algorithm is stateless, which means the reacting node doesn't guarantee an absolute drop in traffic. What it does guarantee is that the requested percentage of new requests gets abatement treatment. 🌸
If the reacting node is at 100% traffic reduction (so it got an OLR saying no traffic should be sent, because the overload report timed out), the sending node SHOULD be conservative. For example, it can first send "probe" messages to learn the overloaded node's condition before settling on whatever traffic amount or rate the sender picks. The same concerns apply whenever an overload report times out, unless the previous overload report stated 0% reduction. 🙏
Note: The point of this behavior is to avoid overload condition thrashing. That's when going straight from 100% reduction to 0% reduction sends the reporting node right back into overload. 💀
7. Attribute Value Pairs 🎀
This section covers the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. 🧚
For more on AVPs and AVP data types, check out Section 4 of [RFC6733]. 📖
7.1. OC-Supported-Features AVP 💖
The OC-Supported-Features AVP (AVP Code 621) is of type Grouped and has two jobs. First, it announces that a node supports the DOIC solution in general. Second, it describes the DOIC features the sending node supports. Every Diameter request message a DOIC supporting node sends MUST include the OC-Supported-Features AVP. 💅
OC-Supported-Features ::= < AVP Header: 621 >
[ OC-Feature-Vector ]
* [ AVP ]7.2. OC-Feature-Vector AVP 🦋
The OC-Feature-Vector AVP (AVP Code 622) is of type Unsigned64. It holds a 64-bit flags field listing the capabilities a DOIC node has announced. The value zero (0) is reserved. ✨
The OC-Feature-Vector sub-AVP announces which DOIC features the node supports. It's a flag-bits field, and each bit announces one feature or capability. If the OC-Feature-Vector AVP is missing from request messages, that means only the default traffic abatement algorithm from this specification is supported. If it's missing from answer messages, the default traffic abatement algorithm from this specification is selected (other traffic abatement algorithms might still be supported), and no features besides abatement algorithms are supported. 🌸
This document defines the following capability:
OLR_DEFAULT_ALGO (0x0000000000000001)When a DOIC reacting node sets this flag, it means the default traffic abatement (loss) algorithm is supported. When a DOIC reporting node sets it, it means the loss algorithm will be used for the requested overload abatement. 🔥
7.3. OC-OLR AVP 🍓
The OC-OLR AVP (AVP Code 623) is of type Grouped and holds the info needed to share an overload report about an overload condition at the reporting node. The application it applies to is identified by the Application-ID in the Diameter message header. The host or realm it concerns is determined from the Origin-Host AVP and/or Origin-Realm AVP in the encapsulating Diameter command. The OC-OLR AVP is meant to be sent only by a reporting node. 👑
OC-OLR ::= < AVP Header: 623 >
< OC-Sequence-Number >
< OC-Report-Type >
[ OC-Reduction-Percentage ]
[ OC-Validity-Duration ]
* [ AVP ]7.4. OC-Sequence-Number AVP 🧚
The OC-Sequence-Number AVP (AVP Code 624) is of type Unsigned64. Section 5.2 explains how it's used in overload control. ✨
Functionally, the OC-Sequence-Number AVP is a nonvolatile, increasing counter for a sequence of overload reports between two DOIC nodes for the same overload occurrence. Sequence numbers work in one direction only. That means the two sequence numbers going each way between two DOIC nodes aren't related or correlated at all. 💖
7.5. OC-Validity-Duration AVP ⏰
The OC-Validity-Duration AVP (AVP Code 625) is of type Unsigned32. It says, in seconds, how long the overload report is valid. The clock starts when the first OC-OLR AVP with a given OC-Sequence-Number AVP value is received. The default value is 30 seconds. If the OC-Validity-Duration AVP isn't in the OC-OLR AVP, the default applies. The maximum value is 86,400 seconds (24 hours). If the received OC-Validity-Duration value is greater than that maximum, the default applies instead. 🫶
7.6. OC-Report-Type AVP 🌈
The OC-Report-Type AVP (AVP Code 626) is of type Enumerated. Its value tells you what the overload report is about. These values are defined for now:
HOST_REPORT(0): The overload report is for a host. Overload abatement treatment applies to host-routed requests. 🏠REALM_REPORT(1): The overload report is for a realm. Overload abatement treatment applies to realm-routed requests. 🌍
The values 2-4294967295 are unassigned. 🙈
7.7. OC-Reduction-Percentage AVP 💜
The OC-Reduction-Percentage AVP (AVP Code 627) is of type Unsigned32. It describes what percentage of its traffic the sender is asked to cut, compared to what it would otherwise send. This AVP applies to the default (loss) algorithm in this specification, but it can be reused for future abatement algorithms if the meaning still fits. 🔥
The value has to be between zero (0) and one hundred (100). Values over 100 get ignored. A value of 100 means all traffic should be throttled. In other words, the reporting node is under severe load and stops processing any new messages. A value of 0 means the reporting node is stable and the reacting node doesn't need to apply any traffic abatement. 💅
7.8. AVP Flag Rules 🎀
Here's the table of AVP flag rules. It lists each attribute's AVP code, the section it's defined in, its value type, and whether the M-bit is MUST or MUST NOT. ✨
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------+----+----+
|OC-Supported-Features 621 7.1 Grouped | | V |
+--------------------------------------------------+----+----+
|OC-Feature-Vector 622 7.2 Unsigned64 | | V |
+--------------------------------------------------+----+----+
|OC-OLR 623 7.3 Grouped | | V |
+--------------------------------------------------+----+----+
|OC-Sequence-Number 624 7.4 Unsigned64 | | V |
+--------------------------------------------------+----+----+
|OC-Validity-Duration 625 7.5 Unsigned32 | | V |
+--------------------------------------------------+----+----+
|OC-Report-Type 626 7.6 Enumerated | | V |
+--------------------------------------------------+----+----+
|OC-Reduction | | |
| -Percentage 627 7.7 Unsigned32 | | V |
+--------------------------------------------------+----+----+As the Diameter base protocol [RFC6733] describes, the application may define how the M-bit is used for a given AVP in a given command. 🦋
8. Error Response Codes 💅
okay so, when a DOIC node turns down a Diameter request because it's overloaded, it MUST pick an appropriate error response code 🎀. The choice comes down to one question: how likely is that request to succeed if it gets retried on a different path? 🧚
Note: This only applies for DOIC nodes that are not the originator of the request.
If a reporting node rejects a Diameter request because of overload and it can assume the same request may succeed on a different path, it SHOULD send a DIAMETER_TOO_BUSY error response 🌸.
But if the reporting node knows or assumes the same request will NOT succeed on a different path, the DIAMETER_UNABLE_TO_COMPLY error response SHOULD be used instead 🙅♀️. Retrying would just eat up valuable resources during an overload, and nobody wants that 💀.
Example: If the request arrived at the reporting node without aDestination-HostAVP, the reporting node might determine that there is an alternative Diameter node that could successfully process the request, and that retrying the transaction would not negatively impact the reporting node. In this case,DIAMETER_TOO_BUSYwould be sent.
Example: If the request arrived at the reporting node with aDestination-HostAVP populated with its own Diameter identity, then the reporting node can assume that retrying the request would result in it coming to the same reporting node. In this case,DIAMETER_UNABLE_TO_COMPLYwould be sent.
Example: A second one: an agent that supports the DOIC solution is acting as a reacting node for a non-supporting client. Requests that get rejected because of DOIC throttling by the agent in this scenario would generally be rejected with a DIAMETER_UNABLE_TO_COMPLY response code 🍓.
9. IANA Considerations 🌈
9.1. AVP Codes
New AVPs defined by this specification are listed in Section 7. All AVP codes are allocated from the "AVP Codes" sub-registry under the "Authentication, Authorization, and Accounting (AAA) Parameters" registry ✨.
9.2. New Registries
Two new registries have been created in the "AVP Specific Values" sub-registry under the "Authentication, Authorization, and Accounting (AAA) Parameters" registry 🦋.
A new "OC-Feature-Vector AVP Values (code 622)" registry has been created. This registry contains the following:
Feature Vector Value Name
Feature Vector Value
Specification defining the new valueSee Section 7.2 for the initial Feature Vector Value in the registry. This specification defines the value. New values can be added to the registry using the Specification Required policy [RFC5226] 💜.
A new "OC-Report-Type AVP Values (code 626)" registry has been created. This registry contains the following:
Report Type Value Name
Report Type Value
Specification defining the new valueSee Section 7.6 for the initial assignment in the registry. New types can be added using the Specification Required policy [RFC5226] 🫶.
10. Security Considerations 😭🚨
okay bestie, this part is SERIOUS, so read it carefully 🙈. DOIC lets Diameter nodes ask their downstream nodes to send fewer Diameter requests. They do this by swapping overload reports that directly cause that reduction. That exchange can be attacked in several ways, and it could be abused as a denial-of-service (DoS) attack vector 💀. For instance, a bunch of injected realm OLRs with a requested reduction percentage of 100% could be used to completely wipe out any traffic going to that realm. Yikes 🥀.
Overload reports may contain information about the topology and current status of a Diameter network. That info is potentially sensitive, so network operators may want to control who gets to see overload reports, so nobody uses them for competitive intelligence or to target attacks 🔥.
Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This may cause complications when sending overload reports between non-adjacent nodes 🫠.
10.1. Potential Threat Modes
Diameter is all about transactions: requests and answers exchanged between clients and servers 🧚. These clients and servers may be peers, meaning they may share a direct transport (e.g., TCP or SCTP) connection, or the messages may travel through one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPsec to authenticate peers and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer 🔐.
When agents are involved, you get an effectively transitive trust model. A Diameter client or server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on 🕸️. Since confidentiality and integrity protection happen at the transport layer, agents can read, and perhaps modify, any part of a Diameter message, including an overload report 👀.
There are several ways an attacker might try to exploit the overload control mechanism. An unauthorized third party might inject an overload report into the network. If this third party is upstream of an agent, and that agent fails to apply proper authorization policies, downstream nodes may mistakenly trust the report 🚫. This attack is at least partially mitigated by the assumption that nodes include overload reports in Diameter answers but not in requests. That means an attacker needs knowledge of the original request in order to construct an answer. Such an answer would also need to arrive at a Diameter node via a protected transport connection. So, implementations MUST validate that an answer containing an overload report is a properly constructed response to a pending request before acting on the overload report, and that the answer was received via an appropriate transport connection 🛡️.
A similar attack involves a compromised but otherwise authorized node that sends an inappropriate overload report. For example, a server for the realm "example.com" might send an overload report saying that a competitor's realm "example.net" is overloaded. If other nodes act on that report, they may falsely believe that "example.net" is overloaded, which effectively cuts that realm's capacity 😤. Therefore, it's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility before acting on the report or forwarding it to other peers 🚩. For example, an overload report from a peer that applies to a realm not handled by that peer is suspect. This may require out-of-band, non-Diameter agreements and/or mechanisms 🤝.
Note: This attack is partially mitigated by the fact that the application, as well as host and realm, for a given OLR is determined implicitly by respective AVPs in the enclosing answer. If a reporting node modifies any of those AVPs, the enclosing transaction will also be affected.
10.2. Denial-of-Service Attacks
Diameter overload reports, especially realm reports, can make a node stop sending some or all Diameter requests for an extended period. That makes them a super tempting vector for DoS attacks 🎯. Plus, since Diameter is almost always used to support other protocols, a DoS attack on Diameter is likely to hit those protocols too. In the worst case, where the Diameter application is used for access control into an IP network, a coordinated DoS attack could block all traffic into that network 😱. So Diameter nodes MUST NOT honor or forward OLRs received from peers that are not trusted to send them. No exceptions, periodt 🙅♀️.
An attacker might also use the info in an OLR to help with DoS attacks. For example, they could use info about current overload conditions to time an attack for maximum effect, or use later overload reports as a feedback loop to learn how a previous or ongoing attack is going 🕵️♀️. Operators need the ability to make sure OLRs don't leak to untrusted parties 🔒.
10.3. Noncompliant Nodes
Without an overload control mechanism, Diameter nodes need to protect themselves from floods of requests, and make sure a disproportionate load from one source doesn't stop other sources from getting service 🛟. For example, a Diameter server might throttle a certain percentage of requests from sources that go over certain limits. Overload control can be thought of as an optimization for those strategies, where downstream nodes never send the excess requests in the first place. However, having an overload control mechanism does not remove the need for these other protection strategies 💖.
When a Diameter node sends an overload report, it cannot assume that all nodes will comply, even if they say they support DOIC 🙄. A noncompliant node might keep sending requests with no reduction in load. That noncompliance could be accidental, or malicious, to gain an unfair advantage over compliant nodes 😈. Requirement 28 in [RFC7068] says the overload control solution cannot assume that all Diameter nodes in a network are trusted. It also requires that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service 👑.
10.4. End-to-End Security Issues 🔐✨
okay bestie, this one is a whole trust issue 💀. the lack of end-to-end integrity features makes it SO hard to trust overload reports from nodes that aren't right next to you 😩. any agent along the message path can slide in and insert or modify overload reports 🙈. so nodes have to trust that their adjacent peers are doing proper checks on reports from their peers, and so on down the line 🔗. that's a transitive-trust requirement that can stretch across potentially really long chains of nodes, and network operators have to figure out if that's actually okay for their deployments 🤔. nodes supporting Diameter overload control MUST give operators the power to pick which peers are trusted to deliver overload reports, and whether they're trusted to forward reports from non-adjacent nodes 👑. DOIC nodes MUST strip DOIC AVPs from messages received from peers that aren't trusted for DOIC purposes 🧹.
the lack of end-to-end confidentiality protection means any Diameter Agent in the path of an overload report can read what's inside it 👀. so on top of picking trusted senders, operators MUST be able to pick which peers are authorized to receive reports 🎀. a node MUST NOT send an overload report to a peer that isn't authorized to receive it 🚫. and an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that isn't authorized to receive overload reports 🧼.
a DOIC node can't always automatically detect that a peer also supports DOIC 😬. for example, a node might have a peer that's a non-supporting agent. if nodes on the other side of that agent send OC-Supported-Features AVPs, the agent is likely to forward them as unknown AVPs 📦. messages received across the non-supporting agent may look exactly like messages received across a DOIC supporting agent, which gives the false impression that the non-supporting agent actually supports DOIC 🤥. this complicates the transitive-trust nature of DOIC, so operators need to be careful to avoid situations where a non-supporting agent is mistakenly trusted to enforce DOIC-related authorization policies 🚨.
it is expected that work on end-to-end Diameter security might make it easier to establish trust in non-adjacent nodes for overload control purposes 🌈. but readers should be reminded that the overload control mechanism allows Diameter Agents to modify AVPs in, or insert additional AVPs into, existing messages that were originated by other nodes 🧩. if end-to-end security is enabled, there's a risk that such modification could violate integrity protection 💔. the details of using any future Diameter end-to-end security mechanism with overload control will require careful consideration, and they're beyond the scope of this document 📝.
11. References 📚
11.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. - [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>.
11.2. Informative References
- [Cx] 3GPP, "Cx and Dx interfaces based on the Diameter protocol; Protocol details", 3GPP TS 29.229 12.7.0, September 2015.
- [PCC] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 12.10.0, September 2015.
- [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, DOI 10.17487/RFC4006, August 2005,
<http://www.rfc-editor.org/info/rfc4006>. - [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, DOI 10.17487/RFC7068, November 2013,
<http://www.rfc-editor.org/info/rfc7068>. - [S13] 3GPP, "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol", 3GPP TS 29.272 12.8.0, September 2015.
Appendix A. Issues Left for Future Specifications 🔮
the base solution for overload control doesn't cover every possible use case 🤷♀️. a bunch of solution aspects were intentionally left for future specification and protocol work, so the following subsections cover some of the potential extensions to the DOIC solution 🌸.
A.1. Additional Traffic Abatement Algorithms
this specification describes only means for a simple loss-based algorithm 📉. future algorithms can be added using the designed solution extension mechanism, and the new algorithms need to be registered with IANA. see Sections 7.2 and 9 for the required IANA steps 📋.
A.2. Agent Overload
this specification focuses on Diameter endpoint (server or client) overload 🖥️. a separate extension will be required to outline the handling of the case of agent overload 🧚.
A.3. New Error Diagnostic AVP
this specification indicates the use of existing error messages when nodes reject requests due to overload 🙃. there's an expectation that additional error codes or AVPs will be defined in a separate specification to indicate that overload was the reason for rejecting the message 💅.
Appendix B. Deployment Considerations 🏡
Non-supporting Agents
due to the way that realm-routed requests are handled in Diameter networks, with the server selection for the request done by an agent, network operators should enable DOIC at agents that perform server selection first 🗺️.
Topology-Hiding Interactions
there are proxies that implement what's referred to as Topology Hiding 🫥. this can include cases where the agent modifies the Origin-Host in answer messages. the behavior of the DOIC solution isn't well understood when this happens, so the DOIC solution does not address this scenario 🙈.
Inter-Realm/Administrative Domain Considerations
there are likely to be special considerations for handling DOIC signaling across administrative boundaries 🚧. this includes considerations for whether or not information included in the DOIC signaling should be sent across those boundaries. also, consideration should be taken as to whether a reacting node in one realm can be trusted to implement the requested overload abatement handling for overload reports received from a separately administered realm 🤝.
Appendix C. Considerations for Applications Integrating the DOIC Solution 🧩
this section outlines the things to think about when you're integrating the DOIC solution into Diameter applications 💖.
C.1. Application Classification
the following is a classification of Diameter applications and request types 🗂️. this discussion is meant to document the factors that play into decisions made by the Diameter entity responsible for handling overload reports ✨.
Section 8.1 of [RFC6733] defines two state machines that imply two types of applications: session-less and session-based applications 🎭. the main difference between them is the lifetime of Session-Ids ⏳.
for session-based applications, the Session-Id is used to tie multiple requests into a single session 🎀. the Credit-Control application defined in [RFC4006] is an example of a Diameter session-based application 💳.
in session-less applications, the lifetime of the Session-Id is a single Diameter transaction. that means the session is implicitly terminated after a single Diameter transaction, and a new Session-Id is generated for each Diameter request 🔁.
for the purposes of this discussion, session-less applications are further divided into two types:
Stateless Applications
requests within a stateless application have no relationship to each other 🫧. the 3GPP-defined S13 application is an example of a stateless application [S13], where only a Diameter command is defined between a client and a server and no state is maintained between two consecutive transactions 🌙.
Pseudo-Session Applications
these applications don't rely on the Session-Id AVP to correlate application messages related to the same session. instead, they use other session-related information in the Diameter requests for this purpose 🕵️♀️. the 3GPP-defined Cx application [Cx] is an example of a pseudo-session application 🦋.
the handling of overload reports must take the type of application into consideration, as discussed in Appendix C.2 👑.
C.2. Implications of Application Type Overload 💅
okay so this part is about how to handle overload that a Diameter entity reports, and it all depends on what kind of application is involved 🎀 Appendix C.3 covers handling different request types when the target server is known to be overloaded, so peep that too ✨
These discussions assume that the strategy for mitigating reported overload is to reduce the overall workload sent to the overloaded entity. Applying overload treatment to requests aimed at an overloaded Diameter entity is basically the whole point here 🧚 The spec doesn't pin down how to cut the offered load. It could mean routing requests to another Diameter entity that's known to be able to handle them, or it could mean rejecting certain requests. For a Diameter Agent, rejecting requests will usually mean generating appropriate Diameter error responses. For a Diameter client, rejecting requests depends on the application. For example, it could mean telling the entity that asked for the Diameter service that the network is busy and to try again later 📞
Stateless Applications 🦋
By definition, there is no relationship between individual requests in a stateless application. So when a request is sent or relayed to an overloaded Diameter entity (either a Diameter Server or a Diameter Agent), the sending or relaying entity can choose to apply overload treatment to any request targeted at that entity 💖
Pseudo-session Applications 🌈
For pseudo-session applications, there is an implied ordering of requests. So decisions about which requests headed to an overloaded entity to reject could take the command code of the request into account. This generally means transactions later in the sequence should get more favorable treatment than messages earlier in it. Why? Because more work has already been done by the Diameter network for the transactions that come later in the sequence. Rejecting them could increase the load on the network, since the earlier transactions might also need to be repeated 😭
Session-Based Applications 🍓
Overload handling for session-based applications has to take into consideration the workload of setting up and maintaining a session 🎀 So the entity sending requests toward an overloaded Diameter entity for a session-based application might tend to reject new session requests before rejecting intra-session requests. Also, session-ending requests might be given a lower probability of being rejected, because rejecting them could leave session status out of sync between the Diameter clients and servers 🙈 Application designers who would decide to reject mid-session requests will need to consider whether the rejection invalidates the session and any resulting session cleanup procedures 🔥
C.3. Request Transaction Classification 🧩
Independent Request 🌸
An independent request is not correlated to any other requests. As such, the lifetime of the Session-Id is constrained to an individual transaction 💜
Session-Initiating Request 🚀
A session-initiating request is the initial message that establishes a Diameter session. The ACR message defined in [RFC6733] is an example of a session-initiating request ✨
Correlated Session-Initiating Request 🔗
There are cases when multiple session-initiated requests must be correlated and managed by the same Diameter server. This is notably the case in the 3GPP Policy and Charging Control (PCC) architecture [PCC], where multiple apparently independent Diameter application sessions are actually correlated and must be handled by the same Diameter server 👑
Intra-session Request 🎀
An intra-session request is a request that uses the same Session-Id as one used in a previous request. An intra-session request generally needs to be delivered to the server that handled the session-creating request for that session. The STR message defined in [RFC6733] is an example of an intra-session request 💅
Pseudo-session Requests 🧚
Pseudo-session requests are independent requests that do not use the same Session-Id, but they are correlated by other session-related information contained in the request. There exist Diameter applications that define an expected ordering of transactions. This sequencing of independent transactions results in a pseudo-session. The AIR, MAR, and SAR requests in the 3GPP-defined Cx [Cx] application are examples of pseudo-session requests 🦋
C.4. Request Type Overload Implications 🌷
The request classes identified in Appendix C.3 have implications for decisions about which requests should be throttled first. The following list of request treatments regarding throttling is provided as guidelines for application designers implementing the Diameter overload control mechanism described in this document. The exact behavior regarding throttling is a matter of local policy, unless it's specifically defined for the application 📋
Independent Requests 🌼
Independent requests can generally be given equal treatment when making throttling decisions, unless application requirements or local policy indicate otherwise 🫶
Session-Initiating Requests 🌟
Session-initiating requests often represent more work than independent or intra-session requests. Moreover, session-initiating requests are typically followed by other session-related requests. Since the main objective of overload control is to reduce the total number of requests sent to the overloaded entity, throttling decisions might favor allowing intra-session requests over session-initiating requests. In the absence of local policies or application-specific requirements to the contrary, individual session-initiating requests can be given equal treatment when making throttling decisions 🍭
Correlated Session-Initiating Requests 💫
A request that results in a new binding is one where the binding is used for routing subsequent session-initiating requests to the same server. These represent more workload than other requests, so they might be throttled more frequently than other request types 🫧
Pseudo-session Requests 🎠
Throttling decisions for pseudo-session requests can take into consideration where individual requests fit into the overall sequence of requests within the pseudo-session. Requests earlier in the sequence might be throttled more aggressively than requests that occur later in it 🌙
Intra-session Requests 🌺
There are two types of intra-session requests: requests that terminate a session, and the remainder of intra-session requests. Implementers and operators may choose to throttle session-terminating requests less aggressively in order to gracefully terminate sessions, allow cleanup of related resources (e.g., session state), and avoid the need for additional intra-session requests. Favoring session termination requests may reduce the session management impact on the overloaded entity. The default handling of other intra-session requests might be to treat them equally when making throttling decisions. There might also be application-level considerations about whether some request types are favored over others 🏁
Contributors 🌸
The following people contributed substantial ideas, feedback, and discussion to this document 🫶
- Eric McMurry
- Hannes Tschofenig
- Ulrich Wiehe
- Jean-Jacques Trottin
- Maria Cruz Bartolome
- Martin Dolly
- Nirav Salot
- Susan Shishufeng
Authors' Addresses 💌
Here are the authors' addresses, straight from the source 💜
Jouni Korhonen (editor)
Broadcom Corporation
3151 Zanker Road
San Jose, CA 95134
United States
Email: jouni.nospam@gmail.comSteve Donovan (editor)
Oracle
7460 Warren Parkway
Frisco, Texas 75034
United States
Email: srdonovan@usdonovans.comBen Campbell
Oracle
7460 Warren Parkway
Frisco, Texas 75034
United States
Email: ben@nostrum.comLionel Morand
Orange Labs
38/40 rue du General Leclerc
Issy-Les-Moulineaux Cedex 9 92794
France
Phone: +33145296257
Email: lionel.morand@orange.com📦 where this page comes from
- ietf: rfc7683 2015-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms