RFC 8583
Diameter Load Information Conveyance
RFC 8583: Diameter Load Information Conveyance 💖
okay bestie, let's start with the header tea ☕ This is RFC 8583, titled Diameter Load Information Conveyance ✨ It was published by the IETF in August 2019 as a Standards Track document, which means it's an official Internet standard, not just a suggestion 💅 The ISSN is 2070-1721 🔥
The authors are B. Campbell, S. Donovan, Ed. (from Oracle), and JJ. Trottin (from Nokia). The header doesn't list an affiliation for B. Campbell, so I'm not going to guess one 🙈 The header also doesn't say that this RFC obsoletes or updates any other RFC 🌸
Here's the full table of contents, copied exactly as it appears in the original:
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Differences between Load and Overload Information . . . . 5
4.2. How Is Load Information Used? . . . . . . . . . . . . . . 6
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 9
6. Load-Mechanism Procedures . . . . . . . . . . . . . . . . . . 11
6.1. Reporting-Node Behavior . . . . . . . . . . . . . . . . . 11
6.1.1. Endpoint Reporting-Node Behavior . . . . . . . . . . 11
6.1.2. Agent Reporting-Node Behavior . . . . . . . . . . . . 12
6.2. Reacting-Node Behavior . . . . . . . . . . . . . . . . . 13
6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 14
6.4. Addition and Removal of Nodes . . . . . . . . . . . . . . 14
7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 15
7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 15
7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 18
A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 18
A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 19
A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 19
A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 21
A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 21
A.7. Fully-Meshed Layers . . . . . . . . . . . . . . . . . . . 22
A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 22
A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23Abstract 🦋
okay so the abstract says: RFC 7068 describes requirements for Overload Control in Diameter 📋 One of those requirements is that Diameter nodes should be allowed to send "load" information, even when they aren't overloaded 🧠 The base solution in RFC 7683 (Diameter Overload Information Conveyance, or DOIC) covers most of the requirements, but it can't send load information yet 😭 So this document defines a way to convey Diameter load information 🫶
Status of This Memo 🌈
this is an Internet Standards Track document 💜
it's a product of the Internet Engineering Task Force (IETF), and it 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 out Section 2 of RFC 7841 📚
info about this document's current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8583 🔗
Copyright Notice 🎀
Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) as they stand on the date this document was published 📜 Please 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 with no warranty, as described in the Simplified BSD License 💖
1. Introduction ✨
so [RFC7068] describes requirements for Overload Control in Diameter [RFC6733] 📋 The DIME Working Group finished the Diameter Overload Information Conveyance (DOIC) mechanism [RFC7683] 🎉 But as it's currently specified, DOIC only meets some of the requirements, not all of them 😬
specifically, DOIC doesn't fulfill Req 23 and Req 24 🙅♀️
REQ 23: The solution MUST provide sufficient information to enable a load-balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them.
REQ 24: The solution MUST provide a mechanism for indicating load levels, even when not in an overload condition, to assist nodes in making decisions to prevent overload conditions from occurring.
there are several other requirements in [RFC7068] that talk about both overload and load information, and DOIC only partly covers those 🧩
the DIME Working Group chose not to cover these requirements when it published DOIC [RFC7683], and it had several reasons 🤔 The main one was that the working group didn't agree on a general approach for conveying load information 😮💨 So it moved forward with the rest of DOIC and pushed load information conveyance off to a DOIC extension or a separate mechanism 💅
this document defines a mechanism that handles the load-related requirements from RFC 7068 🦋
2. Terminology and Abbreviations 📖
here are the terms, bestie 🧚
- AVP: Attribute-Value Pair
- DOIC: Diameter Overload Information Conveyance [RFC7683]
- Load: The relative usage of the Diameter message processing capacity of a Diameter node. A low load level indicates that the Diameter node is underutilized. A high load level indicates that the node is closer to being fully utilized.
- Offered Load: The actual traffic sent to the reporting node after overload abatement and routing decisions are made.
- Reporting Node: A DOIC node that sends a DOIC Overload report in a Diameter answer message.
- Reacting Node: A DOIC node that receives and acts on a DOIC Overload report.
- Routing Information: Routing Information referred to in this document can include the Routing and Peer tables defined in RFC 6733. It can also include other implementation-specific tables used to store load information. This document does not define the structure of such tables.
3. Conventions Used in This Document 🎀
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💜 Only the all-caps versions count, so lowercase words are just regular words ✨
4. Background 🌸
4.1. Differences between Load and Overload Information 🔥
okay this part is so good 🤌 Earlier conversations about solving the load-related requirements in [RFC7068] showed that people didn't have an agreed-upon idea of how "load" information is different from "overload" information 🙈 The two concepts are super connected, but there are two main differences 💅
first, a Diameter node always has a load 📊 At any given moment, that load might be effectively zero, effectively fully loaded, or somewhere in between 🌈 Overload, on the other hand, is an exceptional condition ⚠️ A node only has Overload information when it's in an overloaded state 😤 The relationship between a node's load level and its overload state can also be kind of vague at any given time 🌫️ For example, a node might normally run at a "fully loaded" level and still not be considered overloaded 🤷♀️ Another node might declare itself "overloaded" even though it might not be fully "loaded" 💀
second, Overload information, in the form of a DOIC Overload Report (OLR) [RFC7683], is an explicit request for action from the reacting node 🚨 The OLR asks the reacting node to reduce the offered load (the actual traffic sent to the reporting node after overload abatement and routing decisions are made) by an indicated amount by default, or as prescribed by the selected abatement algorithm 🧮 Basically, DOIC creates a contract between the reporting node and the reacting node 📝
load, on the other hand, is informational 🧁 Load information can be treated as a hint to the recipient node 💡 That node can use it for load-balancing, as an input to certain overload abatement techniques, to guess how likely the sending node is to become overloaded in the immediate future, or for other purposes 🔍
none of this stops a Diameter node from deciding to reduce the offered load based on load information 🙌 The big difference is that an Overload report requires the reduction of the offered load 🫡 It's also reasonable for a Diameter node to decide to increase the offered load based on load information 📈
4.2. How Is Load Information Used? 🎀
okay so [RFC7068] has two main uses in mind for load info 💅 Req 23 is about using it when diversion is the overload abatement technique from [RFC7683]. When a reacting node diverts traffic away from an overloaded node, it needs load info for the other candidates so it can load-balance the diverted load between them. Otherwise, diversion could easily push other nodes into overload 😭
Req 24 is about using Diameter load info when no overload condition exists yet 🧚 Diameter nodes can use it to make decisions that avoid overload in the first place. Normal load-balancing lives in this bucket, but a node can take other proactive steps too ✨
If the loaded nodes are Diameter servers (or clients in the case of server-to-client transactions), both of these uses of load info should be handled by a Diameter node that does server selection (picking the Diameter endpoint the request gets routed to for processing) 👑 Usually that's a node (a client or an agent) that's an immediate peer of the server. BUT there are scenarios (see Appendix A) where a client or proxy that isn't the immediate peer of the selected servers does server selection. In that case, the client or proxy enforces the selection by inserting a Destination-Host AVP 🫶
Here's an example: a Diameter node (e.g., a client) can use a redirect agent to get candidate destination host addresses 🦋 The redirect agent might return several destination host addresses, and the Diameter node picks one. It can use load info received from these hosts to make that choice.
Just as load info can be used for server selection, it can also be used as input when choosing the next-hop peer a request gets routed to 🌸
It should be noted that a Diameter node will need to process both load reports and Overload reports from the same Diameter node 🙈 The reacting node for the overload report always has the responsibility to reduce the amount of Diameter traffic sent to the overloaded node. If, or how, the reacting node uses load info to achieve this is left as an implementation decision 💜
5. Solution Overview ✨
The mechanism defined here for conveying load info is similar to the DOIC mechanism in some ways and different in others 🌈
Just like DOIC, load info gets conveyed by piggybacking the Load AVPs on existing Diameter applications 🎀
There are two primary differences. The first: there is no capability negotiation process for load 💅 The sender sends load info expecting that any supporting nodes will use it when making routing decisions. If there are no nodes that support the Load mechanism, the load info is ignored 💀
The second big difference is visibility of DOIC or load info inside a Diameter network 👀 DOIC info is sent end-to-end, so every node on the path of the answer message carrying the OC-OLR AVP can act on it, although only one node actually consumes and reacts to the report. DOIC Overload reports stay in the message all the way from the reporting node to the node that's the target for the answer message.
For the Load mechanism, there are two types of load reports, and only the first one is sent end-to-end 🧁
The first type is a host-load report, which contains the load of the endpoint sending the answer message 🍓 It's carried end-to-end so any nodes making server selection decisions can use the load status of the sending endpoint. Unlike with DOIC, more than one node may make use of the load info it carries ✨
The second type is a peer-load report 🦋 Diameter nodes use it as part of the logic to select the next-hop Diameter node, so it has no significance beyond the peer node. Load reports of type "PEER" get removed by the first supporting Diameter node to receive the report 🫧
Because load reports can traverse Diameter nodes that don't support the Load mechanism, it is necessary to include the identity of the node the load report applies to as part of the load report 🔍 That lets a Diameter node verify that a load report applies to its peer, or that it should be ignored.
The load report includes a value showing the relative load of the sending node, specified in a manner consistent with that defined for DNS SRV [RFC2782] 💖
The goal is to make it possible to use both the Load values received as part of the Diameter Load mechanism and the weight values received from a DNS SRV query 🌈 So the Diameter Load value has a range of 0-65535 🔢 This value and the DNS SRV weight values then get used in a distribution algorithm similar to the one specified in [RFC2782] ✨
The DNS SRV distribution algorithm results in more messages being sent to a node with a higher weight value. That means a higher Diameter Load value indicates a LOWER load on the sending node 🙃 A node that's heavily loaded sends a lower Diameter Load value. Put another way, a node with zero load would have a Load value of 65535, and a node that's 100% loaded would have a Load value of 0 👑
The distribution algorithm used by Diameter nodes supporting the Diameter Load mechanism is an implementation decision 🎀 It does need to result in behavior similar to the algorithm described for the use of weight values specified in [RFC2782] 🫶
The method for calculating the Load value included in the load report is also left as an implementation decision 💜
The frequency of sending load reports is also an implementation decision 🌸 The sending node might choose to send load reports in all messages, or it might choose to only send load reports when the Load value has changed by some implementation-specific amount. The important consideration is that all nodes needing the load info have a sufficiently accurate view of the node's load 🥹
5.1. Theory of Operation 🦋
This section outlines how the Diameter Load mechanism is expected to work 🧚
For this discussion, assume the following Diameter network configuration:
---A1---A3----S[1], S[2]...S[p]
/ | \ /
C | x
\ | / \
---A2---A4----S[p+1], S[p+2] ...S[n]
Figure 1: Example Diameter NetworkNote that in this diagram, S[1] and S[2] through S[p] are peers to A3. S[p+1] and S[p+2] through S[n] are peers to A4 ✨
Also assume that the request for a Diameter transaction takes the following path:
C A1 A4 S[n]
| | | |
|----->|----->|----->|
xxR xxR xxR
Figure 2: Request Message PathWhen sending the answer message, an endpoint node that supports the Diameter Load mechanism includes its own load info in the answer message 💅 Because it's a Diameter endpoint, it includes a host-load report.
C A1 A4 S[n]
| | | |
| | |<-----|
| | xxA(Load type:HOST, source:S[n])
| | | |
Figure 3: Answer Message from S[n]If Agent A4 supports the Load mechanism, then A4's actions depend on whether A4 is responsible for doing server selection 🌈 If A4 is not doing server selection, then A4 ignores the host-load report. If A4 is responsible for doing server selection, then it stores the load info for S[n] in its routing information for handling subsequent request messages. In both cases, A4 leaves the host-load report in the message 🫶
Note: If A4 does not support the Load mechanism, then it will relay the answer message without doing any processing on the load information. In this case, the load information AVPs will be relayed without change. 🙈
A4 then calculates its own load info and inserts load info AVPs of type "PEER" in the message before sending it to A1 🍓
C A1 A4 S[n]
| | | |
| |<-----| |
| xxA(Load type:PEER, source:A4)
| xxA(Load type:HOST, source:S[n])
| | | |
Figure 4: Answer Message from A4If A1 supports the Load mechanism, then it processes each of the load reports it receives separately 💜
For the peer-load report, A1 first checks whether the source of the report matches the DiameterIdentity of the Diameter node the request was received from. If the identities do not match, the peer-load report is discarded 🗑️ If the identities match, A1 saves the load info in its routing information for routing subsequent request messages. In both cases, A1 strips the peer-load report from the message ✂️
For the host-load report, A1's actions depend on whether A1 is responsible for doing server selection 🦋 If A1 is not doing server selection, then A1 ignores the host-load report. If A1 is responsible for doing server selection, then it stores the load info for S[n] in its routing information for handling subsequent request messages. In both cases, A1 leaves the host-load report in the message 👑
A1 then calculates its own load info and inserts load info AVPs of type "PEER" in the message before sending it to C 🌸
C A1 A4 S[n]
| | | |
|<-----| | |
xxA(Load type:PEER, source:A1)
xxA(Load type:HOST, source:S[n])
Figure 5: Answer Message from A1As with A1, C processes each load report separately 🧁
For the peer-load report, C follows the same procedure as A1 for determining whether the load report was received from the peer it was sent from. When it finds that it was, C stores the load info for use when making future routing decisions 🫧
For the host-load report, C saves the load info only if it is responsible for doing server selection 🔍
The load info received by all nodes is then used for routing subsequent request messages 💖
6. Load-Mechanism Procedures 🌈
This section defines the normative behaviors for the Load mechanism ✨
6.1. Reporting-Node Behavior 💅
This section defines the procedures of Diameter reporting nodes that generate load reports 🎀
6.1.1. Endpoint Reporting-Node Behavior 💖
okay so a Diameter endpoint that supports the Diameter Load mechanism MUST include a load report of type "HOST" in sufficient answer messages, so every consumer of the load info gets timely updates 🚀
the endpoint MUST also put its own DiameterIdentity in the SourceID AVP inside the Load AVP 🪪
and it MUST include a Load-Type AVP of type "HOST" in the Load AVP 🏷️
plus it MUST include its Load value in the Load-Value AVP inside the Load AVP 💅
the Load value should be calculated in a way that reflects the available load independently of the weight of each server, so you can actually compare Load values from different nodes 👀 any specific Load value needs to mean the same amount of available capacity, no matter which Diameter node calculated it. iconic consistency ✨
how the Load value gets calculated is an implementation decision 🛠️ so is how often load reports get sent 📅
for example, if the only one reading the load reports is the endpoint's peer, the endpoint can choose to only include a load report when its load has changed by a meaningful percentage 📉 but if other nodes read the endpoint's load report too (which happens when other nodes are doing server selection), the endpoint might choose to include load reports in all answer messages, so every node doing server selection has accurate load info 🫶
6.1.2. Agent Reporting-Node Behavior 🦋
a Diameter Agent that supports the Diameter Load mechanism MUST include a peer-load report in sufficient answer messages so every user of the load info gets timely updates 🚀
the Diameter Agent MUST put its own DiameterIdentity in the SourceID AVP inside the Load AVP 🪪
the Diameter Agent MUST include a Load-Type AVP of type "PEER" in the Load AVP 🏷️
and it MUST include its Load value in the Load-Value AVP inside the Load AVP 💅
same vibe as the endpoint: the Load value should be calculated so it reflects the available load independently of each agent's weight, so values from different nodes are comparable 📊 any specific Load value needs to identify the same amount of available capacity, regardless of which Diameter node calculates it 🎯
the calculation method is an implementation decision 🛠️ and so is the frequency of sending load reports 📅
Note: For load reports of type "PEER", it is only necessary to include them when the Load value has changed by some meaningful value, as long as the agent makes sure that all peers receive the report. It is also acceptable to include the load report in every answer message handled by the Diameter Agent. 🙈
6.2. Reacting-Node Behavior 💅
this section defines how Diameter nodes behave when they're processing load reports 👑
a Diameter node that supports the Diameter Load mechanism MUST be prepared to process load reports of type "HOST" and of type "PEER", as indicated by the Load-Type AVP inside the Load AVP. this can show up in the same answer message or be spread across multiple answer messages 📬
Note: The node needs to be able to handle messages with no Load reports, messages with just a peer-load report, messages with just a host-load report, and messages with both types of load reports. no node left behind 🧚
if the Diameter node is not responsible for doing server selection, then it SHOULD ignore load reports of type "HOST" 🙅♀️
if the Diameter node is responsible for doing server selection, then it SHOULD save the Load value from the Load-Value AVP inside the Load AVP of type "HOST" in its routing information 🗂️
if the Diameter node gets a load report of type "PEER", then it MUST determine whether that load report was inserted into the answer message by the peer the message came from 🕵️♀️ it does this by comparing the DiameterIdentity linked to the connection the message arrived on with the DiameterIdentity in the SourceID AVP in the load report 🔍
if the Diameter node finds that the load report of type "PEER" was not received from the peer that sent or relayed the answer message, then the node MUST ignore the load report 🚫
if the Diameter node finds that the load report of type "PEER" was received from the peer that sent or relayed the answer message, then the node SHOULD save the load information in its routing information ✅
in all cases, a Diameter Agent MUST strip all load reports of type "PEER" received in answer messages 🧹
Note: This makes sure there will be precisely one load report of type "PEER" (for example, the one from the Diameter node sending the message) in any answer messages the Diameter Agent sends. one report, zero drama 💖
how a Diameter node uses load information for routing decisions is an implementation decision 🤷♀️ but the distribution algorithm MUST result in similar behavior to the algorithm described for the use of weight values in [RFC2782]. no vibes-based routing 📐
6.3. Extensibility 🌈
the Load mechanism can be extended to carry extra info in the load reports ✨
any extension may define new AVPs for use in load reports. these new AVPs SHOULD be defined as extensions to the Load AVPs defined in this document 🧩
grouped AVP extension mechanisms defined by [RFC6733] apply too 🎀 this lets you do things like define a new feature that is mandatory to be understood, even when it's piggybacked on an existing application. main character energy 👑
as with any Diameter specification, [RFC6733] requires all new AVPs to be registered with IANA. see Section 9 for the required procedures 📋
6.4. Addition and Removal of Nodes 🦋
when a Diameter node gets added, the new node starts by advertising its load 🌱 downstream nodes will need to factor that new load info into their load-balancing decisions ⚖️ they can try to ramp traffic up smoothly toward the new node so it doesn't get hit with an immediate traffic spike 📈 how that smooth increase works is implementation-specific, but it can rely on how the load info from the new node and the other nodes changes over time 🫧
when removing a node in a controlled way (like for maintenance, so not a failure case), it might be a good move to gradually reduce traffic to that node by routing it to other nodes 🛤️ simple load info (a load percentage) would not be enough for this 🙅♀️ how node removal gets handled is implementation-specific, but it can rely on how the load info from the node being removed evolves over time 💜
7. Attribute-Value Pairs 🎀
this section defines the AVPs required for the Load mechanism 🧁
7.1. Load AVP 💖
the Load AVP (AVP code 650) is of type Grouped and is used to convey load information between Diameter nodes 📦
Load ::= < AVP Header: 650 >
[ Load-Type ]
[ Load-Value ]
[ SourceID ]
* [ AVP ]7.2. Load-Type AVP 🏷️
the Load-Type AVP (AVP code 651) is of type Enumerated 🔢 it's used to convey the type of Diameter node that sent the load information. these values are defined:
HOST 0 The load report is for a host.
PEER 1 The load report is for a peer.7.3. Load-Value AVP 📊
the Load-Value AVP (AVP code 652) is of type Unsigned64 🧮 it's used to convey relative load information about the sender of the load report 💫
it's specified in a similar way to the weight value in DNS SRV ([RFC2782]) 🎀
the Load value has a range of 0-65535 🌸
a higher value means a lower load on the sending node 📉 a lower value means the sending node is heavily loaded 🔥
Stated another way, a node with zero load would have a Load value of 65535. A node that is 100% loaded would have a Load value of 0. 💀
7.4. SourceID AVP 🪪
the SourceID AVP is defined in [RFC8581] 🙌 it's used to identify the Diameter node that sent the load report 🫶
7.5. Attribute-Value Pair Flag Rules 🌟
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------------+----+----+
|Load 650 7.1 Grouped | | V |
+--------------------------------------------------------+----+----+
|Load-Type 651 7.2 Enumerated | | V |
+--------------------------------------------------------+----+----+
|Load-Value 652 7.3 Unsigned64 | | V |
+------------------------------------------------------ -+----+----+
|SourceID 649 7.4 DiameterIdentity | | V |
+--------------------------------------------------------+----+----+as described in the Diameter base protocol [RFC6733], the M-bit usage for a given AVP in a given command may be defined by the application 🧠
8. Security Considerations 🔐
okay this part is serious bestie, so read it carefully 🫣
load information may be sensitive in some cases 🚨 depending on the mechanism, an unauthorized recipient might be able to infer the topology of a Diameter network from load information 🗺️ load information might also help people find targets for denial-of-service (DoS) attacks, since a node already known to be heavily loaded might be a tempting target 🎯 and load information might be useful as feedback about how well an ongoing DoS attack is going 💀
routing decisions are impacted by load information, so erroneous or malicious load reports could cause negative impacts on a Diameter network 😭 this includes malicious changing of Load values by Diameter Agents 👿
any load information conveyance mechanism will need to let operators avoid sending load information to nodes that aren't authorized to receive it 🔒 Diameter currently only offers authentication of nodes at the transport level and doesn't support end-to-end security mechanisms, so any solution that sends load information to non-peer nodes requires a transitive-trust model 🤝
9. IANA Considerations 📋
IANA has registered three new AVP codes in the "Authentication, Authorization, and Accounting (AAA) Parameters" registry; see Sections 7.1, 7.2, and 7.3 ✨
10. References 📚
10.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, https://www.rfc-editor.org/info/rfc2119.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, https://www.rfc-editor.org/info/rfc2782.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, https://www.rfc-editor.org/info/rfc6733.
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. Morand, "Diameter Overload Indication Conveyance", RFC 7683, DOI 10.17487/RFC7683, October 2015, https://www.rfc-editor.org/info/rfc7683.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.
[RFC8581] Donovan, S., "Diameter Agent Overload and the Peer Overload Report", RFC 8581, DOI 10.17487/RFC8581, August 2019, https://www.rfc-editor.org/info/rfc8581.
10.2. Informative References 🌸
[RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, DOI 10.17487/RFC7068, November 2013, https://www.rfc-editor.org/info/rfc7068.
Appendix A. Topology Scenarios ✨
This section is the fun part, bestie! 🦋 It walks through a bunch of Diameter topology scenarios and talks about how load information might get used in each one.
A.1. No Agent 🎀
Okay so Figure 6 is the simplest vibe: a client picks from a set of candidate servers that are available for a particular realm and application. The client picks the server for each transaction using the load info it got from each server. Iconic. 💅
------S1
/
C
\
------S2Figure 6: Basic Client Server Scenario
If a node supports dynamic discovery, it will not obtain load information from the nodes it has no Diameter connection established with. Nevertheless, it might take into account the load information from the other nodes to decide to add connections to new nodes with the dynamic discovery mechanism. Main character energy, ngl. 🌈
Note: The use of dynamic connections needs to be considered. 🙈
A.2. Single Agent 🧚
Figure 7 shows a client that sends requests to an agent. The agent picks the request destination from a set of candidate servers, using the load information it got from each server. The client doesn't need to receive load information, because it doesn't pick between multiple agents. Simple and slay. ✨
------S1
/
C----A
\
------S2Figure 7: Simple Agent Scenario
A.3. Multiple Agents 🍓
Figure 8 shows a client selecting between multiple agents, where each agent selects from multiple servers. The client picks an agent based on the load info it got from each agent. Each agent then picks a server based on the load info it got from its servers. Lowkey complicated, but we're getting there. 💖
This scenario adds a complication: one set of servers may be more loaded than the other set. If, for example, S4 was the least loaded server, C would need to know to select agent A2 to reach S4. This might require C to receive load information from the servers as well as the agents. Alternatively, each agent might use the load of its servers as an input into calculating its own load, which in effect aggregates upstream load. 🫶
Similarly, if C sends a host-routed request [RFC7683], it needs to know which agent can deliver requests to the selected server. Without some special, potentially proprietary, knowledge of the topology upstream of A1 and A2, C would select the agent based on the normal peer selection procedures for the realm and application, and perhaps consider the load information from A1 and A2. If C sends a request to A1 that contains a Destination-Host AVP with a value of S4, A1 will not be able to deliver the request. 😭
-----S3
/
---A1------S1
/
C
\
---A2------S2
\
---- S4Figure 8: Multiple Agents and Servers
A.4. Linked Agents 🦋
Figure 9 shows a scenario similar to Figure 8, except the agents are linked so that A1 can forward a request to A2, and vice-versa. Each agent could receive load information from the linked agent as well as from its connected servers. 🔥
This somewhat simplifies the complication from Figure 8, because C doesn't necessarily need to choose a particular agent to reach a particular server. But it creates a similar question: how, for example, A1 might know that S4 was less loaded than S1 or S3. It also creates the opportunity for sub-optimal request paths. For example, [C,A1,A2,S4] vs. [C,A2,S4]. Not the most efficient, bestie. 💀
A likely application for linked agents is when each agent prefers to route only to directly connected servers, and only forwards requests to another agent under exceptional circumstances. For example, A1 might not forward requests to A2 unless both S1 and S3 are overloaded. In this case, A1 might use the load information from S1 and S3 to select between those two, and only consider the load information from A2 (and other connected agents) if it needs to divert requests to different agents. 👑
-----S3
/
---A1------S1
/ |
C |
\ |
---A2------S2
\
---- S4Figure 9: Linked Agents
Figure 10 is a variant of Figure 9. In this case, C1 sends all traffic through A1, and C2 sends all traffic through A2. By default, A1 will load-balance traffic between S1 and S3, and A2 will load-balance traffic between S2 and S4. 🌸
Now, if S1 and S3 are significantly more loaded than S2 and S4, A1 may route some C1 traffic to A2. This is a non-optimal path, but it allows better load balancing between the servers. To achieve this, A1 needs to receive some load info from A2 about the S2/S4 load. Sacrifices for the vibe, iykyk. 🙈
-----S3
/
C1----A1------S1
|
|
|
C2----A2------S2
\
---- S4Figure 10: Linked Agents
A.5. Shared Server Pools 🧁
Figure 11 is similar to Figure 9, except that instead of a link between agents, each agent is linked to all servers. (The links to each set of servers should be interpreted as a link to each server. The links are not shown separately due to the limitations of ASCII art.) 🎨
In this scenario, each agent can select among all of the servers based on the load information from the servers. The client only needs to be concerned with the load information of the agents. Clean and efficient, periodt. 💅
---A1---S[1], S[2]...S[p]
/ \ /
C x
\ / \
---A2---S[p+1], S[p+2] ...S[n]Figure 11: Shared Server Pools
A.6. Agent Chains 🧚♀️
The scenario in Figure 12 is similar to Figure 8, except that instead of the client possibly needing to select an agent that can route requests to the least loaded server, here A1 and A2 need to make similar decisions when selecting between A3 or A4. As with the former scenario, this could be mitigated if A3 and A4 aggregate upstream loads into the load information they report downstream. Chain reaction, but make it cute. 🔗
---A1---A3----S[1], S[2]...S[p]
/ | \ /
C | x
\ | / \
---A2---A4----S[p+1], S[p+2] ...S[n]Figure 12: Agent Chains
A.7. Fully-Meshed Layers 🕸️
Figure 13 extends the scenario in Figure 11 by adding an extra layer of agents. But since each layer of nodes can reach any node in the next layer, each node only needs to consider the load of its next-hop peer. Full mesh, full vibes. 💜
---A1---A3---S[1], S[2]...S[p]
/ | \ / |\ /
C | x | x
\ | / \ |/ \
---A2---A4---S[p+1], S[p+2] ...S[n]Figure 13: Full Mesh
A.8. Partitions 🍰
A Diameter network with multiple servers is said to be "partitioned" when only a subset of the available servers can serve a particular realm-routed request. For example, one group of servers may handle users whose names start with "A" through "M", and another group may handle "N" through "Z". Divide and conquer, bestie. ✂️
In such a partitioned network, nodes cannot load balance requests across partitions, since not all servers can handle the request. A client, or an intermediate agent, may still be able to load balance between servers inside a partition. 🧚
A.9. Active-Standby Nodes 🌙
The previous scenarios assume that traffic can be load balanced among all peers that are eligible to handle a request. That is, the peers operate in an "active-active" configuration. In an "active-standby" configuration, traffic would be load balanced among the active peers. Requests would only be sent to peers in a "standby" state if the active peers became unavailable. For example, requests might be diverted to a stand-by peer if one or more active peers becomes overloaded. Backup plan, but make it iconic. 🫶
Authors' Addresses 💌
Ben Campbell
Oracle
7460 Warren Parkway, Suite 300
Frisco, Texas 75034
United States of America
Email: ben@nostrum.comSteve Donovan (editor)
Oracle
7460 Warren Parkway # 300
Frisco, Texas 75034
United States of America
Email: srdonovan@usdonovans.comJean-Jacques Trottin
Nokia
Route de Villejust
91620 Nozay
France
Email: jean-jacques.trottin@nokia.com📦 where this page comes from
- ietf: rfc8583 2019-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms