DOIC [RFC7683] AVPs
Diameter Overload Indication Conveyance (RFC7683)
This interface defines a base solution for Diameter overload control—referred to as Diameter Overload Indication Conveyance (DOIC)—based on the requirements identified in [RFC7068]. It addresses overload control between Diameter nodes that support the DOIC solution, while remaining deployable in environments where some nodes do not implement this mechanism. The solution requires no changes to the Diameter base protocol [RFC6733] and can be integrated into both existing and future Diameter applications.
Purpose of the Diameter Overload Indication Conveyance Interface
- Overload Abatement Coordination: DOIC enables Diameter nodes to request that other nodes perform overload abatement actions—such as throttling or diverting traffic—to reduce the load offered to an overloaded node or realm. This coordination helps maintain network performance during periods of high traffic.
- Seamless Integration: The overload control mechanism is designed to piggyback on existing Diameter messages by inserting new AVPs. This means that Diameter nodes indicate their support for DOIC (via the OC-Supported-Features AVP) and convey overload information without generating new message types, ensuring smooth interoperability across diverse deployments.
Key Elements:
Roles and Node Types:
- DOIC Nodes: Any Diameter node—whether a client, server, or agent—can function as a DOIC node.
- Reporting Nodes: These nodes generate overload indications by inserting Overload Reports (OLRs) using the OC-OLR AVP. A reporting node can indicate overload on its own behalf or on behalf of other nodes.
- Reacting Nodes: Upon receiving OLRs, these nodes perform overload abatement actions according to an agreed-upon algorithm. They may treat requests differently (e.g., throttling or diversion) based on the overload conditions reported.
AVP Piggybacking Mechanism:
- DOIC does not introduce new Diameter messages. Instead, overload-related information is conveyed by adding specific AVPs (such as OC-Supported-Features and OC-OLR) into existing Diameter requests and responses. This mechanism allows nodes to signal and process overload conditions on a per-realm and per-application basis.
Overload Abatement Algorithm:
- The specification defines a mandatory "loss" algorithm that distinguishes between requests that should undergo overload treatment and those that receive normal routing. Overload conditions can vary—affecting a single host or an entire realm—and are indicated through extensible report types.
Interoperability Considerations:
- Even in environments where not all nodes implement DOIC, non-supporting nodes are expected to pass unknown AVPs unchanged, ensuring that overload information can still propagate across the network.
For complete technical specification of Diameter Overload Indication Conveyance please refer to: [RFC7683]
package com.mobius.software.telco.protocols.diameter.primitives.rfc7683
|
Name |
AVP Code |
Data Type |
Vendor |
|
OC-Feature-Vector |
622 |
Unsigned64 |
IETF |
|
Used to announce the capabilities of a DOIC node in a DOIC (Diameter Overload Control) system. It is a 64-bit flags field where each bit represents a different feature or capability supported by the node. The value of zero (0) is reserved, and the AVP allows the node to indicate which features are available for overload control. If this AVP is absent in request messages, it indicates that only the default traffic abatement algorithm is supported by the node. If this AVP is absent in answer messages, it means the default traffic abatement algorithm has been selected, although other algorithms may still be supported, with no other features beyond abatement algorithms being supported. The OC-Feature-Vector AVP supports the OLR_DEFAULT_ALGO (Overload Loss Algorithm), represented as the 64-bit value 0x0000000000000001. When this bit is set by a DOIC reacting node, it indicates that the default traffic abatement (loss) algorithm is supported. When set by a DOIC reporting node, it indicates that this loss algorithm will be used for requested overload abatement. |
|||
|
OC-OLR |
623 |
Grouped |
IETF |
|
Used to convey overload conditions reported by a Diameter node. This AVP contains a collection of attributes that define the details of the overload condition and how it impacts traffic handling. The AVP structure is defined as follows: OC-Sequence-Number (Mandatory): A sequence number used to identify the report and distinguish it from previous overload reports. OC-Report-Type (Mandatory): Indicates the type of overload report being sent. Examples include host-specific or realm-specific reports. OC-Reduction-Percentage (Optional): Specifies the percentage of traffic that should be reduced by the reacting node. This value is expressed as an integer percentage (0-100). OC-Validity-Duration (Optional): The duration, in seconds, for which the overload report remains valid. After this time, the report is considered expired. Supports additional AVPs for extensibility, which can include vendor-specific or future extensions. |
|||
|
OC-Reduction-Percentage |
627 |
Unsigned32 |
IETF |
|
Used to specify the percentage of traffic that a sender is requested to reduce. It is primarily associated with the default traffic abatement algorithm defined in Diameter Overload Control (RFC 7683). The AVP provides flexibility for future abatement algorithms if the semantics remain compatible. Value Range: 0 to 100 Values greater than 100 are ignored. - 100: All traffic is throttled (severe overload). - 0: No abatement is needed (stable). |
|||
|
OC-Report-Type |
626 |
Enumerated |
IETF |
|
Identifies the scope of the overload report in the context of Diameter Overload Control (DOIC). It indicates whether the overload condition applies to a specific host or an entire realm. Enumerated Values: 0: HOST_REPORT: Overload condition applies to a specific host. Abatement measures must target host-routed requests. 1: REALM_REPORT: Overload condition applies to an entire realm. Abatement measures must target realm-routed requests. 2-4294967295: Unassigned: Reserved for future use. |
|||
|
OC-Sequence-Number |
624 |
Unsigned64 |
IETF |
|
Represents a nonvolatile, incrementing counter used in Diameter Overload Control (DOIC) to maintain the order of overload reports. It serves as a unique sequence identifier for a series of overload reports between two DOIC nodes related to the same overload occurrence. The sequence number must persist across sessions to maintain continuity in overload reporting. It increases with each subsequent overload report. |
|||
|
OC-Supported-Features |
621 |
Grouped |
IETF |
|
Serves as an announcement mechanism for a Diameter node's support for Diameter Overload Indication Conveyance (DOIC) and its associated features. This AVP enables nodes to communicate their DOIC capabilities and ensure interoperability by exchanging supported feature details. The AVP structure is defined as follows: OC-Feature-Vector (Optional): Contains a 64-bit flags field that specifies the DOIC features supported by the node. Allows for future extensibility by including other AVPs as needed to convey additional DOIC-related information. The OC-Supported-Features AVP must be included in every Diameter request message a DOIC supporting node sends. |
|||
|
OC-Validity-Duration |
625 |
Unsigned32 |
IETF |
|
Specifies the duration, in seconds, for which the overload report remains valid. This AVP helps define the lifespan of the overload report received in an OC-OLR AVP. Default Value: 30 seconds, applied when the OC-Validity-Duration AVP is not explicitly included. Maximum Value: 86,400 seconds (24 hours). If a higher value is received, the default value of 30 seconds is applied. |
|||
Start innovating with Mobius
What's next? Let's talk!