Diameter Overload Indication Conveyance
updated by
- rfc-8581 — Diameter Agent Overload and the Peer Overload Report
Extracted elements (26)
A single must-support loss algorithm is mandated so that a reporting node can always rely on at least one common abatement algorithm with any reacting node. The loss algorithm is stateless, avoiding the need for reacting nodes to pre-establish state before an overload report arrives.
DOIC does not define a new Diameter application; instead, overload control AVPs are piggybacked onto existing request and answer messages. This allows the solution to apply to existing and future Diameter applications without requiring changes to the Diameter base protocol (RFC 6733).
DOIC node roles (reporting vs. reacting) are determined by message direction—request senders act as reacting nodes, answer senders act as reporting nodes—rather than by Diameter client/server roles. This allows agents and servers to simultaneously act as both roles and supports bidirectional Diameter applications.
DOIC is designed to work through non-supporting Diameter Agents that pass unknown AVPs unchanged. A supporting agent may insert OC-Supported-Features into requests and answers on behalf of non-supporting endpoints, enabling incremental deployment.
A Diameter Agent acting as a reacting node for a non-supporting endpoint MUST insert the OC-Supported-Features AVP into forwarded requests that do not already contain one, and MUST have visibility to all traffic destined for a non-supporting host before acting as its reporting node.
A reacting node MUST include the OC-Supported-Features AVP in all request messages it originates or relays. If it includes the OC-Feature-Vector sub-AVP, it MUST indicate support for the loss algorithm, and MUST also indicate any additional supported algorithms.
A reporting node MUST ensure that new sequence numbers for a given application and report type are strictly greater than any sequence number in a currently active overload report for that type, and this ordering MUST persist across a reboot of the reporting node.
A reporting node MUST include the OC-Supported-Features AVP in the answer for any transaction whose request contained OC-Supported-Features, and MUST NOT include overload control AVPs in answers when the corresponding request lacked OC-Supported-Features.
A reporting node MUST NOT send overload reports of a type not advertised as supported by the reacting node. It SHOULD explicitly signal the end of overload by sending an OLR with OC-Validity-Duration set to zero, and SHOULD decrease requested abatement gradually to avoid traffic oscillations.
A reporting node MUST select a single abatement algorithm in its OC-Feature-Vector AVP, and that algorithm MUST be drawn from the set advertised in the reacting node's request. This ensures the agreed algorithm is usable by both sides.
When a reacting node receives an OC-OLR, it MUST update the matching OCS entry if the received sequence number is greater than the stored one, and MUST silently ignore the OLR (leaving OCS unchanged) if the received sequence number is less than or equal to the stored one. Sequence rollover MUST also be detected and treated as an update.
When a reacting node sends a request that matches an active OCS, it MUST apply the OCS-indicated abatement algorithm. If the algorithm selects the request for abatement, it SHOULD apply diversion if possible, and MUST apply throttling when diversion is not possible or was not applied. An agent that throttles MUST return an appropriate error response.
When rejecting a request due to overload, a DOIC node SHOULD send DIAMETER_TOO_BUSY if the request may succeed on a different path, and SHOULD send DIAMETER_UNABLE_TO_COMPLY if retrying on a different path is unlikely to succeed (e.g., a Destination-Host AVP targets the reporting node itself).
When using the loss abatement algorithm, a reporting node MUST indicate a percentage reduction in the OC-Reduction-Percentage AVP. A reacting node MUST apply abatement treatment to the requested percentage of outgoing request messages, using a stateless per-request probabilistic selection.
OC-Feature-Vector AVP (code 622) is of type Unsigned64, encoding a 64-bit capability flags field. Bit OLR_DEFAULT_ALGO (0x0000000000000001) indicates support for or selection of the loss algorithm. Absence of the AVP in a request implies only loss-algorithm support; absence in an answer implies loss algorithm is selected.
OC-Reduction-Percentage AVP (code 627) is of type Unsigned32 with values 0–100 indicating the percentage of traffic the reacting node is requested to reduce. A value of 100 means all traffic should be throttled; values greater than 100 are ignored.
OC-Report-Type AVP (code 626) is of type Enumerated with values HOST_REPORT (0) for host-scoped overload affecting host-routed requests, and REALM_REPORT (1) for realm-scoped overload affecting realm-routed requests. Values 2–4294967295 are unassigned.
OC-Sequence-Number AVP (code 624) is of type Unsigned64 and acts as a monotonically increasing per-overload-condition counter. Sequence numbers are unidirectional and unrelated between the two directions of a DOIC relationship.
OC-Validity-Duration AVP (code 625) is of type Unsigned32, expressing validity in seconds from receipt of the first OLR with a given sequence number. Default is 30 seconds; maximum is 86,400 seconds (24 hours); values exceeding the maximum cause the default to apply.
Two new IANA registries are created under 'AVP Specific Values' in the AAA Parameters registry: 'OC-Feature-Vector AVP Values (code 622)' for feature flag bits, and 'OC-Report-Type AVP Values (code 626)' for report type enumerations. Both use the Specification Required policy for new values.
Diameter lacks end-to-end integrity or confidentiality, creating a transitive-trust chain through agents: any agent in the path can read or modify overload reports. Operators MUST be able to configure which peers are trusted to deliver and which are authorized to receive overload reports. Non-supporting agents passing DOIC AVPs as unknown may be mistakenly treated as DOIC-supporting.
Diameter nodes MUST NOT honor or forward OLRs received from peers not trusted to send them. DOIC nodes MUST strip DOIC AVPs from messages received from untrusted peers, and nodes MUST NOT send overload reports to peers not authorized to receive them. Agents MUST remove OLRs before forwarding to unauthorized peers.
Injected or maliciously crafted OLRs can be used as DoS vectors—for example, a realm OLR with 100% reduction percentage can silence all traffic to a realm. Implementations MUST validate that an answer containing an OLR is a properly constructed response to a pending request and was received over an appropriate transport connection before acting on it.
Each reacting node maintains per-application Overload Control State (OCS) with a host-type entry (keyed by Application-ID + DiameterIdentity) and a realm-type entry (keyed by Application-ID + realm). Transitions: new OCS created on first OLR, updated when incoming sequence number exceeds stored value, marked expired when validity-duration is zero, unchanged when no OC-OLR AVP is present in an answer.
OC-OLR AVP (code 623) is of type Grouped and contains OC-Sequence-Number, OC-Report-Type, optional OC-Reduction-Percentage, optional OC-Validity-Duration, and optional additional AVPs. The enclosing message's Application-ID, Origin-Host, and Origin-Realm identify the scope of the overload report.
OC-Supported-Features AVP (code 621) is of type Grouped and contains an optional OC-Feature-Vector sub-AVP plus optional additional AVPs. The M-bit MUST NOT be set. It serves as both a DOIC capability declaration and a feature advertisement.