Internet Engineering Task Force (IETF) S. Donovan
Request for Comments: 8581 Oracle
Updates: 7683 August 2019
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Donovan
Request for Comments: 8581 Oracle
Updates: 7683 August 2019
Category: Standards Track
ISSN: 2070-1721
Diameter Agent Overload and the Peer Overload Report
Diameter代理重载和对等重载报告
Abstract
摘要
This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC), a base solution for Diameter overload defined in RFC 7683. The extension defines the Peer Overload report type. The initial use case for the peer report is the handling of occurrences of overload of a Diameter Agent.
本规范记录了直径过载指示传输（DOIC）的扩展，该传输是RFC 7683中定义的直径过载基本解决方案。扩展定义了对等重载报告类型。对等报告的初始用例是处理Diameter代理过载的事件。
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/rfc8581.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8581.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
4. Peer-Report Use Cases . . . . . . . . . . . . . . . . . . . . 5
4.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 5
4.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6
4.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7
4.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 8
4.2.1. Hop-by-Hop Abatement Algorithms . . . . . . . . . . . 8
5. Interaction Between Host/Realm and Peer Overload Reports . . 9
6. Peer-Report Behavior . . . . . . . . . . . . . . . . . . . . 9
6.1. Capability Announcement . . . . . . . . . . . . . . . . . 9
6.1.1. Reacting-Node Behavior . . . . . . . . . . . . . . . 9
6.1.2. Reporting-Node Behavior . . . . . . . . . . . . . . . 9
6.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10
6.2.1. Overload Control State . . . . . . . . . . . . . . . 10
6.2.2. Reporting-Node Maintenance of Peer-Report OCS . . . . 11
6.2.3. Reacting-Node Maintenance of Peer-Report OCS . . . . 12
6.2.4. Peer-Report Reporting-Node Behavior . . . . . . . . . 13
6.2.5. Peer-Report Reacting-Node Behavior . . . . . . . . . 13
7. Peer-Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14
7.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14
7.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 15
7.1.2. OC-Peer-Algo AVP . . . . . . . . . . . . . . . . . . 15
7.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15
7.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 16
7.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
4. Peer-Report Use Cases . . . . . . . . . . . . . . . . . . . . 5
4.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 5
4.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6
4.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7
4.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 8
4.2.1. Hop-by-Hop Abatement Algorithms . . . . . . . . . . . 8
5. Interaction Between Host/Realm and Peer Overload Reports . . 9
6. Peer-Report Behavior . . . . . . . . . . . . . . . . . . . . 9
6.1. Capability Announcement . . . . . . . . . . . . . . . . . 9
6.1.1. Reacting-Node Behavior . . . . . . . . . . . . . . . 9
6.1.2. Reporting-Node Behavior . . . . . . . . . . . . . . . 9
6.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10
6.2.1. Overload Control State . . . . . . . . . . . . . . . 10
6.2.2. Reporting-Node Maintenance of Peer-Report OCS . . . . 11
6.2.3. Reacting-Node Maintenance of Peer-Report OCS . . . . 12
6.2.4. Peer-Report Reporting-Node Behavior . . . . . . . . . 13
6.2.5. Peer-Report Reacting-Node Behavior . . . . . . . . . 13
7. Peer-Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14
7.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14
7.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 15
7.1.2. OC-Peer-Algo AVP . . . . . . . . . . . . . . . . . . 15
7.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15
7.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 16
7.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC), a base solution for Diameter overload [RFC7683]. The extension defines the Peer Overload report type. The initial use case for the peer report is the handling of occurrences of overload of a Diameter Agent.
本规范记录了直径过载指示传输（DOIC）的扩展，这是直径过载的基本解决方案[RFC7683]。扩展定义了对等重载报告类型。对等报告的初始用例是处理Diameter代理过载的事件。
This document defines the behavior of Diameter nodes when Diameter Agents enter an overload condition and send an Overload report requesting a reduction of traffic. It also defines a new Overload report type, the Peer Overload report type, which is used for handling agent overload conditions. The Peer Overload report type is defined in a generic fashion so that it can also be used for other Diameter overload scenarios.
本文档定义了Diameter代理进入过载状态并发送过载报告请求减少通信量时Diameter节点的行为。它还定义了一个新的重载报告类型，即对等重载报告类型，用于处理代理重载条件。对等重载报告类型是以通用方式定义的，因此它也可以用于其他直径重载场景。
The base Diameter overload specification [RFC7683] addresses the handling of overload when a Diameter endpoint (a Diameter Client or Diameter Server as defined in [RFC6733]) becomes overloaded.
基本直径过载规范[RFC7683]解决了当直径端点（如[RFC6733]中定义的直径客户端或直径服务器）过载时的过载处理。
In the base specification, the goal is to handle abatement of the overload occurrence as close to the source of the Diameter traffic as feasible. When possible, this is done at the originator of the traffic, generally referred to as a Diameter Client. A Diameter Agent might also handle the overload mitigation. For instance, a Diameter Agent might handle Diameter overload mitigation when it knows that a Diameter Client does not support the DOIC extension.
在基本规范中，目标是在尽可能接近直径交通源的情况下处理超载发生的减少。在可能的情况下，这是在流量的发起方完成的，通常称为Diameter客户端。直径代理也可以处理过载缓解。例如，当Diameter代理知道Diameter客户端不支持DOIC扩展时，它可能会处理Diameter过载缓解。
This document extends the base Diameter endpoint overload specification to address the case when Diameter Agents become overloaded. Just as is the case with other Diameter nodes, i.e., Diameter Clients and Diameter Servers, surges in Diameter traffic can cause a Diameter Agent to be asked to handle more Diameter traffic than it was configured to handle. For a more detailed discussion of what can cause the overload of Diameter nodes, refer to the Diameter overload requirements [RFC7068].
本文档扩展了基本直径端点重载规范，以解决直径代理重载的情况。与其他Diameter节点（即Diameter客户端和Diameter服务器）的情况一样，Diameter流量激增可能会导致Diameter代理处理的Diameter流量超过其配置处理的流量。有关导致直径节点过载的原因的更详细讨论，请参阅直径过载要求[RFC7068]。
This document defines a new Overload report type to communicate occurrences of agent overload. This report type works for the Diameter overload loss abatement algorithm defined in [RFC7683] and is expected to work for other overload abatement algorithms defined in extensions to the DOIC solution.
本文档定义了一种新的过载报告类型，用于传达代理过载的发生情况。此报告类型适用于[RFC7683]中定义的直径过载损失消除算法，预计也适用于DOIC解决方案扩展中定义的其他过载消除算法。
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]所述进行解释。
AVP
AVP
Attribute-Value Pair
属性值对
Diameter Node
直径节点
A Diameter Client, Diameter Server, or Diameter Agent [RFC6733]
Diameter客户端、Diameter服务器或Diameter代理[RFC6733]
Diameter Endpoint
直径端点
A Diameter Client or Diameter Server [RFC6733]
Diameter客户端或Diameter服务器[RFC6733]
Diameter Agent
直径剂
A Diameter node that provides relay, proxy, redirect, or translation services [RFC6733]
提供中继、代理、重定向或转换服务的Diameter节点[RFC6733]
Reporting Node
报告节点
A DOIC node that sends an Overload report in a Diameter answer message
在Diameter应答消息中发送重载报告的DOIC节点
Reacting Node
反应节点
A DOIC node that receives and acts on a DOIC Overload report
接收DOIC重载报告并对其执行操作的DOIC节点
DOIC Node
DOIC节点
A Diameter node that supports the DOIC solution defined in [RFC7683]
支持[RFC7683]中定义的DOIC解决方案的Diameter节点
This section outlines representative use cases for the peer report used to communicate agent overload.
本节概述了用于通信代理过载的对等报告的典型用例。
There are two primary classes of use cases currently identified: those involving the overload of agents, and those involving the overload of Diameter endpoints. In both cases, the goal is to use an overload algorithm that controls traffic sent towards peers.
目前确定的用例主要有两类：涉及代理过载的用例和涉及直径端点过载的用例。在这两种情况下，目标都是使用过载算法来控制发送到对等方的流量。
The peer report needs to support the use cases described below.
同行报告需要支持下面描述的用例。
In the figures in this section, elements labeled "c" are Diameter Clients, elements labeled "a" are Diameter Agents, and elements labeled "s" are Diameter Servers.
在本节的图中，标记为“c”的元素是Diameter客户端，标记为“a”的元素是Diameter代理，标记为“s”的元素是Diameter服务器。
This use case is illustrated in Figure 1. In this case, the client sends all traffic through the single agent. If there is a failure in the agent, then the client is unable to send Diameter traffic toward the server.
该用例如图1所示。在这种情况下，客户端通过单个代理发送所有通信量。如果代理发生故障，则客户端无法向服务器发送Diameter流量。
+-+ +-+ +-+
|c|----|a|----|s|
+-+ +-+ +-+
+-+ +-+ +-+
|c|----|a|----|s|
+-+ +-+ +-+
Figure 1
图1
A more likely case for the use of agents is illustrated in Figure 2. In this case, there are multiple servers behind the single agent. The client sends all traffic through the agent, and the agent determines how to distribute the traffic to the servers based on local routing and load distribution policy.
使用代理的更可能的情况如图2所示。在这种情况下，单个代理后面有多个服务器。客户端通过代理发送所有流量，代理根据本地路由和负载分配策略确定如何将流量分配到服务器。
+-+
--|s|
+-+ +-+ / +-+
|c|----|a|- ...
+-+ +-+ \ +-+
--|s|
+-+
+-+
--|s|
+-+ +-+ / +-+
|c|----|a|- ...
+-+ +-+ \ +-+
--|s|
+-+
Figure 2
图2
In both of these cases, the occurrence of overload in the single agent must by handled by the client similarly to as if the client were handling the overload of a directly connected server. When the agent becomes overloaded, it will insert an Overload report in answer messages flowing to the client. This Overload report will contain a requested reduction in the amount of traffic sent to the agent. The client will apply overload abatement behavior as defined in the base Diameter overload specification [RFC7683] or in the extension document that defines the indicated overload abatement algorithm. This will result in the throttling of the abated traffic that would have been sent to the agent, as there is no alternative route. The client sends an appropriate error response to the originator of the request.
在这两种情况下，客户端必须像处理直接连接的服务器的过载一样处理单个代理中的过载。当代理超载时，它将在流向客户端的应答消息中插入超载报告。此过载报告将包含发送到代理的通信量的请求减少。客户将应用基础直径过载规范[RFC7683]或定义所示过载消除算法的扩展文件中定义的过载消除行为。这将导致发送给代理的减弱的通信量受到限制，因为没有替代路由。客户端向请求的发起人发送适当的错误响应。
Figure 3 and Figure 4 illustrate a second, and more likely, type of deployment scenario involving agents. In both of these cases, the client has Diameter connections to two agents.
图3和图4展示了第二种（更可能的）涉及代理的部署场景。在这两种情况下，客户端都有到两个代理的Diameter连接。
Figure 3 illustrates a client that has a primary connection to one of the agents (agent a1) and a secondary connection to the other agent (agent a2). In this scenario, under normal circumstances, the client will use the primary connection for all traffic. The secondary connection is used when there is a failure scenario of some sort.
图3显示了一个客户端，该客户端与一个代理（代理a1）有主连接，与另一个代理（代理a2）有次连接。在这种情况下，在正常情况下，客户端将对所有流量使用主连接。当出现某种故障情况时，使用辅助连接。
+--+ +-+
--|a1|---|s|
+-+ / +--+\ /+-+
|c|- x
+-+ . +--+/ \+-+
..|a2|---|s|
+--+ +-+
+--+ +-+
--|a1|---|s|
+-+ / +--+\ /+-+
|c|- x
+-+ . +--+/ \+-+
..|a2|---|s|
+--+ +-+
Figure 3
图3
The second case, in Figure 4, illustrates the case where the connections to the agents are both actively used. In this case, the client will have local distribution policy to determine the traffic sent through each client.
图4中的第二种情况说明了到代理的连接都被积极使用的情况。在这种情况下，客户端将使用本地分发策略来确定通过每个客户端发送的流量。
+--+ +-+
--|a1|---|s|
+-+ / +--+\ /+-+
|c|- x
+-+ \ +--+/ \+-+
--|a2|---|s|
+--+ +-+
+--+ +-+
--|a1|---|s|
+-+ / +--+\ /+-+
|c|- x
+-+ \ +--+/ \+-+
--|a2|---|s|
+--+ +-+
Figure 4
图4
In the case where one of the agents in the above scenarios become overloaded, the client should reduce the amount of traffic sent to the overloaded agent by the amount requested. This traffic should instead be routed through the non-overloaded agent. For example, assume that the overloaded agent requests a reduction of 10 percent. The client should send 10 percent of the traffic that would have been routed to the overloaded agent through the non-overloaded agent.
In the case where one of the agents in the above scenarios become overloaded, the client should reduce the amount of traffic sent to the overloaded agent by the amount requested. This traffic should instead be routed through the non-overloaded agent. For example, assume that the overloaded agent requests a reduction of 10 percent. The client should send 10 percent of the traffic that would have been routed to the overloaded agent through the non-overloaded agent.translate error, please retry
When the client has both an active and a standby connection to the two agents, then an alternative strategy for responding to an Overload report from an agent is to change the standby connection to active. This will result in all traffic being routed through the new active connection.
当客户端与两个代理同时具有活动和备用连接时，响应代理过载报告的另一种策略是将备用连接更改为活动。这将导致所有流量通过新的活动连接路由。
In the case where both agents are reporting overload, the client may need to start decreasing the total traffic sent to the agents. This would be done in a similar fashion as that discussed in Section 4.1.1. The amount of traffic depends on the combined reduction requested by the two agents.
在两个代理都报告过载的情况下，客户端可能需要开始减少发送给代理的总流量。这将以第4.1.1节中讨论的类似方式进行。通信量取决于两个代理请求的合并减少量。
There are also deployment scenarios where there can be multiple Diameter Agents between Diameter Clients and Diameter Servers. An example of this type of deployment is when there are Diameter Agents between administrative domains.
还有一些部署场景，其中Diameter客户端和Diameter服务器之间可以有多个Diameter代理。此类部署的一个示例是管理域之间存在Diameter代理时。
Figure 5 illustrates one such network deployment case. Note that while this figure shows a maximum of two agents being involved in a Diameter transaction, it is possible for more than two agents to be in the path of a transaction.
图5展示了一个这样的网络部署案例。请注意，虽然此图显示一个Diameter事务最多涉及两个代理，但一个事务的路径中可能有两个以上的代理。
+---+ +---+ +-+
--|a11|-----|a21|---|s|
+-+ / +---+ \ / +---+\ /+-+
|c|- x x
+-+ \ +---+ / \ +---+/ \+-+
--|a12|-----|a22|---|s|
+---+ +---+ +-+
+---+ +---+ +-+
--|a11|-----|a21|---|s|
+-+ / +---+ \ / +---+\ /+-+
|c|- x x
+-+ \ +---+ / \ +---+/ \+-+
--|a12|-----|a22|---|s|
+---+ +---+ +-+
Figure 5
图5
The handling of overload for one or both agents, a11 or a12 in this case, is equivalent to that discussed in Section 4.1.2.
一种或两种药剂（本例中为a11或a12）的过载处理与第4.1.2节中讨论的相同。
The overload of agents a21 and a22 must be handled by the previous-hop agents. As such, agents a11 and a12 must handle the overload mitigation logic when receiving an Agent Overload report from agents a21 and a22.
代理a21和a22的过载必须由前一个跃点代理处理。因此，当从代理a21和a22接收代理过载报告时，代理a11和a12必须处理过载缓解逻辑。
The handling of Peer Overload reports is similar to that discussed in Section 4.1.2. If the overload can be addressed using diversion, then this approach should be taken.
对等过载报告的处理与第4.1.2节中讨论的类似。如果可以通过改道来解决超载问题，则应采用这种方法。
If both of the agents have requested a reduction in traffic, then the previous-hop agent must start throttling the appropriate number of transactions. When throttling requests, an agent uses the same error responses as defined in the base DOIC specification [RFC7683].
如果两个代理都请求减少通信量，则前一个跃点代理必须开始限制适当的事务数。当限制请求时，代理使用基本DOIC规范[RFC7683]中定义的相同错误响应。
This section outlines use cases for the Peer Overload report involving Diameter Clients and Diameter Servers.
本节概述了涉及Diameter客户端和Diameter服务器的对等过载报告的用例。
It is envisioned that abatement algorithms will be defined that will support the option for Diameter endpoints to send peer reports. For instance, it is envisioned that one usage scenario for the rate algorithm [RFC8582] will involve abatement being done on a hop-by-hop basis.
预计将定义消除算法，该算法将支持Diameter端点发送对等报告的选项。例如，可以设想速率算法[RFC8582]的一种使用场景将涉及逐跳进行减排。
This rate-deployment scenario would involve Diameter endpoints generating peer reports and selecting the rate algorithm for abatement of overload conditions.
此速率部署场景将涉及Diameter端点生成对等报告，并选择速率算法以减轻过载情况。
It is possible for both an agent and an endpoint in the path of a transaction to be overloaded at the same time. When this occurs, Diameter entities need to handle multiple Overload reports. In this scenario, the reacting node should first handle the throttling of the overloaded Host or Realm. Any messages that survive throttling due to Host or Realm reports should then go through abatement for the Peer Overload report. In this scenario, when doing abatement on the peer report, the reacting node SHOULD take into consideration the number of messages already throttled by the handling of the host/ realm report abatement.
事务路径中的代理和端点可能同时重载。出现这种情况时，Diameter实体需要处理多个重载报告。在此场景中，反应节点应首先处理重载主机或领域的节流。由于主机或领域报告而在限制后仍然有效的任何消息都应通过对等过载报告的消除。在这种情况下，当对对等报告执行消除时，作出反应的节点应该考虑到已被主机/领域报告消除处理限制的消息数量。
Note: The goal is to avoid traffic oscillations that might result from throttling of messages for both the host/realm Overload reports and the PEER Overload reports. This is especially a concern if both reports indicate the loss abatement algorithm.
注意：目标是避免由于主机/领域过载报告和对等过载报告的消息限制而导致的流量波动。如果两份报告都指出了减少损失的算法，这一点尤其值得关注。
This section defines the normative behavior associated with the Peer-Report extension to the DOIC solution.
本节定义了与DOIC解决方案的对等报告扩展相关的规范行为。
When sending a Diameter request, a DOIC node that supports the OC_PEER_REPORT feature (as defined in Section 7.1.1) MUST include in the OC-Supported-Features AVP an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.
发送Diameter请求时，支持OC_PEER_报告功能（如第7.1.1节所定义）的DOIC节点必须在OC支持的功能AVP中包含OC特征向量AVP，并设置OC_PEER_报告位。
When sending a request, a DOIC node that supports the OC_PEER_REPORT feature MUST include a SourceID AVP in the OC-Supported-Features AVP with its own DiameterIdentity.
发送请求时，支持OC_PEER_报告功能的DOIC节点必须在OC支持的功能AVP中包含一个SourceID AVP，并具有自己的直径。
When a Diameter Agent relays a request that includes a SourceID AVP in the OC-Supported-Features AVP, if the Diameter Agent supports the OC_PEER_REPORT feature, then it MUST remove the received SourceID AVP and replace it with a SourceID AVP containing its own DiameterIdentity.
当Diameter代理中继在OC Supported Features AVP中包含SourceID AVP的请求时，如果Diameter代理支持OC_PEER_REPORT功能，则它必须删除接收到的SourceID AVP，并将其替换为包含其自身直径的SourceID AVP。
When receiving a request, a DOIC node that supports the OC_PEER_REPORT feature MUST update transaction state with an indication of whether or not the peer from which the request was received supports the OC_PEER_REPORT feature.
在接收请求时，支持OC_PEER_报告功能的DOIC节点必须更新事务状态，以指示接收请求的对等方是否支持OC_PEER_报告功能。
Note: The transaction state is used when the DOIC node is acting as a peer-report reporting node and needs to send OC-OLR AVP reports of type "PEER-REPORT" in answer messages. The Peer Overload reports are only included in answer messages being sent to peers that support the OC_PEER_REPORT feature.
注意：当DOIC节点充当对等报告报告节点并且需要在应答消息中发送“对等报告”类型的OC-OLR AVP报告时，使用事务状态。对等过载报告仅包含在发送给支持OC_对等报告功能的对等方的应答消息中。
The peer supports the OC_PEER_REPORT feature if the received request contains an OC-Supported-Features AVP with the OC-Feature-Vector with the OC_PEER_REPORT feature bit set and with a SourceID AVP with a value that matches the DiameterIdentity of the peer from which the request was received.
如果接收到的请求包含OC支持的特征AVP，且OC特征向量设置了OC_peer_报告特征位，且SourceID AVP的值与接收到请求的对等方的直径匹配，则对等方支持OC_peer_报告特征。
When an agent relays an answer message, a reporting node that supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from the OC-Supported-Features AVP.
当代理中继应答消息时，支持OC_PEER_报告功能的报告节点必须从OC支持的功能AVP中删除任何SourceID AVP。
When sending an answer message, a reporting node that supports the OC_PEER_REPORT feature MUST determine if the peer to which the answer is to be sent supports the OC_PEER_REPORT feature.
发送应答消息时，支持OC_PEER_报告功能的报告节点必须确定要向其发送应答的对等方是否支持OC_PEER_报告功能。
If the peer supports the OC_PEER_REPORT feature, then the reporting node MUST indicate support for the feature in the OC-Supported-Features AVP.
如果对等方支持OC_peer_报告功能，则报告节点必须在OC Supported Features AVP中指示对该功能的支持。
If the peer supports the OC_PEER_REPORT feature, then the reporting node MUST insert the SourceID AVP in the OC-Supported-Features AVP in the answer message.
如果对等方支持OC_peer_报告功能，则报告节点必须在应答消息的OC Supported Features AVP中插入SourceID AVP。
If the peer supports the OC_PEER_REPORT feature, then the reporting node MUST insert the OC-Peer-Algo AVP in the OC-Supported-Features AVP. The OC-Peer-Algo AVP MUST indicate the overload abatement algorithm that the reporting node wants the reacting nodes to use should the reporting node send a Peer Overload report as a result of becoming overloaded.
如果对等方支持OC_peer_报告功能，则报告节点必须在OC支持的功能AVP中插入OC peer Algo AVP。OC Peer Algo AVP必须指出，如果报告节点因过载而发送对等过载报告，则报告节点希望反应节点使用的过载减轻算法。
This section defines the behavior for the handling of Overload reports of type "PEER-REPORT".
本节定义了处理“对等报告”类型的过载报告的行为。
This section describes the Overload Control State (OCS) that might be maintained by both the peer-report reporting node and the peer-report reacting node.
本节描述对等报告报告节点和对等报告响应节点可能维护的过载控制状态（OCS）。
This is an extension of the OCS handling defined in [RFC7683].
这是[RFC7683]中定义的OCS处理的扩展。
A DOIC node that supports the OC_PEER_REPORT feature SHOULD maintain Reporting-Node OCS, as defined in [RFC7683] and extended here.
支持OC_PEER_REPORT功能的DOIC节点应维护[RFC7683]中定义并在此扩展的报告节点OCS。
If different abatement-specific contents are sent to each peer, then the reporting node MUST maintain a separate reporting-node peer-report OCS entry per peer, to which a Peer Overload report is sent.
如果向每个对等方发送不同的减排特定内容，则报告节点必须为每个对等方维护单独的报告节点对等方报告OCS条目，并向其发送对等方过载报告。
Note: The rate-overload abatement algorithm allows for different rates to be sent to each peer.
注意：速率过载消除算法允许向每个对等方发送不同的速率。
In addition to OCS maintained as defined in [RFC7683], a reacting node that supports the OC_PEER_REPORT feature maintains the following OCS per supported Diameter application:
除了按照[RFC7683]中的定义维护OCS外，支持OC_PEER_报告功能的反应节点还为每个受支持的Diameter应用程序维护以下OCS：
A peer-report OCS entry for each peer to which it sends requests
每个向其发送请求的对等机的对等机报告OCS条目
A peer-report OCS entry is identified by both the Application-ID and the peer's DiameterIdentity.
对等报告OCS条目由应用程序ID和对等方的直径标识。
The peer-report OCS entry includes the following information (the actual information stored is an implementation decision):
对等报告OCS条目包括以下信息（存储的实际信息是实施决策）：
Sequence number (as received in the OC-OLR AVP)
序列号（在OC-OLR AVP中接收）
Time of expiry (derived from the OC-Validity-Duration AVP received in the OC-OLR AVP and time of reception of the message carrying the OC-OLR AVP)
到期时间（根据OC-OLR AVP中接收到的OC有效期AVP和承载OC-OLR AVP的消息的接收时间得出）
Selected abatement algorithm (as received in the OC-Supported-Features AVP)
选定的消减算法（在OC支持的功能AVP中接收）
Input data that is specific to the abatement algorithm (as received in the OC-OLR AVP, e.g., OC-Reduction-Percentage for the loss abatement algorithm)
特定于消减算法的输入数据（在OC-OLR AVP中接收，例如，损耗消减算法的OC减少百分比）
All rules for managing the reporting-node OCS entries defined in [RFC7683] apply to the peer report.
[RFC7683]中定义的用于管理报告节点OCS条目的所有规则均适用于对等报告。
When a reacting node receives an OC-OLR AVP with a report type of "PEER-REPORT", it MUST determine if the report was generated by the Diameter peer from which the report was received.
当反应节点接收到报告类型为“对等报告”的OC-OLR AVP时，它必须确定报告是否由接收报告的Diameter对等方生成。
If a reacting node receives an OC-OLR AVP of type "PEER-REPORT" and the SourceID matches the DiameterIdentity of the Diameter peer from which the response message was received, then the report was generated by a Diameter peer.
如果反应节点接收到类型为“PEER-REPORT”的OC-OLR AVP，并且SourceID与接收响应消息的Diameter对等方的直径匹配，则报告由Diameter对等方生成。
If a reacting node receives an OC-OLR AVP of type "PEER-REPORT" and the SourceID does not match the DiameterIdentity of the Diameter peer from which the response message was received, then the reacting node MUST ignore the Overload report.
如果反应节点接收到类型为“PEER-REPORT”的OC-OLR AVP，并且SourceID与接收到响应消息的直径对等体的直径不匹配，则反应节点必须忽略重载报告。
Note: Under normal circumstances, a Diameter node will not add a peer report when sending to a peer that does not support this extension. This requirement is to handle the case where peer reports are erroneously or maliciously inserted into response messages.
注意：在正常情况下，Diameter节点在发送到不支持此扩展的对等方时不会添加对等方报告。此要求用于处理对等报告错误或恶意插入响应消息的情况。
If the peer report was received from a Diameter peer, then the reacting node MUST determine if it is for an existing or new overload condition.
如果从Diameter对等方接收到对等方报告，则响应节点必须确定它是针对现有的还是新的过载情况。
The peer report is for an existing overload condition if the reacting node has an OCS that matches the received peer report. For a peer report, this means it matches the Application-ID and the peer's DiameterIdentity in an existing OCS entry.
如果响应节点具有与接收到的对等报告匹配的OCS，则对等报告适用于现有过载条件。对于对等报告，这意味着它匹配现有OCS条目中的应用程序ID和对等方的直径。
If the peer report is for an existing overload condition, then it MUST determine if the peer report is a retransmission or an update to the existing OLR.
如果对等报告针对现有过载条件，则必须确定对等报告是对现有OLR的重新传输还是更新。
If the sequence number for the received peer report is greater than the sequence number stored in the matching OCS entry, then the reacting node MUST update the matching OCS entry.
如果接收到的对等报告的序列号大于存储在匹配OCS条目中的序列号，则响应节点必须更新匹配OCS条目。
If the sequence number for the received peer report is less than or equal to the sequence number in the matching OCS entry, then the reacting node MUST silently ignore the received peer report. The matching OCS MUST NOT be updated in this case.
如果接收到的对等报告的序列号小于或等于匹配OCS条目中的序列号，则响应节点必须以静默方式忽略接收到的对等报告。在这种情况下，不得更新匹配的OCS。
If the received peer report is for a new overload condition, then the reacting node MUST generate a new OCS entry for the overload condition.
如果收到的对等报告针对新的过载条件，则响应节点必须为过载条件生成新的OCS条目。
For a peer report, this means it creates an OCS entry with a DiameterIdentity from the SourceID AVP in the received OC-OLR AVP.
对于对等报告，这意味着它从接收到的OC-OLR AVP中的SourceID AVP创建直径为的OCS条目。
If the received peer report contains a validity duration of zero ("0"), then the reacting node MUST update the OCS entry as being expired.
如果收到的对等报告的有效期为零（“0”），则响应节点必须将OCS条目更新为已过期。
The reacting node does not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e., the absence of OLR means "no change").
响应节点在接收到不包含OC-OLR AVP的应答消息时不删除OCS（即，没有OLR意味着“没有改变”）。
The reacting node sets the abatement algorithm based on the OC-Peer-Algo AVP in the received OC-Supported-Features AVP.
反应节点根据接收到的OC支持的特征AVP中的OC对等算法AVP设置消减算法。
When there is an existing reporting-node peer-report OCS entry, the reporting node MUST include an OC-OLR AVP with a report type of "PEER-REPORT" using the contents of the reporting-node peer-report OCS entry in all answer messages sent by the reporting node to peers that support the OC_PEER_REPORT feature.
当存在现有报告节点对等报告OCS条目时，报告节点必须在报告节点发送给支持OC_对等报告功能的对等方的所有应答消息中使用报告节点对等报告OCS条目的内容，包括报告类型为“对等报告”的OC-OLR AVP。
Note: The reporting node determines if a peer supports the OC_PEER_REPORT feature based on the indication recorded in the reporting node's transaction state.
注意：报告节点根据报告节点事务状态中记录的指示确定对等方是否支持OC_peer_报告功能。
The reporting node MUST include its DiameterIdentity in the SourceID AVP in the OC-OLR AVP. This is used by DOIC nodes that support the OC_PEER_REPORT feature to determine if the report was received from a Diameter peer.
报告节点必须在OC-OLR AVP的SourceID AVP中包含其直径。这被支持OC_PEER_报告功能的DOIC节点用来确定报告是否是从Diameter PEER接收的。
The reporting agent must follow all other overload reporting-node behaviors outlined in the DOIC specification.
报告代理必须遵循DOIC规范中概述的所有其他重载报告节点行为。
A reacting node supporting this extension MUST support the receipt of multiple Overload reports in a single message. The message might include a Host Overload report, a Realm Overload report, and/or a Peer Overload report.
支持此扩展的响应节点必须支持在单个消息中接收多个过载报告。该消息可能包括主机过载报告、领域过载报告和/或对等过载报告。
When a reacting node sends a request, it MUST determine if that request matches an active OCS.
当响应节点发送请求时，它必须确定该请求是否与活动OCS匹配。
In all cases, if the reacting node is an agent, then it MUST strip the Peer-Report OC-OLR AVP from the message.
在所有情况下，如果反应节点是代理，则必须从消息中删除对等报告OC-OLR AVP。
If the request matches an active OCS, then the reacting node MUST apply abatement treatment to the request. The abatement treatment applied depends on the abatement algorithm indicated in the OCS.
如果请求与活动OCS匹配，则反应节点必须对请求应用消减处理。采用的减排处理取决于OCS中指示的减排算法。
For Peer Overload Reports, the preferred abatement treatment is diversion. As such, the reacting node SHOULD attempt to divert requests identified as needing abatement to other peers.
对于同级超载报告，首选的缓解措施是分流。因此，作出反应的节点应尝试将被确定为需要消除的请求转移到其他对等方。
If there is not sufficient capacity to divert abated traffic, then the reacting node MUST throttle the necessary requests to fit within the available capacity of the peers able to handle the requests.
如果没有足够的容量来转移减弱的流量，那么响应节点必须限制必要的请求，以适应能够处理请求的对等方的可用容量。
If the abatement treatment results in throttling of the request and if the reacting node is an agent, then the agent MUST send an appropriate error response as defined in [RFC7683].
如果消减处理导致请求节流，并且反应节点是代理，则代理必须发送[RFC7683]中定义的适当错误响应。
In the case that the OCS entry validity duration expires or has a validity duration of zero ("0"), meaning that if the reporting node has explicitly signaled the end of the overload condition, then abatement associated with the OCS entry MUST be ended in a controlled fashion.
在OCS条目有效期到期或有效期为零（“0”）的情况下，这意味着如果报告节点已明确发出过载条件结束的信号，则与OCS条目相关的消减必须以受控方式结束。
This extension adds a new feature to the OC-Feature-Vector AVP. This feature indication shows support for handling of Peer Overload reports. Peer Overload reports are used by agents to indicate the need for overload abatement handling by the agent's peer.
此扩展将向OC特征向量AVP添加一个新特征。此功能指示显示对处理对等过载报告的支持。代理使用对等过载报告来指示代理的对等端进行过载消除处理的需要。
A supporting node must also include the SourceID AVP in the OC-Supported-Features capability AVP.
支持节点还必须在OC支持的功能AVP中包含SourceID AVP。
This AVP contains the DiameterIdentity of the node that supports the OC_PEER_REPORT feature. This AVP is used to determine if support for the Peer Overload report is in an adjacent node. The value of this AVP should be the same Diameter identity used as part of the Diameter Capabilities Exchange procedure defined in [RFC7683].
此AVP包含支持OC_PEER_报告功能的节点的直径。此AVP用于确定相邻节点是否支持对等过载报告。此AVP的值应与[RFC7683]中定义的直径能力交换过程中使用的直径标识相同。
This extension also adds the OC-Peer-Algo AVP to the OC-Supported-Features AVP. This AVP is used by a reporting node to indicate the abatement algorithm it will use for Peer Overload reports.
此扩展还将OC对等Algo AVP添加到OC支持的功能AVP中。报告节点使用此AVP来指示将用于对等过载报告的消除算法。
OC-Supported-Features ::= < AVP Header: 621 >
[ OC-Feature-Vector ]
[ SourceID ]
[ OC-Peer-Algo]
* [ AVP ]
OC-Supported-Features ::= < AVP Header: 621 >
[ OC-Feature-Vector ]
[ SourceID ]
[ OC-Peer-Algo]
* [ AVP ]
The Peer-Report feature defines a new feature bit for the OC-Feature-Vector AVP.
对等报告功能为OC功能向量AVP定义一个新的功能位。
OC_PEER_REPORT (0x0000000000000010)
OC_PEER_报告（0x0000000000000010）
When this flag is set by a DOIC node, it indicates that the DOIC node supports the Peer Overload report type.
当DOIC节点设置此标志时，它表示DOIC节点支持对等重载报告类型。
The OC-Peer-Algo AVP (AVP code 648) is of type Unsigned64 and contains a 64-bit flags field of announced capabilities for a DOIC node. The value of zero ("0") is reserved.
OC对等Algo AVP（AVP代码648）的类型为Unsigned64，并包含一个DOIC节点的已宣布功能的64位标志字段。保留零（“0”）的值。
Feature bits defined for the OC-Feature-Vector AVP and associated with overload abatement algorithms are reused for this AVP.
为OC特征向量AVP定义并与过载消除算法相关联的特征位被重新用于该AVP。
This extension makes no changes to the OC_Sequence_Number or OC_Validity_Duration AVPs in the OC-OLR AVP. These AVPs can also be used in Peer Overload reports.
此扩展不会更改OC-OLR AVP中的OC_序列号或OC_有效期AVP。这些AVP也可用于对等过载报告。
The OC_PEER_REPORT feature extends the base Diameter overload specification by defining a new Overload report type of "PEER-REPORT". See Section 7.6 of [RFC7683] for a description of the OC-Report-Type AVP.
OC_PEER_报告功能通过定义新的重载报告类型“PEER-REPORT”，扩展了基本直径重载规范。有关OC报告类型AVP的说明，请参见[RFC7683]第7.6节。
The peer report MUST also include the Diameter identity of the agent that generated the report. This is necessary to handle the case where there is a non-supporting agent between the reporting node and the reacting node. Without the indication of the agent that generated the peer report, the reacting node could erroneously assume that the report applied to the non-supporting node. This could, in turn, result in unnecessary traffic being either diverted or throttled.
对等报告还必须包括生成报告的代理的直径标识。这对于处理报告节点和反应节点之间存在非支持代理的情况是必要的。如果没有生成对等报告的代理的指示，反应节点可能会错误地认为该报告应用于非支持节点。这反过来可能导致不必要的交通被分流或阻塞。
The SourceID AVP is used in the OC-OLR AVP to carry this DiameterIdentity.
OC-OLR AVP中使用SourceID AVP来承载该直径。
OC-OLR ::= < AVP Header: 623 >
< OC-Sequence-Number >
< OC-Report-Type >
[ OC-Reduction-Percentage ]
[ OC-Validity-Duration ]
[ SourceID ]
* [ AVP ]
OC-OLR ::= < AVP Header: 623 >
< OC-Sequence-Number >
< OC-Report-Type >
[ OC-Reduction-Percentage ]
[ OC-Validity-Duration ]
[ SourceID ]
* [ AVP ]
The following new report type is defined for the OC-Report-Type AVP.
为OC报告类型AVP定义了以下新报告类型。
PEER_REPORT 2: The overload treatment should apply to all requests bound for the peer identified in the Overload report. If the peer identified in the peer report is not a peer to the reacting endpoint, then the peer report should be stripped and not acted upon.
PEER_报告2：重载处理应适用于重载报告中标识的绑定到对等方的所有请求。如果对等报告中标识的对等点不是反应端点的对等点，则应对对等报告进行剥离，而不是对其采取行动。
The SourceID AVP (AVP code 649) is of type DiameterIdentity and is inserted by a Diameter node to indicate the source of the AVP in which it is a part.
SourceID AVP（AVP代码649）为DiameterIdentity类型，由直径节点插入，以指示AVP的来源，AVP是其中的一部分。
In the case of peer reports, the SourceID AVP indicates the node that supports this feature (in the OC-Supported-Features AVP) or the node that generates an overload report with a report type of "PEER-REPORT" (in the OC-OLR AVP).
对于对等报告，SourceID AVP表示支持此功能的节点（在OC支持的功能AVP中）或生成报告类型为“对等报告”的过载报告的节点（在OC-OLR AVP中）。
It contains the DiameterIdentity of the inserting node. This is used by other Diameter nodes to determine the node that inserted the enclosing AVP that contains the SourceID AVP.
它包含插入节点的直径。其他Diameter节点将使用此选项确定插入包含SourceID AVP的封闭AVP的节点。
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------------+----+----+
|OC-Peer-Algo 648 7.1.2 Unsigned64 | | V |
|SourceID 649 7.3 DiameterIdentity | | V |
+--------------------------------------------------------+----+----+
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------------+----+----+
|OC-Peer-Algo 648 7.1.2 Unsigned64 | | V |
|SourceID 649 7.3 DiameterIdentity | | V |
+--------------------------------------------------------+----+----+
IANA has registered the following values in the "Authentication, Authorization, and Accounting (AAA) Parameters" registry:
IANA已在“身份验证、授权和记帐（AAA）参数”注册表中注册了以下值：
Two new AVP codes are defined in Section 7.4.
第7.4节定义了两个新的AVP代码。
Note that the values used for the OC-Peer-Algo AVP are a subset of the "OC-Feature-Vector AVP Values (code 622)" registry. Only the values in that registry that apply to overload abatement algorithms apply to the OC-Peer-Algo AVP.
请注意，用于OC对等Algo AVP的值是“OC特征向量AVP值（代码622）”注册表的子集。只有该注册表中适用于过载消除算法的值适用于OC对等算法AVP。
A new OC-Feature-Vector AVP value is defined in Section 7.1.1.
第7.1.1节定义了新的OC特征向量AVP值。
A new OC-Report-Type AVP value is defined in Section 7.2.1.
第7.2.1节定义了新的OC报告类型AVP值。
Agent overload is an extension to the base Diameter Overload mechanism. As such, all of the security considerations outlined in [RFC7683] apply to the agent overload scenarios.
代理重载是基本直径重载机制的扩展。因此，[RFC7683]中概述的所有安全注意事项都适用于代理过载场景。
It is possible that the malicious insertion of an peer report could have a bigger impact on a Diameter network as agents can be concentration points in a Diameter network. Where an endpoint report would impact the traffic sent to a single Diameter Server, for example, a peer report could throttle all traffic to the Diameter network.
恶意插入对等报告可能会对Diameter网络产生更大的影响，因为代理可能是Diameter网络中的集中点。例如，在端点报告会影响发送到单个Diameter服务器的流量的情况下，对等报告可能会限制到Diameter网络的所有流量。
This impact is amplified in a Diameter agent that sits at the edge of a Diameter network that serves as the entry point from all other Diameter networks.
这种影响在位于Diameter网络边缘的Diameter代理中放大，该网络作为所有其他Diameter网络的入口点。
The impacts of this attack, as well as the mitigation strategies, are the same as those outlined in [RFC7683].
此攻击的影响以及缓解策略与[RFC7683]中概述的相同。
[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>.
[RFC8582] Donovan, S., Ed. and E. Noel, "Diameter Overload Rate Control", RFC 8582, DOI 10.17487/RFC8582, August 2019, <https://www.rfc-editor.org/info/rfc8582>.
[RFC8582]Donovan，S.，Ed.和E.Noel，“直径过载率控制”，RFC 8582，DOI 10.17487/RFC8582，2019年8月<https://www.rfc-editor.org/info/rfc8582>.
[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>.
[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>.
[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>.
Acknowledgements
致谢
The author would like to thank Adam Roach and Eric McMurry for the work done in defining a comprehensive Diameter overload solution in draft-roach-dime-overload-ctrl-03.txt.
作者要感谢Adam Roach和Eric McMurry在draft-Roach-dime-overload-ctrl-03.txt中定义综合直径过载解决方案所做的工作。
The author would also like to thank Ben Campbell for his insights and review of early versions of this document.
作者还要感谢Ben Campbell对本文件早期版本的见解和评论。
Author's Address
作者地址
Steve Donovan Oracle 7460 Warren Parkway, Suite 300 Frisco, Texas 75034 United States of America
Steve Donovan Oracle 7460 Warren Parkway，美国德克萨斯州弗里斯科300号套房，邮编75034
Email: srdonovan@usdonovans.com
Email: srdonovan@usdonovans.com