[要約] RFC 8583は、Diameterプロトコルを使用して負荷情報を伝達するための仕様です。目的は、ネットワークの負荷状況を追跡し、リソースの効率的な管理を可能にすることです。
Internet Engineering Task Force (IETF) B. Campbell
Request for Comments: 8583 S. Donovan, Ed.
Category: Standards Track Oracle
ISSN: 2070-1721 JJ. Trottin
Nokia
August 2019
Diameter Load Information Conveyance
直径負荷情報伝達
Abstract
概要
RFC 7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The base solution defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC)) describes a mechanism meeting most of the requirements but does not currently include the ability to send load information. This document defines a mechanism for the conveying of Diameter load information.
RFC 7068は、Diameterのオーバーロード制御の要件を記述しています。これには、ノードが過負荷になっていなくても、Diameterノードが「負荷」情報を送信できるようにする要件が含まれます。 RFC 7683（直径過負荷情報伝達（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/rfc8583.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8583で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Differences between Load and Overload Information . . . . 5
4.2. How Is Load Information Used? . . . . . . . . . . . . . . 6
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 9
6. Load-Mechanism Procedures . . . . . . . . . . . . . . . . . . 11
6.1. Reporting-Node Behavior . . . . . . . . . . . . . . . . . 11
6.1.1. Endpoint Reporting-Node Behavior . . . . . . . . . . 11
6.1.2. Agent Reporting-Node Behavior . . . . . . . . . . . . 12
6.2. Reacting-Node Behavior . . . . . . . . . . . . . . . . . 13
6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 14
6.4. Addition and Removal of Nodes . . . . . . . . . . . . . . 14
7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 15
7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 15
7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 18
A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 18
A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 19
A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 19
A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 21
A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 21
A.7. Fully-Meshed Layers . . . . . . . . . . . . . . . . . . . 22
A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 22
A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
[RFC7068] describes requirements for Overload Control in Diameter [RFC6733]. The DIME Working Group has finished the Diameter Overload Information Conveyance (DOIC) mechanism [RFC7683]. As currently specified, DOIC fulfills some, but not all, of the requirements.
[RFC7068]は、Diameter [RFC6733]の過負荷制御の要件を説明しています。 DIMEワーキンググループは、Diameterオーバーロード情報伝達（DOIC）メカニズム[RFC7683]を終了しました。現在指定されているように、DOICはすべてではなく一部の要件を満たしています。
In particular, DOIC does not fulfill Req 23 and Req 24:
特に、DOICはReq 23およびReq 24を満たしていません。
REQ 23: The solution MUST provide sufficient information to enable a load-balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them.
REQ 23：ソリューションは、負荷分散ノードが、過負荷のアップストリームノードによって拒否またはその他の方法で抑制されたメッセージを、それらを処理するのに十分な容量を持つ可能性が最も高い他のアップストリームノードに迂回できるようにするのに十分な情報を提供する必要があります。
REQ 24: The solution MUST provide a mechanism for indicating load levels, even when not in an overload condition, to assist nodes in making decisions to prevent overload conditions from occurring.
REQ 24：ソリューションは、過負荷状態でない場合でも、ノードが過負荷状態の発生を防ぐための決定を行うのを支援するために、負荷レベルを示すメカニズムを提供する必要があります。
There are several other requirements in [RFC7068] that mention both overload and load information that are only partially fulfilled by DOIC.
[RFC7068]には、DOICによって部分的にのみ満たされる過負荷情報と負荷情報の両方に言及している他のいくつかの要件があります。
The DIME Working Group explicitly chose not to fulfill these requirements when publishing DOIC [RFC7683] due to several reasons. A principal reason was that the working group did not agree on a general approach for conveying load information. It chose to progress the rest of DOIC and deferred load information conveyance to a DOIC extension or a separate mechanism.
DIMEワーキンググループは、いくつかの理由により、DOIC [RFC7683]の公開時にこれらの要件を満たさないことを明示的に選択しました。主な理由は、ワーキンググループが負荷情報を伝達するための一般的なアプローチに同意しなかったためです。 DOICの残りの部分と遅延負荷情報の伝達をDOIC拡張または別のメカニズムに進めることを選択しました。
This document defines a mechanism that addresses the load-related requirements from RFC 7068.
このドキュメントでは、RFC 7068の負荷関連の要件に対処するメカニズムを定義しています。
AVP Attribute-Value Pair
AVP属性値ペア
DOIC Diameter Overload Information Conveyance [RFC7683]
DOIC直径過負荷情報伝達[RFC7683]
Load The relative usage of the Diameter message processing capacity of a Diameter node. A low load level indicates that the Diameter node is underutilized. A high load level indicates that the node is closer to being fully utilized.
負荷DiameterノードのDiameterメッセージ処理能力の相対的な使用状況。負荷レベルが低い場合は、Diameterノードが十分に活用されていないことを示しています。負荷レベルが高い場合は、ノードが完全に利用されていることを示しています。
Offered Load The actual traffic sent to the reporting node after overload abatement and routing decisions are made.
提供負荷過負荷軽減およびルーティングの決定が行われた後にレポートノードに送信された実際のトラフィック。
Reporting Node A DOIC node that sends a DOIC Overload report in a Diameter answer message.
レポートノードDiameter応答メッセージでDOICオーバーロードレポートを送信するDOICノード。
Reacting Node A DOIC node that receives and acts on a DOIC Overload report.
反応ノードDOIC過負荷レポートを受信して動作するDOICノード。
Routing Information Routing Information referred to in this document can include the Routing and Peer tables defined in RFC 6733. It can also include other implementation-specific tables used to store load information. This document does not define the structure of such tables.
ルーティング情報このドキュメントで参照されるルーティング情報には、RFC 6733で定義されたルーティングテーブルとピアテーブルを含めることができます。また、負荷情報を格納するために使用される他の実装固有のテーブルを含めることもできます。このドキュメントでは、そのようなテーブルの構造を定義していません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Previous discussions of how to solve the load-related requirements in [RFC7068] have shown that people did not have an agreed-upon concept of how "load" information differs from "overload" information. While the two concepts are highly interrelated, there are two primary differences. First, a Diameter node always has a load. At any given time, that load may be effectively zero, effectively fully loaded, or somewhere in between. In contrast, overload is an exceptional condition. A node only has Overload information when it is in an overloaded state. Furthermore, the relationship between a node's load level and overload state at any given time may be vague. For example, a node may normally operate at a "fully loaded" level, but still not be considered overloaded. Another node may declare itself to be "overloaded" even though it might not be fully "loaded".
[RFC7068]の負荷関連の要件を解決する方法に関する以前の議論は、「負荷」情報が「過負荷」情報とどのように異なるかという合意された概念を人々が持っていなかったことを示しました。 2つの概念は相互に関連していますが、2つの主な違いがあります。まず、Diameterノードには常に負荷があります。いつでも、その負荷は実質的にゼロ、実質的に完全に負荷された状態、またはその中間にある可能性があります。対照的に、過負荷は例外的な状態です。ノードは、過負荷状態のときにのみ過負荷情報を保持します。さらに、ある時点でのノードの負荷レベルと過負荷状態の関係はあいまいな場合があります。たとえば、ノードは通常「完全にロードされた」レベルで動作しますが、それでも過負荷とは見なされません。別のノードは、完全に「ロード」されていない場合でも、それ自体が「オーバーロード」であると宣言する場合があります。
Second, Overload information, in the form of a DOIC Overload Report (OLR) [RFC7683] indicates an explicit request for action on the part of the reacting node; the OLR requests that the reacting node reduce the offered load, the actual traffic sent to the reporting node after overload abatement and routing decisions are made, by an indicated amount (by default) or as prescribed by the selected abatement algorithm. Effectively, DOIC provides a contract between the reporting node and the reacting node.
第2に、DOIC過負荷レポート（OLR）[RFC7683]の形式の過負荷情報は、反応しているノードのアクションの明示的な要求を示します。 OLRは、対応するノードが提供された負荷を軽減することを要求します。指定された量（デフォルト）または選択された軽減アルゴリズムによって規定されているように、過負荷軽減およびルーティングの決定が行われた後にレポートノードに送信される実際のトラフィック。事実上、DOICはレポートノードとリアクションノード間の契約を提供します。
In contrast, load is informational; load information can be considered a hint to the recipient node. That node may use the load information for load-balancing purposes, as an input to certain overload abatement techniques, to make inferences about the likelihood that the sending node becomes overloaded in the immediate future, or for other purposes.
対照的に、負荷は情報提供です。負荷情報は、受信ノードへのヒントと考えることができます。そのノードは、特定の過負荷軽減技術への入力として、負荷分散の目的で負荷情報を使用して、送信ノードが当面または他の目的で過負荷になる可能性について推論することができます。
None of this prevents a Diameter node from deciding to reduce the offered load based on load information. The fundamental difference is that an Overload report requires the reduction of the offered load. It is also reasonable for a Diameter node to decide to increase the offered load based on load information.
これは、Diameterノードが負荷情報に基づいて提供される負荷を減らすことを決定することを妨げるものではありません。基本的な違いは、過負荷レポートでは、提供された負荷の削減が必要なことです。また、Diameterノードが、負荷情報に基づいて提供される負荷を増やすことを決定することも妥当です。
[RFC7068] contemplates two primary uses for load information. Req 23 discusses how load information might be used when performing diversion as an overload abatement technique as described in [RFC7683]. When a reacting node diverts traffic away from an overloaded node, it needs load information for the other candidates for that traffic in order to effectively load-balance the diverted load between potential candidates. Otherwise, diversion has a greater potential to drive other nodes into overload.
[RFC7068]は、負荷情報の2つの主要な使用法を想定しています。 Req 23は、[RFC7683]で説明されているように、オーバーロード軽減技術として迂回を実行するときに負荷情報がどのように使用されるかを説明しています。反応するノードが過負荷のノードからトラフィックをそらす場合、潜在的な候補間で迂回された負荷を効果的に負荷分散するために、そのトラフィックの他の候補の負荷情報が必要です。それ以外の場合、宛先変更は他のノードを過負荷状態にする可能性が高くなります。
Req 24 discusses how Diameter load information might be used when no overload condition currently exists. Diameter nodes can use the load information to make decisions to try to avoid overload conditions in the first place. Normal load-balancing falls into this category, but the Diameter node can take other proactive steps as well.
要求24は、現在過負荷状態が存在しない場合に、Diameterの負荷情報がどのように使用されるかを説明しています。 Diameterノードは、負荷情報を使用して、そもそも過負荷状態を回避しようとする決定を下すことができます。通常のロードバランシングはこのカテゴリに分類されますが、Diameterノードは他の予防的な手順を実行することもできます。
If the loaded nodes are Diameter servers (or clients in the case of server-to-client transactions), both of these uses of load information should be accomplished by a Diameter node that performs server selection (selection of the Diameter endpoint to which the request is to be routed for processing). Typically, server selection is performed by a node (a client or an agent) that is an immediate peer of the server. However, there are scenarios (see Appendix A) where a client or proxy that is not the immediate peer to the selected servers performs server selection. In this case, the client or proxy enforces the server selection by inserting a Destination-Host AVP.
ロードされたノードがDiameterサーバー（またはサーバーからクライアントへのトランザクションの場合はクライアント）である場合、これらの負荷情報の使用は両方とも、サーバーの選択（要求の対象となるDiameterエンドポイントの選択）を実行するDiameterノードによって行われる必要があります。処理のためにルーティングされます）。通常、サーバーの選択は、サーバーの直接のピアであるノード（クライアントまたはエージェント）によって実行されます。ただし、選択したサーバーの直接のピアではないクライアントまたはプロキシがサーバーの選択を実行するシナリオ（付録Aを参照）があります。この場合、クライアントまたはプロキシは、Destination-Host AVPを挿入することによってサーバーの選択を強制します。
As an example, a Diameter node (e.g., client) can use a redirect agent to get candidate destination host addresses. The redirect agent might return several destination host addresses from which the Diameter node selects one. The Diameter node can use load information received from these hosts to make the selection.
例として、Diameterノード（クライアントなど）はリダイレクトエージェントを使用して候補の宛先ホストアドレスを取得できます。リダイレクトエージェントは、Diameterノードが1つを選択するいくつかの宛先ホストアドレスを返す場合があります。 Diameterノードは、これらのホストから受信した負荷情報を使用して選択を行うことができます。
Just as load information can be used as part of server selection, it can also be used as input to the selection of the next-hop peer to which a request is to be routed.
負荷情報がサーバー選択の一部として使用できるのと同様に、要求がルーティングされるネクストホップピアの選択への入力としても使用できます。
It should be noted that a Diameter node will need to process both load reports and Overload reports from the same Diameter node. The reacting node for the overload report always has the responsibility to reduce the amount of Diameter traffic sent to the overloaded node. If, or how, the reacting node uses load information to achieve this is left as an implementation decision.
Diameterノードは、同じDiameterノードからの負荷レポートと過負荷レポートの両方を処理する必要があることに注意してください。過負荷レポートの反応ノードは常に、過負荷ノードに送信されるDiameterトラフィックの量を減らす責任があります。対応するノードが負荷情報を使用してこれを達成する場合、またはその方法は、実装の決定として残されます。
The mechanism defined here for the conveyance of load information is similar in some ways to the mechanism defined for DOIC and is different in other ways.
荷重情報を伝達するためにここで定義されているメカニズムは、DOICで定義されているメカニズムといくつかの点で類似しており、他の点では異なります。
As with DOIC, load information is conveyed by piggybacking the Load AVPs on existing Diameter applications.
DOICと同様に、負荷情報は、既存のDiameterアプリケーションのLoad AVPをピギーバックすることによって伝達されます。
There are two primary differences. First, there is no capability negotiation process for load. The sender of the load information is sending it with the expectation that any supporting nodes will use it when making routing decisions. If there are no nodes that support the Load mechanism, then the load information is ignored.
主な違いは2つあります。まず、負荷の機能ネゴシエーションプロセスはありません。負荷情報の送信者は、サポートするノードがルーティングを決定するときにそれを使用することを期待して、情報を送信します。ロードメカニズムをサポートするノードがない場合、ロード情報は無視されます。
The second big difference between DOIC and Load is visibility of the DOIC or load information within a Diameter network. DOIC information is sent end-to-end resulting in the ability of all nodes in the path of the answer message that carries the OC-OLR AVP to act on the information, although only one node actually consumes and reacts to the report. The DOIC Overload reports remain in the message all the way from the reporting node to the node that is the target for the answer message.
DOICとロードの2番目の大きな違いは、Diameterネットワーク内のDOICまたはロード情報の可視性です。 DOIC情報はエンドツーエンドで送信されるため、OC-OLR AVPを伝送する応答メッセージのパス内のすべてのノードが情報を処理できますが、実際にレポートを消費して反応するのは1つのノードだけです。 DOIC過負荷レポートは、レポートノードから応答メッセージのターゲットであるノードまでメッセージに残ります。
For the Load mechanism, there are two types of load reports and only the first one is transmitted end-to-end.
負荷メカニズムには、2種類の負荷レポートがあり、最初のレポートのみがエンドツーエンドで送信されます。
The first type of load report is a host-load report, which contains the load of the endpoint sending the answer message. This load report is carried end-to-end to enable any nodes that make server selection decisions to use the load status of the sending endpoint as part of the server selection decision. Unlike with DOIC, more than one node may make use of the load information received.
最初のタイプの負荷レポートはホスト負荷レポートで、応答メッセージを送信するエンドポイントの負荷が含まれます。この負荷レポートはエンドツーエンドで送信され、サーバー選択の決定を行うノードがサーバー選択決定の一部として送信エンドポイントの負荷ステータスを使用できるようにします。 DOICとは異なり、複数のノードが受信した負荷情報を利用する場合があります。
The second type of load report is a peer-load report. This report is used by Diameter nodes as part of the logic to select the next-hop Diameter node and, as such, does not have significance beyond the peer node. load reports of type "PEER" are removed by the first supporting Diameter node to receive the report.
2番目のタイプの負荷レポートは、ピア負荷レポートです。このレポートは、Diameterノードが次ホップのDiameterノードを選択するロジックの一部として使用するため、ピアノード以外には意味がありません。タイプ「PEER」の負荷レポートは、レポートを受信する最初のサポートDiameterノードによって削除されます。
Because load reports can traverse Diameter nodes that do not support the Load mechanism, it is necessary to include the identity of the node to which the load report applies as part of the load report. This allows for a Diameter node to verify that a load report applies to its peer or that it should be ignored.
負荷レポートは、負荷メカニズムをサポートしていないDiameterノードをトラバースできるため、負荷レポートが適用されるノードのIDを負荷レポートの一部として含める必要があります。これにより、Diameterノードは、負荷レポートがそのピアに適用されること、または無視されることを確認できます。
The load report includes a value indicating the relative load of the sending node, specified in a manner consistent with that defined for DNS SRV [RFC2782].
負荷レポートには、送信ノードの相対負荷を示す値が含まれており、DNS SRV [RFC2782]に定義されている方法と一致する方法で指定されています。
The goal is to make it possible to use both the Load values received as a part of the Diameter Load mechanism and weight values received as a result of a DNS SRV query. As a result, the Diameter Load value has a range of 0-65535. This value and DNS SRV weight values are then used in a distribution algorithm similar to that specified in [RFC2782].
目標は、Diameterロードメカニズムの一部として受け取ったロード値と、DNS SRVクエリの結果として受け取ったウェイト値の両方を使用できるようにすることです。その結果、Diameter Load値の範囲は0〜65535です。この値とDNS SRV重み値は、[RFC2782]で指定されているものと同様の配布アルゴリズムで使用されます。
The DNS SRV distribution algorithm results in more messages being sent to a node with a higher weight value. As a result, a higher Diameter Load value indicates a LOWER load on the sending node. A node that is heavily loaded sends a lower Diameter Load value. Stated another way, a node that has zero load would have a Load value of 65535. A node that is 100% loaded would have a Load value of 0.
DNS SRV分散アルゴリズムにより、重み値が高いノードに送信されるメッセージが増えます。その結果、Diameter Loadの値が高いほど、送信ノードの負荷が低くなります。負荷が高いノードは、より低いDiameter Load値を送信します。言い換えると、負荷がゼロのノードの負荷値は65535になります。100％負荷のノードの負荷値は0になります。
The distribution algorithm used by Diameter nodes supporting the Diameter Load mechanism is an implementation decision, but it needs to result in similar behavior to the algorithm described for the use of weight values specified in [RFC2782].
Diameter LoadメカニズムをサポートするDiameterノードで使用される分散アルゴリズムは実装の決定ですが、[RFC2782]で指定されている重み値の使用について説明されているアルゴリズムと同様の動作をもたらす必要があります。
The method for calculating the Load value included in the load report is also left as an implementation decision.
負荷レポートに含まれる負荷値を計算する方法も、実装の決定として残されます。
The frequency for sending of load reports is also left as an implementation decision. The sending node might choose to send load reports in all messages or it might choose to only send load reports when the Load value has changed by some implementation-specific amount. The important consideration is that all nodes needing the load information have a sufficiently accurate view of the node's load.
負荷レポートの送信頻度も実装の決定として残されます。送信ノードは、すべてのメッセージで負荷レポートを送信することを選択する場合と、負荷値が実装固有の量だけ変更された場合にのみ負荷レポートを送信することを選択する場合があります。重要な考慮事項は、負荷情報を必要とするすべてのノードがノードの負荷を十分に正確に把握していることです。
This section outlines how the Diameter Load mechanism is expected to work.
このセクションでは、Diameter Loadメカニズムがどのように機能するかを概説します。
For this discussion, assume the following Diameter network configuration:
この説明では、次のDiameterネットワーク構成を想定しています。
---A1---A3----S[1], S[2]...S[p]
/ | \ /
C | x
\ | / \
---A2---A4----S[p+1], S[p+2] ...S[n]
Figure 1: Example Diameter Network
図1：Diameterネットワークの例
Note that in this diagram, S[1] and S[2] through S[p] are peers to A3. S[p+1] and S[p+2] through S[n] are peers to A4.
この図では、S [1]とS [2]〜S [p]がA3のピアであることに注意してください。 S [p + 1]およびS [p + 2]からS [n]は、A4のピアです。
Also assume that the request for a Diameter transaction takes the following path:
また、Diameterトランザクションのリクエストが次のパスをとるとします。
C A1 A4 S[n]
| | | |
|----->|----->|----->|
xxR xxR xxR
Figure 2: Request Message Path
図2：リクエストメッセージパス
When sending the answer message, an endpoint node that supports the Diameter Load mechanism includes its own load information in the answer message. Because it is a Diameter endpoint, it includes a host-load report.
応答メッセージを送信するとき、Diameterロードメカニズムをサポートするエンドポイントノードは、応答メッセージに独自のロード情報を含めます。これはDiameterエンドポイントであるため、ホスト負荷レポートが含まれています。
C A1 A4 S[n]
| | | |
| | |<-----|
| | xxA(Load type:HOST, source:S[n])
| | | |
Figure 3: Answer Message from S[n]
図3：S [n]からの応答メッセージ
If Agent A4 supports the Load mechanism, then A4's actions depend on whether A4 is responsible for doing server selection. If A4 is not doing server selection, then A4 ignores the host-load report. If A4 is responsible for doing server selection, then it stores the load information for S[n] in its routing information for the handling of subsequent request messages. In both cases, A4 leaves the host-load report in the message.
エージェントA4がロードメカニズムをサポートしている場合、A4のアクションは、A4がサーバーの選択を担当するかどうかによって異なります。 A4がサーバーを選択していない場合、A4はホスト負荷レポートを無視します。 A4がサーバーの選択を担当している場合は、後続の要求メッセージを処理するために、ルーティング情報にS [n]の負荷情報を格納します。どちらの場合も、A4はホスト負荷レポートをメッセージに残します。
Note: If A4 does not support the Load mechanism, then it will relay the answer message without doing any processing on the load information. In this case, the load information AVPs will be relayed without change.
注：A4がロードメカニズムをサポートしていない場合は、ロード情報の処理を行わずに応答メッセージを中継します。この場合、負荷情報AVPはそのまま中継されます。
A4 then calculates its own load information and inserts load information AVPs of type "PEER" in the message before sending the message to A1.
次に、A4は独自の負荷情報を計算し、タイプ「PEER」の負荷情報AVPをメッセージに挿入してから、メッセージをA1に送信します。
C A1 A4 S[n]
| | | |
| |<-----| |
| xxA(Load type:PEER, source:A4)
| xxA(Load type:HOST, source:S[n])
| | | |
Figure 4: Answer Message from A4
図4：A4からの応答メッセージ
If A1 supports the Load mechanism, then it processes each of the load reports it receives separately.
A1がロードメカニズムをサポートしている場合、A1は個別に受け取った各ロードレポートを処理します。
For the peer-load report, A1 first determines if the source of the report indicated in the load report matches the DiameterIdentity of the Diameter node from which the request was received. If the identities do not match, then the peer-load report is discarded. If the identities match, then A1 saves the load information in its routing information for routing of subsequent request messages. In both cases, A1 strips the peer-load report from the message.
ピア負荷レポートの場合、A1はまず、負荷レポートに示されているレポートのソースが、要求の送信元のDiameterノードのDiameterIdentityと一致するかどうかを判断します。 IDが一致しない場合、ピアロードレポートは破棄されます。 IDが一致する場合、A1は後続の要求メッセージのルーティングのために、ルーティング情報に負荷情報を保存します。どちらの場合も、A1はピアロードレポートをメッセージから削除します。
For the host-load report, A1's actions depend on whether A1 is responsible for doing server selection. If A1 is not doing server selection, then A1 ignores the host-load report. If A1 is responsible for doing server selection, then it stores the load information for S[n] in its routing information for the handling of subsequent request messages. In both cases, A1 leaves the host-load report in the message.
ホスト負荷レポートの場合、A1のアクションは、A1がサーバーの選択を行うかどうかによって異なります。 A1がサーバーを選択していない場合、A1はホスト負荷レポートを無視します。 A1がサーバーの選択を担当する場合は、後続の要求メッセージを処理するために、ルーティング情報にS [n]の負荷情報を格納します。どちらの場合も、A1はホスト負荷レポートをメッセージに残します。
A1 then calculates its own load information and inserts load information AVPs of type "PEER" in the message before sending the message to C:
次に、A1は独自の負荷情報を計算し、メッセージをCに送信する前に、メッセージに「PEER」タイプの負荷情報AVPを挿入します。
C A1 A4 S[n]
| | | |
|<-----| | |
xxA(Load type:PEER, source:A1)
xxA(Load type:HOST, source:S[n])
Figure 5: Answer Message from A1
図5：A1からの応答メッセージ
As with A1, C processes each load report separately.
A1と同様に、Cは各負荷レポートを個別に処理します。
For the peer-load report, C follows the same procedure as A1 for determining if the load report was received from the peer from which the report was sent. When finding it does, C stores the load information for use when making future routing decisions.
ピアロードレポートの場合、CはA1と同じ手順に従って、レポートの送信元のピアからロードレポートを受信したかどうかを判断します。見つかった場合、Cは将来のルーティングを決定するときに使用する負荷情報を保存します。
For the host-load report, C saves the load information only if it is responsible for doing server selection.
ホスト負荷レポートの場合、Cはサーバーの選択を行う責任がある場合にのみ負荷情報を保存します。
The load information received by all nodes is then used for routing of subsequent request messages.
すべてのノードが受信した負荷情報は、後続の要求メッセージのルーティングに使用されます。
This section defines the normative behaviors for the Load mechanism.
このセクションでは、ロードメカニズムの規範的な動作を定義します。
This section defines the procedures of Diameter reporting nodes that generate load reports.
このセクションでは、負荷レポートを生成するDiameterレポートノードの手順を定義します。
A Diameter endpoint that supports the Diameter Load mechanism MUST include a load report of type "HOST" in sufficient answer messages to ensure that all consumers of the load information receive timely updates.
DiameterロードメカニズムをサポートするDiameterエンドポイントは、ロード情報のすべてのコンシューマがタイムリーな更新を確実に受信できるように、十分な応答メッセージにタイプ「HOST」のロードレポートを含める必要があります。
The Diameter endpoint MUST include its own DiameterIdentity in the SourceID AVP included in the Load AVP.
Diameterエンドポイントは、Load AVPに含まれるSourceID AVPに独自のDiameterIdentityを含める必要があります。
The Diameter endpoint MUST include a Load-Type AVP of type "HOST" in the Load AVP.
Diameterエンドポイントには、タイプ「HOST」のロードタイプAVPがロードAVPに含まれている必要があります。
The Diameter endpoint MUST include its Load value in the Load-Value AVP in the Load AVP.
Diameterエンドポイントは、Load AVPのLoad-Value AVPにそのLoad値を含める必要があります。
The Load value should be calculated in a way that reflects the available load independently of the weight of each server in order to accurately compare Load values from different nodes. Any specific Load value needs to identify the same amount of available capacity regardless of the Diameter node that calculates the value.
異なるノードからの負荷値を正確に比較するために、負荷値は、各サーバーの重みとは無関係に利用可能な負荷を反映する方法で計算する必要があります。特定の負荷値は、値を計算するDiameterノードに関係なく、利用可能な容量の同じ量を識別する必要があります。
The mechanism used to calculate the Load value that fulfills this requirement is an implementation decision.
この要件を満たすLoad値の計算に使用されるメカニズムは、実装の決定です。
The frequency of sending load reports is an implementation decision.
負荷レポートを送信する頻度は、実装の決定です。
For instance, if the only consumer of the load reports is the endpoint's peer, then the endpoint can choose to only include a load report when the load of the endpoint has changed by a meaningful percentage. If there are consumers of the endpoint load report other than the endpoint's peer (this will be the case if other nodes are responsible for server selection), then the endpoint might choose to include load reports in all answer messages as a way of ensuring that all nodes doing server selection get accurate load information.
たとえば、負荷レポートの唯一のコンシューマがエンドポイントのピアである場合、エンドポイントは、エンドポイントの負荷が有意な割合で変化したときにのみ、負荷レポートを含めることを選択できます。エンドポイントのピア以外のエンドポイント負荷レポートのコンシューマーがある場合（これは、他のノードがサーバーの選択を担当している場合に当てはまります）、すべての応答メッセージに負荷レポートを含めることを選択できます。サーバーの選択を行うノードは、正確な負荷情報を取得します。
A Diameter Agent that supports the Diameter Load mechanism MUST include a peer-load report in sufficient answer messages to ensure that all users of the load information receive timely updates.
DiameterロードメカニズムをサポートするDiameterエージェントは、負荷情報のすべてのユーザーがタイムリーな更新を確実に受信できるように、十分な応答メッセージにピアロードレポートを含める必要があります。
The Diameter Agent MUST include its own DiameterIdentity in the SourceID AVP included in the Load AVP.
Diameterエージェントは、Load AVPに含まれるSourceID AVPに独自のDiameterIdentityを含める必要があります。
The Diameter Agent MUST include a Load-Type AVP of type "PEER" in the Load AVP.
Diameterエージェントは、タイプ「PEER」のロードタイプAVPをロードAVPに含める必要があります。
The Diameter Agent MUST include its Load value in the Load-Value AVP in the Load AVP.
Diameterエージェントは、Load AVPのLoad-Value AVPにそのLoad値を含める必要があります。
The Load value should be calculated in a way that reflects the available load independently of the weight of each agent in order to accurately compare Load values from different nodes. Any specific Load value needs to identify the same amount of available capacity regardless of the Diameter node that calculates the value.
異なるノードからの負荷値を正確に比較するために、負荷値は、各エージェントの重みとは無関係に利用可能な負荷を反映する方法で計算する必要があります。特定の負荷値は、値を計算するDiameterノードに関係なく、利用可能な容量の同じ量を識別する必要があります。
The mechanism used to calculate the Load value that fulfills this requirement is an implementation decision.
この要件を満たすLoad値の計算に使用されるメカニズムは、実装の決定です。
The frequency of sending load reports is an implementation decision.
負荷レポートを送信する頻度は、実装の決定です。
Note: In the case of load reports of type "PEER", it is only necessary to include load reports when the Load value has changed by some meaningful value, as long as the agent ensures that all peers receive the report. It is also acceptable to include the load report in every answer message handled by the Diameter Agent.
注：タイプ「PEER」の負荷レポートの場合、エージェントがすべてのピアがレポートを確実に受信できる限り、負荷値が意味のある値だけ変更されたときにのみ負荷レポートを含める必要があります。 Diameterエージェントが処理するすべての応答メッセージに負荷レポートを含めることもできます。
This section defines the behavior of Diameter nodes processing load reports.
このセクションでは、負荷レポートを処理するDiameterノードの動作を定義します。
A Diameter node that supports the Diameter Load mechanism MUST be prepared to process load reports of type "HOST" and of type "PEER", as indicated in the Load-Type AVP included in the Load AVP received in the same answer message or from multiple answer messages.
同じ応答メッセージまたは複数から受信されたロードAVPに含まれるロードタイプAVPに示されているように、DiameterロードメカニズムをサポートするDiameterノードは、タイプ「ホスト」およびタイプ「PEER」のロードレポートを処理する準備ができている必要があります。メッセージに答える。
Note: The node needs to be able to handle messages with no Load reports, messages with just a peer-load report, messages with just a host-load report, and messages with both types of load reports.
注：ノードは、負荷レポートのないメッセージ、ピア負荷レポートのみのメッセージ、ホスト負荷レポートのみのメッセージ、および両方のタイプの負荷レポートのメッセージを処理できる必要があります。
If the Diameter node is not responsible for doing server selection, then it SHOULD ignore load reports of type "HOST".
Diameterノードがサーバーの選択を行わない場合、タイプ「HOST」の負荷レポートを無視する必要があります。
If the Diameter node is responsible for doing server selection, then it SHOULD save the Load value included in the Load-Value AVP included in the Load AVP of type "HOST" in its routing information.
Diameterノードがサーバーの選択を行う責任がある場合は、ルーティング情報のタイプ「HOST」のLoad AVPに含まれるLoad-Value AVPに含まれるLoad値を保存する必要があります。
If the Diameter node receives a load report of type "PEER", then the Diameter node MUST determine if the load report was inserted into the answer message by the peer from which the message was received. This is achieved by comparing the DiameterIdentity associated with the connection from which the message was received with the DiameterIdentity included in the SourceID AVP in the load report.
Diameterノードがタイプ「PEER」の負荷レポートを受信する場合、Diameterノードは、メッセージの受信元のピアによって応答メッセージに負荷レポートが挿入されたかどうかを判断する必要があります。これは、メッセージの受信元の接続に関連付けられているDiameterIdentityと、負荷レポートのSourceID AVPに含まれているDiameterIdentityを比較することで実現されます。
If the Diameter node determines that the load report of type "PEER" was not received from the peer that sent or relayed the answer message, then the node MUST ignore the load report.
Diameterノードが、タイプ「PEER」の負荷レポートが、応答メッセージを送信または中継したピアから受信されなかったと判断した場合、ノードは負荷レポートを無視する必要があります。
If the Diameter node determines that the load report of type "PEER" was received from the peer that sent or relayed the answer message, then the node SHOULD save the load information in its routing information.
Diameterノードが応答メッセージを送信またはリレーしたピアからタイプ「PEER」の負荷レポートが受信されたと判断した場合、ノードはルーティング情報に負荷情報を保存する必要があります（SHOULD）。
In all cases, a Diameter Agent MUST strip all load reports of type "PEER" received in answer messages.
すべての場合において、Diameterエージェントは、応答メッセージで受信されたタイプ「PEER」のすべての負荷レポートを削除する必要があります。
Note: This ensures that there will be precisely one load report of type "PEER", e.g., that of the Diameter node sending the message, in any answer messages sent by the Diameter Agent.
注：これにより、Diameterエージェントが送信するすべての応答メッセージ内に、「PEER」タイプの負荷レポート（メッセージを送信するDiameterノードの負荷レポートなど）が1つだけ存在することが保証されます。
How a Diameter node uses load information for making routing decisions is an implementation decision. However, the distribution algorithm MUST result in similar behavior as the algorithm described for the use of weight values in [RFC2782].
Diameterノードがルーティング情報を決定するために負荷情報をどのように使用するかは、実装に関する決定事項です。ただし、配布アルゴリズムは、[RFC2782]で重み値の使用について説明されているアルゴリズムと同様の動作を引き起こす必要があります。
The Load mechanism can be extended to include additional information in the load reports.
負荷メカニズムを拡張して、負荷レポートに追加情報を含めることができます。
Any extension may define new AVPs for use in load reports. These new AVPs SHOULD be defined to be extensions to the Load AVPs defined in this document.
どの拡張機能でも、負荷レポートで使用する新しいAVPを定義できます。これらの新しいAVPは、このドキュメントで定義されているロードAVPの拡張として定義されるべきです（SHOULD）。
Grouped AVP extension mechanisms defined by [RFC6733] apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing application.
[RFC6733]で定義されたグループ化されたAVP拡張メカニズムが適用されます。これにより、たとえば、既存のアプリケーションに便乗した場合でも理解する必要がある新しい機能を定義できます。
As with any Diameter specification, [RFC6733] requires all new AVPs to be registered with IANA. See Section 9 for the required procedures.
すべてのDiameter仕様と同様に、[RFC6733]では、すべての新しいAVPをIANAに登録する必要があります。必要な手順については、セクション9を参照してください。
When a Diameter node is added, the new node will start by advertising its load. Downstream nodes will need to factor the new load information into load-balancing decisions. The downstream nodes can attempt to ensure a smooth increase of the traffic to the new node, avoiding an immediate spike of traffic to that new node. The method for the handling of such a smooth increase is implementation-specific, but it can rely on the evolution of load information received from the new node and from the other nodes.
Diameterノードが追加されると、新しいノードはその負荷をアドバタイズすることから始まります。下流ノードは、新しい負荷情報を負荷分散の決定に組み込む必要があります。ダウンストリームノードは、新しいノードへのトラフィックの急激な増加を回避して、新しいノードへのトラフィックをスムーズに増加させることを試みることができます。このようなスムーズな増加を処理する方法は実装固有ですが、新しいノードや他のノードから受信した負荷情報の変化に依存する場合があります。
When removing a node in a controlled way (e.g., for maintenance purposes, so outside a failure case), it might be appropriate to progressively reduce the traffic to this node by routing traffic to other nodes. Simple load information (load percentage) would not be sufficient. The method for the handling of the node removal is implementation-specific, but it can rely on the evolution of the load information received from the node to be removed.
制御された方法でノードを削除する場合（たとえば、メンテナンス目的で、障害の場合を除きます）、他のノードにトラフィックをルーティングすることにより、このノードへのトラフィックを徐々に減らすことが適切な場合があります。単純な負荷情報（負荷率）では不十分です。ノードの削除の処理方法は実装固有ですが、削除するノードから受信した負荷情報の変化に依存する場合があります。
The section defines the AVPs required for the Load mechanism.
このセクションでは、ロードメカニズムに必要なAVPを定義します。
The Load AVP (AVP code 650) is of type Grouped and is used to convey load information between Diameter nodes.
Load AVP（AVPコード650）はGroupedタイプであり、Diameterノード間で負荷情報を伝達するために使用されます。
Load ::= < AVP Header: 650 >
[ Load-Type ]
[ Load-Value ]
[ SourceID ]
* [ AVP ]
The Load-Type AVP (AVP code 651) is of type Enumerated. It is used to convey the type of Diameter node that sent the load information. The following values are defined:
Load-Type AVP（AVPコード651）はEnumeratedタイプです。負荷情報を送信したDiameterノードのタイプを伝えるために使用されます。以下の値が定義されています。
HOST 0 The load report is for a host.
HOST 0負荷レポートはホスト用です。
PEER 1 The load report is for a peer.
ピア1負荷レポートはピア用です。
The Load-Value AVP (AVP code 652) is of type Unsigned64. It is used to convey relative load information about the sender of the load report.
Load-Value AVP（AVPコード652）のタイプはUnsigned64です。負荷レポートの送信者に関する相対的な負荷情報を伝えるために使用されます。
The Load-Value AVP is specified in a manner similar to the weight value in DNS SRV ([RFC2782]).
Load-Value AVPは、DNS SRV（[RFC2782]）の重み値と同様の方法で指定されます。
The Load value has a range of 0-65535.
Load値の範囲は0〜65535です。
A higher value indicates a lower load on the sending node. A lower value indicates that the sending node is heavily loaded.
値が高いほど、送信ノードの負荷が低いことを示します。値が小さいほど、送信ノードの負荷が高くなっています。
Stated another way, a node that has zero load would have a Load value of 65535. A node that is 100% loaded would have a Load value of 0.
言い換えると、負荷がゼロのノードの負荷値は65535になります。100％負荷のノードの負荷値は0になります。
The SourceID AVP is defined in [RFC8581]. It is used to identify the Diameter node that sent the load report.
SourceID AVPは[RFC8581]で定義されています。負荷レポートを送信したDiameterノードを識別するために使用されます。
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------------+----+----+
|Load 650 7.1 Grouped | | V |
+--------------------------------------------------------+----+----+
|Load-Type 651 7.2 Enumerated | | V |
+--------------------------------------------------------+----+----+
|Load-Value 652 7.3 Unsigned64 | | V |
+------------------------------------------------------ -+----+----+
|SourceID 649 7.4 DiameterIdentity | | V |
+--------------------------------------------------------+----+----+
As described in the Diameter base protocol [RFC6733], the M-bit usage for a given AVP in a given command may be defined by the application.
Diameter基本プロトコル[RFC6733]で説明されているように、特定のコマンドでの特定のAVPのMビットの使用は、アプリケーションで定義できます。
Load information may be sensitive information in some cases. Depending on the mechanism, an unauthorized recipient might be able to infer the topology of a Diameter network from load information. Load information might be useful in identifying targets for denial-of-service (DoS) attacks, where a node known to be already heavily loaded might be a tempting target. Load information might also be useful as feedback about the success of an ongoing DoS attack.
負荷情報は、場合によっては機密情報である可能性があります。メカニズムによっては、不正な受信者が負荷情報からDiameterネットワークのトポロジを推測できる場合があります。負荷情報は、サービス拒否（DoS）攻撃のターゲットを識別するのに役立つ場合があります。この場合、負荷が高いことがわかっているノードが魅力的なターゲットになる可能性があります。負荷情報は、進行中のDoS攻撃の成功に関するフィードバックとしても役立つ場合があります。
Given that routing decisions are impacted by load information, there is potential for negative impacts on a Diameter network caused by erroneous or malicious load reports. This includes the malicious changing of Load values by Diameter Agents.
ルーティングの決定は負荷情報の影響を受けるため、誤ったまたは悪意のある負荷レポートが原因でDiameterネットワークに悪影響が及ぶ可能性があります。これには、Diameterエージェントによる負荷値の悪意のある変更が含まれます。
Any load information conveyance mechanism will need to allow operators to avoid sending load information to nodes that are not authorized to receive it. Since Diameter currently only offers authentication of nodes at the transport level and does not support end-to-end security mechanisms, any solution that sends load information to non-peer nodes requires a transitive-trust model.
負荷情報伝達メカニズムでは、オペレーターが負荷情報の受信を許可されていないノードに負荷情報を送信しないようにする必要があります。現在、Diameterはノードの認証をトランスポートレベルでのみ提供し、エンドツーエンドのセキュリティメカニズムをサポートしていないため、負荷情報を非ピアノードに送信するソリューションには、推移的信頼モデルが必要です。
IANA has registered three new AVP codes in the "Authentication, Authorization, and Accounting (AAA) Parameters" registry; see Sections 7.1, 7.2, and 7.3.
IANAは、「Authentication、Authorization、and Accounting（AAA）Parameters」レジストリに3つの新しいAVPコードを登録しました。セクション7.1、7.2、および7.3を参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<https：// www.rfc-editor.org/info/rfc2782>。
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.rfc-editor.org/info/rfc6733>.
[RFC6733] Fajardo、V。、編、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>。
[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>。
This section presents a number of Diameter topology scenarios and discusses how load information might be used in each scenario.
このセクションでは、Diameterトポロジのシナリオをいくつか紹介し、各シナリオで負荷情報がどのように使用されるかについて説明します。
Figure 6 shows a simple client-server scenario where a client picks from a set of candidate servers available for a particular realm and application. The client selects the server for a given transaction using the load information received from each server.
図6は、クライアントが特定のレルムとアプリケーションで使用可能な候補サーバーのセットから選択する、単純なクライアントサーバーシナリオを示しています。クライアントは、各サーバーから受信した負荷情報を使用して、特定のトランザクションのサーバーを選択します。
------S1
/
C
\
------S2
Figure 6: Basic Client Server Scenario
図6：基本的なクライアントサーバーシナリオ
If a node supports dynamic discovery, it will not obtain load information from the nodes with which it has no Diameter connection established. Nevertheless, it might take into account the load information from the other nodes to decide to add connections to new nodes with the dynamic discovery mechanism.
ノードが動的検出をサポートしている場合、Diameter接続が確立されていないノードから負荷情報を取得しません。それでも、動的検出メカニズムを使用して新しいノードへの接続を追加することを決定するために、他のノードからの負荷情報が考慮される場合があります。
Note: The use of dynamic connections needs to be considered.
注：動的接続の使用を検討する必要があります。
Figure 7 shows a client that sends requests to an agent. The agent selects the request destination from a set of candidate servers, using load information received from each server. The client does not need to receive load information since it does not select between multiple agents.
図7は、エージェントにリクエストを送信するクライアントを示しています。エージェントは、各サーバーから受信した負荷情報を使用して、候補サーバーのセットから要求の宛先を選択します。クライアントは複数のエージェントを選択しないため、負荷情報を受信する必要はありません。
------S1
/
C----A
\
------S2
Figure 7: Simple Agent Scenario
図7：単純なエージェントのシナリオ
Figure 8 shows a client selecting between multiple agents and each agent selecting from multiple servers. The client selects an agent based on the load information received from each agent. Each agent selects a server based on the load information received from its servers.
図8は、複数のエージェントから選択するクライアントと、複数のサーバーから選択する各エージェントを示しています。クライアントは、各エージェントから受信した負荷情報に基づいてエージェントを選択します。各エージェントは、サーバーから受信した負荷情報に基づいてサーバーを選択します。
This scenario adds a complication that one set of servers may be more loaded than the other set. If, for example, S4 was the least loaded server, C would need to know to select agent A2 to reach S4. This might require C to receive load information from the servers as well as the agents. Alternatively, each agent might use the load of its servers as an input into calculating its own load, in effect aggregating upstream load.
このシナリオは、サーバーの1つのセットが他のセットよりも負荷が高くなる可能性があるという複雑さを追加します。たとえば、S4が最も負荷の少ないサーバーである場合、CはS4に到達するためにエージェントA2を選択することを知る必要があります。これには、Cがサーバーとエージェントから負荷情報を受信する必要がある場合があります。あるいは、各エージェントは、サーバーの負荷を入力として使用して、自身の負荷を計算し、実際には上流の負荷を集計することもできます。
Similarly, if C sends a host-routed request [RFC7683], it needs to know which agent can deliver requests to the selected server. Without some special, potentially proprietary, knowledge of the topology upstream of A1 and A2, C would select the agent based on the normal peer selection procedures for the realm and application, and perhaps consider the load information from A1 and A2. If C sends a request to A1 that contains a Destination-Host AVP with a value of S4, A1 will not be able to deliver the request.
同様に、Cがホストルーティングされたリクエスト[RFC7683]を送信する場合、Cは選択されたサーバーにリクエストを配信できるエージェントを知る必要があります。 A1とA2の上流トポロジの特別な、潜在的に独占的な知識がなければ、Cはレルムとアプリケーションの通常のピア選択手順に基づいてエージェントを選択し、おそらくA1とA2からの負荷情報を考慮します。 Cが値S4の宛先ホストAVPを含む要求をA1に送信すると、A1は要求を配信できなくなります。
-----S3
/
---A1------S1
/
C
\
---A2------S2
\
---- S4
Figure 8: Multiple Agents and Servers
図8：複数のエージェントとサーバー
Figure 9 shows a scenario similar to that of Figure 8, except that the agents are linked so that A1 can forward a request to A2, and vice-versa. Each agent could receive load information from the linked agent as well as its connected servers.
図9は、A1がリクエストをA2に転送できるようにエージェントがリンクされていることを除いて、図8のシナリオと同様のシナリオを示しています。各エージェントは、リンクされたエージェントと接続されたサーバーから負荷情報を受け取ることができます。
This somewhat simplifies the complication from Figure 8 due to the fact that C does not necessarily need to choose a particular agent to reach a particular server. But, it creates a similar question of how, for example, A1 might know that S4 was less loaded than S1 or S3. Additionally, it creates the opportunity for sub-optimal request paths. For example, [C,A1,A2,S4] vs. [C,A2,S4].
これは、Cが特定のサーバーに到達するために特定のエージェントを必ずしも選択する必要がないため、図8の複雑さを幾分単純化します。しかし、たとえば、A1がS4がS1またはS3よりも負荷が少ないことをどのようにして知ることができるかという同様の質問を作成します。さらに、それは次善のリクエストパスの機会を作り出します。たとえば、[C、A1、A2、S4]と[C、A2、S4]です。
A likely application for linked agents is when each agent prefers to route only to directly connected servers and only forwards requests to another agent under exceptional circumstances. For example, A1 might not forward requests to A2 unless both S1 and S3 are overloaded. In this case, A1 might use the load information from S1 and S3 to select between those, and only consider the load information from A2 (and other connected agents) if it needs to divert requests to different agents.
リンクされたエージェントの可能性が高いアプリケーションは、各エージェントが直接接続されたサーバーのみにルーティングすることを好み、例外的な状況下で要求を別のエージェントにのみ転送する場合です。たとえば、S1とS3の両方が過負荷でない限り、A1は要求をA2に転送しない可能性があります。この場合、A1はS1とS3からの負荷情報を使用してそれらを選択し、リクエストを別のエージェントに転送する必要がある場合にのみ、A2（および他の接続されたエージェント）からの負荷情報を考慮します。
-----S3
/
---A1------S1
/ |
C |
\ |
---A2------S2
\
---- S4
Figure 9: Linked Agents
図9：リンクされたエージェント
Figure 10 is a variant of Figure 9. In this case, C1 sends all traffic through A1, and C2 sends all traffic through A2. By default, A1 will load-balance traffic between S1 and S3, and A2 will load-balance traffic between S2 and S4.
図10は図9の変形です。この場合、C1はすべてのトラフィックをA1経由で送信し、C2はすべてのトラフィックをA2経由で送信します。デフォルトでは、A1はS1とS3の間のトラフィックを負荷分散し、A2はS2とS4の間のトラフィックを負荷分散します。
Now, if S1 and S3 are significantly more loaded than S2 and S4, A1 may route some C1 traffic to A2. This is a non-optimal path, but it allows better load balancing between the servers. To achieve this, A1 needs to receive some load info from A2 about the S2/S4 load.
S1とS3の負荷がS2とS4よりも大幅に大きい場合、A1は一部のC1トラフィックをA2にルーティングする可能性があります。これは最適なパスではありませんが、サーバー間のより良い負荷分散を可能にします。これを実現するには、A2からS2 / S4のロードに関するロード情報を受け取る必要があります。
-----S3
/
C1----A1------S1
|
|
|
C2----A2------S2
\
---- S4
Figure 10: Linked Agents
図10：リンクされたエージェント
Figure 11 is similar to Figure 9, except that instead of a link between agents, each agent is linked to all servers (The links to each set of servers should be interpreted as a link to each server. The links are not shown separately due to the limitations of ASCII art.).
図11は図9と似ていますが、エージェント間のリンクではなく、各エージェントがすべてのサーバーにリンクされています（サーバーの各セットへのリンクは、各サーバーへのリンクとして解釈される必要があります。 ASCIIアートの制限。
In this scenario, each agent can select among all of the servers based on the load information from the servers. The client need only be concerned with the load information of the agents.
このシナリオでは、各エージェントは、サーバーからの負荷情報に基づいて、すべてのサーバーから選択できます。クライアントは、エージェントの負荷情報のみを考慮する必要があります。
---A1---S[1], S[2]...S[p]
/ \ /
C x
\ / \
---A2---S[p+1], S[p+2] ...S[n]
Figure 11: Shared Server Pools
図11：共有サーバープール
The scenario in Figure 12 is similar to that of Figure 8, except that instead of the client possibly needing to select an agent that can route requests to the least loaded server, in this case A1 and A2 need to make similar decisions when selecting between A3 or A4. As the former scenario, this could be mitigated if A3 and A4 aggregate upstream loads into the load information they report downstream.
図12のシナリオは図8のシナリオと似ていますが、クライアントが要求を最小負荷のサーバーにルーティングできるエージェントを選択する必要がある可能性があります。この場合、A1とA2はA3の間で選択するときに同様の決定を行う必要があります。またはA4。前者のシナリオと同様に、A3とA4が上流の負荷を下流で報告する負荷情報に集約すると、これを軽減できます。
---A1---A3----S[1], S[2]...S[p]
/ | \ /
C | x
\ | / \
---A2---A4----S[p+1], S[p+2] ...S[n]
Figure 12: Agent Chains
図12：エージェントチェーン
Figure 13 extends the scenario in Figure 11 by adding an extra layer of agents. But since each layer of nodes can reach any node in the next layer, each node only needs to consider the load of its next-hop peer.
図13は、エージェントの層を追加することにより、図11のシナリオを拡張したものです。ただし、ノードの各層は次の層の任意のノードに到達できるため、各ノードは次のホップピアの負荷を考慮するだけで済みます。
---A1---A3---S[1], S[2]...S[p]
/ | \ / |\ /
C | x | x
\ | / \ |/ \
---A2---A4---S[p+1], S[p+2] ...S[n]
Figure 13: Full Mesh
図13：フルメッシュ
A Diameter network with multiple servers is said to be "partitioned" when only a subset of available servers can serve a particular realm-routed request. For example, one group of servers may handle users whose names start with "A" through "M", and another group may handle "N" through "Z".
複数のサーバーがあるDiameterネットワークは、利用可能なサーバーのサブセットのみが特定のレルムでルーティングされたリクエストを処理できる場合に、「分割」されていると言われます。たとえば、サーバーの1つのグループが、名前が「A」から「M」で始まるユーザーを処理し、別のグループが「N」から「Z」を処理する場合があります。
In such a partitioned network, nodes cannot load balance requests across partitions since not all servers can handle the request. A client, or an intermediate agent, may still be able to load balance between servers inside a partition.
このような分割されたネットワークでは、すべてのサーバーが要求を処理できるわけではないため、ノードはパーティション間で要求の負荷を分散できません。クライアントまたは中間エージェントは、パーティション内のサーバー間で負荷を分散できる場合があります。
The previous scenarios assume that traffic can be load balanced among all peers that are eligible to handle a request. That is, the peers operate in an "active-active" configuration. In an "active-standby" configuration, traffic would be load balanced among active peers. Requests would only be sent to peers in a "standby" state if the active peers became unavailable. For example, requests might be diverted to a stand-by peer if one or more active peers becomes overloaded.
前のシナリオでは、要求を処理する資格のあるすべてのピア間でトラフィックを負荷分散できると想定しています。つまり、ピアは「アクティブ-アクティブ」構成で動作します。 「アクティブ-スタンバイ」構成では、トラフィックはアクティブなピア間で負荷分散されます。アクティブなピアが利用できなくなった場合、リクエストは「スタンバイ」状態のピアにのみ送信されます。たとえば、1つ以上のアクティブなピアが過負荷になると、要求がスタンバイピアに転送される可能性があります。
Authors' Addresses
著者のアドレス
Ben Campbell Oracle 7460 Warren Parkway, Suite 300 Frisco, Texas 75034 United States of America
ベンキャンベルオラクル7460ウォーレンパークウェイ、スイート300フリスコ、テキサス75034アメリカ合衆国
Email: ben@nostrum.com
Steve Donovan (editor) Oracle 7460 Warren Parkway # 300 Frisco, Texas 75034 United States of America
Steve Donovan（編集者）Oracle 7460 Warren Parkway＃300 Frisco、Texas 75034アメリカ合衆国
Email: srdonovan@usdonovans.com
Jean-Jacques Trottin Nokia Route de Villejust 91620 Nozay France
Jean-Jacques Trottin Nokia Route de Villejust 91620 Nozay France
Email: jean-jacques.trottin@nokia.com