Diameter Agent Overload and the Peer Overload Report
updates
- rfc-7683 — Diameter Overload Indication Conveyance
Extracted elements (26)
The peer report type is defined generically so it can be used not only for agent overload but also for other Diameter overload scenarios such as hop-by-hop abatement algorithms for Diameter endpoints using the rate algorithm.
The SourceID AVP is included in the OC-OLR AVP to carry the DiameterIdentity of the reporting agent specifically to handle the case where a non-supporting agent sits between the reporting node and reacting node; without it, the reacting node could incorrectly attribute the peer report to the non-supporting intermediate node and unnecessarily throttle or divert traffic.
The reacting node's requirement to ignore peer reports whose SourceID does not match the sending peer's DiameterIdentity is specifically designed to handle cases where peer reports are erroneously or maliciously inserted by non-supporting intermediate nodes.
A DOIC node that supports the OC_PEER_REPORT feature MUST include a SourceID AVP containing its own DiameterIdentity in the OC-Supported-Features AVP when sending a request.
A reacting node supporting this extension MUST support receipt of multiple Overload reports in a single message, which may include Host, Realm, and/or Peer Overload reports.
For Peer Overload Reports, the preferred abatement treatment is diversion; the reacting node SHOULD attempt to divert requests identified as needing abatement to other peers. If insufficient capacity exists, the reacting node MUST throttle necessary requests.
If a reacting node receives an OC-OLR AVP of type PEER-REPORT and the SourceID does not match the DiameterIdentity of the Diameter peer from which the response was received, the reacting node MUST ignore the Overload report.
If the peer supports OC_PEER_REPORT, the reporting node MUST insert the OC-Peer-Algo AVP in the OC-Supported-Features AVP indicating the overload abatement algorithm it wants reacting nodes to use.
If the reacting node is an agent, it MUST strip the Peer-Report OC-OLR AVP from the message before forwarding.
If the sequence number for a received peer report is greater than the sequence number stored in the matching OCS entry, the reacting node MUST update the matching OCS entry; if less than or equal, it MUST silently ignore the received peer report and MUST NOT update the OCS.
When a Diameter Agent relays a request containing a SourceID AVP in the OC-Supported-Features AVP and the agent supports OC_PEER_REPORT, it MUST remove the received SourceID AVP and replace it with a SourceID AVP containing its own DiameterIdentity.
When an agent relays an answer message, a reporting node supporting OC_PEER_REPORT MUST strip any SourceID AVP from the OC-Supported-Features AVP.
When both host/realm and peer overload reports are active simultaneously, the reacting node SHOULD take into consideration the number of messages already throttled by host/realm report abatement when performing abatement for the peer report.
When receiving a request, a DOIC node supporting OC_PEER_REPORT MUST update transaction state with an indication of whether the peer from which the request was received supports the OC_PEER_REPORT feature.
When there is an existing reporting-node peer-report OCS entry, the reporting node MUST include an OC-OLR AVP with report type PEER-REPORT in all answer messages sent to peers that support OC_PEER_REPORT, and MUST include its DiameterIdentity in the SourceID AVP.
The OC-Peer-Algo AVP (AVP code 648) is of type Unsigned64 and contains a 64-bit flags field of announced capabilities. Feature bits defined for OC-Feature-Vector AVP associated with overload abatement algorithms are reused for this AVP; value zero is reserved.
The OC_PEER_REPORT feature bit (0x0000000000000010) is defined for the OC-Feature-Vector AVP. When set, it indicates that the DOIC node supports the Peer Overload report type.
The PEER_REPORT value (2) is defined for the OC-Report-Type AVP, indicating that overload treatment should apply to all requests bound for the peer identified in the Overload report.
The SourceID AVP (AVP code 649) is of type DiameterIdentity and is inserted by a Diameter node to indicate the source of the enclosing AVP. In peer reports, it identifies either the node supporting the feature (in OC-Supported-Features) or the node generating the overload report (in OC-OLR).
RFC 8581 registers a new OC-Feature-Vector AVP value OC_PEER_REPORT (0x0000000000000010) and a new OC-Report-Type AVP value PEER_REPORT (2) in the AAA Parameters registry.
RFC 8581 registers two new AVP codes in the AAA Parameters registry: OC-Peer-Algo (code 648) and SourceID (code 649), both with MUST NOT V flag rule.
Malicious insertion of a peer report could have greater impact than an endpoint report, since agents are concentration points: a forged peer report could throttle all traffic to a Diameter network, especially for an edge agent serving as entry point from other networks. Mitigation strategies are the same as those in RFC 7683.
The Reacting-Node Peer-Report OCS tracks per-peer, per-application overload state. States are: no OCS (new peer report creates OCS), active OCS (updated when sequence number increases), expired OCS (validity duration zero or timer expiry triggers controlled abatement end). A non-matching SourceID causes the report to be ignored entirely.
The Reporting-Node Peer-Report OCS may maintain a separate OCS entry per peer when different abatement-specific content (e.g., different rates) is sent to each peer. All RFC 7683 OCS management rules apply.
The OC-OLR AVP (AVP Header 623) is extended to include an optional SourceID sub-AVP carrying the DiameterIdentity of the reporting agent, alongside OC-Sequence-Number, OC-Report-Type, OC-Reduction-Percentage, and OC-Validity-Duration.
The OC-Supported-Features AVP (AVP Header 621) is extended to include optional SourceID and OC-Peer-Algo sub-AVPs alongside the existing OC-Feature-Vector, enabling peer report capability announcement.