[要約] RFC 8582は、Diameterネットワークでの過負荷制御を提供するためのプロトコル拡張です。その目的は、ネットワークの過負荷状態を検出し、トラフィックの制御を行うことです。
Internet Engineering Task Force (IETF) S. Donovan, Ed.
Request for Comments: 8582 Oracle
Category: Standards Track E. Noel
ISSN: 2070-1721 AT&T Labs
August 2019
Diameter Overload Rate Control
直径過負荷率制御
Abstract
概要
This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution, which is defined in RFC 7683. This extension adds a new overload-control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node.
この仕様は、RFC 7683で定義されているDiameter Overload Indication Conveyance（DOIC）基本ソリューションへの拡張を文書化しています。この拡張は、新しい過負荷制御軽減アルゴリズムを追加します。この削減アルゴリズムにより、DOICレポートノードは、DOIC反応ノードがDiameterリクエストをDOICレポートノードに送信する最大レートを指定できます。
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/rfc8582.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8582で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Interaction with DOIC Report Types . . . . . . . . . . . . . 5
5. Capability Announcement . . . . . . . . . . . . . . . . . . . 6
6. Overload-Report Handling . . . . . . . . . . . . . . . . . . 7
6.1. Reporting-Node OCS . . . . . . . . . . . . . . . . . . . 7
6.2. Reacting-Node OCS . . . . . . . . . . . . . . . . . . . . 7
6.3. Reporting-Node Maintenance of OCS . . . . . . . . . . . . 8
6.4. Reacting-Node Maintenance of OCS . . . . . . . . . . . . 8
6.5. Reporting-Node Behavior for Rate Abatement Algorithm . . 9
6.6. Reacting-Node Behavior for Rate Abatement Algorithm . . . 9
7. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 9
7.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 9
7.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 10
7.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 10
7.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 10
7.3. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . 11
8. Rate Abatement Algorithm . . . . . . . . . . . . . . . . . . 11
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Reporting-Node Behavior . . . . . . . . . . . . . . . . . 11
8.3. Reacting-Node Behavior . . . . . . . . . . . . . . . . . 13
8.3.1. Default Algorithm for Rate-Based Control . . . . . . 13
8.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 16
8.3.3. Optional Enhancement: Avoidance of Resonance . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. OC-Supported-Features . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
This document defines a new Diameter overload-control abatement algorithm, the "rate" algorithm.
このドキュメントでは、新しいDiameter過負荷制御軽減アルゴリズムである「レート」アルゴリズムを定義しています。
The base Diameter overload specification [RFC7683] defines the "loss algorithm" as the default Diameter overload loss abatement algorithm. The loss algorithm allows a reporting node (see Section 3) to instruct a reacting node (see Section 3) to reduce the amount of traffic sent to the reporting node by abating (diverting or throttling) a percentage of requests sent to the server. While this can effectively decrease the load handled by the server, it does not directly address cases where the rate of arrival of service requests changes quickly. For instance, if the service requests that result in Diameter transactions increase quickly, then the loss algorithm cannot guarantee the load presented to the server remains below a specific rate level. The loss algorithm can be slow to ensure the stability of reporting nodes when subjected to rapidly-changing loads. The "loss" algorithm errs both in throttling too much when there is a dip in offered load, and throttling not enough when there is a spike in offered load.
基本Diameter過負荷仕様[RFC7683]は、デフォルトのDiameter過負荷損失軽減アルゴリズムとして「損失アルゴリズム」を定義しています。損失アルゴリズムを使用すると、レポートノード（セクション3を参照）が反応ノード（セクション3を参照）に指示して、サーバーに送信される要求の割合を削減（迂回またはスロットル）することにより、レポートノードに送信されるトラフィックの量を減らすことができます。これにより、サーバーで処理される負荷を効果的に減らすことができますが、サービス要求の到着率が急速に変化する場合には直接対応しません。たとえば、Diameterトランザクションを発生させるサービス要求が急速に増加する場合、損失アルゴリズムは、サーバーに提示される負荷が特定のレートレベルを下回ったままであることを保証できません。急速に変化する負荷にさらされた場合、損失アルゴリズムはレポートノードの安定性を確保するために遅くなる可能性があります。 「損失」アルゴリズムは、提供された負荷に急降下がある場合のスロットルが大きすぎる場合と、提供された負荷に急上昇がある場合のスロットルが不十分な場合の両方でエラーになります。
Consider the case where a reacting node is handling 100 service requests per second, where each of these service requests results in one Diameter transaction being sent to a reporting node. If the reporting node is approaching an overload state, or is already in an overload state, it will send a Diameter Overload report requesting a percentage reduction in traffic sent when the loss algorithm is used as a Diameter overload abatement algorithm. Assume for this discussion that the reporting node requests a 10% reduction. The reacting node will then abate (diverting or throttling) ten Diameter transactions a second, sending the remaining 90 transactions per second to the reporting node.
反応ノードが1秒あたり100のサービス要求を処理し、これらのサービス要求のそれぞれが1つのDiameterトランザクションをレポートノードに送信する場合を考えます。レポートノードが過負荷状態に近づいている場合、またはすでに過負荷状態にある場合、損失アルゴリズムがDiameter過負荷軽減アルゴリズムとして使用されている場合に送信されるトラフィックの割合の減少を要求するDiameter過負荷レポートを送信します。この説明では、レポートノードが10％の削減を要求していると想定します。反応ノードは、1秒あたり10個のDiameterトランザクションを削減（迂回またはスロットリング）し、残りの1秒あたり90個のトランザクションをレポートノードに送信します。
Now assume that the reacting node's service requests spike to 1000 requests per second. The reacting node will continue to honor the reporting node's request for a 10% reduction in traffic. This results, in this example, in the reacting node sending 900 Diameter transactions per second, abating the remaining 100 transactions per second. This spike in traffic is significantly higher than the reporting node is expecting to handle and can result in negative impacts to the stability of the reporting node.
次に、対応するノードのサービス要求が1秒あたり1000要求に急増すると仮定します。反応ノードは、トラフィックの10％削減を求めるレポートノードの要求を引き続き受け入れます。この結果、この例では、反応するノードが1秒あたり900のDiameterトランザクションを送信し、1秒あたりの残りの100トランザクションを削減します。このトラフィックの急増は、レポートノードが処理することを期待しているよりも大幅に高く、レポートノードの安定性に悪影響を及ぼす可能性があります。
The reporting node can, and likely would, send another Overload report requesting that the reacting node abate 91% of requests to get back to the desired 90 transactions per second. However, once the spike has abated and the rate at which the reacting node handles requests has returned to 100 per second, this will result in just 9 transactions per second being sent to the reporting node, requiring a new Overload report setting the reduction percentage back to 10%. This control feedback loop has the potential to make the situation worse by causing wide fluctuations in traffic on multiple nodes in the Diameter network.
レポートノードは、対応するノードが要求の91％を減らして1秒あたりの望ましい90トランザクションに戻るよう要求する別のオーバーロードレポートを送信できます。ただし、スパイクが収まり、反応ノードがリクエストを処理するレートが1秒あたり100に戻ると、レポートノードに送信されるトランザクションは1秒あたり9トランザクションになり、削減率を設定する新しいオーバーロードレポートが必要になります。 10％に。この制御フィードバックループは、Diameterネットワークの複数のノードでトラフィックに大きな変動を引き起こすことにより、状況を悪化させる可能性があります。
One of the benefits of a rate-based algorithm over the loss algorithm is that it better handles spikes in traffic. Instead of sending a request to reduce traffic by a percentage, the rate approach allows the reporting node to specify the maximum number of Diameter requests per second that can be sent to the reporting node. For instance, in this example, the reporting node could send a rate-based request specifying the maximum transactions per second to be 90. The reacting node will send the 90 regardless of whether it is receiving 100 or 1000 service requests per second.
損失アルゴリズムに対するレートベースアルゴリズムの利点の1つは、トラフィックのスパイクをより適切に処理できることです。割合でトラフィックを削減するリクエストを送信する代わりに、レートアプローチでは、レポートノードがレポートノードに送信できる1秒あたりのDiameterリクエストの最大数を指定できます。たとえば、この例では、レポートノードは、1秒あたりの最大トランザクションを90に指定するレートベースの要求を送信できます。反応するノードは、1秒あたり100または1000のサービス要求を受信しているかどうかに関係なく、90を送信します。
It should be noted that one of the implications of the rate-based algorithm is that the reporting node needs to determine how it wants to distribute its load over the set of reacting nodes from which it is receiving traffic. For instance, if the reporting node is receiving Diameter traffic from 10 reacting nodes and has a capacity of 100 transactions per second, then the reporting node could choose to set the rate for each of the reacting nodes to 10 transactions per second. This, of course, is assuming that each of the reacting nodes has equal performance characteristics. The reporting node could also choose to have a high-capacity reacting node send 55 transactions per second and the remaining 9 low-capacity reacting nodes send 5 transactions per second. The ability of the reporting node to specify the amount of traffic on a per-reacting-node basis implies that the reporting node must maintain state for each of the reacting nodes. This state includes the current allocation of Diameter traffic to that reacting node. If the number of reacting nodes changes, either because new nodes are added, nodes are removed from service, or nodes fail, then the reporting node will need to redistribute the maximum Diameter transactions over the new set of reacting nodes.
レートベースアルゴリズムの影響の1つは、レポートノードが、トラフィックの受信元である一連の反応ノードに負荷を分散する方法を決定する必要があることです。たとえば、レポートノードが10個の反応ノードからDiameterトラフィックを受信しており、1秒あたり100トランザクションの容量がある場合、レポートノードは各反応ノードのレートを1秒あたり10トランザクションに設定することを選択できます。もちろん、これは反応するノードのそれぞれが等しいパフォーマンス特性を持っていることを前提としています。レポートノードは、高容量の反応ノードが1秒あたり55のトランザクションを送信し、残りの9つの低容量の反応ノードが1秒あたり5のトランザクションを送信するように選択することもできます。レポートノードが反応ノードごとにトラフィック量を指定できることは、レポートノードが各反応ノードの状態を維持する必要があることを意味します。この状態には、対応するノードへのDiameterトラフィックの現在の割り当てが含まれます。新しいノードが追加された、ノードがサービスから削除された、またはノードが失敗したなどの理由で反応ノードの数が変化した場合、レポートノードは新しい反応ノードのセット全体で最大Diameterトランザクションを再分散する必要があります。
This document extends the base Diameter Overload Indication Conveyance (DOIC) solution [RFC7683] to add support for the rate abatement algorithm.
このドキュメントは、基本的なDiameter Overload Indication Conveyance（DOIC）ソリューション[RFC7683]を拡張して、レート削減アルゴリズムのサポートを追加します。
This document draws heavily on work in the SIP Overload Control Working Group. The definition of the rate abatement algorithm is copied almost verbatim from the SIP Overload Control (SOC) document [RFC7415], with changes focused on making the wording consistent with the DOIC solution and the Diameter protocol.
このドキュメントは、SIP過負荷制御ワーキンググループの作業に重点を置いています。レート削減アルゴリズムの定義は、SIPオーバーロードコントロール（SOC）ドキュメント[RFC7415]からほぼそのままコピーされており、DOICソリューションとDiameterプロトコルとの一貫性のある表現に焦点が変更されています。
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]で説明されているように解釈されます。
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]
DOIC Node
DOICノード
A Diameter node that supports the DOIC solution defined in [RFC7683]
[RFC7683]で定義されたDOICソリューションをサポートするDiameterノード
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ノード
As of the publication of this specification, there are three DOIC report types:
この仕様の公開時点では、3つのDOICレポートタイプがあります。
HOST_REPORT 0: Overload of a specific Diameter application at a specific Diameter node as defined in [RFC7683]
HOST_REPORT 0：[RFC7683]で定義されている特定のDiameterノードでの特定のDiameterアプリケーションのオーバーロード
REALM_REPORT 1: Overload of a specific Diameter application at a specific Diameter realm as defined in [RFC7683]
REALM_REPORT 1：[RFC7683]で定義されている特定のDiameterレルムでの特定のDiameterアプリケーションのオーバーロード
PEER_REPORT 2: Overload of a specific Diameter peer as defined in [RFC8581]
PEER_REPORT 2：[RFC8581]で定義されている特定のDiameterピアのオーバーロード
The rate algorithm MAY be selected by reporting nodes for any of these report types.
レートアルゴリズムは、これらのレポートタイプのいずれかのレポートノードによって選択される場合があります。
It is expected that all report types defined in the future will indicate whether or not the rate algorithm can be used with that report type.
将来定義されるすべてのレポートタイプは、レートアルゴリズムをそのレポートタイプで使用できるかどうかを示すことが期待されます。
This document defines the rate abatement algorithm (referred to as "rate" in this document) feature. Support for the rate feature by a DOIC node will be indicated by a new value of the OC-Feature-Vector attribute-value pair (AVP), as described in Section 7.1.1, per the rules defined in [RFC7683].
このドキュメントでは、レート削減アルゴリズム（このドキュメントでは「レート」と呼びます）機能を定義しています。 [RFC7683]で定義されているルールに従って、セクション7.1.1で説明されているように、DOICノードによるレート機能のサポートは、OC-Feature-Vector属性値ペア（AVP）の新しい値によって示されます。
Since all nodes that support DOIC are required to support the loss algorithm, DOIC nodes supporting the rate feature will support both the loss and rate abatement algorithms.
DOICをサポートするすべてのノードは損失アルゴリズムをサポートする必要があるため、レート機能をサポートするDOICノードは、損失アルゴリズムとレート削減アルゴリズムの両方をサポートします。
DOIC reacting nodes supporting the rate feature MUST indicate support for both the loss and rate algorithms in the OC-Feature-Vector AVP and MAY indicate support for other algorithms.
レート機能をサポートするDOIC反応ノードは、OC-Feature-Vector AVPの損失アルゴリズムとレートアルゴリズムの両方のサポートを示す必要があり、他のアルゴリズムのサポートを示す場合があります。
As defined in [RFC7683], a DOIC reporting node supporting the rate feature selects a single abatement algorithm in the OC-Feature-Vector AVP and OC-Peer-Algo AVP in the answer message sent to the DOIC reacting nodes.
[RFC7683]で定義されているように、レート機能をサポートするDOICレポートノードは、DOIC反応ノードに送信される応答メッセージのOC-Feature-Vector AVPおよびOC-Peer-Algo AVPで単一の軽減アルゴリズムを選択します。
A reporting node can select one abatement algorithm to apply to Host and Realm reports, and a different algorithm to apply to peer reports.
レポートノードは、ホストおよびレルムレポートに適用する1つの削減アルゴリズムと、ピアレポートに適用する別のアルゴリズムを選択できます。
For Host or Realm reports, the selected algorithm is reflected in the OC-Feature-Vector AVP sent as part of the OC-Supported-Features AVP included in answer messages for transactions where the request contained an OC-Supported-Features AVP. This is per the procedures defined in [RFC7683].
ホストまたはレルムレポートの場合、選択したアルゴリズムは、リクエストにOC-Supported-Features AVPが含まれるトランザクションの応答メッセージに含まれるOC-Supported-Features AVPの一部として送信されるOC-Feature-Vector AVPに反映されます。これは、[RFC7683]で定義されている手順に従っています。
For Peer reports, the selected algorithm is reflected in the OC-Peer-Algo AVP sent as part of the OC-Supported-Features AVP included in answer messages for transactions where the request contained an OC-Supported-Features AVP. This is per the procedures defined in [RFC8581].
ピアレポートの場合、選択したアルゴリズムは、要求にOC-Supported-Features AVPが含まれるトランザクションの応答メッセージに含まれるOC-Supported-Features AVPの一部として送信されるOC-Peer-Algo AVPに反映されます。これは、[RFC8581]で定義されている手順に従っています。
This section describes any changes to the behavior defined in [RFC7683] for the handling of Overload reports when the rate abatement algorithm is used.
このセクションでは、レート削減アルゴリズムが使用されている場合の、[RFC7683]で定義されている過負荷レポートの処理に関する動作の変更について説明します。
A reporting node that uses the rate abatement algorithm SHOULD maintain reporting-node Overload Control State (OCS) for each reacting node to which it sends a rate Overload Report (OLR).
レート削減アルゴリズムを使用するレポートノードは、レート過負荷レポート（OLR）の送信先である各反応ノードのレポートノード過負荷制御状態（OCS）を維持する必要があります（SHOULD）。
Note: This is different from the behavior defined in [RFC7683] where a reporting node sends a single loss percentage to all reacting nodes.
注：これは、[RFC7683]で定義されている動作とは異なります。この場合、レポートノードは単一の損失率をすべての反応ノードに送信します。
A reporting node SHOULD maintain OCS entries when using the rate abatement algorithm per supported Diameter application, per targeted reacting node and per report type.
レポートノードは、サポートされているDiameterアプリケーションごと、対象となる反応ノードごと、およびレポートタイプごとにレート削減アルゴリズムを使用するときに、OCSエントリを維持する必要があります（SHOULD）。
A rate OCS entry is identified by the tuple of Application-ID, report type, and DiameterIdentity of the target of the rate OLR.
レートOCSエントリは、アプリケーションOID、レポートタイプ、およびレートOLRのターゲットのDiameterIdentityのタプルによって識別されます。
The rate OCS entry SHOULD include the rate allocated to the reacting node.
レートOCSエントリには、対応するノードに割り当てられたレートを含める必要があります（SHOULD）。
A reporting node that has selected the rate abatement algorithm MUST indicate the rate requested to be applied by DOIC reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP.
レート削減アルゴリズムを選択したレポートノードは、OC-OLR AVPに含まれるOC-Maximum-Rate AVPのDOIC反応ノードによって適用されるように要求されたレートを示す必要があります。
All other elements for the OCS defined in [RFC7683] and [RFC8581] also apply to the reporting node's OCS when using the rate abatement algorithm.
[RFC7683]と[RFC8581]で定義されているOCSの他のすべての要素は、レート削減アルゴリズムを使用する場合、レポートノードのOCSにも適用されます。
A reacting node that supports the rate abatement algorithm MUST indicate rate as the selected abatement algorithm in the reacting-node OCS based on the OC-Feature-Vector AVP or the OC-Peer-Algo AVP in the received OC-Supported-Features AVP.
レート削減アルゴリズムをサポートする反応ノードは、受信したOC-Supported-Features AVPのOC-Feature-Vector AVPまたはOC-Peer-Algo AVPに基づいて、反応ノードOCSで選択された削減アルゴリズムとしてレートを示す必要があります。
A reacting node that supports the rate abatement algorithm MUST include the rate specified in the OC-Maximum-Rate AVP included in the OC-OLR AVP as an element of the abatement-algorithm-specific portion of reacting-node OCS entries.
レート削減アルゴリズムをサポートする反応ノードは、OC-OLR AVPに含まれるOC-Maximum-Rate AVPで指定されたレートを、反応ノードOCSエントリの削減アルゴリズム固有部分の要素として含める必要があります。
All other elements for the OCS defined in [RFC7683] and [RFC8581] also apply to the reporting nodes OCS when using the rate abatement algorithm.
[RFC7683]と[RFC8581]で定義されているOCSの他のすべての要素は、レート削減アルゴリズムを使用するときにレポートノードOCSにも適用されます。
A reporting node that has selected the rate abatement algorithm and enters an overload condition MUST indicate rate as the abatement algorithm and MUST indicate the selected rate in the resulting reporting-node OCS entries.
レート削減アルゴリズムを選択して過負荷状態になったレポートノードは、削減アルゴリズムとしてレートを示し、結果のレポートノードOCSエントリで選択したレートを示す必要があります。
When selecting the rate algorithm in the response to a request that contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP indicating support for the rate feature, a reporting node MUST ensure that a reporting-node OCS entry exists for the target of the Overload report. The target is defined as follows:
レート機能のサポートを示すOC-Feature-Vector AVPを含むOC-Supporting-Features AVPを含むリクエストへの応答でレートアルゴリズムを選択する場合、レポートノードは、レポートノードOCSエントリが存在することを確認する必要があります。過負荷レポートのターゲット。ターゲットは次のように定義されます。
o For Host reports, the target is the DiameterIdentity contained in the Origin-Host AVP received in the request.
o ホストレポートの場合、ターゲットは、リクエストで受信したOrigin-Host AVPに含まれるDiameterIdentityです。
o For Realm reports, the target is the DiameterIdentity contained in the Origin-Realm AVP received in the request.
o レルムレポートの場合、ターゲットは、リクエストで受信したOrigin-Realm AVPに含まれるDiameterIdentityです。
o For Peer reports, the target is the DiameterIdentity of the Diameter peer from which the request was received.
o ピアレポートの場合、ターゲットは、リクエストの受信元のDiameterピアのDiameterIdentityです。
A reporting node that receives a capability announcement from a new reacting node, meaning a reacting node for which it does not have an OCS entry, and the reporting node that chooses the rate algorithm for that reacting node may need to recalculate the rate to be allocated to all reacting nodes. Any changed rate values will be communicated in the next OLR sent to each reacting node.
新しい反応ノード、つまりOCSエントリがない反応ノードから機能アナウンスを受信するレポートノード、およびその反応ノードのレートアルゴリズムを選択するレポートノードは、割り当てられるレートを再計算する必要がある場合があります。すべての反応ノードに。変更されたレート値は、各反応ノードに送信される次のOLRで通知されます。
When receiving an answer message indicating that the reporting node has selected the rate algorithm, a reacting node MUST indicate the rate abatement algorithm in the reacting-node OCS entry for the reporting node.
レポートノードがレートアルゴリズムを選択したことを示す応答メッセージを受信すると、反応ノードは、レポートノードの反応ノードOCSエントリでレート削減アルゴリズムを示さなければなりません（MUST）。
A reacting node receiving an Overload report for the rate abatement algorithm MUST save the rate received in the OC-Maximum-Rate AVP contained in the OC-OLR AVP in the reacting-node OCS entry.
レート削減アルゴリズムの過負荷レポートを受信する反応ノードは、反応ノードOCSエントリのOC-OLR AVPに含まれるOC-Maximum-Rate AVPで受信したレートを保存する必要があります。
When in an overload condition with rate selected as the overload abatement algorithm and when handling a request that contained an OC-Supported-Features AVP that indicated support for the rate abatement algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate algorithm using the parameters stored in the reporting-node OCS for the target of the Overload report.
過負荷軽減アルゴリズムとしてレートが選択された過負荷状態で、レート軽減アルゴリズムのサポートを示すOC-Supported-Features AVPを含むリクエストを処理する場合、レポートノードはレートアルゴリズムのOC-OLR AVPを含める必要があります過負荷レポートのターゲットとして、レポートノードOCSに格納されているパラメーターを使用します。
Note: It is also possible for the reporting node to send Overload reports with the rate algorithm indicated even when the reporting node is not in an overloaded state. This could be a strategy to proactively avoid entering into an overloaded state. Whether or not to do so is up to local policy.
注：また、レポートノードが過負荷状態にない場合でも、レポートノードがレートアルゴリズムが示された過負荷レポートを送信することもできます。これは、過負荷状態になるのを予防的に回避するための戦略である可能性があります。そうするかどうかは地域の方針次第です。
When sending an Overload report for the rate algorithm, the OC-Maximum-Rate AVP MUST be included in the OC-OLR AVP and the OC-Reduction-Percentage AVP MUST NOT be included.
レートアルゴリズムの過負荷レポートを送信する場合、OC-Maximum-Rate AVPをOC-OLR AVPに含める必要があり、OC-Reduction-Percentage AVPを含めることはできません。
When determining if abatement treatment should be applied to a request being sent to a reporting node that has selected the rate abatement algorithm, the reacting node can choose to use the algorithm detailed in Section 8.
レート削減アルゴリズムを選択したレポートノードに送信されるリクエストに削減処理を適用する必要があるかどうかを判断する場合、対応するノードは、セクション8で詳述されているアルゴリズムの使用を選択できます。
Other algorithms for controlling the rate MAY be implemented by the reacting node. Any algorithm implemented MUST correctly limit the maximum rate of traffic being sent to the reporting node.
レートを制御するための他のアルゴリズムは、反応するノードによって実装される場合があります。実装されているアルゴリズムは、レポートノードに送信されるトラフィックの最大レートを正しく制限する必要があります。
Once a determination is made by the reacting node that an individual Diameter request is to be subjected to abatement treatment, then the procedures for throttling and diversion defined in [RFC7683] and [RFC8581] apply.
個々のDiameterリクエストが削減処理の対象であると反応ノードによって決定されると、[RFC7683]と[RFC8581]で定義されたスロットリングと宛先変更の手順が適用されます。
The rate algorithm does not add any new AVPs to the OC-Supported-Features AVP.
レートアルゴリズムは、OC-Supported-Features AVPに新しいAVPを追加しません。
The rate algorithm does add a new feature bit to be carried in the OC-Feature-Vector AVP.
レートアルゴリズムは、OC-Feature-Vector AVPで伝送される新しい機能ビットを追加します。
This extension adds the following capability to the OC-Feature-Vector AVP.
この拡張機能は、OC-Feature-Vector AVPに次の機能を追加します。
OLR_RATE_ALGORITHM (0x0000000000000004)
OLR_RATE_ALGORITHM（0x0000000000000004）
This bit is assigned to the rate abatement algorithm. When this flag is set by the overload-control endpoint, it indicates that the DOIC node supports the rate abatement algorithm.
このビットは、レート削減アルゴリズムに割り当てられます。このフラグが過負荷制御エンドポイントによって設定されている場合、DOICノードがレート削減アルゴリズムをサポートしていることを示しています。
This extension defines the OC-Maximum-Rate AVP to be an optional part of the OC-OLR AVP.
この拡張機能は、OC-Maximum-Rate AVPをOC-OLR AVPのオプション部分として定義します。
OC-OLR ::= < AVP Header: 623 >
< OC-Sequence-Number >
< OC-Report-Type >
[ OC-Reduction-Percentage ]
[ OC-Validity-Duration ]
[ SourceID ]
[ OC-Maximum-Rate ]
* [ AVP ]
This extension makes no changes to the other AVPs that are part of the OC-OLR AVP.
この拡張機能は、OC-OLR AVPの一部である他のAVPに変更を加えません。
This extension does not define new Overload report types. The existing report types of HOST_REPORT and REALM_REPORT defined in [RFC7683] apply to the rate control algorithm. The report type of PEER_REPORT defined in [RFC8581] also applies to the rate control algorithm.
この拡張機能は、新しいオーバーロードレポートタイプを定義しません。 [RFC7683]で定義されているHOST_REPORTおよびREALM_REPORTの既存のレポートタイプは、レート制御アルゴリズムに適用されます。 [RFC8581]で定義されているPEER_REPORTのレポートタイプは、レート制御アルゴリズムにも適用されます。
The OC-Maximum-Rate AVP (AVP code 670) is of type Unsigned32 and describes the maximum rate that the sender is requested to send traffic. This is specified in terms of requests per second.
OC-Maximum-Rate AVP（AVPコード670）のタイプはUnsigned32であり、送信者がトラフィックの送信を要求される最大レートを示します。これは、1秒あたりのリクエスト数で指定されます。
A value of zero indicates that no traffic is to be sent.
ゼロの値は、トラフィックが送信されないことを示します。
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+---------------------------------------------------------+----+----+
|OC-Maximum-Rate 670 7.2.1 Unsigned32 | | V |
+---------------------------------------------------------+----+----+
This section is pulled from [RFC7415] with minor changes needed to make it apply to the Diameter protocol.
このセクションは、[RFC7415]から抜粋して、Diameterプロトコルに適用するために若干の変更が必要です。
The reporting node is the one protected by the overload control algorithm defined here. The reacting node is the one that abates traffic towards the server.
レポートノードは、ここで定義される過負荷制御アルゴリズムによって保護されるノードです。反応ノードは、サーバーへのトラフィックを削減するノードです。
Following the procedures defined in [RFC7683], the reacting node and reporting node signal their support for rate-based overload control.
[RFC7683]で定義されている手順に従って、反応ノードと報告ノードは、レートベースの過負荷制御のサポートを通知します。
Then, periodically, the reporting node relies on internal measurements (e.g., CPU utilization or queuing delay) to evaluate its overload state and estimate a target maximum Diameter request rate in number of requests per second (as opposed to target percent reduction in the case of loss-based abatement).
次に、定期的に、レポートノードは内部測定値（CPU使用率やキューイング遅延など）に依存してその過負荷状態を評価し、1秒あたりのリクエスト数でターゲットの最大Diameterリクエストレートを推定します（損失ベースの削減）。
When in an overloaded state, the reporting node uses the OC-OLR AVP to inform reacting nodes of its overload state and of the target Diameter request rate.
過負荷状態の場合、レポートノードはOC-OLR AVPを使用して、過負荷状態とターゲットDiameter要求レートを反応ノードに通知します。
Upon receiving the Overload report with a target maximum Diameter request rate, each reacting node applies overload abatement for new Diameter requests towards the reporting node.
ターゲットの最大Diameterリクエストレートを含む過負荷レポートを受信すると、各反応ノードは、レポートノードに向けて新しいDiameterリクエストに過負荷軽減を適用します。
The actual algorithm used by the reporting node to determine its overload state and estimate a target maximum Diameter request rate is beyond the scope of this document.
レポートノードが過負荷状態を判断し、ターゲットの最大Diameterリクエストレートを推定するために使用する実際のアルゴリズムは、このドキュメントの範囲外です。
However, the reporting node MUST periodically evaluate its overload state and estimate a target Diameter request rate beyond which it would become overloaded. The reporting node must allocate a portion of the target Diameter request rate to each of its reacting nodes. The reporting node may set the same rate for every reacting node, or may set different rates for different reacting nodes.
ただし、レポートノードは定期的にその過負荷状態を評価し、それを超えると過負荷になる目標Diameter要求レートを推定する必要があります。レポートノードは、対応する各ノードにターゲットDiameter要求レートの一部を割り当てる必要があります。レポートノードは、すべての反応ノードに同じレートを設定することも、異なる反応ノードに異なるレートを設定することもできます。
The maximum rate determined by the reporting node for a reacting node applies to the entire stream of Diameter requests, even though abatement may only affect a particular subset of the requests, since the reacting node might apply priority as part of its decision of which requests to abate.
反応ノードが要求の決定の一部として優先度を適用する可能性があるため、削減は要求の特定のサブセットにのみ影響を与える可能性があるにもかかわらず、反応ノードのレポートノードによって決定される最大レートは、Diameter要求のストリーム全体に適用されます軽減する。
When setting the maximum rate for a particular reacting node, the reporting node may need to take into account the workload (e.g., CPU load per request) of the distribution of message types from that reacting node. Furthermore, because the reacting node may prioritize the specific types of messages it sends while under overload restriction, this distribution of message types may be different from the message distribution for that reacting node under non-overload conditions (e.g., either higher or lower CPU load).
特定の反応ノードの最大レートを設定する場合、レポートノードは、その反応ノードからのメッセージタイプの分散のワークロード（リクエストごとのCPU負荷など）を考慮する必要がある場合があります。さらに、反応ノードは、過負荷制限下で送信する特定のタイプのメッセージに優先順位を付ける可能性があるため、このメッセージタイプの分布は、非過負荷状態（たとえば、CPU負荷が高いまたは低い）での反応ノードのメッセージ分布とは異なる場合があります。 ）。
Note that the value of OC-Maximum-Rate AVP (in request messages per second) for the rate algorithm provides a loose upper bound on the traffic sent by the reacting node to the reporting node.
レートアルゴリズムのOC-Maximum-Rate AVP（リクエストメッセージ/秒）の値は、反応ノードからレポートノードに送信されるトラフィックの緩やかな上限を提供することに注意してください。
In other words, when multiple reacting nodes are being controlled by an overloaded reporting node, at any given time, some reporting nodes may receive requests at a rate below its target maximum Diameter request rate while receiving others above that target rate. But, the resulting request rate presented to the overloaded reporting node will converge towards the target Diameter request rate or a lower rate.
言い換えると、複数の反応ノードが過負荷のレポートノードによって制御されている場合、常に、一部のレポートノードはターゲットの最大Diameterリクエストレートを下回るレートでリクエストを受信し、そのターゲットレートを超える他のノードを受信する場合があります。ただし、過負荷のレポートノードに提示される結果のリクエストレートは、ターゲットのDiameterリクエストレートまたはそれよりも低いレートに収束します。
Upon detection of overload, and the determination to invoke overload controls, the reporting node follows the specifications in [RFC7683] to notify its reacting nodes of the allocated target maximum Diameter request rate, and to notify them that the rate abatement is in effect.
過負荷の検出、および過負荷制御を呼び出す決定の際に、レポートノードは[RFC7683]の仕様に従って、割り当てられたターゲット最大Diameterリクエストレートを反応ノードに通知し、レート削減が有効であることを通知します。
The reporting node uses the OC-Maximum-Rate AVP defined in this specification to communicate a target maximum Diameter request rate to each of its clients.
レポートノードは、この仕様で定義されたOC-Maximum-Rate AVPを使用して、ターゲットの最大Diameterリクエストレートを各クライアントに通知します。
A reference algorithm is shown below.
参照アルゴリズムを以下に示します。
Note that use of "//" below indicates a comment.
以下の「//」の使用はコメントを示すことに注意してください。
No priority case:
優先ケースなし：
// T: inter-transmission interval, set to 1 / OC-Maximum-Rate
// TAU: tolerance parameter
// ta: arrival time of the most recent arrival
// LCT: arrival time of last Diameter request that
// was sent to the server
// (initialized to the first arrival time)
// X: current value of the leaky bucket counter (initialized to
// TAU0)
// After most recent arrival, calculate auxiliary variable Xp
Xp = X - (ta - LCT);
if (Xp <= TAU) {
// Transmit Diameter request
// Update X and LCT
X = max (0, Xp) + T;
LCT = ta;
} else {
// Reject Diameter request
// Do not update X and LCT
}
In determining whether or not to transmit a specific message, the reacting node can use any algorithm that limits the message rate to the OC-Maximum-Rate AVP value in units of messages per second. For ease of discussion, we define T = 1/[OC-Maximum-Rate] as the target inter-Diameter request interval. It may be strictly deterministic, or it may be probabilistic. It may or may not have a tolerance factor, to allow for short bursts, as long as the long-term rate remains below 1/T.
特定のメッセージを送信するかどうかを決定する際、反応するノードは、メッセージレートをOC-Maximum-Rate AVP値（1秒あたりのメッセージ数）に制限するアルゴリズムを使用できます。説明を簡単にするために、T = 1 / [OC-Maximum-Rate]をターゲットの直径間要求間隔として定義します。厳密に決定的である場合もあれば、確率的である場合もあります。長期的なレートが1 / T未満のままである限り、短いバーストを可能にする許容係数がある場合とない場合があります。
The algorithm may have provisions for prioritizing traffic.
アルゴリズムには、トラフィックを優先するための規定がある場合があります。
If the algorithm requires other parameters (in addition to "T", which is 1/OC-Maximum-Rate), they may be set autonomously by the reacting node, or they may be negotiated independently between the reacting node and the reporting node.
アルゴリズムが他のパラメーターを必要とする場合（「T」に加えて、1 / OC-Maximum-Rate）、パラメーターは反応ノードによって自律的に設定されるか、反応ノードとレポートノードの間で独立してネゴシエートされる場合があります。
In either case, the coordination is out of the scope of this document. The default algorithms presented here (one with and one without provisions for prioritizing traffic) are only examples.
どちらの場合も、調整はこのドキュメントの範囲外です。ここに提示されているデフォルトのアルゴリズム（1つはトラフィックの優先順位付けのプロビジョニングあり、もう1つはなし）は単なる例です。
To apply abatement treatment to new Diameter requests at the rate specified in the OC-Maximum-Rate AVP value sent by the reporting node to its reacting nodes, the reacting node MAY use the proposed default algorithm for rate-based control or any other equivalent algorithm that forward messages in conformance with the upper bound of 1/T messages per second.
レポートノードから対応ノードに送信されたOC-Maximum-Rate AVP値で指定されたレートで新しいDiameterリクエストに削減処理を適用するには、対応ノードがレートベースの制御用に提案されたデフォルトアルゴリズムまたはその他の同等のアルゴリズムを使用してもよい（MAY） 1秒あたり1 / Tメッセージの上限に準拠してメッセージを転送します。
The default leaky bucket algorithm presented here is based on Appendix A.2 of [ITU-T-I.371]. The algorithm makes it possible for reacting nodes to deliver Diameter requests at a rate specified in the OC-Maximum-Rate value with tolerance parameter TAU (preferably configurable).
ここに示すデフォルトのリーキーバケットアルゴリズムは、[ITU-T-I.371]の付録A.2に基づいています。このアルゴリズムにより、リアクションノードは、許容パラメーターTAU（できれば設定可能）を使用してOC-Maximum-Rate値で指定されたレートでDiameterリクエストを配信できます。
Conceptually, the leaky bucket algorithm can be viewed as a finite capacity bucket whose real-valued content drains out at a continuous rate of 1 unit of content per time unit and whose content increases by the increment T for each forwarded Diameter request. T is computed as the inverse of the rate specified in the OC-Maximum-Rate AVP value, namely T = 1 / OC-Maximum-Rate.
概念的には、リーキーバケットアルゴリズムは、実数値のコンテンツが時間単位あたり1ユニットのコンテンツの連続レートで排出され、転送される各Diameterリクエストの増分Tだけコンテンツが増加する有限容量バケットと見なすことができます。 Tは、OC-Maximum-Rate AVP値で指定されたレートの逆数、つまりT = 1 / OC-Maximum-Rateとして計算されます。
Note that when the OC-Maximum-Rate value is 0 with a non-zero OC-Validity-Duration, then the reacting node should apply abatement treatment to 100% of Diameter requests destined to the overloaded reporting node. However, when the OC-Validity-Duration value is 0, the reacting node should stop applying abatement treatment.
OC-Maximum-Rate値が0で、OC-Validity-Durationがゼロでない場合、反応するノードは、過負荷のレポートノード宛てのDiameterリクエストの100％に軽減処理を適用する必要があります。ただし、OC-Validity-Duration値が0の場合、反応するノードは削減処理の適用を停止する必要があります。
If, at a new Diameter request arrival, the content of the bucket is less than or equal to the limit value TAU, then the Diameter request is forwarded to the server; otherwise, the abatement treatment is applied to the Diameter request.
新しいDiameterリクエストの到着時に、バケットのコンテンツが制限値TAU以下の場合、Diameterリクエストはサーバーに転送されます。それ以外の場合、削減処理はDiameterリクエストに適用されます。
Note that the capacity of the bucket (the upper bound of the counter) is (T + TAU).
バケットの容量（カウンターの上限）は（T + TAU）であることに注意してください。
The tolerance parameter TAU determines how close the long-term admitted rate is to an ideal control that would admit all Diameter requests for arrival rates less than 1/T and then admit Diameter requests precisely at the rate of 1/T for arrival rates above 1/T. In particular, at mean arrival rates close to 1/T, it determines the tolerance to deviation of the inter-arrival time from T. (The larger TAU, the more tolerance to deviations from the inter-departure interval T.) This deviation from the inter-departure interval influences the admitted rate burstiness or the number of consecutive Diameter requests forwarded to the reporting node (burst size proportional to TAU over the difference between 1/T and the arrival rate).
許容パラメータTAUは、長期承認レートが、1 / T未満の到着レートに対するすべてのDiameterリクエストを承認し、1を超える到着レートに対して1 / TのレートでDiameterリクエストを正確に承認する理想的なコントロールにどれだけ近いかを決定します/ T。特に、1 / Tに近い平均到着率では、Tからの到着間時間の偏差に対する許容範囲を決定します（TAUが大きいほど、出発間隔Tからの偏差に対する許容範囲が大きくなります）。出発間隔は、許可されたレートのバースト性、またはレポートノードに転送される連続するDiameterリクエストの数に影響します（バーストサイズは、1 / Tと到着レートの差のTAUに比例します）。
In situations where reacting nodes are configured with some knowledge about the reporting node and other traffic sources (e.g., operator pre-provisioning), it can be beneficial to choose a value of TAU based on how many reacting nodes will be sending requests to the reporting node.
レポートノードおよび他のトラフィックソース（たとえば、オペレーターの事前プロビジョニング）に関する知識を備えた対応ノードが構成されている状況では、レポートにリクエストを送信する対応ノードの数に基づいてTAUの値を選択すると効果的です。ノード。
Reporting nodes with a very large number of reacting nodes, each with a relatively small arrival rate, will generally benefit from a smaller value for TAU in order to limit queuing (and hence response times) at the reporting node when subjected to a sudden surge of traffic from all reacting nodes. Conversely, a reporting node with a relatively small number of reacting nodes, each with a proportionally larger arrival rate, will benefit from a larger value of TAU.
非常に多数の反応ノードがあり、それぞれの到着率が比較的小さいレポートノードは、通常、TAUの値を小さくすると、レポートノードでのキューイング（および応答時間）を制限するために、すべての反応ノードからのトラフィック。逆に、反応ノードの数が比較的少なく、それぞれに比例して到着率が大きいレポートノードは、TAUの値が大きいほどメリットがあります。
Once the control has been activated, at the arrival time of the k-th new Diameter request, ta(k), the content of the bucket is provisionally updated to the value
コントロールがアクティブ化されると、k番目の新しいDiameterリクエストの到着時にta（k）で、バケットのコンテンツが値に暫定的に更新されます。
X' = X - (ta(k) - LCT)
where X is the value of the leaky bucket counter after arrival of the last forwarded Diameter request, and LCT is the time at which the last Diameter request was forwarded.
Xは、最後に転送されたDiameter要求の到着後のリーキーバケットカウンタの値であり、LCTは最後のDiameter要求が転送された時刻です。
If X' is less than or equal to the limit value TAU, then the new Diameter request is forwarded and the leaky bucket counter X is set to X' (or to 0 if X' is negative) plus the increment T, and LCT is set to the current time ta(k). If X' is greater than the limit value TAU, then the abatement treatment is applied to the new Diameter request, and the values of X and LCT are unchanged.
X 'が制限値TAU以下の場合、新しいDiameter要求が転送され、リーキーバケットカウンターXがX'（またはX 'が負の場合は0）に増分Tを加えた値に設定され、LCTは現在時刻ta（k）に設定します。 X 'が制限値TAUより大きい場合、削減処理が新しいDiameterリクエストに適用され、XとLCTの値は変更されません。
When the first response from the reporting node has been received, indicating control activation (OC-Validity-Duration>0), LCT is set to the time of activation, and the leaky bucket counter is initialized to the parameter TAU0 (preferably configurable), which is 0 or larger but less than or equal to TAU.
レポートノードからの最初の応答が受信され、制御のアクティブ化（OC-Validity-Duration> 0）が示されると、LCTがアクティブ化の時間に設定され、リーキーバケットカウンターがパラメーターTAU0（できれば設定可能）に初期化されます。これは0以上でTAU以下です。
TAU can assume any positive real number value and is not necessarily bounded by T.
TAUは任意の正の実数値を想定でき、必ずしもTによって制限されません。
TAU=4*T is a reasonable compromise between burst size and abatement rate adaptation at low offered rate.
TAU = 4 * Tは、バーストサイズと、低オファーレートでの削減率適応との間の妥当な妥協点です。
Note that specification of a value for TAU, and any communication or coordination between servers, is beyond the scope of this document.
TAUの値の指定、およびサーバー間の通信や調整は、このドキュメントの範囲を超えていることに注意してください。
A reference algorithm is shown below.
参照アルゴリズムを以下に示します。
Priority case:
優先ケース：
// T: inter-transmission interval, set to 1 / OC-Maximum-Rate
// TAU1: tolerance parameter of no priority Diameter requests
// TAU2: tolerance parameter of priority Diameter requests
// ta: arrival time of the most recent arrival
// LCT: arrival time of last Diameter request that
// was sent to the server
// (initialized to the first arrival time)
// X: current value of the leaky bucket counter (initialized to
// TAU0)
// After most recent arrival, calculate auxiliary variable Xp
Xp = X - (ta - LCT);
if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived &&
Xp <= TAU2 && Xp > TAU1) {
// Transmit Diameter request
// Update X and LCT
X = max (0, Xp) + T;
LCT = ta;
} else {
// Apply abatement treatment to Diameter request
// Do not update X and LCT
}
The reacting node is responsible for applying message priority and for maintaining two categories of requests: request candidates for reduction, and requests not subject to reduction (except under extenuating circumstances when there aren't any messages in the first category that can be reduced).
反応ノードは、メッセージの優先度を適用し、2つのカテゴリの要求を維持する責任があります。削減の候補の要求と、削減の対象外の要求（削減できる最初のカテゴリにメッセージがない状況の例外を除く）。
Accordingly, the proposed leaky bucket implementation is modified to support priority using two thresholds for Diameter requests in the set of request candidates for reduction. With two priorities, the proposed leaky bucket requires two thresholds TAU1 < TAU2:
したがって、提案されたリーキーバケット実装は、削減の要求候補のセットでDiameter要求の2つのしきい値を使用して優先度をサポートするように変更されます。 2つの優先度がある場合、提案されたリーキーバケットには2つのしきい値TAU1 <TAU2が必要です。
o All new requests would be admitted when the leaky bucket counter is at or below TAU1.
o すべての新しい要求は、リーキーバケットカウンタがTAU1以下になると許可されます。
o Only higher priority requests would be admitted when the leaky bucket counter is between TAU1 and TAU2.
o リーキーバケットカウンタがTAU1とTAU2の間にある場合は、優先度の高いリクエストのみが許可されます。
o All requests would be rejected when the bucket counter is above TAU2.
o バケットカウンタがTAU2を超えると、すべての要求が拒否されます。
This can be generalized to n priorities using n thresholds for n>2.
これは、n> 2のn個のしきい値を使用して、n個の優先度に一般化できます。
With a priority scheme that relies on two tolerance parameters (TAU2 influences the priority traffic, and TAU1 influences the non-priority traffic), always set TAU1 <= TAU2 (TAU is replaced by TAU1 and TAU2). Setting both tolerance parameters to the same value is equivalent to having no priority. TAU1 influences the admitted rate the same way as TAU does when no priority is set, and the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing.
2つの許容パラメータに依存する優先度スキーム（TAU2は優先トラフィックに影響を与え、TAU1は非優先トラフィックに影響を与える）では、常にTAU1 <= TAU2に設定します（TAUはTAU1とTAU2に置き換えられます）。両方の許容パラメータを同じ値に設定することは、優先度がないことと同じです。 TAU1は、優先度が設定されていない場合のTAUと同じように許容レートに影響し、TAU1とTAU2の差が大きいほど、厳密な優先キューイングに制御が近づきます。
TAU1 and TAU2 can assume any positive real number value and is not necessarily bounded by T.
TAU1およびTAU2は、任意の正の実数値を想定することができ、必ずしもTによって制限されません。
Reasonable values for TAU0, TAU1, and TAU2 are:
TAU0、TAU1、およびTAU2の妥当な値は次のとおりです。
o TAU0 = 0,
o TAU0 = 0、
o TAU1 = 1/2 * TAU2, and
o TAU1 = 1/2 * TAU2、および
o TAU2 = 10 * T.
o TAU2 = 10 *T。
Note that specification of a value for TAU1 and TAU2, and any communication or coordination between servers, is beyond the scope of this document.
TAU1とTAU2の値の指定、およびサーバー間の通信や調整は、このドキュメントの範囲を超えていることに注意してください。
As the number of reacting-node sources of traffic increases and the throughput of the reporting node decreases, the maximum rate admitted by each reacting node needs to decrease, and therefore the value of T becomes larger. Under some circumstances, e.g., if the traffic arises very quickly simultaneously at many sources, the occupancies of each bucket can become synchronized, resulting in both the admissions from each source being close in time and batched, or very "peaky" arrivals at the reporting node. This gives rise not only to control instability, but also very poor delays and even lost messages. An appropriate term for this is "resonance" [Erramilli].
トラフィックの反応ノードソースの数が増加し、レポートノードのスループットが低下すると、各反応ノードによって許可される最大レートを下げる必要があるため、Tの値は大きくなります。状況によっては、たとえば、トラフィックが多くのソースで同時に非常に速く発生した場合、各バケットの占有率が同期され、各ソースからのアドミッションの両方が時間的に近くバッチ処理されるか、レポートに非常に「ピーク」の到着が発生します。ノード。これにより、制御が不安定になるだけでなく、遅延が非常に少なくなり、メッセージが失われることもあります。これにふさわしい用語は「共鳴」[エラミリ]です。
If the network topology is such that resonance can occur, then a simple way to avoid resonance is to randomize the bucket occupancy at two appropriate points: at the activation of control, and whenever the bucket empties, as described below:
共振が発生する可能性があるネットワークトポロジの場合、共振を回避する簡単な方法は、以下のように、制御のアクティブ化時とバケットが空になるときの2つの適切な時点でバケット占有をランダム化することです。
After updating the value of the leaky bucket to X', generate a value u as follows:
リーキーバケットの値をX 'に更新した後、次のように値uを生成します。
if X' > 0, then u=0
X '> 0の場合、u = 0
else, if X' <= 0, then let u be set to a random value uniformly
distributed between -1/2 and +1/2
Then, (only) if the arrival is admitted, increase the bucket content by an amount T + uT, which will therefore be just T if the bucket hadn't emptied, or lie between T/2 and 3T/2 if it had.
次に、（のみ）到着が許可された場合、バケットの内容をT + uTだけ増やします。したがって、バケットが空にならなかった場合はTになり、空になった場合はT / 2と3T / 2の間にあります。
This randomization should also be done when control is activated, i.e., instead of simply initializing the leaky bucket counter to TAU0, initialize it to TAU0 + uT, where u is uniformly distributed as above. Since activation would have been a result of the response to a request sent by the reacting node, the second term in this expression can be interpreted as being the bucket increment following that admission.
このランダム化は、制御がアクティブになったときにも実行する必要があります。つまり、単にリーキーバケットカウンターをTAU0に初期化する代わりに、TAU0 + uTに初期化します。ここで、uは上記のように均一に分散されます。アクティブ化は、応答ノードによって送信された要求への応答の結果であったため、この式の2番目の用語は、その承認後のバケットの増分であると解釈できます。
This method has the following characteristics:
このメソッドには次の特性があります。
o If TAU0 is chosen to be equal to TAU and all sources activate control at the same time due to an extremely high request rate, then the time until the first request admitted by each reacting node would be uniformly distributed over [0,T];
o TAU0がTAUと等しくなるように選択され、リクエストレートが非常に高いためにすべてのソースが同時に制御をアクティブにする場合、各反応ノードによって許可された最初のリクエストまでの時間は[0、T]に均一に分散されます。
o The maximum occupancy is TAU + (3/2)T, rather than TAU + T without randomization;
o 最大占有率は、ランダム化なしのTAU + Tではなく、TAU +（3/2）Tです。
o For the special case of "classic gapping", where TAU=0, then the minimum time between admissions is uniformly distributed over [T/2, 3T/2], and the mean time between admissions is the same, i.e., T+1/R where R is the request arrival rate.
o 「クラシックギャッピング」の特別なケースでは、TAU = 0の場合、入院間の最小時間は[T / 2、3T / 2]に均一に分散され、入院間の平均時間は同じ、つまりT + 1になります。 / Rここで、Rは要求到着率です。
o At high load, randomization rarely occurs. Therefore, there is no loss of precision of the admitted rate, even though the randomized "phasing" of the buckets remains.
o 高負荷では、ランダム化はほとんど発生しません。したがって、バケットのランダム化された「フェーズ」が残っていても、許容レートの精度が失われることはありません。
IANA has registered the following values in the "Authentication, Authorization, and Accounting (AAA) Parameters" registry:
IANAは、「Authentication、Authorization、and Accounting（AAA）Parameters」レジストリに次の値を登録しています。
One new AVP code is defined in Section 7.2.1.
1つの新しいAVPコードがセクション7.2.1で定義されています。
One new OC-Feature-Vector AVP value is defined in Section 7.1.1.
1つの新しいOC-Feature-Vector AVP値がセクション7.1.1で定義されています。
As indicated in Section 7.1.1, a new allocation has been made for the OC-Feature-Vector AVP.
セクション7.1.1に示すように、OC-Feature-Vector AVPに新しい割り当てが行われました。
The rate abatement mechanism is an extension to the base Diameter Overload mechanism. As such, all of the security considerations outlined in [RFC7683] apply to the rate abatement mechanism.
レート削減メカニズムは、基本のDiameter Overloadメカニズムを拡張したものです。そのため、[RFC7683]で概説されているすべてのセキュリティの考慮事項は、レート削減メカニズムに適用されます。
In addition, the rate algorithm could be used to handle denial-of-service (DoS) attacks more effectively than the loss algorithm.
さらに、レートアルゴリズムを使用すると、損失アルゴリズムよりもサービス拒否（DoS）攻撃を効果的に処理できます。
[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>。
[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>。
[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。、「Diameter Agent Overload and the Peer Overload Report」、RFC 8581、DOI 10.17487 / RFC8581、2019年8月、<https://www.rfc-editor.org/info/rfc8581>。
[Erramilli] Erramilli, A. and L. Forys, "Traffic Synchronization Effects In Teletraffic Systems", 1991.
[Erramilli] Erramilli、A.およびL. Forys、「テレトラフィックシステムにおけるトラフィック同期効果」、1991年。
[ITU-T-I.371] ITU-T, "Traffic control and congestion control in B-ISDN", ITU-T Recommendation I.371, March 2004.
[ITU-T-I.371] ITU-T、「B-ISDNのトラフィック制御と輻輳制御」、ITU-T勧告I.371、2004年3月。
[RFC7415] Noel, E. and P. Williams, "Session Initiation Protocol (SIP) Rate Control", RFC 7415, DOI 10.17487/RFC7415, February 2015, <https://www.rfc-editor.org/info/rfc7415>.
[RFC7415]ノエル、E.、P。ウィリアムス、「Session Initiation Protocol（SIP）Rate Control」、RFC 7415、DOI 10.17487 / RFC7415、2015年2月、<https://www.rfc-editor.org/info/rfc7415 >。
Acknowledgements
謝辞
The authors would like to thank Lionel Morand for his contributions to this document.
著者は、Lionel Morandがこの文書に貢献してくれたことに感謝します。
Authors' Addresses
著者のアドレス
Steve Donovan (editor) 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
Eric Noel AT&T Labs 200s Laurel Avenue Middletown, NJ 07747 United States of America
エリックノエルAT＆Tラボ200年代ローレルアベニューミドルタウン、ニュージャージー州07747アメリカ合衆国
Email: ecnoel@research.att.com