Diameter Load Information Conveyance
Extracted elements (25)
Load information is informational ('a hint') unlike DOIC Overload reports which constitute a contract requiring reduction of offered load. A node may use load information for load-balancing, overload prevention, or inferences about future overload, but is not obligated to reduce traffic based on load alone.
Load values are specified analogously to DNS SRV weight values (range 0-65535) to allow interoperability between Diameter Load values and DNS SRV weights in distribution algorithms. A higher Load value indicates lower node load (65535 = zero load, 0 = 100% loaded).
The Load value calculation method, distribution algorithm, and frequency of sending load reports are all left as implementation decisions. The key requirement is that all nodes needing the information have a sufficiently accurate view of the node's load.
The Load value range (0-65535) and semantics are aligned with DNS SRV weight values to allow operators to use both Diameter Load values and DNS SRV weights in the same distribution algorithm, avoiding the need for separate scaling or normalization.
There is no capability negotiation process for the Load mechanism, unlike DOIC. The sender transmits load information expecting supporting nodes to use it; nodes that do not support the mechanism simply ignore the AVPs.
Because load reports can traverse Diameter nodes that do not support the Load mechanism, each load report must include the SourceID identifying the node to which it applies, allowing receiving nodes to verify applicability or discard irrelevant reports.
If an agent does not support the Load mechanism, it relays answer messages without processing load information AVPs, which are passed through unchanged. This allows HOST-type load reports to reach non-peer nodes that perform server selection.
A Diameter Agent MUST strip all load reports of type PEER received in answer messages, ensuring exactly one PEER-type load report (that of the forwarding agent) appears in any answer message sent by the agent.
A Diameter Agent that supports the Load mechanism MUST include a peer-load report in sufficient answer messages to ensure all users of the load information receive timely updates, and MUST include its own DiameterIdentity in the SourceID AVP with Load-Type of PEER.
A Diameter endpoint MUST include its own DiameterIdentity in the SourceID AVP, MUST include a Load-Type AVP of type HOST, and MUST include its Load value in the Load-Value AVP within the Load AVP.
A Diameter endpoint that supports the Load mechanism MUST include a load report of type HOST in sufficient answer messages to ensure all consumers of the load information receive timely updates.
A Diameter node that supports the Load mechanism MUST be prepared to process load reports of type HOST and PEER, including messages with no load reports, only peer-load, only host-load, or both types simultaneously.
If a Diameter node determines that a PEER-type load report was received from the correct peer, it SHOULD save the load information in its routing information for future routing decisions.
If a Diameter node is not responsible for server selection, it SHOULD ignore HOST-type load reports. If it is responsible for server selection, it SHOULD save the Load-Value from HOST load reports in its routing information.
New AVPs defined as extensions to the Load mechanism SHOULD be defined as extensions to the Load AVPs defined in this document, and all new AVPs must be registered with IANA per RFC 6733.
The distribution algorithm used by Diameter nodes supporting the Load mechanism MUST result in similar behavior as the weight-value algorithm described in RFC 2782 (DNS SRV).
When a Diameter node receives a PEER-type load report, it MUST determine whether the report was inserted by the peer from which the message was received by comparing the SourceID DiameterIdentity against the connection's DiameterIdentity; if they do not match, the node MUST ignore the load report.
The Load AVP (AVP code 650) is of type Grouped and carries load information. It contains optional Load-Type, Load-Value, and SourceID sub-AVPs, plus extensibility via additional AVPs.
The SourceID AVP (AVP code 649, defined in RFC 8581) is included in the Load AVP to identify the Diameter node that sent the load report, enabling receiving nodes to verify that a PEER-type report came from the expected peer.
Two types of load reports are defined: HOST reports, which are conveyed end-to-end and contain the load of the endpoint sending the answer, and PEER reports, which are hop-by-hop and consumed and stripped by the first supporting Diameter node that receives them.
IANA registered three new AVP codes in the 'Authentication, Authorization, and Accounting (AAA) Parameters' registry: Load (650, Grouped), Load-Type (651, Enumerated), and Load-Value (652, Unsigned64).
Load information may be sensitive: unauthorized recipients could infer network topology, identify heavily loaded nodes as DoS targets, or use load reports as feedback about an ongoing DoS attack. Additionally, malicious or erroneous load reports (including manipulation by agents) can negatively impact routing decisions.
Operators must be able to prevent sending load information to unauthorized nodes. Since Diameter only provides transport-level node authentication and lacks end-to-end security, conveying load information to non-peer nodes requires a transitive-trust model.
The Load-Type AVP (AVP code 651) is of type Enumerated with two values: HOST (0) indicating the load report is for a host endpoint, and PEER (1) indicating the load report is for a peer agent.
The Load-Value AVP (AVP code 652) is of type Unsigned64 carrying a value in the range 0-65535, where higher values indicate lower load. A value of 65535 means zero load and 0 means 100% loaded.