From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8583.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc8583.txt (limited to 'doc/rfc/rfc8583.txt') diff --git a/doc/rfc/rfc8583.txt b/doc/rfc/rfc8583.txt new file mode 100644 index 0000000..bc0d422 --- /dev/null +++ b/doc/rfc/rfc8583.txt @@ -0,0 +1,1291 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Campbell +Request for Comments: 8583 S. Donovan, Ed. +Category: Standards Track Oracle +ISSN: 2070-1721 JJ. Trottin + Nokia + August 2019 + + + Diameter Load Information Conveyance + +Abstract + + RFC 7068 describes requirements for Overload Control in Diameter. + This includes a requirement to allow Diameter nodes to send "load" + information, even when the node is not overloaded. The base solution + defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC)) + describes a mechanism meeting most of the requirements but does not + currently include the ability to send load information. This + document defines a mechanism for the conveying of Diameter load + information. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8583. + + + + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 1] + +RFC 8583 Diameter Load August 2019 + + +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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 2] + +RFC 8583 Diameter Load August 2019 + + +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 . . . . . . . . . . . . . . . . . . . . . . . 23 + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 3] + +RFC 8583 Diameter Load August 2019 + + +1. Introduction + + [RFC7068] describes requirements for Overload Control in Diameter + [RFC6733]. The DIME Working Group has finished the Diameter Overload + Information Conveyance (DOIC) mechanism [RFC7683]. As currently + specified, DOIC fulfills some, but not all, of the requirements. + + In particular, DOIC does not 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 mention both + overload and load information that are only partially fulfilled by + DOIC. + + The DIME Working Group explicitly chose not to fulfill these + requirements when publishing DOIC [RFC7683] due to several reasons. + A principal reason was that the working group did not agree on a + general approach for conveying load information. It chose to + progress the rest of DOIC and deferred load information conveyance to + a DOIC extension or a separate mechanism. + + This document defines a mechanism that addresses the load-related + requirements from RFC 7068. + +2. Terminology and Abbreviations + + 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. + + + + + +Campbell, et al. Standards Track [Page 4] + +RFC 8583 Diameter Load August 2019 + + + 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. + +4. Background + +4.1. Differences between Load and Overload Information + + Previous discussions of how to solve the load-related requirements in + [RFC7068] have shown that people did not have an agreed-upon concept + of how "load" information differs from "overload" information. While + the two concepts are highly interrelated, there are two primary + differences. First, a Diameter node always has a load. At any given + time, that load may be effectively zero, effectively fully loaded, or + somewhere in between. In contrast, overload is an exceptional + condition. A node only has Overload information when it is in an + overloaded state. Furthermore, the relationship between a node's + load level and overload state at any given time may be vague. For + example, a node may normally operate at a "fully loaded" level, but + still not be considered overloaded. Another node may declare itself + to be "overloaded" even though it might not be fully "loaded". + + Second, Overload information, in the form of a DOIC Overload Report + (OLR) [RFC7683] indicates an explicit request for action on the part + of the reacting node; the OLR requests that the reacting node reduce + the offered load, the actual traffic sent to the reporting node after + + + +Campbell, et al. Standards Track [Page 5] + +RFC 8583 Diameter Load August 2019 + + + overload abatement and routing decisions are made, by an indicated + amount (by default) or as prescribed by the selected abatement + algorithm. Effectively, DOIC provides a contract between the + reporting node and the reacting node. + + In contrast, load is informational; load information can be + considered a hint to the recipient node. That node may use the load + information for load-balancing purposes, as an input to certain + overload abatement techniques, to make inferences about the + likelihood that the sending node becomes overloaded in the immediate + future, or for other purposes. + + None of this prevents a Diameter node from deciding to reduce the + offered load based on load information. The fundamental difference + is that an Overload report requires the reduction of the offered + load. It is also reasonable for a Diameter node to decide to + increase the offered load based on load information. + +4.2. How Is Load Information Used? + + [RFC7068] contemplates two primary uses for load information. Req 23 + discusses how load information might be used when performing + diversion as an overload abatement technique as described in + [RFC7683]. When a reacting node diverts traffic away from an + overloaded node, it needs load information for the other candidates + for that traffic in order to effectively load-balance the diverted + load between potential candidates. Otherwise, diversion has a + greater potential to drive other nodes into overload. + + Req 24 discusses how Diameter load information might be used when no + overload condition currently exists. Diameter nodes can use the load + information to make decisions to try to avoid overload conditions in + the first place. Normal load-balancing falls into this category, but + the Diameter node can take other proactive steps as well. + + If the loaded nodes are Diameter servers (or clients in the case of + server-to-client transactions), both of these uses of load + information should be accomplished by a Diameter node that performs + server selection (selection of the Diameter endpoint to which the + request is to be routed for processing). Typically, server selection + is performed by a node (a client or an agent) that is an immediate + peer of the server. However, there are scenarios (see Appendix A) + where a client or proxy that is not the immediate peer to the + selected servers performs server selection. In this case, the client + or proxy enforces the server selection by inserting a Destination- + Host AVP. + + + + + +Campbell, et al. Standards Track [Page 6] + +RFC 8583 Diameter Load August 2019 + + + As an example, a Diameter node (e.g., client) can use a redirect + agent to get candidate destination host addresses. The redirect + agent might return several destination host addresses from which the + Diameter node selects one. The Diameter node can use load + information received from these hosts to make the selection. + + Just as load information can be used as part of server selection, it + can also be used as input to the selection of the next-hop peer to + which a request is to be routed. + + 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 information to achieve this + is left as an implementation decision. + +5. Solution Overview + + The mechanism defined here for the conveyance of load information is + similar in some ways to the mechanism defined for DOIC and is + different in other ways. + + As with DOIC, load information is conveyed by piggybacking the Load + AVPs on existing Diameter applications. + + There are two primary differences. First, there is no capability + negotiation process for load. The sender of the load information is + sending it with the expectation that any supporting nodes will use it + when making routing decisions. If there are no nodes that support + the Load mechanism, then the load information is ignored. + + The second big difference between DOIC and Load is visibility of the + DOIC or load information within a Diameter network. DOIC information + is sent end-to-end resulting in the ability of all nodes in the path + of the answer message that carries the OC-OLR AVP to act on the + information, although only one node actually consumes and reacts to + the report. The DOIC Overload reports remain in the message all the + way from the reporting node to the node that is the target for the + answer message. + + For the Load mechanism, there are two types of load reports and only + the first one is transmitted end-to-end. + + The first type of load report is a host-load report, which contains + the load of the endpoint sending the answer message. This load + report is carried end-to-end to enable any nodes that make server + selection decisions to use the load status of the sending endpoint as + + + +Campbell, et al. Standards Track [Page 7] + +RFC 8583 Diameter Load August 2019 + + + part of the server selection decision. Unlike with DOIC, more than + one node may make use of the load information received. + + The second type of load report is a peer-load report. This report is + used by Diameter nodes as part of the logic to select the next-hop + Diameter node and, as such, does not have significance beyond the + peer node. load reports of type "PEER" are removed by the first + supporting Diameter node to receive the report. + + Because load reports can traverse Diameter nodes that do not support + the Load mechanism, it is necessary to include the identity of the + node to which the load report applies as part of the load report. + This allows for a Diameter node to verify that a load report applies + to its peer or that it should be ignored. + + The load report includes a value indicating 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 a part of the Diameter Load mechanism and weight values received + as a result of a DNS SRV query. As a result, the Diameter Load value + has a range of 0-65535. This value and DNS SRV weight values are + then used in a distribution algorithm similar to that specified in + [RFC2782]. + + The DNS SRV distribution algorithm results in more messages being + sent to a node with a higher weight value. As a result, a higher + Diameter Load value indicates a LOWER load on the sending node. A + node that is heavily loaded sends a lower Diameter Load value. + Stated another way, a node that has zero load would have a Load value + of 65535. A node that is 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, but it needs + to result in similar behavior 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 for sending of load reports is also left as 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 information have a sufficiently accurate view of the node's + load. + + + +Campbell, et al. Standards Track [Page 8] + +RFC 8583 Diameter Load August 2019 + + +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 Network + + Note 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 Path + + When sending the answer message, an endpoint node that supports the + Diameter Load mechanism includes its own load information in the + answer message. Because it is 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 + + + + + +Campbell, et al. Standards Track [Page 9] + +RFC 8583 Diameter Load August 2019 + + + information for S[n] in its routing information for the handling of + 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 information and inserts load + information AVPs of type "PEER" in the message before sending the + message 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 A4 + + If A1 supports the Load mechanism, then it processes each of the load + reports it receives separately. + + For the peer-load report, A1 first determines if the source of the + report indicated in the load report matches the DiameterIdentity of + the Diameter node from which the request was received. If the + identities do not match, then the peer-load report is discarded. If + the identities match, then A1 saves the load information in its + routing information for routing of 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 + information for S[n] in its routing information for the handling of + subsequent request messages. In both cases, A1 leaves the host-load + report in the message. + + + + + + + + + + + +Campbell, et al. Standards Track [Page 10] + +RFC 8583 Diameter Load August 2019 + + + A1 then calculates its own load information and inserts load + information AVPs of type "PEER" in the message before sending the + message 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 A1 + + As with A1, C processes each load report separately. + + For the peer-load report, C follows the same procedure as A1 for + determining if the load report was received from the peer from which + the report was sent. When finding it does, C stores the load + information for use when making future routing decisions. + + For the host-load report, C saves the load information only if it is + responsible for doing server selection. + + The load information received by all nodes is then used for routing + of 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 + + A Diameter endpoint that supports the Diameter Load mechanism MUST + include a load report of type "HOST" in sufficient answer messages to + ensure that all consumers of the load information receive timely + updates. + + The Diameter endpoint MUST include its own DiameterIdentity in the + SourceID AVP included in the Load AVP. + + The Diameter endpoint MUST include a Load-Type AVP of type "HOST" in + the Load AVP. + + + + + +Campbell, et al. Standards Track [Page 11] + +RFC 8583 Diameter Load August 2019 + + + The Diameter endpoint MUST include its Load value in the Load-Value + AVP in the Load AVP. + + The Load value should be calculated in a way that reflects the + available load independently of the weight of each server in order to + accurately compare Load values from different nodes. Any specific + Load value needs to identify the same amount of available capacity + regardless of the Diameter node that calculates the value. + + The mechanism used to calculate the Load value that fulfills this + requirement is an implementation decision. + + The frequency of sending load reports is an implementation decision. + + For instance, if the only consumer of the load reports is the + endpoint's peer, then the endpoint can choose to only include a load + report when the load of the endpoint has changed by a meaningful + percentage. If there are consumers of the endpoint load report other + than the endpoint's peer (this will be the case if other nodes are + responsible for server selection), then the endpoint might choose to + include load reports in all answer messages as a way of ensuring that + all nodes doing server selection get accurate load information. + +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 to ensure + that all users of the load information receive timely updates. + + The Diameter Agent MUST include its own DiameterIdentity in the + SourceID AVP included in the Load AVP. + + The Diameter Agent MUST include a Load-Type AVP of type "PEER" in the + Load AVP. + + The Diameter Agent MUST include its Load value in the Load-Value AVP + in the Load AVP. + + The Load value should be calculated in a way that reflects the + available load independently of the weight of each agent in order to + accurately compare Load values from different nodes. Any specific + Load value needs to identify the same amount of available capacity + regardless of the Diameter node that calculates the value. + + The mechanism used to calculate the Load value that fulfills this + requirement is an implementation decision. + + The frequency of sending load reports is an implementation decision. + + + +Campbell, et al. Standards Track [Page 12] + +RFC 8583 Diameter Load August 2019 + + + Note: In the case of load reports of type "PEER", it is only + necessary to include load reports when the Load value has changed + by some meaningful value, as long as the agent ensures 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 the behavior of Diameter nodes 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 in the Load-Type AVP included in the Load AVP received + in the same answer message or from 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. + + 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 included in the Load-Value AVP included + in the Load AVP of type "HOST" in its routing information. + + If the Diameter node receives a load report of type "PEER", then the + Diameter node MUST determine if the load report was inserted into the + answer message by the peer from which the message was received. This + is achieved by comparing the DiameterIdentity associated with the + connection from which the message was received with the + DiameterIdentity included in the SourceID AVP in the load report. + + If the Diameter node determines 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 determines 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. + + + + + + +Campbell, et al. Standards Track [Page 13] + +RFC 8583 Diameter Load August 2019 + + + Note: This ensures that there will be precisely one load report of + type "PEER", e.g., that of the Diameter node sending the message, + in any answer messages sent by the Diameter Agent. + + How a Diameter node uses load information for making routing + decisions is an implementation decision. However, the distribution + algorithm MUST result in similar behavior as the algorithm described + for the use of weight values in [RFC2782]. + +6.3. Extensibility + + The Load mechanism can be extended to include additional information + in the load reports. + + Any extension may define new AVPs for use in load reports. These new + AVPs SHOULD be defined to be extensions to the Load AVPs defined in + this document. + + Grouped AVP extension mechanisms defined by [RFC6733] apply. This + allows, for example, defining a new feature that is mandatory to be + understood even when piggybacked on an existing application. + + 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 is added, the new node will start by advertising + its load. Downstream nodes will need to factor the new load + information into load-balancing decisions. The downstream nodes can + attempt to ensure a smooth increase of the traffic to the new node, + avoiding an immediate spike of traffic to that new node. The method + for the handling of such a smooth increase is implementation- + specific, but it can rely on the evolution of load information + received from the new node and from the other nodes. + + When removing a node in a controlled way (e.g., for maintenance + purposes, so outside a failure case), it might be appropriate to + progressively reduce the traffic to this node by routing traffic to + other nodes. Simple load information (load percentage) would not be + sufficient. The method for the handling of the node removal is + implementation-specific, but it can rely on the evolution of the load + information received from the node to be removed. + + + + + + + +Campbell, et al. Standards Track [Page 14] + +RFC 8583 Diameter Load August 2019 + + +7. Attribute-Value Pairs + + The 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 is used + to convey the type of Diameter node that sent the load information. + The following 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 is used + to convey relative load information about the sender of the load + report. + + The Load-Value AVP is specified in a manner similar to the weight + value in DNS SRV ([RFC2782]). + + The Load value has a range of 0-65535. + + A higher value indicates a lower load on the sending node. A lower + value indicates that the sending node is heavily loaded. + + Stated another way, a node that has 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 is used to identify the + Diameter node that sent the load report. + + + + +Campbell, et al. Standards Track [Page 15] + +RFC 8583 Diameter Load August 2019 + + +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 + + Load information may be sensitive information 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 be useful in identifying targets for denial- + of-service (DoS) attacks, where a node known to be already heavily + loaded might be a tempting target. Load information might also be + useful as feedback about the success of an ongoing DoS attack. + + Given that routing decisions are impacted by load information, there + is potential for negative impacts on a Diameter network caused by + erroneous or malicious load reports. This includes the malicious + changing of Load values by Diameter Agents. + + Any load information conveyance mechanism will need to allow + operators to avoid sending load information to nodes that are not + authorized to receive it. Since Diameter currently only offers + authentication of nodes at the transport level and does not support + end-to-end security mechanisms, 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. + + + +Campbell, et al. Standards Track [Page 16] + +RFC 8583 Diameter Load August 2019 + + +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, + . + + [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, + . + + [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, + Ed., "Diameter Base Protocol", RFC 6733, + DOI 10.17487/RFC6733, October 2012, + . + + [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. + Morand, "Diameter Overload Indication Conveyance", + RFC 7683, DOI 10.17487/RFC7683, October 2015, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8581] Donovan, S., "Diameter Agent Overload and the Peer + Overload Report", RFC 8581, DOI 10.17487/RFC8581, August + 2019, . + +10.2. Informative References + + [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control + Requirements", RFC 7068, DOI 10.17487/RFC7068, November + 2013, . + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 17] + +RFC 8583 Diameter Load August 2019 + + +Appendix A. Topology Scenarios + + This section presents a number of Diameter topology scenarios and + discusses how load information might be used in each scenario. + +A.1. No Agent + + Figure 6 shows a simple client-server scenario where a client picks + from a set of candidate servers available for a particular realm and + application. The client selects the server for a given transaction + using the load information received from each server. + + ------S1 + / + C + \ + ------S2 + + Figure 6: Basic Client Server Scenario + + If a node supports dynamic discovery, it will not obtain load + information from the nodes with which it has no Diameter + connection established. 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. + + 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 + selects the request destination from a set of candidate servers, + using load information received from each server. The client does + not need to receive load information since it does not select between + multiple agents. + + ------S1 + / + C----A + \ + ------S2 + + Figure 7: Simple Agent Scenario + + + + + + + + +Campbell, et al. Standards Track [Page 18] + +RFC 8583 Diameter Load August 2019 + + +A.3. Multiple Agents + + Figure 8 shows a client selecting between multiple agents and each + agent selecting from multiple servers. The client selects an agent + based on the load information received from each agent. Each agent + selects a server based on the load information received from its + servers. + + This scenario adds a complication that 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, in effect + aggregating 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 + \ + ---- S4 + + Figure 8: Multiple Agents and Servers + +A.4. Linked Agents + + Figure 9 shows a scenario similar to that of Figure 8, except that + 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 its connected servers. + + This somewhat simplifies the complication from Figure 8 due to the + fact that C does not necessarily need to choose a particular agent to + reach a particular server. But, it creates a similar question of + + + + +Campbell, et al. Standards Track [Page 19] + +RFC 8583 Diameter Load August 2019 + + + how, for example, A1 might know that S4 was less loaded than S1 or + S3. Additionally, it creates the opportunity for sub-optimal request + paths. For example, [C,A1,A2,S4] vs. [C,A2,S4]. + + 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, 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 + \ + ---- S4 + + Figure 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. + + -----S3 + / + C1----A1------S1 + | + | + | + C2----A2------S2 + \ + ---- S4 + + Figure 10: Linked Agents + + + + + +Campbell, et al. Standards Track [Page 20] + +RFC 8583 Diameter Load August 2019 + + +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 need only + be concerned with the load information of the agents. + + ---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 that of Figure 8, except that + instead of the client possibly needing to select an agent that can + route requests to the least loaded server, in this case A1 and A2 + need to make similar decisions when selecting between A3 or A4. As + the former scenario, this could be mitigated if A3 and A4 aggregate + upstream loads into the load information they report downstream. + + ---A1---A3----S[1], S[2]...S[p] + / | \ / + C | x + \ | / \ + ---A2---A4----S[p+1], S[p+2] ...S[n] + + Figure 12: Agent Chains + + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 21] + +RFC 8583 Diameter Load August 2019 + + +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. + + ---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 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". + + 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 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. + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 22] + +RFC 8583 Diameter Load August 2019 + + +Authors' Addresses + + Ben Campbell + Oracle + 7460 Warren Parkway, Suite 300 + Frisco, Texas 75034 + United States of America + + Email: ben@nostrum.com + + + Steve Donovan (editor) + Oracle + 7460 Warren Parkway # 300 + Frisco, Texas 75034 + United States of America + + Email: srdonovan@usdonovans.com + + + Jean-Jacques Trottin + Nokia + Route de Villejust + 91620 Nozay + France + + Email: jean-jacques.trottin@nokia.com + + + + + + + + + + + + + + + + + + + + + + + + +Campbell, et al. Standards Track [Page 23] + -- cgit v1.2.3