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
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.
RFC 7068描述了直径过载控制的要求。这包括允许Diameter节点发送“负载”信息的要求，即使节点没有过载。RFC 7683（直径过载信息传输（DOIC））中定义的基本解决方案描述了满足大多数要求的机制，但目前不包括发送负载信息的能力。本文件定义了传递直径载荷信息的机制。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8583.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
[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.
[RFC7068]描述了直径过载控制的要求[RFC6733]。DIME工作组已完成直径过载信息传输（DOIC）机制[RFC7683]。按照目前的规定，内政部满足一些但不是全部的要求。
In particular, DOIC does not fulfill Req 23 and Req 24:
特别是，DOIC不满足要求23和要求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 23：解决方案必须提供足够的信息，以使负载平衡节点能够将被过载的上游节点拒绝或以其他方式限制的消息转移到最有可能有足够能力处理它们的其他上游节点。
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.
REQ 24：解决方案必须提供指示负载水平的机制，即使在不处于过载状态时，也可以帮助节点做出决策，以防止过载情况发生。
There are several other requirements in [RFC7068] that mention both overload and load information that are only partially fulfilled by DOIC.
[RFC7068]中还有几个其他要求提到了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.
DIME工作组在发布DOIC[RFC7683]时明确选择不满足这些要求，原因有几个。一个主要原因是，工作组没有就传递负荷信息的一般方法达成一致意见。它选择将DOIC的其余部分进行升级，并将加载信息传输延迟到DOIC扩展或单独的机制。
This document defines a mechanism that addresses the load-related requirements from RFC 7068.
本文件定义了一种机制，用于满足RFC 7068中与负载相关的要求。
AVP Attribute-Value Pair
属性值对
DOIC Diameter Overload Information Conveyance [RFC7683]
DOIC直径过载信息传输[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.
加载Diameter节点的Diameter消息处理能力的相对使用情况。低负载级别表示Diameter节点未充分利用。高负载级别表示节点已接近充分利用。
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.
报告节点在Diameter应答消息中发送DOIC重载报告的DOIC节点。
Reacting Node A DOIC node that receives and acts on a DOIC Overload report.
反应节点接收DOIC重载报告并对其执行操作的DOIC节点。
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.
路由信息本文档中提到的路由信息可以包括RFC 6733中定义的路由和对等表。它还可以包括用于存储负载信息的其他特定于实现的表。本文件未定义此类表格的结构。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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".
先前关于如何解决[RFC7068]中与负载相关的要求的讨论表明，人们对“负载”信息与“过载”信息的区别没有一致的概念。虽然这两个概念高度相关，但有两个主要区别。首先，直径节点始终具有载荷。在任何给定的时间，该载荷可能是有效的零载荷、有效的满载载荷或介于两者之间的某个位置。相反，过载是一种例外情况。节点只有在处于重载状态时才具有重载信息。此外，节点的负载水平和任何给定时间的过载状态之间的关系可能是模糊的。例如，节点通常可以在“满载”级别运行，但仍不被视为过载。另一个节点可能会声明自己“过载”，即使它可能没有完全“加载”。
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
第二，以DOIC过载报告（OLR）[RFC7683]的形式出现的过载信息表示响应节点的明确动作请求；OLR请求作出反应的节点减少提供的负载，即发送到报告节点的实际流量
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.
根据指定的数量（默认情况下）或所选缓解算法的规定，做出过载缓解和路由决策。实际上，DOIC在报告节点和反应节点之间提供了一个契约。
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.
所有这些都不会阻止Diameter节点根据负载信息决定减少提供的负载。基本区别在于，过载报告要求减少提供的负载。直径节点根据负载信息决定增加提供的负载也是合理的。
[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.
[RFC7068]考虑了负载信息的两种主要用途。Req 23讨论了在[RFC7683]中所述的将改道作为过载缓解技术时，如何使用负载信息。当反应节点从过载节点转移流量时，它需要该流量的其他候选节点的负载信息，以便在潜在候选节点之间有效地负载平衡转移的负载。否则，转移将有更大的可能导致其他节点过载。
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.
Req 24讨论了当前不存在过载情况时如何使用直径负载信息。Diameter节点可以使用负载信息来做出决策，以便首先尝试避免过载情况。正常的负载平衡属于这一类，但是Diameter节点也可以采取其他主动步骤。
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.
如果加载的节点是Diameter服务器（或在服务器到客户端事务的情况下是客户端），则这两种负载信息的使用都应由执行服务器选择的Diameter节点完成（选择要将请求路由到其进行处理的Diameter端点）。通常，服务器选择由作为服务器直接对等方的节点（客户端或代理）执行。但是，在某些情况下（参见附录A），与所选服务器不直接对等的客户端或代理会执行服务器选择。在这种情况下，客户端或代理通过插入目标主机AVP来强制执行服务器选择。
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.
例如，Diameter节点（例如，客户端）可以使用重定向代理来获取候选目标主机地址。重定向代理可能返回多个目标主机地址，Diameter节点从中选择一个。Diameter节点可以使用从这些主机接收的负载信息进行选择。
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.
应注意，Diameter节点需要处理来自同一Diameter节点的负载报告和过载报告。重载报告的响应节点始终负责减少发送到重载节点的Diameter通信量。反应节点是否或如何使用负载信息来实现这一点，留给实现决策。
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.
此处定义的用于传输负载信息的机制在某些方面与为DOIC定义的机制相似，但在其他方面不同。
As with DOIC, load information is conveyed by piggybacking the Load AVPs on existing Diameter applications.
与DOIC一样，负载信息通过在现有直径应用程序上搭载负载AVP来传输。
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.
DOIC和Load之间的第二大区别是Diameter网络中DOIC或Load信息的可见性。DOIC信息是端到端发送的，这导致应答消息路径中的所有节点都能够对信息进行操作，尽管只有一个节点实际使用并对报告作出反应。DOIC重载报告始终保留在消息中，从报告节点到应答消息的目标节点。
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
第一种类型的负载报告是主机负载报告，其中包含发送应答消息的端点的负载。此负载报告端到端地传输，以使做出服务器选择决策的任何节点都能够将发送端点的负载状态用作
part of the server selection decision. Unlike with DOIC, more than one node may make use of the load information received.
服务器选择决策的一部分。与DOIC不同，多个节点可以使用接收到的负载信息。
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.
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.translate error, please retry
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.
由于负载报告可以遍历不支持负载机制的Diameter节点，因此有必要将负载报告应用到的节点的标识作为负载报告的一部分。这允许Diameter节点验证负载报告是否应用于其对等节点或是否应忽略它。
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].
负载报告包括指示发送节点的相对负载的值，该值以与为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].
目标是使使用作为直径加载机制一部分接收的加载值和作为DNS SRV查询结果接收的重量值成为可能。因此，直径载荷值的范围为0-65535。然后，将该值和DNS SRV权重值用于类似于[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.
DNS SRV分发算法会导致向具有更高权重值的节点发送更多消息。因此，较高的直径负载值表示发送节点上的负载较低。负载较重的节点发送较低的直径负载值。换句话说，零负载节点的负载值为65535。100%加载的节点的加载值为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].
支持直径加载机制的直径节点使用的分布算法是一个实现决策，但它需要产生与[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.
发送负载报告的频率也由实现决定。发送节点可以选择在所有消息中发送负载报告，也可以选择仅在负载值更改了某个特定于实现的量时发送负载报告。重要的考虑是，需要负载信息的所有节点都有足够准确的节点负载视图。
This section outlines how the Diameter Load mechanism is expected to work.
本节概述了直径加载机制的预期工作方式。
For this discussion, assume the following Diameter network configuration:
对于本讨论，假设以下Diameter网络配置：
---A1---A3----S[1], S[2]...S[p]
/ | \ /
C | x
\ | / \
---A2---A4----S[p+1], S[p+2] ...S[n]
---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
图1：直径网络示例
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.
注意，在该图中，S[1]和S[2]到S[p]是A3的对等点。S[p+1]和S[p+2]到S[n]是A4的对等点。
Also assume that the request for a Diameter transaction takes the following path:
还假设Diameter事务的请求采用以下路径：
C A1 A4 S[n]
| | | |
|----->|----->|----->|
xxR xxR xxR
C A1 A4 S[n]
| | | |
|----->|----->|----->|
xxR xxR xxR
Figure 2: Request Message Path
图2：请求消息路径
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.
发送应答消息时，支持Diameter加载机制的端点节点在应答消息中包含自己的加载信息。因为它是一个Diameter端点，所以它包含一个主机负载报告。
C A1 A4 S[n]
| | | |
| | |<-----|
| | xxA(Load type:HOST, source:S[n])
| | | |
C A1 A4 S[n]
| | | |
| | |<-----|
| | xxA(Load type:HOST, source:S[n])
| | | |
Figure 3: Answer Message from S[n]
图3：来自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
如果代理A4支持加载机制，那么A4的操作取决于A4是否负责进行服务器选择。如果A4未进行服务器选择，则A4将忽略主机加载报告。如果A4负责选择服务器，那么它将存储负载
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.
用于处理后续请求消息的路由信息中的S[n]信息。在这两种情况下，A4都会在消息中保留主机负载报告。
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不支持加载机制，则它将中继应答消息，而不对加载信息进行任何处理。在这种情况下，负载信息AVPs将在不改变的情况下进行中继。
A4 then calculates its own load information and inserts load information AVPs of type "PEER" in the message before sending the message to A1.
A4然后计算自己的负载信息，并在将消息发送到A1之前在消息中插入类型为“PEER”的负载信息AVP。
C A1 A4 S[n]
| | | |
| |<-----| |
| xxA(Load type:PEER, source:A4)
| xxA(Load type:HOST, source:S[n])
| | | |
C A1 A4 S[n]
| | | |
| |<-----| |
| xxA(Load type:PEER, source:A4)
| xxA(Load type:HOST, source:S[n])
| | | |
Figure 4: Answer Message from A4
图4：来自A4的应答消息
If A1 supports the Load mechanism, then it processes each of the load reports it receives separately.
如果A1支持加载机制，那么它将分别处理收到的每个加载报告。
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.
对于对等负载报告，A1首先确定负载报告中指示的报告源是否与接收请求的直径节点的直径匹配。如果标识不匹配，则丢弃对等加载报告。如果标识匹配，则A1将负载信息保存在其路由信息中，以用于后续请求消息的路由。在这两种情况下，A1都会从消息中剥离对等负载报告。
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.
对于主机负载报告，A1的操作取决于A1是否负责进行服务器选择。如果A1不进行服务器选择，则A1将忽略主机负载报告。如果A1负责进行服务器选择，则它将S[n]的负载信息存储在其路由信息中，以便处理后续请求消息。在这两种情况下，A1都会在消息中保留主机负载报告。
A1 then calculates its own load information and inserts load information AVPs of type "PEER" in the message before sending the message to C:
A1然后计算其自身的负载信息，并在将消息发送到C之前，在消息中插入类型为“PEER”的负载信息AVP：
C A1 A4 S[n]
| | | |
|<-----| | |
xxA(Load type:PEER, source:A1)
xxA(Load type:HOST, source:S[n])
C A1 A4 S[n]
| | | |
|<-----| | |
xxA(Load type:PEER, source:A1)
xxA(Load type:HOST, source:S[n])
Figure 5: Answer Message from A1
图5：来自A1的应答消息
As with A1, C processes each load report separately.
与A1一样，C单独处理每个负载报告。
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.
对于对等负载报告，C遵循与A1相同的过程来确定负载报告是否从发送报告的对等方接收。当发现它确实存在时，C存储负载信息，以便在将来做出路由决策时使用。
For the host-load report, C saves the load information only if it is responsible for doing server selection.
对于主机负载报告，C仅在负责选择服务器时才保存负载信息。
The load information received by all nodes is then used for routing of subsequent request messages.
然后，所有节点接收的负载信息用于后续请求消息的路由。
This section defines the normative behaviors for the Load mechanism.
本节定义了加载机制的规范行为。
This section defines the procedures of Diameter reporting nodes that generate load reports.
本节定义生成负载报告的直径报告节点的过程。
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.
支持Diameter加载机制的Diameter端点必须在足够的应答消息中包含类型为“HOST”的加载报告，以确保加载信息的所有使用者都能及时收到更新。
The Diameter endpoint MUST include its own DiameterIdentity in the SourceID AVP included in the Load AVP.
直径端点必须在加载AVP中包含的SourceID AVP中包含其自身的直径。
The Diameter endpoint MUST include a Load-Type AVP of type "HOST" in the Load AVP.
直径端点必须包括加载AVP中“主机”类型的加载类型AVP。
The Diameter endpoint MUST include its Load value in the Load-Value AVP in the Load AVP.
直径端点必须在载荷AVP中的载荷值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.
例如，如果负载报告的唯一使用者是端点的对等方，那么当端点的负载发生了有意义的百分比变化时，端点可以选择仅包含负载报告。如果端点负载报告的使用者不是端点的对等者（如果其他节点负责服务器选择，则会出现这种情况），则端点可能会选择在所有应答消息中包含负载报告，以确保所有进行服务器选择的节点都获得准确的负载信息。
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.
支持Diameter加载机制的Diameter代理必须在足够的应答消息中包含对等加载报告，以确保加载信息的所有用户都能及时收到更新。
The Diameter Agent MUST include its own DiameterIdentity in the SourceID AVP included in the Load AVP.
直径代理必须在加载AVP中包含的SourceID AVP中包含其自身的直径。
The Diameter Agent MUST include a Load-Type AVP of type "PEER" in the Load AVP.
直径代理必须在加载AVP中包含“对等”类型的加载类型AVP。
The Diameter Agent MUST include its Load value in the Load-Value AVP in the Load AVP.
直径代理必须将其荷载值包含在荷载AVP中的荷载值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.
发送负载报告的频率是一个实现决策。
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.
注意：对于类型为“对等”的负载报告，只有当负载值改变了某个有意义的值时，才需要包含负载报告，只要代理确保所有对等方都收到该报告。在Diameter代理处理的每个应答消息中包含负载报告也是可以接受的。
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.
支持Diameter加载机制的Diameter节点必须准备好处理类型为“主机”和类型为“对等”的加载报告，如在同一应答消息或从多个应答消息中接收的加载AVP中包含的加载类型AVP所示。
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".
如果Diameter节点不负责选择服务器，那么它应该忽略类型为“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.
如果Diameter节点负责进行服务器选择，那么它应该在其路由信息中保存“主机”类型的Load AVP中包含的Load value AVP中包含的Load value AVP中包含的Load value。
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.
如果Diameter节点接收到类型为“PEER”的负载报告，则Diameter节点必须确定负载报告是否由接收消息的对等方插入应答消息中。这是通过比较与接收消息的连接相关联的直径与加载报告中SourceID AVP中包含的直径来实现的。
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.
如果Diameter节点确定没有从发送或转发应答消息的对等方接收到类型为“PEER”的负载报告，则该节点必须忽略负载报告。
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.
如果Diameter节点确定从发送或转发应答消息的对等方接收到类型为“PEER”的负载报告，则该节点应将负载信息保存在其路由信息中。
In all cases, a Diameter Agent MUST strip all load reports of type "PEER" received in answer messages.
在所有情况下，Diameter代理必须删除应答消息中收到的所有“对等”类型的负载报告。
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.
注意：这确保在Diameter代理发送的任何应答消息中，都会有一个类型为“对等”的负载报告，例如发送消息的Diameter节点的负载报告。
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].
Diameter节点如何使用负载信息进行路由决策是一个实现决策。但是，分配算法必须产生与[RFC2782]中描述的使用权重值的算法类似的行为。
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.
任何扩展都可以定义新的AVP以用于负载报告。这些新的AVP应定义为本文件中定义的Load AVP的扩展。
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.
[RFC6733]定义的分组AVP扩展机制适用。例如，这允许定义一个新特性，即使是在现有应用程序上也必须理解该特性。
As with any Diameter specification, [RFC6733] requires all new AVPs to be registered with IANA. See Section 9 for the required procedures.
与任何直径规格一样，[RFC6733]要求所有新的AVP在IANA注册。所需程序见第9节。
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.
当以受控方式移除节点时（例如，出于维护目的，因此在故障情况之外），可能适合通过将流量路由到其他节点来逐渐减少到该节点的流量。简单的负载信息（负载百分比）是不够的。处理节点移除的方法是特定于实现的，但是它可以依赖于从要移除的节点接收的负载信息的演变。
The section defines the AVPs required for the Load mechanism.
本节定义了加载机制所需的AVP。
The Load AVP (AVP code 650) is of type Grouped and is used to convey load information between Diameter nodes.
载荷AVP（AVP代码650）属于分组类型，用于在直径节点之间传送载荷信息。
Load ::= < AVP Header: 650 >
[ Load-Type ]
[ Load-Value ]
[ SourceID ]
* [ AVP ]
Load ::= < AVP Header: 650 >
[ Load-Type ]
[ Load-Value ]
[ SourceID ]
* [ 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:
负载类型AVP（AVP代码651）为枚举类型。它用于传递发送荷载信息的直径节点的类型。定义了以下值：
HOST 0 The load report is for a host.
主机0加载报告是针对主机的。
PEER 1 The load report is for a peer.
PEER 1负载报告是针对一个PEER的。
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.
加载值AVP（AVP代码652）的类型为Unsigned64。它用于传递有关负载报告发送者的相对负载信息。
The Load-Value AVP is specified in a manner similar to the weight value in DNS SRV ([RFC2782]).
以与DNS SRV（[RFC2782]）中的权重值类似的方式指定负载值AVP。
The Load value has a range of 0-65535.
负载值的范围为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.
换句话说，零负载节点的负载值为65535。100%加载的节点的加载值为0。
The SourceID AVP is defined in [RFC8581]. It is used to identify the Diameter node that sent the load report.
SourceID AVP在[RFC8581]中定义。它用于标识发送负载报告的直径节点。
+---------+
|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 |
+--------------------------------------------------------+----+----+
+---------+
|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.
如Diameter base protocol[RFC6733]中所述，给定命令中给定AVP的M位使用可由应用程序定义。
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.
在某些情况下，负载信息可能是敏感信息。根据不同的机制，未经授权的收件人可能能够从负载信息推断Diameter网络的拓扑结构。负载信息可能有助于识别拒绝服务（DoS）攻击的目标，其中已知负载已很重的节点可能是一个诱人的目标。负载信息还可以作为正在进行的DoS攻击成功的反馈。
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.
考虑到路由决策受到负载信息的影响，错误或恶意负载报告可能会对Diameter网络造成负面影响。这包括Diameter代理恶意更改负载值。
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.
任何负载信息传输机制都需要允许操作员避免向无权接收负载信息的节点发送负载信息。由于Diameter目前仅在传输级别提供节点身份验证，不支持端到端安全机制，因此任何向非对等节点发送负载信息的解决方案都需要一个可传递的信任模型。
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.
IANA在“认证、授权和记帐（AAA）参数”注册表中注册了三个新的AVP代码；见第7.1、7.2和7.3节。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<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>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基准协议”，RFC 6733，DOI 10.17487/RFC6733，2012年10月<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>.
[RFC7683]Korhonen，J.，Ed.，Donovan，S.，Ed.，Campbell，B.，和L.Morand，“直径过载指示运输”，RFC 7683，DOI 10.17487/RFC7683，2015年10月<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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<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>.
[RFC8581]Donovan，S.，“直径代理超载和对等超载报告”，RFC 8581，DOI 10.17487/RFC8581，2019年8月<https://www.rfc-editor.org/info/rfc8581>.
[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>.
[RFC7068]McMurry，E.和B.Campbell，“直径过载控制要求”，RFC 7068，DOI 10.17487/RFC7068，2013年11月<https://www.rfc-editor.org/info/rfc7068>.
This section presents a number of Diameter topology scenarios and discusses how load information might be used in each scenario.
本节介绍了许多Diameter拓扑方案，并讨论了在每个方案中如何使用负载信息。
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.
图6显示了一个简单的客户机-服务器场景，其中客户机从一组可用于特定领域和应用程序的候选服务器中进行选择。客户端使用从每个服务器接收的负载信息为给定事务选择服务器。
------S1
/
C
\
------S2
------S1
/
C
\
------S2
Figure 6: Basic Client Server Scenario
图6：基本客户机-服务器场景
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.
如果节点支持动态发现，则不会从未建立Diameter连接的节点获取负载信息。然而，它可能会考虑来自其他节点的负载信息，以决定使用动态发现机制向新节点添加连接。
Note: The use of dynamic connections needs to be considered.
注：需要考虑使用动态连接。
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.
图7显示了向代理发送请求的客户端。代理使用从每个服务器接收的负载信息从一组候选服务器中选择请求目标。客户端不需要接收负载信息，因为它不在多个代理之间进行选择。
------S1
/
C----A
\
------S2
------S1
/
C----A
\
------S2
Figure 7: Simple Agent Scenario
图7：简单代理场景
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.
图8显示了一个客户机在多个代理之间进行选择，每个代理从多个服务器中进行选择。客户端根据从每个代理接收的负载信息选择代理。每个代理根据从其服务器接收的负载信息选择服务器。
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.
此场景增加了一个复杂性，即一组服务器可能比另一组服务器负载更多。例如，如果S4是负载最少的服务器，则C需要知道如何选择代理A2以到达S4。这可能需要C从服务器和代理接收负载信息。或者，每个代理可以使用其服务器的负载作为计算其自身负载的输入，实际上是聚合上游负载。
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.
类似地，如果C发送主机路由请求[RFC7683]，它需要知道哪个代理可以向所选服务器发送请求。如果没有某些特殊的、潜在的专有知识，对A1和A2上游拓扑结构的知识，C将基于该领域和应用程序的正常对等选择过程来选择代理，并且可能考虑来自A1和A2的负载信息。如果C向A1发送包含目标主机AVP且值为S4的请求，A1将无法发送该请求。
-----S3
/
---A1------S1
/
C
\
---A2------S2
\
---- S4
-----S3
/
---A1------S1
/
C
\
---A2------S2
\
---- S4
Figure 8: Multiple Agents and Servers
图8：多个代理和服务器
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.
图9显示了一个类似于图8的场景，不同之处在于代理被链接，以便A1可以将请求转发给A2，反之亦然。每个代理都可以从链接的代理及其连接的服务器接收负载信息。
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
这在某种程度上简化了图8的复杂性，因为C不一定需要选择特定的代理来访问特定的服务器。但是，这也产生了一个类似的问题
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].
例如，A1如何知道S4的负载小于S1或S3。此外，它还为次优请求路径创造了机会。例如，[C，A1，A2，S4]对[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.
链接代理的一个可能应用是，每个代理只希望路由到直接连接的服务器，并且在特殊情况下只将请求转发给另一个代理。例如，A1可能不会将请求转发到A2，除非S1和S3都过载。在这种情况下，A1可以使用来自S1和S3的负载信息来在这些之间进行选择，并且仅考虑A2（和其他连接的代理）的负载信息，如果它需要向不同的代理转移请求。
-----S3
/
---A1------S1
/ |
C |
\ |
---A2------S2
\
---- S4
-----S3
/
---A1------S1
/ |
C |
\ |
---A2------S2
\
---- S4
Figure 9: Linked Agents
图9：链接代理
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.
图10是图9的变体。在这种情况下，C1通过A1发送所有通信量，C2通过A2发送所有通信量。默认情况下，A1将负载平衡S1和S3之间的流量，A2将负载平衡S2和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.
现在，如果S1和S3的负载明显大于S2和S4，A1可能会将一些C1流量路由到A2。这是一条非最佳路径，但它允许在服务器之间实现更好的负载平衡。为此，A1需要从A2接收有关S2/S4负载的一些负载信息。
-----S3
/
C1----A1------S1
|
|
|
C2----A2------S2
\
---- S4
-----S3
/
C1----A1------S1
|
|
|
C2----A2------S2
\
---- S4
Figure 10: Linked Agents
图10：链接代理
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.).
图11与图9类似，不同的是，每个代理都链接到所有服务器，而不是代理之间的链接（指向每组服务器的链接应解释为指向每个服务器的链接。由于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]
---A1---S[1], S[2]...S[p]
/ \ /
C x
\ / \
---A2---S[p+1], S[p+2] ...S[n]
Figure 11: Shared Server Pools
图11：共享服务器池
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.
图12中的场景与图8中的场景类似，除了客户端可能需要选择一个可以将请求路由到负载最少的服务器的代理之外，在这种情况下，A1和A2在选择A3或A4时需要做出类似的决定。与前一种情况一样，如果A3和A4将上游负载聚合到下游报告的负载信息中，则可以缓解这种情况。
---A1---A3----S[1], S[2]...S[p]
/ | \ /
C | x
\ | / \
---A2---A4----S[p+1], S[p+2] ...S[n]
---A1---A3----S[1], S[2]...S[p]
/ | \ /
C | x
\ | / \
---A2---A4----S[p+1], S[p+2] ...S[n]
Figure 12: Agent Chains
图12：代理链
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.
图13通过添加额外的代理层扩展了图11中的场景。但是，由于每个节点层可以到达下一层中的任何节点，所以每个节点只需要考虑其下一跳对等节点的负载。
---A1---A3---S[1], S[2]...S[p]
/ | \ / |\ /
C | x | x
\ | / \ |/ \
---A2---A4---S[p+1], S[p+2] ...S[n]
---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
图13：全网格
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".
当只有可用服务器的子集可以服务于特定领域路由请求时，具有多个服务器的Diameter网络被称为“分区”。例如，一组服务器可以处理名称以“A”到“M”开头的用户，另一组可以处理“N”到“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.
在这种分区网络中，节点无法跨分区负载平衡请求，因为并非所有服务器都可以处理该请求。客户端或中间代理可能仍然能够在分区内的服务器之间实现负载平衡。
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.
前面的场景假设流量可以在有资格处理请求的所有对等方之间进行负载平衡。也就是说，对等点在“主动-主动”配置中运行。在“主动-备用”配置中，流量将在活动对等方之间进行负载平衡。只有在活动对等点不可用时，才会将请求发送到处于“待机”状态的对等点。例如，如果一个或多个活动对等点过载，请求可能会转移到备用对等点。
Authors' Addresses
作者地址
Ben Campbell Oracle 7460 Warren Parkway, Suite 300 Frisco, Texas 75034 United States of America
本坎贝尔甲骨文7460沃伦大道，300室弗里斯科，德克萨斯州75034美利坚合众国
Email: ben@nostrum.com
Email: ben@nostrum.com
Steve Donovan (editor) Oracle 7460 Warren Parkway # 300 Frisco, Texas 75034 United States of America
Steve Donovan（编辑）Oracle 7460 Warren Parkway#300 Frisco，德克萨斯州75034美利坚合众国
Email: srdonovan@usdonovans.com
Email: srdonovan@usdonovans.com
Jean-Jacques Trottin Nokia Route de Villejust 91620 Nozay France
Jean-Jacques Trottin诺基亚Villejust路线91620法国诺扎伊
Email: jean-jacques.trottin@nokia.com
Email: jean-jacques.trottin@nokia.com