draft-ietf-dime-load-09.txt   rfc8583.txt 
Internet Engineering Task Force B. Campbell Internet Engineering Task Force (IETF) B. Campbell
Internet-Draft S. Donovan, Ed. Request for Comments: 8583 S. Donovan, Ed.
Intended status: Standards Track Oracle Category: Standards Track Oracle
Expires: September 23, 2017 JJ. Trottin ISSN: 2070-1721 JJ. Trottin
Nokia Nokia
March 22, 2017 August 2019
Diameter Load Information Conveyance Diameter Load Information Conveyance
draft-ietf-dime-load-09
Abstract Abstract
RFC7068 describes requirements for Overload Control in Diameter. RFC 7068 describes requirements for Overload Control in Diameter.
This includes a requirement to allow Diameter nodes to send "load" This includes a requirement to allow Diameter nodes to send "load"
information, even when the node is not overloaded. RFC7683 (Diameter information, even when the node is not overloaded. The base solution
Overload Information Conveyance (DOIC)) solution describes a defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC))
mechanism meeting most of the requirements, but does not currently describes a mechanism meeting most of the requirements but does not
include the ability to send load information. This document defines currently include the ability to send load information. This
a mechanism for conveying of Diameter load information. document defines a mechanism for the conveying of Diameter load
information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 23, 2017. 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.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Differences between Load and Overload information . . . . 4 4.1. Differences between Load and Overload Information . . . . 5
4.2. How is Load Information Used? . . . . . . . . . . . . . . 5 4.2. How Is Load Information Used? . . . . . . . . . . . . . . 6
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 8 5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 9
6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 10 6. Load-Mechanism Procedures . . . . . . . . . . . . . . . . . . 11
6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10 6.1. Reporting-Node Behavior . . . . . . . . . . . . . . . . . 11
6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 10 6.1.1. Endpoint Reporting-Node Behavior . . . . . . . . . . 11
6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 11 6.1.2. Agent Reporting-Node Behavior . . . . . . . . . . . . 12
6.2. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12 6.2. Reacting-Node Behavior . . . . . . . . . . . . . . . . . 13
6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 14
6.4. Addition and Removal of Nodes . . . . . . . . . . . . . . 13 6.4. Addition and Removal of Nodes . . . . . . . . . . . . . . 14
7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 14 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 15
7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 14 7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 15
7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15 7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 15 7.5. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 17 Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 18
A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 17 A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 18
A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 18 A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 19
A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 19 A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 19
A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 20 A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 21
A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 20 A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 21
A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 21 A.7. Fully-Meshed Layers . . . . . . . . . . . . . . . . . . . 22
A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 21 A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 22
A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 21 A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
[RFC7068] describes requirements for Overload Control in Diameter [RFC7068] describes requirements for Overload Control in Diameter
[RFC6733]. The DIME working group has finished the Diameter Overload [RFC6733]. The DIME Working Group has finished the Diameter Overload
Information Conveyance (DOIC) mechanism [RFC7683]. As currently Information Conveyance (DOIC) mechanism [RFC7683]. As currently
specified, DOIC fulfills some, but not all, of the requirements. specified, DOIC fulfills some, but not all, of the requirements.
In particular, DOIC does not fulfill Req 23 and Req 24: In particular, DOIC does not fulfill Req 23 and Req 24:
REQ 23: The solution MUST provide sufficient information to enable REQ 23: The solution MUST provide sufficient information to enable
a load-balancing node to divert messages that are rejected or a load-balancing node to divert messages that are rejected or
otherwise throttled by an overloaded upstream node to other otherwise throttled by an overloaded upstream node to other
upstream nodes that are the most likely to have sufficient upstream nodes that are the most likely to have sufficient
capacity to process them. capacity to process them.
REQ 24: The solution MUST provide a mechanism for indicating load REQ 24: The solution MUST provide a mechanism for indicating load
levels, even when not in an overload condition, to assist nodes in levels, even when not in an overload condition, to assist nodes in
making decisions to prevent overload conditions from occurring. making decisions to prevent overload conditions from occurring.
There are several other requirements in [RFC7068] that mention both There are several other requirements in [RFC7068] that mention both
overload and load information that are only partially fulfilled by overload and load information that are only partially fulfilled by
DOIC. DOIC.
The DIME working group explicitly chose not to fulfill these The DIME Working Group explicitly chose not to fulfill these
requirements when publishing DOIC [RFC7683] due to several reasons. requirements when publishing DOIC [RFC7683] due to several reasons.
A principal reason was that the working group did not agree on a A principal reason was that the working group did not agree on a
general approach for conveying load information. It chose to general approach for conveying load information. It chose to
progress the rest of DOIC, and deferred load information conveyance progress the rest of DOIC and deferred load information conveyance to
to a DOIC extension or a separate mechanism. a DOIC extension or a separate mechanism.
This document defines a mechanism that addresses the load-related This document defines a mechanism that addresses the load-related
requirements from RFC 7068. requirements from RFC 7068.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
AVP AVP
Attribute-Value Pair
Attribute Value Pair
DOIC DOIC
Diameter Overload Information Conveyance [RFC7683]
Diameter Overload Information Conveyance ([RFC7683])
Load Load
The relative usage of the Diameter message processing capacity of The relative usage of the Diameter message processing capacity of
a Diameter node. A low load level indicates that the Diameter a Diameter node. A low load level indicates that the Diameter
node is under utilized. A high load level indicates that the node node is underutilized. A high load level indicates that the node
is closer to being fully utilized. is closer to being fully utilized.
Offered Load Offered Load
The actual traffic sent to the reporting node after overload The actual traffic sent to the reporting node after overload
abatement and routing decisions are made. abatement and routing decisions are made.
Reporting Node Reporting Node
A DOIC node that sends a DOIC Overload report in a Diameter answer
Reporting Node: A Diameter node that generates a load report. message.
Reacting Node Reacting Node
A DOIC node that receives and acts on a DOIC Overload report.
Reacting Node: A Diameter node that acts upon a load report.
Routing Information Routing Information
Routing Information referred to in this document can include the Routing Information referred to in this document can include the
Routing and Peer tables defined in RFC 6733. It can also include Routing and Peer tables defined in RFC 6733. It can also include
other implementation specific tables used to store load other implementation-specific tables used to store load
information. This document does not define the structure of such information. This document does not define the structure of such
tables. tables.
3. Conventions Used in This Document 3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
RFC 2119 [RFC2119] interpretation does not apply for the above listed capitals, as shown here.
words when they are not used in all-caps format.
4. Background 4. Background
4.1. Differences between Load and Overload information 4.1. Differences between Load and Overload Information
Previous discussions of how to solve the load-related requirements in Previous discussions of how to solve the load-related requirements in
[RFC7068] have shown that people did not have an agreed-upon concept [RFC7068] have shown that people did not have an agreed-upon concept
of how "load" information differs from "overload" information. While of how "load" information differs from "overload" information. While
the two concepts are highly interrelated, there are two primary the two concepts are highly interrelated, there are two primary
differences. First, a Diameter node always has a load. At any given differences. First, a Diameter node always has a load. At any given
time that load may be effectively zero, effectively fully loaded, or time, that load may be effectively zero, effectively fully loaded, or
somewhere in between. In contrast, overload is an exceptional somewhere in between. In contrast, overload is an exceptional
condition. A node only has overload information when it is in an condition. A node only has Overload information when it is in an
overloaded state. Furthermore, the relationship between a node's overloaded state. Furthermore, the relationship between a node's
load level and overload state at any given time may be vague. For 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 example, a node may normally operate at a "fully loaded" level, but
still not be considered overloaded. Another node may declare itself still not be considered overloaded. Another node may declare itself
to be "overloaded" even though it might not be fully "loaded". to be "overloaded" even though it might not be fully "loaded".
Second, Overload information, in the form of a DOIC Overload Report Second, Overload information, in the form of a DOIC Overload Report
(OLR) [RFC7683] indicates an explicit request for action on the part (OLR) [RFC7683] indicates an explicit request for action on the part
of the reacting node. That is, the OLR requests that the reacting of the reacting node; the OLR requests that the reacting node reduce
node reduces the offered load -- the actual traffic sent to the the offered load, the actual traffic sent to the reporting node after
reporting node after overload abatement and routing decisions are overload abatement and routing decisions are made, by an indicated
made -- by an indicated amount (by default), or as prescribed by the amount (by default) or as prescribed by the selected abatement
selected abatement algorithm. Effectively, DOIC provides a contract algorithm. Effectively, DOIC provides a contract between the
between the reporting node and the reacting node. reporting node and the reacting node.
In contrast, load is informational. That is, load information can be In contrast, load is informational; load information can be
considered a hint to the recipient node. That node may use the load considered a hint to the recipient node. That node may use the load
information for load balancing purposes, as an input to certain information for load-balancing purposes, as an input to certain
overload abatement techniques, to make inferences about the overload abatement techniques, to make inferences about the
likelihood that the sending node becomes overloaded in the immediate likelihood that the sending node becomes overloaded in the immediate
future, or for other purposes. future, or for other purposes.
None of this prevents a Diameter node from deciding to reduce the None of this prevents a Diameter node from deciding to reduce the
offered load based on load information. The fundamental difference offered load based on load information. The fundamental difference
is that an overload report requires the reduction of offered load. is that an Overload report requires the reduction of the offered
It is also reasonable for a Diameter node to decide to increase the load. It is also reasonable for a Diameter node to decide to
offered load based on load information. increase the offered load based on load information.
4.2. How is Load Information Used? 4.2. How Is Load Information Used?
[RFC7068] contemplates two primary uses for load information. Req 23 [RFC7068] contemplates two primary uses for load information. Req 23
discusses how load information might be used when performing discusses how load information might be used when performing
diversion as an overload abatement technique, as described in diversion as an overload abatement technique as described in
[RFC7683]. When a reacting node diverts traffic away from an [RFC7683]. When a reacting node diverts traffic away from an
overloaded node, it needs load information for the other candidates overloaded node, it needs load information for the other candidates
for that traffic in order to effectively load balance the diverted for that traffic in order to effectively load-balance the diverted
load between potential candidates. Otherwise, diversion has a load between potential candidates. Otherwise, diversion has a
greater potential to drive other nodes into overload. greater potential to drive other nodes into overload.
Req 24 discusses how Diameter load information might be used when no Req 24 discusses how Diameter load information might be used when no
overload condition currently exists. Diameter nodes can use the load overload condition currently exists. Diameter nodes can use the load
information to make decisions to try to avoid overload conditions in information to make decisions to try to avoid overload conditions in
the first place. Normal load-balancing falls into this category, but the first place. Normal load-balancing falls into this category, but
the diameter node can take other proactive steps as well. the Diameter node can take other proactive steps as well.
If the loaded nodes are Diameter servers (or clients in the case of If the loaded nodes are Diameter servers (or clients in the case of
server-to-client transactions), both of these uses of load server-to-client transactions), both of these uses of load
information should be accomplished by a Diameter node that performs information should be accomplished by a Diameter node that performs
server selection (selection of the Diameter endpont to which the server selection (selection of the Diameter endpoint to which the
request is to be routed for processing). Typically, server selection request is to be routed for processing). Typically, server selection
is performed by a node (a client or an agent) that is an immediate 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) peer of the server. However, there are scenarios (see Appendix A)
where a client or proxy that is not the immediate peer to the where a client or proxy that is not the immediate peer to the
selected servers performs server selection. In this case, the client selected servers performs server selection. In this case, the client
or proxy enforces the server selection by inserting a Destination- or proxy enforces the server selection by inserting a Destination-
Host AVP. Host AVP.
For example, a Diameter node (e.g. client) can use a redirect As an example, a Diameter node (e.g., client) can use a redirect
agent to get candidate destination host addresses. The redirect agent to get candidate destination host addresses. The redirect
agent might return several destination host addresses, from which agent might return several destination host addresses from which the
the Diameter node selects one. The Diameter node can use load Diameter node selects one. The Diameter node can use load
information received from these hosts to make the selection. information received from these hosts to make the selection.
Just as load information can be used as part of server selection, it 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 can also be used as input to the selection of the next-hop peer to
which a request is to be routed. which a request is to be routed.
It should be noted that a Diameter node will need to process both It should be noted that a Diameter node will need to process both
Load reports and Overload reports from the same Diameter node. The load reports and Overload reports from the same Diameter node. The
reacting node for the Overload report always has the responsibility reacting node for the overload report always has the responsibility
to reduce the amount of Diameter traffic sent to the overloaded node. to reduce the amount of Diameter traffic sent to the overloaded node.
If, or how, the reacting node uses load information to achieve this If, or how, the reacting node uses load information to achieve this
is left as an implementation decision. is left as an implementation decision.
5. Solution Overview 5. Solution Overview
The mechanism defined here for the conveyance of load information is The mechanism defined here for the conveyance of load information is
similar in some ways to the mechanism defined for DOIC and is similar in some ways to the mechanism defined for DOIC and is
different in other ways. different in other ways.
As with DOIC, load information is conveyed by piggy-backing the Load As with DOIC, load information is conveyed by piggybacking the Load
AVPs on existing Diameter applications. AVPs on existing Diameter applications.
There are two primary differences. First, there is no capability There are two primary differences. First, there is no capability
negotiation process for load. The sender of the load information is negotiation process for load. The sender of the load information is
sending it with the expectation that any supporting nodes will use it sending it with the expectation that any supporting nodes will use it
when making routing decisions. If there are no nodes that support when making routing decisions. If there are no nodes that support
the Load mechanism then the load information is ignored. the Load mechanism, then the load information is ignored.
The second big difference between DOIC and Load is visibility of the The second big difference between DOIC and Load is visibility of the
DOIC or load information within a Diameter network. DOIC information 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 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 of the answer message that carries the OC-OLR AVP to act on the
information, although only one node actually comsumes and reacts to information, although only one node actually consumes and reacts to
the report. The DOIC overload reports remain in the message all the 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 way from the reporting node to the node that is the target for the
answer message. answer message.
For the Load mechanism there are two types of Load reports and only For the Load mechanism, there are two types of load reports and only
the first one is transmitted end-to-end. the first one is transmitted end-to-end.
The first type of Load report is a HOST report which contains the The first type of load report is a host-load report, which contains
load of the endpoint sending the answer message. This Load report is the load of the endpoint sending the answer message. This load
carried end-to-end to enable any nodes that make server selection report is carried end-to-end to enable any nodes that make server
decisions to use the load status of the sending endpoint as part of selection decisions to use the load status of the sending endpoint as
the server selection decision. Unlike with DOIC, more than one node part of the server selection decision. Unlike with DOIC, more than
may make use of the load information received. one node may make use of the load information received.
The second type of Load report is a PEER report. This report is used The second type of load report is a peer-load report. This report is
by Diameter nodes as part of the logic to select the next-hop 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 Diameter node and, as such, does not have significance beyond the
peer node. Load reports of type PEER are removed by the first peer node. load reports of type "PEER" are removed by the first
supporting Diameter node to receive the report. supporting Diameter node to receive the report.
Because Load reports can traverse Diameter nodes that do not support Because load reports can traverse Diameter nodes that do not support
the Load mechanism, it is necessary to include the identity of the 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. 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 This allows for a Diameter node to verify that a load report applies
to its peer or if it should be ignored. to its peer or that it should be ignored.
The Load report includes a value indicating relative load of the The load report includes a value indicating the relative load of the
sending node, specified in a manner consistent with that defined for sending node, specified in a manner consistent with that defined for
DNS SRV [RFC2782]. DNS SRV [RFC2782].
The goal is to make it possible to use both the load values received 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 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 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 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 then used in a distribution algorithm similar to that specified in
[RFC2782]. [RFC2782].
The DNS SRV distribution algorithm results in more messages being The DNS SRV distribution algorithm results in more messages being
sent to a node with a higher weight value. As a result, a higher 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 Diameter Load value indicates a LOWER load on the sending node. A
node that is heavily loaded sends a lower Diameter load value. 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 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. of 65535. A node that is 100% loaded would have a Load value of 0.
The distribution algorithm used by Diameter nodes supporting the The distribution algorithm used by Diameter nodes supporting the
Diameter Load mechanism is an implementation decision but it needs to Diameter Load mechanism is an implementation decision, but it needs
result in similar behavior to the algorithm described for the use of to result in similar behavior to the algorithm described for the use
weight values specified in [RFC2782]. of weight values specified in [RFC2782].
The method for calculating the load value included in the Load report The method for calculating the Load value included in the load report
is also left as an implementation decision. is also left as an implementation decision.
The frequency for sending of Load reports is also left as an The frequency for sending of load reports is also left as an
implementation decision. The sending node might choose to send Load implementation decision. The sending node might choose to send load
reports in all messages or it might choose to only send Load reports reports in all messages or it might choose to only send load reports
when the load value has changed by some implementation specific when the Load value has changed by some implementation-specific
amount. The important consideration is that all nodes needing the amount. The important consideration is that all nodes needing the
load information have a sufficiently accurate view of the node's load information have a sufficiently accurate view of the node's
load. load.
5.1. Theory of Operation 5.1. Theory of Operation
This section outlines how the Diameter Load mechanism is expected to This section outlines how the Diameter Load mechanism is expected to
work. work.
For this discussion, assume the following Diameter network For this discussion, assume the following Diameter network
configuration: configuration:
---A1---A3----S[1], S[2]...S[p] ---A1---A3----S[1], S[2]...S[p]
/ | \ / / | \ /
C | x C | x
\ | / \ \ | / \
---A2---A4----S[p+1], S[p+2] ...S[n] ---A2---A4----S[p+1], S[p+2] ...S[n]
Figure 1: Example Diameter Network Figure 1: Example Diameter Network
Note that in this diagram, S[1], S[2] through S[p] are peers to A3. Note that in this diagram, S[1] and S[2] through S[p] are peers to
S[p+1], S[p+2] through S[n] are peers to A4. 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 Also assume that the request for a Diameter transaction takes the
following path: following path:
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
|----->|----->|----->| |----->|----->|----->|
xxR xxR xxR xxR xxR xxR
Figure 2: Request Message Path Figure 2: Request Message Path
When sending the answer message, an endpoint node that supports the When sending the answer message, an endpoint node that supports the
Diameter Load mechanism includes its own load information in the Diameter Load mechanism includes its own load information in the
answer message. Because it is a Diameter endpoint it includes a HOST answer message. Because it is a Diameter endpoint, it includes a
Load report. host-load report.
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
| | |<-----| | | |<-----|
| | xxA(Load type:HOST, source:S[n]) | | xxA(Load type:HOST, source:S[n])
| | | | | | | |
Figure 3: Answer Message from S[n] Figure 3: Answer Message from S[n]
If Agent A4 supports the Load mechanism then A4's actions depend on 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 whether A4 is responsible for doing server selection. If A4 is not
doing server selection then A4 ignores the HOST Load report. If A4 doing server selection, then A4 ignores the host-load report. If A4
is responsible for doing server selection then it stores the load is responsible for doing server selection, then it stores the load
information for S[n] in its routing information for the handling of information for S[n] in its routing information for the handling of
subsequent request messages. In both cases A4 leaves the HOST report subsequent request messages. In both cases, A4 leaves the host-load
in the message. report in the message.
Note: If A4 does not support the Load mechanism then it will relay Note: If A4 does not support the Load mechanism, then it will
the answer message without doing any processing on the load relay the answer message without doing any processing on the load
information. In this case the load information AVPs will be information. In this case, the load information AVPs will be
relayed without change. relayed without change.
A4 then calculates its own load information and inserts load A4 then calculates its own load information and inserts load
information AVPs of type PEER in the message before sending the information AVPs of type "PEER" in the message before sending the
message to A1. message to A1.
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
| |<-----| | | |<-----| |
| xxA(Load type:PEER, source:A4) | xxA(Load type:PEER, source:A4)
| xxA(Load type:HOST, source:S[n]) | xxA(Load type:HOST, source:S[n])
| | | | | | | |
Figure 4: Answer Message from A4 Figure 4: Answer Message from A4
If A1 supports the Load mechanism then it processes each of the Load If A1 supports the Load mechanism, then it processes each of the load
reports it receives separately. reports it receives separately.
For the PEER Load report, A1 first determines if the source of the For the peer-load report, A1 first determines if the source of the
report indicated in the Load report matches the DiameterIdentity of report indicated in the load report matches the DiameterIdentity of
the Diameter node from which the request was received. If the the Diameter node from which the request was received. If the
identities do not match then the PEER Load report is discarded. If identities do not match, then the peer-load report is discarded. If
the identities match then A1 saves the load information in its the identities match, then A1 saves the load information in its
routing information for routing of subsequent request messages. In routing information for routing of subsequent request messages. In
both cases A1 strips the PEER Load report from the message. both cases, A1 strips the peer-load report from the message.
For the HOST Load report, A1's actions depend on whether A1 is For the host-load report, A1's actions depend on whether A1 is
responsible for doing server selection. If A1 is not doing server responsible for doing server selection. If A1 is not doing server
selection then A1 ignores the HOST Load report. If A1 is responsible selection, then A1 ignores the host-load report. If A1 is
for doing server selection then it stores the load information for responsible for doing server selection, then it stores the load
S[n] in its routing information for the handling of subsequent information for S[n] in its routing information for the handling of
request messages. In both cases A1 leaves the HOST report in the subsequent request messages. In both cases, A1 leaves the host-load
message. report in the message.
A1 then calculates its own load information and inserts load A1 then calculates its own load information and inserts load
information AVPs of type PEER in the message before sending the information AVPs of type "PEER" in the message before sending the
message to C: message to C:
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
|<-----| | | |<-----| | |
xxA(Load type:PEER, source:A1) xxA(Load type:PEER, source:A1)
xxA(Load type:HOST, source:S[n]) xxA(Load type:HOST, source:S[n])
Figure 5: Answer Message from A1 Figure 5: Answer Message from A1
As with A1, C processes each Load report separately. As with A1, C processes each load report separately.
For the PEER Load report, C follows the same procedure as A1 for 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 determining if the load report was received from the peer from which
the report was sent. When finding it does, C stores the load the report was sent. When finding it does, C stores the load
information for use when making future routing decisions. information for use when making future routing decisions.
For the HOST Load report, C saves the load information only if it is For the host-load report, C saves the load information only if it is
responsible for doing server selection. responsible for doing server selection.
The load information received by all nodes is then used for routing The load information received by all nodes is then used for routing
of subsequent request messages. of subsequent request messages.
6. Load Mechanism Procedures 6. Load-Mechanism Procedures
This section defines the normative behaviors for the Load mechanism. This section defines the normative behaviors for the Load mechanism.
6.1. Reporting Node Behavior 6.1. Reporting-Node Behavior
This section defines the procedures of Diameter reporting nodes that This section defines the procedures of Diameter reporting nodes that
generate Load reports. generate load reports.
6.1.1. Endpoint Reporting Node Behavior 6.1.1. Endpoint Reporting-Node Behavior
A Diameter endpoint that supports the Diameter Load mechanism MUST A Diameter endpoint that supports the Diameter Load mechanism MUST
include a Load report of type HOST in sufficient answer messages to include a load report of type "HOST" in sufficient answer messages to
ensure that all consumers of the load information receive timely ensure that all consumers of the load information receive timely
updates. updates.
The Diameter endpoint MUST include its own DiameterIdentity in the The Diameter endpoint MUST include its own DiameterIdentity in the
SourceID AVP included in the Load AVP. SourceID AVP included in the Load AVP.
The Diameter endpoint MUST include a Load-Type AVP of type HOST in The Diameter endpoint MUST include a Load-Type AVP of type "HOST" in
the Load AVP. the Load AVP.
The Diameter endpoint MUST include its load value in the Load-Value The Diameter endpoint MUST include its Load value in the Load-Value
AVP in the Load AVP. AVP in the Load AVP.
The LOAD value should be calculated in a way that reflects the The Load value should be calculated in a way that reflects the
available load independently of the weight of each server, in order available load independently of the weight of each server in order to
to accurately compare LOAD values from different nodes. Any specific accurately compare Load values from different nodes. Any specific
LOAD value needs to identify the same amount of available capacity, Load value needs to identify the same amount of available capacity
regardless the Diameter node that calculates the value. regardless of the Diameter node that calculates the value.
The mechanism used to calculate the LOAD value that fulfills this The mechanism used to calculate the Load value that fulfills this
requirement is an implementation decision. requirement is an implementation decision.
The frequency of sending Load reports 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 For instance, if the only consumer of the load reports is the
endpoint's peer then the endpoint can choose to only include a endpoint's peer, then the endpoint can choose to only include a load
Load report when the load of the endpoint has changed by a report when the load of the endpoint has changed by a meaningful
meaningful percentage. If there are consumers of the endpoint percentage. If there are consumers of the endpoint load report other
Load report other then the endpoint's peer (this will be the case than the endpoint's peer (this will be the case if other nodes are
if other nodes are responsible for server selection) then the responsible for server selection), then the endpoint might choose to
endpoint might choose to include Load reports in all answer include load reports in all answer messages as a way of ensuring that
messages as a way of ensuring that all nodes doing server all nodes doing server selection get accurate load information.
selection get accurate load information.
6.1.2. Agent Reporting Node Behavior 6.1.2. Agent Reporting-Node Behavior
A Diameter Agent that supports the Diameter Load mechanism MUST A Diameter Agent that supports the Diameter Load mechanism MUST
include a PEER Load report in sufficient answer messages to ensure include a peer-load report in sufficient answer messages to ensure
that all users of the load information receive timely updates. that all users of the load information receive timely updates.
The Diameter Agent MUST include its own DiameterIdentity in the The Diameter Agent MUST include its own DiameterIdentity in the
SourceID AVP included in the Load AVP. SourceID AVP included in the Load AVP.
The Diameter Agent MUST include a Load-Type AVP of type PEER in the The Diameter Agent MUST include a Load-Type AVP of type "PEER" in the
Load AVP. Load AVP.
The Diameter Agent MUST include its load value in the Load-Value AVP The Diameter Agent MUST include its Load value in the Load-Value AVP
in the Load AVP. in the Load AVP.
The LOAD value should be calculated in a way that reflects the The Load value should be calculated in a way that reflects the
available load independently of the weight of each agent, in order to available load independently of the weight of each agent in order to
accurately compare LOAD values from different nodes. Any specific accurately compare Load values from different nodes. Any specific
LOAD value needs to identify the same amount of available capacity, Load value needs to identify the same amount of available capacity
regardless the Diameter node that calculates the value. regardless of the Diameter node that calculates the value.
The mechanism used to calculate the LOAD value that fulfills this The mechanism used to calculate the Load value that fulfills this
requirement is an implementation decision. requirement is an implementation decision.
The frequency of sending Load reports is an implementation decision. The frequency of sending load reports is an implementation decision.
Note: In the case of peer Load reports it is only necessary to Note: In the case of load reports of type "PEER", it is only
include Load reports when the load value has changed by some necessary to include load reports when the Load value has changed
meaningful value, as long as the agent ensures that all peers by some meaningful value, as long as the agent ensures that all
receive the report. It is also acceptable to include the Load peers receive the report. It is also acceptable to include the
report in every answer message handled by the Diameter Agent. load report in every answer message handled by the Diameter Agent.
6.2. Reacting Node Behavior 6.2. Reacting-Node Behavior
This section defines the behavior of Diameter nodes processing Load This section defines the behavior of Diameter nodes processing load
reports. reports.
A Diameter node that supports the Diameter Load mechanism MUST be A Diameter node that supports the Diameter Load mechanism MUST be
prepared to process Load reports of type HOST and of type PEER, as prepared to process load reports of type "HOST" and of type "PEER",
indicated in the Load-Type AVP included in the Load AVP received in as indicated in the Load-Type AVP included in the Load AVP received
the same answer message or from multiple answer messages. in the same answer message or from multiple answer messages.
Note that the node needs to be able to handle messages with no Note: The node needs to be able to handle messages with no Load
load reports, messages with just a PEER Load report, messages with reports, messages with just a peer-load report, messages with just
just an HOST Load report and messages with both types of Load a host-load report, and messages with both types of load reports.
reports.
If the Diameter node is not responsible for doing server selection If the Diameter node is not responsible for doing server selection,
then it SHOULD ignore Load reports of type HOST. then it SHOULD ignore load reports of type "HOST".
If the Diameter node is responsible for doing server selection then If the Diameter node is responsible for doing server selection, then
it SHOULD save the load value included in the Load-Value AVP included it SHOULD save the Load value included in the Load-Value AVP included
in the Load AVP of type HOST in its routing information. in the Load AVP of type "HOST" in its routing information.
If the Diameter node receives a Load report of type PEER then the 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 Diameter node MUST determine if the load report was inserted into the
answer message by the peer from which the message was received. This answer message by the peer from which the message was received. This
is achieved by comparing the DiameterIdentity associated with the is achieved by comparing the DiameterIdentity associated with the
connection from which the message was received with the connection from which the message was received with the
DiameterIdentity included in the SourceID AVP in the Load report. DiameterIdentity included in the SourceID AVP in the load report.
If the Diameter node determines that the Load report of type PEER was If the Diameter node determines that the load report of type "PEER"
not received from the peer that sent or relayed the answer message was not received from the peer that sent or relayed the answer
then the node MUST ignore the Load report. message, then the node MUST ignore the load report.
If the Diameter node determines that the Load report of type PEER was If the Diameter node determines that the load report of type "PEER"
received from the peer that sent or relayed the answer message then was received from the peer that sent or relayed the answer message,
the node SHOULD save the load information in its routing information. 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 In all cases, a Diameter Agent MUST strip all load reports of type
PEER received in answer messages. "PEER" received in answer messages.
Note: This ensures that there will be precisely one Load report of Note: This ensures that there will be precisely one load report of
type PEER, that of the Diameter node sending the message, in any type "PEER", e.g., that of the Diameter node sending the message,
answer messages sent by the Diameter Agent. in any answer messages sent by the Diameter Agent.
How a Diameter node uses load information for making routing How a Diameter node uses load information for making routing
decisions is an implementation decision. However, the distribution decisions is an implementation decision. However, the distribution
algorithm MUST result in similar behavior as the algorithm described algorithm MUST result in similar behavior as the algorithm described
for the use of weight values in [RFC2782]. for the use of weight values in [RFC2782].
6.3. Extensibility 6.3. Extensibility
The Load mechanism can be extended to include additional information The Load mechanism can be extended to include additional information
in the Load reports. in the load reports.
Any extension may define new AVPs for use in Load reports. These new 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 AVPs SHOULD be defined to be extensions to the Load AVPs defined in
this document. this document.
[RFC6733] defined Grouped AVP extension mechanisms apply. This Grouped AVP extension mechanisms defined by [RFC6733] apply. This
allows, for example, defining a new feature that is mandatory to be allows, for example, defining a new feature that is mandatory to be
understood even when piggybacked on an existing application. understood even when piggybacked on an existing application.
As with any Diameter specification, [RFC6733] requires all new AVPs As with any Diameter specification, [RFC6733] requires all new AVPs
to be registered with IANA. See Section 9 for the required to be registered with IANA. See Section 9 for the required
procedures. procedures.
6.4. Addition and Removal of Nodes 6.4. Addition and Removal of Nodes
When a Diameter node is added, the new node will start by advertising When a Diameter node is added, the new node will start by advertising
its load. Downstream nodes will need to factor the new load its load. Downstream nodes will need to factor the new load
information into load balancing decisions. The downstream nodes can information into load-balancing decisions. The downstream nodes can
attempt to ensure a smooth increase of the traffic to the new node, attempt to ensure a smooth increase of the traffic to the new node,
avoiding an immediate spike of traffic to the new node. The method avoiding an immediate spike of traffic to that new node. The method
for handling of such a smooth increase is implementation specific but for the handling of such a smooth increase is implementation-
it can rely on the evolution of load information received from the specific, but it can rely on the evolution of load information
new node and from the other nodes. received from the new node and from the other nodes.
When removing a node in a controlled way (e.g. for maintenance When removing a node in a controlled way (e.g., for maintenance
purpose, so outside a failure case), it might be appropriate to purposes, so outside a failure case), it might be appropriate to
progressively reduce the traffic to this node by routing traffic to progressively reduce the traffic to this node by routing traffic to
other nodes. Simple load information (load percentage) would not be other nodes. Simple load information (load percentage) would not be
sufficient. The method for handling of the node removal is sufficient. The method for the handling of the node removal is
implementation specific but it can rely on the evolution of the load implementation-specific, but it can rely on the evolution of the load
information received from the node to be removed. information received from the node to be removed.
7. Attribute Value Pairs 7. Attribute-Value Pairs
The section defines the AVPs required for the Load mechanism. The section defines the AVPs required for the Load mechanism.
7.1. Load AVP 7.1. Load AVP
The Load AVP (AVP code TBD1) is of type Grouped and is used to convey The Load AVP (AVP code 650) is of type Grouped and is used to convey
load information between Diameter nodes. load information between Diameter nodes.
Load ::= < AVP Header: TBD1 > Load ::= < AVP Header: 650 >
[ Load-Type ] [ Load-Type ]
[ Load-Value ] [ Load-Value ]
[ SourceID ] [ SourceID ]
* [ AVP ] * [ AVP ]
7.2. Load-Type AVP 7.2. Load-Type AVP
The Load-Type AVP (AVP code TBD2) is of type Enumerated. It is used 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. to convey the type of Diameter node that sent the load information.
The following values are defined: The following values are defined:
HOST 0 The Load report is for a host. HOST 0 The load report is for a host.
PEER 1 The Load report is for a peer. PEER 1 The load report is for a peer.
7.3. Load-Value AVP 7.3. Load-Value AVP
The Load-Value AVP (AVP code TBD3) is of type Unsigned64. It is used 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 to convey relative load information about the sender of the load
report. report.
The Load-Value AVP is specified in a manner similar to the weight The Load-Value AVP is specified in a manner similar to the weight
value in DNS SRV ([RFC2782]). value in DNS SRV ([RFC2782]).
The Load-Value has a range of 0-65535. The Load value has a range of 0-65535.
A higher value indicates a lower load on the sending node. A lower A higher value indicates a lower load on the sending node. A lower
value indicates that the sending node is heavily loaded. value indicates that the sending node is heavily loaded.
Stated another way, a node that has zero load would have a load 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 65535. A node that is 100% loaded would have a Load
value of 0. value of 0.
7.4. SourceID AVP 7.4. SourceID AVP
The SourceID AVP is defined in [I-D.ietf-dime-agent-overload]. It is The SourceID AVP is defined in [RFC8581]. It is used to identify the
used to identify the Diameter node that sent the Load report. Diameter node that sent the load report.
7.5. Attribute Value Pair flag rules 7.5. Attribute-Value Pair Flag Rules
+---------+ +---------+
|AVP flag | |AVP flag |
|rules | |rules |
+----+----+ +----+----+
AVP Section | |MUST| AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|Load TBD1 x.1 Grouped | | V | |Load 650 7.1 Grouped | | V |
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|Load-Type TBD2 x.2 Enumerated | | V | |Load-Type 651 7.2 Enumerated | | V |
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|Load-Value TBD3 x.3 Unsigned64 | | V | |Load-Value 652 7.3 Unsigned64 | | V |
+------------------------------------------------------ -+----+----+ +------------------------------------------------------ -+----+----+
|SourceID TBD4 x.4 DiameterIdentity | | V | |SourceID 649 7.4 DiameterIdentity | | V |
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
As described in the Diameter base protocol [RFC6733], the M-bit usage 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. for a given AVP in a given command may be defined by the application.
8. Security Considerations 8. Security Considerations
Load information may be sensitive information in some cases. Load information may be sensitive information in some cases.
Depending on the mechanism, an unauthorized recipient might be able Depending on the mechanism, an unauthorized recipient might be able
to infer the topology of a Diameter network from load information. to infer the topology of a Diameter network from load information.
Load information might be useful in identifying targets for Denial of Load information might be useful in identifying targets for denial-
Service (DoS) attacks, where a node known to be already heavily of-service (DoS) attacks, where a node known to be already heavily
loaded might be a tempting target. Load information might also be loaded might be a tempting target. Load information might also be
useful as feedback about the success of an ongoing DoS attack. useful as feedback about the success of an ongoing DoS attack.
Given that routing decisions are impacted by load information, there Given that routing decisions are impacted by load information, there
is potential for negative impacts on a Diameter network caused by is potential for negative impacts on a Diameter network caused by
erroneous or malicious Load reports. This includes the malicious erroneous or malicious load reports. This includes the malicious
changing of load values by Diameter Agents. changing of Load values by Diameter Agents.
Any load information conveyance mechanism will need to allow Any load information conveyance mechanism will need to allow
operators to avoid sending load information to nodes that are not operators to avoid sending load information to nodes that are not
authorized to receive it. Since Diameter currently only offers authorized to receive it. Since Diameter currently only offers
authentication of nodes at the transport level and does not support authentication of nodes at the transport level and does not support
end-to-end security mechanisms, any solution that sends load end-to-end security mechanisms, any solution that sends load
information to non-peer nodes requires a transitive-trust model. information to non-peer nodes requires a transitive-trust model.
9. IANA Considerations 9. IANA Considerations
9.1. AVP Codes IANA has registered three new AVP codes in the "Authentication,
Authorization, and Accounting (AAA) Parameters" registry; see
New AVPs defined by this specification are listed in Sections 7.1, 7.2, and 7.3.
Section Section 7. All AVP codes are allocated from the
'Authentication, Authorization, and Accounting (AAA) Parameters' AVP
Codes registry.
9.2. New Registries
This document makes no new registry requests of IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dime-agent-overload]
Donovan, S., "Diameter Agent Overload", draft-ietf-dime-
agent-overload-02 (work in progress), August 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>. <https://www.rfc-editor.org/info/rfc2782>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance", Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015, RFC 7683, DOI 10.17487/RFC7683, October 2015,
<http://www.rfc-editor.org/info/rfc7683>. <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 10.2. Informative References
[RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control
Requirements", RFC 7068, DOI 10.17487/RFC7068, November Requirements", RFC 7068, DOI 10.17487/RFC7068, November
2013, <http://www.rfc-editor.org/info/rfc7068>. 2013, <https://www.rfc-editor.org/info/rfc7068>.
Appendix A. Topology Scenarios Appendix A. Topology Scenarios
This section presents a number of Diameter topology scenarios, and This section presents a number of Diameter topology scenarios and
discusses how load information might be used in each scenario. discusses how load information might be used in each scenario.
A.1. No Agent A.1. No Agent
Figure 6 shows a simple client-server scenario, where a client picks Figure 6 shows a simple client-server scenario where a client picks
from a set of candidate servers available for a particular realm and from a set of candidate servers available for a particular realm and
application. The client selects the server for a given transaction application. The client selects the server for a given transaction
using the load information received from each server. using the load information received from each server.
------S1 ------S1
/ /
C C
\ \
------S2 ------S2
Figure 6: Basic Client Server Scenario Figure 6: Basic Client Server Scenario
If a node supports dynamic discovery, it will not obtain load If a node supports dynamic discovery, it will not obtain load
information from the nodes with which it has no Diameter information from the nodes with which it has no Diameter
connection established. Nevertheless it might take into account connection established. Nevertheless, it might take into account
the load information from the other nodes to decide to add the load information from the other nodes to decide to add
connections to new nodes with the dynamic discovery mechanism. connections to new nodes with the dynamic discovery mechanism.
Note: The use of dynamic connections needs to be considered. Note: The use of dynamic connections needs to be considered.
A.2. Single Agent A.2. Single Agent
Figure 7 shows a client that sends requests to an agent. The agent Figure 7 shows a client that sends requests to an agent. The agent
selects the request destination from a set of candidate servers, selects the request destination from a set of candidate servers,
using load information received from each server. The client does using load information received from each server. The client does
not need to receive load information, since it does not select not need to receive load information since it does not select between
between multiple agents. multiple agents.
------S1 ------S1
/ /
C----A C----A
\ \
------S2 ------S2
Figure 7: Simple Agent Scenario Figure 7: Simple Agent Scenario
A.3. Multiple Agents A.3. Multiple Agents
Figure 8 shows a client selecting between multiple agents, and each Figure 8 shows a client selecting between multiple agents and each
agent selecting from multiple servers. The client selects an agent agent selecting from multiple servers. The client selects an agent
based on the load information received from each agent. Each agent based on the load information received from each agent. Each agent
selects a server based on the load information received from its selects a server based on the load information received from its
servers. servers.
This scenario adds a complication that one set of servers may be more 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 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 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 might require C to receive load information from the servers as well
as the agents. Alternatively, each agent might use the load of its as the agents. Alternatively, each agent might use the load of its
skipping to change at page 19, line 8 skipping to change at page 19, line 45
\ \
---A2------S2 ---A2------S2
\ \
---- S4 ---- S4
Figure 8: Multiple Agents and Servers Figure 8: Multiple Agents and Servers
A.4. Linked Agents A.4. Linked Agents
Figure 9 shows a scenario similar to that of Figure 8, except that 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 the agents are linked so that A1 can forward a request to A2, and
vice-versa. Each agent could receive load information from the vice-versa. Each agent could receive load information from the
linked agent, as well as its connected servers. linked agent as well as its connected servers.
This somewhat simplifies the complication from Figure 8, due to the This somewhat simplifies the complication from Figure 8 due to the
fact that C does not necessarily need to choose a particular agent to fact that C does not necessarily need to choose a particular agent to
reach a particular server. But it creates a similar question of how, reach a particular server. But, it creates a similar question of
for example, A1 might know that S4 was less loaded than S1 or S3. how, for example, A1 might know that S4 was less loaded than S1 or
Additionally, it creates the opportunity for sub-optimal request S3. Additionally, it creates the opportunity for sub-optimal request
paths. For example [C,A1,A2,S4] vs. [C,A2,S4]. paths. For example, [C,A1,A2,S4] vs. [C,A2,S4].
A likely application for linked agents is when each agent prefers to A likely application for linked agents is when each agent prefers to
route only to directly connected servers and only forwards requests route only to directly connected servers and only forwards requests
to another agent under exceptional circumstances. For example, A1 to another agent under exceptional circumstances. For example, A1
might not forward requests to A2 unless both S1 and S3 are might not forward requests to A2 unless both S1 and S3 are
overloaded. In this case, A1 might use the load information from S1 overloaded. In this case, A1 might use the load information from S1
and S3 to select between those, and only consider the load and S3 to select between those, and only consider the load
information from A2 (and other connected agents) if it needs to information from A2 (and other connected agents) if it needs to
divert requests to different agents. divert requests to different agents.
skipping to change at page 19, line 41 skipping to change at page 20, line 30
/ | / |
C | C |
\ | \ |
---A2------S2 ---A2------S2
\ \
---- S4 ---- S4
Figure 9: Linked Agents Figure 9: Linked Agents
Figure 10 is a variant of Figure 9. In this case, C1 sends all 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, 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 A1 will load-balance traffic between S1 and S3, and A2 will load-
balance traffic between S2 and S4. balance traffic between S2 and S4.
Now, if S1 S3 are significantly more loaded than S2 S4, A1 may route Now, if S1 and S3 are significantly more loaded than S2 and S4, A1
some C1 traffic to A2. This is non optimal path but allows a better may route some C1 traffic to A2. This is a non-optimal path, but it
load balancing between the servers. To achieve this, A1 needs to allows better load balancing between the servers. To achieve this,
receive some load info from A2 about S2/S4 load. A1 needs to receive some load info from A2 about the S2/S4 load.
-----S3 -----S3
/ /
C1----A1------S1 C1----A1------S1
| |
| |
| |
C2----A2------S2 C2----A2------S2
\ \
---- S4 ---- S4
Figure 10: Linked Agents Figure 10: Linked Agents
A.5. Shared Server Pools A.5. Shared Server Pools
Figure 11 is similar to Figure 9, except that instead of a link 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 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. 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 The links are not shown separately due to the limitations of ASCII
art.) art.).
In this scenario, each agent can select among all of the servers, In this scenario, each agent can select among all of the servers
based on the load information from the servers. The client need only based on the load information from the servers. The client need only
be concerned with the load information of the agents. be concerned with the load information of the agents.
---A1---S[1], S[2]...S[p] ---A1---S[1], S[2]...S[p]
/ \ / / \ /
C x C x
\ / \ \ / \
---A2---S[p+1], S[p+2] ...S[n] ---A2---S[p+1], S[p+2] ...S[n]
Figure 11: Shared Server Pools Figure 11: Shared Server Pools
A.6. Agent Chains A.6. Agent Chains
The scenario in Figure 12 is similar to that of Figure 8, except The scenario in Figure 12 is similar to that of Figure 8, except that
that, instead of the client possibly needing to select an agent that instead of the client possibly needing to select an agent that can
can route requests to the least loaded server, in this case A1 and A2 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 need to make similar decisions when selecting between A3 or A4. As
the former scenario, this could be mitigated if A3 and A4 aggregate the former scenario, this could be mitigated if A3 and A4 aggregate
upstream loads into the load information they report downstream. upstream loads into the load information they report downstream.
---A1---A3----S[1], S[2]...S[p] ---A1---A3----S[1], S[2]...S[p]
/ | \ / / | \ /
C | x C | x
\ | / \ \ | / \
---A2---A4----S[p+1], S[p+2] ...S[n] ---A2---A4----S[p+1], S[p+2] ...S[n]
Figure 12: Agent Chains Figure 12: Agent Chains
A.7. Fully Meshed Layers A.7. Fully-Meshed Layers
Figure 13 extends the scenario in Figure 11 by adding an extra layer 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 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 next layer, each node only needs to consider the load of its next-hop
peer. peer.
---A1---A3---S[1], S[2]...S[p] ---A1---A3---S[1], S[2]...S[p]
/ | \ / |\ / / | \ / |\ /
C | x | x C | x | x
\ | / \ |/ \ \ | / \ |/ \
skipping to change at page 21, line 36 skipping to change at page 22, line 28
Figure 13: Full Mesh Figure 13: Full Mesh
A.8. Partitions A.8. Partitions
A Diameter network with multiple servers is said to be "partitioned" A Diameter network with multiple servers is said to be "partitioned"
when only a subset of available servers can serve a particular realm- when only a subset of available servers can serve a particular realm-
routed request. For example, one group of servers may handle users routed request. For example, one group of servers may handle users
whose names start with "A" through "M", and another group may handle whose names start with "A" through "M", and another group may handle
"N" through "Z". "N" through "Z".
In such a partitioned network, nodes cannot load-balance requests In such a partitioned network, nodes cannot load balance requests
across partitions, since not all servers can handle the request. A across partitions since not all servers can handle the request. A
client, or an intermediate agent, may still be able to load-balance client, or an intermediate agent, may still be able to load balance
between servers inside a partition. between servers inside a partition.
A.9. Active-Standby Nodes A.9. Active-Standby Nodes
The previous scenarios assume that traffic can be load balanced among The previous scenarios assume that traffic can be load balanced among
all peers that are eligible to handle a request. That is, the peers all peers that are eligible to handle a request. That is, the peers
operate in an "active-active" configuration. In an "active-standby" operate in an "active-active" configuration. In an "active-standby"
configuration, traffic would be load-balanced among active peers. configuration, traffic would be load balanced among active peers.
Requests would only be sent to peers in a "standby" state if the Requests would only be sent to peers in a "standby" state if the
active peers became unavailable. For example, requests might be active peers became unavailable. For example, requests might be
diverted to a stand-by peer if one or more active peers becomes diverted to a stand-by peer if one or more active peers becomes
overloaded. overloaded.
Authors' Addresses Authors' Addresses
Ben Campbell Ben Campbell
Oracle Oracle
7460 Warren Parkway # 300 7460 Warren Parkway, Suite 300
Frisco, Texas 75034 Frisco, Texas 75034
USA United States of America
Email: ben@nostrum.com Email: ben@nostrum.com
Steve Donovan (editor) Steve Donovan (editor)
Oracle Oracle
7460 Warren Parkway # 300 7460 Warren Parkway # 300
Frisco, Texas 75034 Frisco, Texas 75034
United States United States of America
Email: srdonovan@usdonovans.com Email: srdonovan@usdonovans.com
Jean-Jacques Trottin Jean-Jacques Trottin
Nokia Nokia
Route de Villejust Route de Villejust
91620 Nozay 91620 Nozay
France France
Email: jean-jacques.trottin@nokia.com Email: jean-jacques.trottin@nokia.com
 End of changes. 158 change blocks. 
325 lines changed or deleted 309 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/