doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

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,
+              <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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+