[要約] RFC 8581は、Diameterエージェントの過負荷とピアの過負荷レポートに関する標準仕様です。このRFCの目的は、Diameterネットワークでの過負荷状態の検出と通知を可能にすることです。
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.
この仕様は、RFC 7683で定義されているDiameter過負荷の基本ソリューションであるDiameter過負荷表示伝達（DOIC）の拡張機能を文書化しています。拡張機能は、ピアオーバーロードレポートタイプを定義します。ピアレポートの最初の使用例は、Diameterエージェントの過負荷の発生の処理です。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
この仕様は、Diameterオーバーロードの基本ソリューションであるDiameter Overload Indication Conveyance（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ノードの動作を定義します。また、エージェントの過負荷状態を処理するために使用される新しいオーバーロードレポートタイプであるピアオーバーロードレポートタイプも定義します。ピアオーバーロードレポートタイプは、他の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.
ベースのDiameterオーバーロード仕様[RFC7683]は、Diameterエンドポイント（[RFC6733]で定義されているDiameterクライアントまたはDiameterサーバー）がオーバーロードになったときのオーバーロードの処理を扱います。
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エージェントは、過負荷の軽減も処理します。たとえば、DiameterクライアントがDOIC拡張をサポートしていないことがわかっている場合、Diameterエージェントは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トラフィックの急増により、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]で定義されたDiameter過負荷損失軽減アルゴリズムで機能し、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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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.
現在識別されているユースケースの2つの主要なクラスがあります。エージェントの過負荷を伴うものと、Diameterエンドポイントの過負荷を伴うものです。どちらの場合も、ピアに送信されるトラフィックを制御する過負荷アルゴリズムを使用することが目標です。
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|
+-+ +-+ +-+
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|
+-+
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.
これらのどちらの場合でも、単一のエージェントでの過負荷の発生は、クライアントが直接接続されたサーバーの過負荷を処理しているかのように、クライアントが処理する必要があります。エージェントが過負荷になると、クライアントに流れる応答メッセージに過負荷レポートが挿入されます。この過負荷レポートには、エージェントに送信されるトラフィック量の削減要求が含まれています。クライアントは、基本のDiameterオーバーロード仕様[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は、エージェントが関係する2番目の、より可能性の高いタイプの展開シナリオを示しています。これらのどちらの場合でも、クライアントには2つのエージェントへの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は、エージェントの1つ（エージェントa1）へのプライマリ接続と、他のエージェント（エージェントa2）へのセカンダリ接続を持つクライアントを示しています。このシナリオでは、通常の状況では、クライアントはすべてのトラフィックにプライマリ接続を使用します。セカンダリ接続は、何らかの障害シナリオがある場合に使用されます。
+--+ +-+
--|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の2番目のケースは、エージェントへの接続が両方ともアクティブに使用されているケースを示しています。この場合、クライアントには、各クライアントを介して送信されるトラフィックを決定するローカル配布ポリシーがあります。
+--+ +-+
--|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.
上記のシナリオのいずれかのエージェントが過負荷になった場合、クライアントは、過負荷のエージェントに送信されるトラフィックの量を要求された量だけ減らす必要があります。このトラフィックは、代わりに過負荷でないエージェントを介してルーティングする必要があります。たとえば、過負荷のエージェントが10％の削減を要求するとします。クライアントは、過負荷でないエージェントを介して過負荷のエージェントにルーティングされるはずだったトラフィックの10％を送信する必要があります。
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.
クライアントに2つのエージェントへのアクティブ接続とスタンバイ接続の両方がある場合、エージェントからの過負荷レポートに応答するための代替戦略は、スタンバイ接続をアクティブに変更することです。これにより、すべてのトラフィックが新しいアクティブな接続を介してルーティングされます。
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で説明したのと同様の方法で行われます。トラフィックの量は、2つのエージェントによって要求された削減の合計に依存します。
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トランザクションに関与している最大2つのエージェントが示されていますが、3つ以上のエージェントがトランザクションのパスに存在する可能性があることに注意してください。
+---+ +---+ +-+
--|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.
1つまたは両方のエージェント（この場合は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の過負荷は、前のホップのエージェントによって処理される必要があります。そのため、エージェントa11およびa12は、エージェントa21およびa22からエージェントオーバーロードレポートを受信したときに、過負荷軽減ロジックを処理する必要があります。
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]の1つの使用シナリオには、ホップバイホップベースで実行される削減が含まれることが想定されています。
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エンティティは複数のオーバーロードレポートを処理する必要があります。このシナリオでは、反応するノードは最初に過負荷のホストまたはレルムのスロットルを処理する必要があります。ホストまたはレルムレポートによるスロットルを生き延びたメッセージはすべて、ピアオーバーロードレポートの削減を行う必要があります。このシナリオでは、ピアレポートで削減を行う場合、反応するノードは、ホスト/レルムレポートの削減の処理によってすでに抑制されたメッセージの数を考慮する必要があります（SHOULD）。
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.
注：目標は、ホスト/レルムの過負荷レポートとPEERの過負荷レポートの両方のメッセージのスロットルから生じる可能性のあるトラフィックの変動を回避することです。両方のレポートが損失削減アルゴリズムを示している場合、これは特に懸念事項です。
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_REPORT機能（セクション7.1.1で定義）をサポートするDOICノードは、OC_PEER_REPORTビットが設定されたOC-Feature-Vector AVPをOC-Supported-Features AVPに含める必要があります。
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_REPORT機能をサポートするDOICノードは、独自のDiameterIdentityを持つOC-Supported-Features 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を削除し、独自のDiameterIdentityを含む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_REPORT機能をサポートするDOICノードは、要求の受信元のピアがOC_PEER_REPORT機能をサポートするかどうかを示すトランザクション状態を更新しなければなりません（MUST）。
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ノードがピアレポートレポートノードとして機能しており、応答メッセージでタイプ「PEER-REPORT」のOC-OLR AVPレポートを送信する必要がある場合に使用されます。ピアオーバーロードレポートは、OC_PEER_REPORT機能をサポートするピアに送信される応答メッセージにのみ含まれます。
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_PEER_REPORT機能ビットが設定されたOC-Feature-Vectorと、要求元のピアのDiameterIdentityと一致する値を持つSourceID AVPを持つOC-Supported-Features AVPが含まれる場合、ピアはOC_PEER_REPORT機能をサポートします。受け取りました。
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_REPORT機能をサポートするレポートノードは、OC-Supported-Features 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_REPORT機能をサポートするレポートノードは、応答の送信先のピアがOC_PEER_REPORT機能をサポートするかどうかを決定する必要があります。
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_REPORT機能をサポートしている場合、レポートノードは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_REPORT機能をサポートしている場合、レポートノードは、応答メッセージの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_REPORT機能をサポートしている場合、レポートノードはOC-Peer-Algo AVPをOC-Supported-Features AVPに挿入する必要があります。 OC-Peer-Algo AVPは、過負荷になった結果としてレポートノードがピアオーバーロードレポートを送信した場合に、レポートノードが対応ノードに使用させたいオーバーロード軽減アルゴリズムを示さなければなりません（MUST）。
This section defines the behavior for the handling of Overload reports of type "PEER-REPORT".
このセクションでは、「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を維持する必要があります（SHOULD）。
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_REPORT機能をサポートする反応ノードは、サポートされる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とピアのDiameterIdentityの両方で識別されます。
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-Validity-Duration AVPおよびOC-OLR AVPを伝送するメッセージの受信時間から派生）
Selected abatement algorithm (as received in the OC-Supported-Features AVP)
選択された削減アルゴリズム（OC-Supported-Features 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-Reduction-Percentage）
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.
反応ノードは、レポートタイプが「PEER-REPORT」の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ピアのDiameterIdentityと一致する場合、レポートは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が応答メッセージの受信元のDiameterピアのDiameterIdentityと一致しない場合、反応ノードは過負荷レポートを無視する必要があります。
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ピアから受信された場合、反応するノードは、それが既存の過負荷状態か新しい過負荷状態かを判断しなければなりません（MUST）。
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エントリのApplication-IDおよびピアのDiameterIdentityと一致することを意味します。
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エントリのシーケンス番号以下の場合、反応するノードは、受信したピアレポートを黙って無視しなければなりません（MUST）。この場合、一致する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からDiameterIdentityを持つ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-Supported-Features AVPのOC-Peer-Algo 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エントリがある場合、レポートノードは、すべての回答でレポートノードピアレポートOCSエントリの内容を使用して、レポートタイプが「PEER-REPORT」のOC-OLR AVPを含める必要がありますレポートノードからOC_PEER_REPORT機能をサポートするピアに送信されるメッセージ。
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_REPORT機能をサポートしているかどうかを判断します。
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.
レポートノードは、そのDiameterIdentityをOC-OLR AVPのSourceID AVPに含める必要があります。これは、OC_PEER_REPORT機能をサポートするDOICノードで使用され、レポートがDiameterピアから受信されたかどうかを判断します。
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-Feature-Vector AVPに新しい機能を追加します。この機能表示は、ピアオーバーロードレポートの処理のサポートを示しています。ピア過負荷レポートは、エージェントのピアによる過負荷軽減処理の必要性を示すためにエージェントによって使用されます。
A supporting node must also include the SourceID AVP in the OC-Supported-Features capability AVP.
サポートノードは、OC-Supported-Features機能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_REPORT機能をサポートするノードのDiameterIdentityが含まれています。このAVPは、ピアオーバーロードレポートのサポートが隣接ノードにあるかどうかを判断するために使用されます。このAVPの値は、[RFC7683]で定義されているDiameter機能交換手順の一部として使用されているのと同じDiameter IDである必要があります。
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-Peer-Algo AVPがOC-Supported-Features AVPに追加されます。この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-Feature-Vector AVPの新しい機能ビットを定義します。
OC_PEER_REPORT (0x0000000000000010)
OC_PEER_REPORT（0x0000000000000010）
When this flag is set by a DOIC node, it indicates that the DOIC node supports the Peer Overload report type.
このフラグがDOICノードによって設定されている場合、DOICノードがPeer Overloadレポートタイプをサポートしていることを示します。
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-Peer-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-Feature-Vector 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_Sequence_NumberまたはOC_Validity_Duration 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_REPORT機能は、「PEER-REPORT」という新しいオーバーロードレポートタイプを定義することにより、基本Diameterオーバーロード仕様を拡張します。 OC-Report-Type 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.
ピアレポートには、レポートを生成したエージェントのDiameter IDも含める必要があります。これは、レポートノードと対応ノードの間にサポートされていないエージェントがある場合の処理に必要です。ピアレポートを生成したエージェントを示さない場合、反応するノードは、レポートがサポートしていないノードに適用されたと誤って想定する可能性があります。これにより、不要なトラフィックが迂回または抑制される可能性があります。
The SourceID AVP is used in the OC-OLR AVP to carry this DiameterIdentity.
SourceID AVPは、OC-OLR AVPでこのDiameterIdentityを伝送するために使用されます。
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-Report-Type 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_REPORT 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であり、Diameterノードによって挿入され、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-Supported-Features AVP）またはレポートタイプが "PEER-REPORT"の過負荷レポートを生成するノード（OC-Supported-Features AVP）を示します。 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.
挿入ノードのDiameterIdentityが含まれます。これは他の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 |
+--------------------------------------------------------+----+----+
IANA has registered the following values in the "Authentication, Authorization, and Accounting (AAA) Parameters" registry:
IANAは、「Authentication、Authorization、and Accounting（AAA）Parameters」レジストリに次の値を登録しています。
Two new AVP codes are defined in Section 7.4.
セクション7.4では、2つの新しい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-Peer-Algo AVPに使用される値は、「OC-Feature-Vector AVP値（コード622）」レジストリのサブセットであることに注意してください。 OC-Peer-Algo AVPに適用されるのは、オーバーロード軽減アルゴリズムに適用されるそのレジストリの値のみです。
A new OC-Feature-Vector AVP value is defined in Section 7.1.1.
新しいOC-Feature-Vector AVP値は、セクション7.1.1で定義されています。
A new OC-Report-Type AVP value is defined in Section 7.2.1.
新しいOC-Report-Type AVP値は、セクション7.2.1で定義されています。
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.
エージェントオーバーロードは、基本のDiameterオーバーロードメカニズムの拡張機能です。そのため、[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。、編、Arkko、J.、Loughney、J。、およびG. Zorn、編、「Diameter Base Protocol」、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、「Diameter Overload Indication Conveyance」、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]ドノバン、S。、エド。 E. Noel、「Diameter Overload Rate Control」、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、「Diameter Overload Control Requirements」、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.
著者は、draft-roach-dime-overload-ctrl-03.txtで包括的なDiameter過負荷ソリューションを定義する際に行われた作業について、Adam RoachとEric McMurryに感謝します。
The author would also like to thank Ben Campbell for his insights and review of early versions of this document.
著者はまた、このドキュメントの初期バージョンの洞察とレビューについてベンキャンベルに感謝します。
Author's Address
著者のアドレス
Steve Donovan Oracle 7460 Warren Parkway, Suite 300 Frisco, Texas 75034 United States of America
Steve Donovan Oracle 7460 Warren Parkway、Suite 300 Frisco、Texas 75034アメリカ合衆国
Email: srdonovan@usdonovans.com