[要約] RFC 7068は、Diameterオーバーロード制御の要件を定義しています。その目的は、Diameterネットワークの過負荷状態を制御し、サービスの品質を維持することです。
Internet Engineering Task Force (IETF) E. McMurry
Request for Comments: 7068 B. Campbell
Category: Informational Oracle
ISSN: 2070-1721 November 2013
Diameter Overload Control Requirements
直径過負荷制御の要件
Abstract
概要
When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing Diameter mechanisms are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided.
Diameterサーバーまたはエージェントが過負荷になった場合、通常は一定期間トラフィックを削減するようにクライアントにアドバイスすることにより、負荷を適切に削減できる必要があります。それ以外の場合は、Diameterメッセージの解析と応答にリソースを費やす必要があり、次第に深刻な過負荷状態になる可能性があります。既存のDiameterメカニズムは、過負荷状態を管理するには不十分です。このドキュメントでは、既存のメカニズムの制限について説明します。新しい過負荷管理メカニズムの要件も提供されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7068.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7068で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Documentation Conventions ..................................4
1.2. Causes of Overload .........................................5
1.3. Effects of Overload ........................................6
1.4. Overload vs. Network Congestion ............................6
1.5. Diameter Applications in a Broader Network .................7
2. Overload Control Scenarios ......................................7
2.1. Peer-to-Peer Scenarios .....................................8
2.2. Agent Scenarios ...........................................10
2.3. Interconnect Scenario .....................................14
3. Diameter Overload Case Studies .................................15
3.1. Overload in Mobile Data Networks ..........................15
3.2. 3GPP Study on Core Network Overload .......................16
4. Existing Mechanisms ............................................17
5. Issues with the Current Mechanisms .............................18
5.1. Problems with Implicit Mechanism ..........................18
5.2. Problems with Explicit Mechanisms .........................18
6. Extensibility and Application Independence .....................19
7. Solution Requirements ..........................................20
7.1. General ...................................................20
7.2. Performance ...............................................21
7.3. Heterogeneous Support for Solution ........................22
7.4. Granular Control ..........................................23
7.5. Priority and Policy .......................................23
7.6. Security ..................................................23
7.7. Flexibility and Extensibility .............................24
8. Security Considerations ........................................25
8.1. Access Control ............................................25
8.2. Denial-of-Service Attacks .................................26
8.3. Replay Attacks ............................................26
8.4. Man-in-the-Middle Attacks .................................26
8.5. Compromised Hosts .........................................27
9. References .....................................................27
9.1. Normative References ......................................27
9.2. Informative References ....................................27
Appendix A. Contributors ..........................................29
Appendix B. Acknowledgements ......................................29
A Diameter [RFC6733] node is said to be overloaded when it has insufficient resources to successfully process all of the Diameter requests that it receives. When a node becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing mechanisms provided by Diameter are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms and provides requirements for new overload management mechanisms.
Diameter [RFC6733]ノードは、受信するすべてのDiameterリクエストを正常に処理するためのリソースが不足している場合、過負荷と呼ばれます。ノードが過負荷になった場合、通常は一定期間トラフィックを削減するようにクライアントにアドバイスすることにより、負荷を適切に削減できる必要があります。それ以外の場合は、Diameterメッセージの解析と応答にリソースを費やす必要があり、次第に深刻な過負荷状態になる可能性があります。 Diameterが提供する既存のメカニズムでは、過負荷状態を管理するには不十分です。このドキュメントでは、既存のメカニズムの制限について説明し、新しい過負荷管理メカニズムの要件を示します。
This document draws on the work done on SIP overload control ([RFC5390], [RFC6357]) as well as on experience gained via overload handling in Signaling System No. 7 (SS7) networks and studies done by the Third Generation Partnership Project (3GPP) (Section 3).
このドキュメントは、SIP過負荷制御（[RFC5390]、[RFC6357]）で行われた作業と、Signaling System No. 7（SS7）ネットワークでの過負荷処理によって得られた経験と、第3世代パートナーシッププロジェクト（3GPP）によって行われた研究に基づいています。 ）（セクション3）。
Diameter is not typically an end-user protocol; rather, it is generally used as one component in support of some end-user activity.
Diameterは通常、エンドユーザープロトコルではありません。むしろ、それは一般的に、いくつかのエンドユーザー活動をサポートする1つのコンポーネントとして使用されます。
For example, a SIP server might use Diameter to authenticate and authorize user access. Overload in the Diameter backend infrastructure will likely impact the experience observed by the end user in the SIP application.
たとえば、SIPサーバーはDiameterを使用して、ユーザーアクセスを認証および承認します。 Diameterバックエンドインフラストラクチャの過負荷は、エンドユーザーがSIPアプリケーションで観察するエクスペリエンスに影響を与える可能性があります。
The impact of Diameter overload on the client application (a client application may use the Diameter protocol and other protocols to do its job) is beyond the scope of this document.
クライアントアプリケーションでのDiameter過負荷の影響（クライアントアプリケーションは、Diameterプロトコルと他のプロトコルを使用してその仕事を行う場合があります）は、このドキュメントの範囲を超えています。
This document presents non-normative descriptions of causes of overload, along with related scenarios and studies. Finally, it offers a set of normative requirements for an improved overload indication mechanism.
このドキュメントでは、過負荷の原因の非規範的な説明を、関連するシナリオと研究とともに示します。最後に、改善された過負荷表示メカニズムに対する一連の規範的な要件を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as defined in [RFC2119], with the exception that they are not intended for interoperability of implementations. Rather, they are used to describe requirements towards future specifications where the interoperability requirements will be defined.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で定義されているように解釈されますが、実装の相互運用性を目的としたものではありません。むしろ、相互運用性の要件が定義される将来の仕様に向けた要件を説明するために使用されます。
The terms "client", "server", "agent", "node", "peer", "upstream", and "downstream" are used as defined in [RFC6733].
「クライアント」、「サーバー」、「エージェント」、「ノード」、「ピア」、「アップストリーム」、および「ダウンストリーム」という用語は、[RFC6733]で定義されているように使用されます。
Overload occurs when an element, such as a Diameter server or agent, has insufficient resources to successfully process all of the traffic it is receiving. Resources include all of the capabilities of the element used to process a request, including CPU processing, memory, I/O, and disk resources. It can also include external resources such as a database or DNS server, in which case the CPU, processing, memory, I/O, and disk resources of those elements are effectively part of the logical element processing the request.
過負荷は、Diameterサーバーやエージェントなどの要素に、受信しているすべてのトラフィックを正常に処理するための十分なリソースがない場合に発生します。リソースには、CPU処理、メモリ、I / O、ディスクリソースなど、リクエストの処理に使用される要素のすべての機能が含まれます。データベースやDNSサーバーなどの外部リソースを含めることもできます。この場合、これらの要素のCPU、処理、メモリ、I / O、およびディスクリソースは、要求を処理する論理要素の一部です。
External resources can include upstream Diameter nodes; for example, a Diameter agent can become effectively overloaded if one or more upstream nodes are overloaded.
外部リソースには、上流のDiameterノードを含めることができます。たとえば、1つ以上の上流ノードが過負荷になると、Diameterエージェントが効果的に過負荷になる可能性があります。
A Diameter node can become overloaded due to request levels that exceed its capacity, a reduction of available resources (for example, a local or upstream hardware failure), or a combination of the two.
Diameterノードは、その容量を超えるリクエストレベル、使用可能なリソースの減少（たとえば、ローカルまたはアップストリームのハードウェア障害）、またはその2つの組み合わせにより、過負荷になる可能性があります。
Overload can occur for many reasons, including:
過負荷は、次のようなさまざまな理由で発生する可能性があります。
Inadequate capacity: When designing Diameter networks, that is, application-layer multi-node Diameter deployments, it can be very difficult to predict all scenarios that may cause elevated traffic. It may also be more costly to implement support for some scenarios than a network operator may deem worthwhile. This results in the likelihood that a Diameter network will not have adequate capacity to handle all situations.
容量が不十分：Diameterネットワーク、つまりアプリケーションレイヤーのマルチノードDiameterデプロイメントを設計する場合、トラフィックの増加を引き起こす可能性のあるすべてのシナリオを予測することは非常に難しい場合があります。また、ネットワークオペレーターが価値があると考える場合よりも、一部のシナリオのサポートを実装する方がコストがかかる場合があります。これにより、Diameterネットワークにすべての状況を処理する十分な容量がない可能性があります。
Dependency failures: A Diameter node can become overloaded because a resource on which it depends has failed or become overloaded, greatly reducing the logical capacity of the node. In these cases, even minimal traffic might cause the node to go into overload. Examples of such dependency overloads include DNS servers, databases, disks, and network interfaces that have failed or become overloaded.
依存関係の障害：Diameterノードは、依存するリソースに障害が発生したか、過負荷になり、ノードの論理容量が大幅に減少するため、過負荷になる可能性があります。これらの場合、最小限のトラフィックでもノードが過負荷になる可能性があります。このような依存関係の過負荷の例としては、DNSサーバー、データベース、ディスク、およびネットワークインターフェイスの障害や過負荷が挙げられます。
Component failures: A Diameter node can become overloaded when it is a member of a cluster of servers that each share the load of traffic and one or more of the other members in the cluster fail. In this case, the remaining nodes take over the work of the failed nodes. Normally, capacity planning takes such failures into account, and servers are typically run with enough spare capacity to handle failure of another node. However, unusual failure conditions can cause many nodes to fail at once. This is often the case with software failures, where a bad packet or bad database entry hits the same bug in a set of nodes in a cluster.
コンポーネントの障害：Diameterノードは、それぞれがトラフィックの負荷を共有するサーバーのクラスターのメンバーであり、クラスター内の他のメンバーの1つ以上に障害が発生すると、過負荷になる可能性があります。この場合、残りのノードが障害のあるノードの作業を引き継ぎます。通常、容量計画ではこのような障害が考慮され、サーバーは通常、別のノードの障害を処理するのに十分な予備の容量で実行されます。ただし、異常な障害状態が発生すると、多くのノードで同時に障害が発生する可能性があります。これは多くの場合、ソフトウェア障害の場合であり、不良パケットまたは不良データベースエントリは、クラスター内の一連のノードの同じバグにヒットします。
Network-initiated traffic flood: Certain access network events can precipitate floods of Diameter signaling traffic. For example, operational changes can trigger avalanche restarts, or frequent radio overlay handovers can generate excessive authorization requests. Failure of a Diameter proxy may also result in a large amount of signaling as connections and sessions are reestablished.
ネットワーク起動のトラフィックフラッド：特定のアクセスネットワークイベントにより、Diameterシグナリングトラフィックのフラッドが発生する可能性があります。たとえば、運用上の変更によってなだれの再起動がトリガーされたり、頻繁な無線オーバーレイハンドオーバーによって過剰な認証要求が生成されたりすることがあります。 Diameterプロキシに障害が発生すると、接続とセッションが再確立されるため、大量のシグナリングが発生する可能性もあります。
Subscriber-initiated traffic flood: Large gatherings of subscribers or events that result in many subscribers interacting with the network in close time proximity can result in Diameter signaling traffic floods. For example, the finale of a large fireworks show could be immediately followed by many subscribers posting messages, pictures, and videos concentrated on one portion of a network. Subscriber devices such as smartphones may use aggressive registration strategies that generate unusually high Diameter traffic loads.
サブスクライバーが開始するトラフィックフラッド：多くのサブスクライバーまたはイベントが大量に集まると、多くのサブスクライバーがネットワークと短時間で対話し、Diameterシグナリングトラフィックフラッドが発生する可能性があります。たとえば、大規模な花火ショーのフィナーレの直後に、ネットワークの一部に集中したメッセージ、写真、ビデオを投稿する多くの加入者が続く可能性があります。スマートフォンなどの加入者デバイスは、異常に高いDiameterトラフィック負荷を生成する積極的な登録戦略を使用する場合があります。
DoS attacks: An attacker wishing to disrupt service in the network can cause a large amount of traffic to be launched at a target element. This can be done from a central source of traffic or through a distributed DoS attack. In all cases, the volume of traffic well exceeds the capacity of the element, sending the system into overload.
DoS攻撃：攻撃者がネットワーク内のサービスを妨害したい場合、大量のトラフィックがターゲットエレメントで起動される可能性があります。これは、トラフィックの中央ソースから、または分散型DoS攻撃を介して実行できます。すべての場合において、トラフィックの量は要素の容量を大幅に超え、システムを過負荷にします。
Modern Diameter networks, composed of application-layer multi-node deployments of Diameter elements, may operate at very large transaction volumes. If a Diameter node becomes overloaded or, even worse, fails completely, a large number of messages may be lost very quickly. Even with redundant servers, many messages can be lost in the time it takes for failover to complete. While a Diameter client or agent should be able to retry such requests, an overloaded peer may cause a sudden large increase in the number of transactions needing to be retried, rapidly filling local queues or otherwise contributing to local overload. Therefore, Diameter devices need to be able to shed load before critical failures can occur.
Diameter要素のアプリケーション層マルチノードデプロイメントで構成される最新のDiameterネットワークは、非常に大きなトランザクション量で動作する可能性があります。 Diameterノードが過負荷になるか、さらに悪い場合には完全に失敗すると、多数のメッセージがすぐに失われる可能性があります。冗長サーバーがある場合でも、フェイルオーバーが完了するまでの間に多くのメッセージが失われる可能性があります。 Diameterクライアントまたはエージェントはそのような要求を再試行できるはずですが、過負荷のピアにより、再試行する必要のあるトランザクションの数が突然大幅に増加し、ローカルキューが急速にいっぱいになるか、ローカルの過負荷の一因となる場合があります。したがって、Diameterデバイスは、重大な障害が発生する前に負荷を分散できる必要があります。
This document uses the term "overload" to refer to application-layer overload at Diameter nodes. This is distinct from "network congestion", that is, congestion that occurs at the lower networking layers that may impact the delivery of Diameter messages between nodes. This document recognizes that element overload and network congestion are interrelated, and that overload can contribute to network congestion and vice versa.
このドキュメントでは、「過負荷」という用語を使用して、Diameterノードでのアプリケーション層の過負荷を指します。これは、「ネットワークの輻輳」、つまりノード間のDiameterメッセージの配信に影響を与える可能性のある下位のネットワークレイヤで発生する輻輳とは異なります。このドキュメントは、要素の過負荷とネットワークの輻輳が相互に関連していること、および過負荷がネットワークの輻輳の一因となる可能性があること、およびその逆を認識しています。
Network congestion issues are better handled by the transport protocols. Diameter uses TCP and the Stream Control Transmission Protocol (SCTP), both of which include congestion management features. Analysis of whether those features are sufficient for transport-level congestion between Diameter nodes and of any work to further mitigate network congestion is out of scope for both this document and the work proposed by it.
ネットワークの輻輳の問題は、トランスポートプロトコルによって適切に処理されます。 Diameterは、TCPとStream Control Transmission Protocol（SCTP）を使用します。どちらも輻輳管理機能を備えています。これらの機能がDiameterノード間のトランスポートレベルの輻輳に十分かどうか、およびネットワークの輻輳をさらに緩和する作業の分析は、このドキュメントとそれによって提案された作業の両方の範囲外です。
Most elements using Diameter applications do not use Diameter exclusively. It is important to realize that overload of an element can be caused by a number of factors that may be unrelated to the processing of Diameter or Diameter applications.
Diameterアプリケーションを使用するほとんどの要素は、Diameterを排他的に使用しません。要素の過負荷は、DiameterまたはDiameterアプリケーションの処理とは無関係のいくつかの要因によって発生する可能性があることを理解することが重要です。
An element that doesn't use Diameter exclusively needs to be able to signal to Diameter peers that it is experiencing overload regardless of the cause of the overload, since the overload will affect that element's ability to process Diameter transactions. If the element communicates with protocols other than Diameter, it may also need to signal the overload situation on these protocols, depending on its function and the architecture of the network and application for which it is providing services. Whether that is necessary can only be decided within the context of that architecture and use cases. This specification details the requirements for a mechanism for signaling overload with Diameter; this mechanism provides Diameter nodes the ability to inform their Diameter peers of overload, mitigating that part of the issue. Diameter nodes may need to use this, as well as other mechanisms, to solve their broader overload issues. Indicating overload on protocols other than Diameter is out of scope for this document and for the work proposed by it.
Diameterを排他的に使用しない要素は、Diameterピアに過負荷の原因に関係なく過負荷が発生していることを通知できる必要があります。過負荷はその要素のDiameterトランザクションを処理する機能に影響を与えるためです。要素がDiameter以外のプロトコルと通信する場合、その機能と、サービスを提供するネットワークおよびアプリケーションのアーキテクチャーによっては、これらのプロトコルの過負荷状態を通知する必要がある場合もあります。それが必要かどうかは、そのアーキテクチャーとユースケースのコンテキスト内でのみ決定できます。この仕様では、Diameterで過負荷を通知するメカニズムの要件について詳しく説明しています。このメカニズムは、Diameterノードに過負荷をDiameterピアに通知する機能を提供し、問題のその部分を軽減します。 Diameterノードは、広範なオーバーロードの問題を解決するために、これと他のメカニズムを使用する必要がある場合があります。 Diameter以外のプロトコルの過負荷を示すことは、このドキュメントおよびこのドキュメントによって提案された作業の範囲外です。
Several Diameter deployment scenarios exist that may impact overload management. The following scenarios help motivate the requirements for an overload management mechanism.
過負荷管理に影響を与える可能性があるいくつかのDiameterデプロイメントシナリオが存在します。次のシナリオは、過負荷管理メカニズムの要件を動機付けるのに役立ちます。
These scenarios are by no means exhaustive and are in general simplified for the sake of clarity. In particular, this document assumes for the sake of clarity that the client sends Diameter requests to the server, and the server sends responses to the client, even though Diameter supports bidirectional applications. Each direction in such an application can be modeled separately.
これらのシナリオは決して網羅的なものではなく、一般的にわかりやすくするために簡略化されています。特に、このドキュメントでは、わかりやすくするために、Diameterが双方向アプリケーションをサポートしている場合でも、クライアントがサーバーにDiameter要求を送信し、サーバーがクライアントに応答を送信することを前提としています。このようなアプリケーションの各方向は、個別にモデル化できます。
In a large-scale deployment, many of the nodes represented in these scenarios would be deployed as clusters of servers. This document assumes that such a cluster is responsible for managing its own internal load-balancing and overload management so that it appears as a single Diameter node. That is, other Diameter nodes can treat it as a single, monolithic node for the purposes of overload management.
大規模な展開では、これらのシナリオで表されるノードの多くはサーバーのクラスターとして展開されます。このドキュメントでは、そのようなクラスタが独自の内部負荷分散および過負荷管理を管理して、単一のDiameterノードとして表示されることを前提としています。つまり、他のDiameterノードは、過負荷管理のために単一のモノリシックノードとして扱うことができます。
These scenarios do not illustrate the client application. As mentioned in Section 1, Diameter is not typically an end-user protocol; rather, it is generally used in support of some other client application. These scenarios do not consider the impact of Diameter overload on the client application.
これらのシナリオは、クライアントアプリケーションを示していません。セクション1で述べたように、Diameterは通常、エンドユーザープロトコルではありません。むしろ、他のクライアントアプリケーションをサポートするために一般的に使用されます。これらのシナリオでは、クライアントアプリケーションに対するDiameter過負荷の影響は考慮されていません。
This section describes Diameter peer-to-peer scenarios, that is, scenarios where a Diameter client talks directly with a Diameter server, without the use of a Diameter agent.
このセクションでは、Diameterピアツーピアシナリオ、つまりDiameterクライアントがDiameterエージェントを使用せずにDiameterサーバーと直接通信するシナリオについて説明します。
Figure 1 illustrates the simplest possible Diameter relationship. The client and server share a one-to-one peer-to-peer relationship. If the server becomes overloaded, either because the client exceeds the server's capacity or because the server's capacity is reduced due to some resource dependency, the client needs to reduce the amount of Diameter traffic it sends to the server. Since the client cannot forward requests to another server, it must either queue requests until the server recovers or itself become overloaded in the context of the client application and other protocols it may also use.
図1は、最も単純なDiameter関係を示しています。クライアントとサーバーは、1対1のピアツーピア関係を共有します。クライアントがサーバーの容量を超えたため、またはリソースの依存関係によってサーバーの容量が減少したためにサーバーが過負荷になった場合、クライアントはサーバーに送信するDiameterトラフィックの量を減らす必要があります。クライアントは要求を別のサーバーに転送できないため、サーバーが回復するまで、またはクライアントアプリケーションと他のプロトコルのコンテキストでサーバー自体が過負荷になるまで、要求をキューに入れる必要があります。
+------------------+
| |
| |
| Server |
| |
+--------+---------+
|
|
+--------+---------+
| |
| |
| Client |
| |
+------------------+
Figure 1: Basic Peer-to-Peer Scenario
図1：基本的なピアツーピアシナリオ
Figure 2 shows a similar scenario, except in this case the client has multiple servers that can handle work for a specific realm and application. If Server 1 becomes overloaded, the client can forward traffic to Server 2. Assuming that Server 2 has sufficient reserve capacity to handle the forwarded traffic, the client should be able to continue serving client application protocol users. If Server 1 is approaching overload, but can still handle some number of new requests, it needs to be able to instruct the client to forward a subset of its traffic to Server 2.
図2は同様のシナリオを示していますが、この場合、クライアントには、特定のレルムとアプリケーションの作業を処理できる複数のサーバーがあります。サーバー1が過負荷になった場合、クライアントはサーバー2にトラフィックを転送できます。サーバー2に転送されたトラフィックを処理するための十分な予備容量があると仮定すると、クライアントは引き続きクライアントアプリケーションプロトコルユーザーにサービスを提供できるはずです。サーバー1が過負荷に近づいているが、それでもいくつかの新しい要求を処理できる場合は、サーバーにトラフィックのサブセットを転送するようにクライアントに指示できる必要があります。
+------------------+ +------------------+
| | | |
| | | |
| Server 1 | | Server 2 |
| | | |
+--------+-`.------+ +------.'+---------+
`. .'
`. .'
`. .'
`. .'
+-------`.'--------+
| |
| |
| Client |
| |
+------------------+
Figure 2: Multiple-Server Peer-to-Peer Scenario
図2：複数サーバーのピアツーピアシナリオ
Figure 3 illustrates a peer-to-peer scenario with multiple Diameter realm and application combinations. In this example, Server 2 can handle work for both applications. Each application might have different resource dependencies. For example, a server might need to access one database for Application A and another for Application B. This creates a possibility that Server 2 could become overloaded for Application A but not for Application B, in which case the client would need to divert some part of its Application A requests to Server 1, but the client should not divert any Application B requests. This requires that Server 2 be able to distinguish between applications when it indicates an overload condition to the client.
図3は、複数のDiameterレルムとアプリケーションの組み合わせによるピアツーピアシナリオを示しています。この例では、サーバー2は両方のアプリケーションの作業を処理できます。アプリケーションごとに異なるリソースの依存関係がある場合があります。たとえば、サーバーはアプリケーションAの1つのデータベースとアプリケーションBの別のデータベースにアクセスする必要がある場合があります。これにより、サーバー2がアプリケーションAではオーバーロードされ、アプリケーションBではオーバーロードされない可能性があります。この場合、クライアントは一部を迂回する必要があります。そのアプリケーションA要求のサーバー1への送信を行いますが、クライアントはアプリケーションB要求を転送しないでください。これは、サーバー2がクライアントに過負荷状態を示しているときに、アプリケーションを区別できる必要があります。
On the other hand, it's possible that the servers host many applications. If Server 2 becomes overloaded for all applications, it would be undesirable for it to have to notify the client separately for each application. Therefore, it also needs a way to indicate that it is overloaded for all possible applications.
一方、サーバーが多くのアプリケーションをホストしている可能性があります。すべてのアプリケーションでサーバー2が過負荷になった場合、アプリケーションごとにクライアントに通知する必要があるのは望ましくありません。したがって、可能なすべてのアプリケーションでオーバーロードであることを示す方法も必要です。
+---------------------------------------------+
| Application A +----------------------+----------------------+
|+------------------+ | +----------------+ | +------------------+|
|| | | | | | | ||
|| | | | | | | ||
|| Server 1 | | | Server 2 | | | Server 3 ||
|| | | | | | | ||
|+--------+---------+ | +-------+--------+ | +-+----------------+|
| | | | | | |
+---------+-----------+----------+-----------+ | |
| | | | |
| | | | Application B |
| +----------+----------------+-----------------+
``-.._ | |
`-..__ | _.-''
`--._ | _.-''
``-._ | _.-''
+-----`-.-''-----+
| |
| |
| Client |
| |
+----------------+
Figure 3: Multiple-Application Peer-to-Peer Scenario
図3：複数アプリケーションのピアツーピアシナリオ
This section describes scenarios that include a Diameter agent, in the form of either a Diameter relay or Diameter proxy. These scenarios do not consider Diameter redirect agents, since they are more readily modeled as end servers. The examples have been kept simple deliberately, to illustrate basic concepts. Significantly more complicated topologies are possible with Diameter, including multiple intermediate agents in a path connected in a variety of ways.
このセクションでは、DiameterリレーまたはDiameterプロキシのいずれかの形式で、Diameterエージェントを含むシナリオについて説明します。これらのシナリオはエンドサーバーとしてより容易にモデル化されるため、Diameterリダイレクトエージェントは考慮されません。例は、基本的な概念を説明するために、意図的に単純化されています。 Diameterを使用すると、さまざまな方法で接続されたパスに複数の中間エージェントを含む、かなり複雑なトポロジが可能になります。
Figure 4 illustrates a simple Diameter agent scenario with a single client, agent, and server. In this case, overload can occur at the server, at the agent, or both. But in most cases, client behavior is the same whether overload occurs at the server or at the agent. From the client's perspective, server overload and agent overload are the same thing.
図4は、単一のクライアント、エージェント、およびサーバーを使用した単純なDiameterエージェントシナリオを示しています。この場合、サーバー、エージェント、またはその両方で過負荷が発生する可能性があります。ただし、ほとんどの場合、サーバーまたはエージェントで過負荷が発生しても、クライアントの動作は同じです。クライアントの観点からは、サーバーの過負荷とエージェントの過負荷は同じものです。
+------------------+
| |
| |
| Server |
| |
+--------+---------+
|
|
+--------+---------+
| |
| |
| Agent |
| |
+--------+---------+
|
|
+--------+---------+
| |
| |
| Client |
| |
+------------------+
Figure 4: Basic Agent Scenario
図4：基本的なエージェントのシナリオ
Figure 5 shows an agent scenario with multiple servers. If Server 1 becomes overloaded but Server 2 has sufficient reserve capacity, the agent may be able to transparently divert some or all Diameter requests originally bound for Server 1 to Server 2.
図5は、複数のサーバーがあるエージェントのシナリオを示しています。サーバー1が過負荷になったが、サーバー2に十分な予備容量がある場合、エージェントは、サーバー1に当初バインドされていた一部またはすべてのDiameter要求をサーバー2に透過的に転送できる可能性があります。
In most cases, the client does not have detailed knowledge of the Diameter topology upstream of the agent. If the agent uses dynamic discovery to find eligible servers, the set of eligible servers may not be enumerable from the perspective of the client. Therefore, in most cases the agent needs to deal with any upstream overload issues in a way that is transparent to the client. If one server notifies the agent that it has become overloaded, the notification should not be passed back to the client in a way that the client could mistakenly perceive the agent itself as being overloaded. If the set of all possible destinations upstream of the agent no longer has sufficient capacity for incoming load, the agent itself becomes effectively overloaded.
ほとんどの場合、クライアントには、エージェントの上流のDiameterトポロジに関する詳細な知識がありません。エージェントが動的検出を使用して適格なサーバーを見つける場合、クライアントの観点からは、適格なサーバーのセットを列挙できない場合があります。したがって、ほとんどの場合、エージェントは、クライアントに対して透過的な方法で、アップストリームの過負荷の問題に対処する必要があります。 1つのサーバーがエージェントに過負荷になったことを通知する場合は、クライアントにエージェント自体が過負荷であると誤って認識されるような方法で、通知をクライアントに返す必要はありません。エージェントの上流にある可能性のあるすべての宛先のセットに着信負荷に対して十分な容量がない場合、エージェント自体が実質的に過負荷になります。
On the other hand, there are cases where the client needs to be able to select a particular server from behind an agent. For example, if a Diameter request is part of a multiple-round-trip authentication, or is otherwise part of a Diameter "session", it may have a Destination-Host Attribute-Value Pair (AVP) that requires that the request be served by Server 1. Therefore, the agent may need to inform a client that a particular upstream server is overloaded or otherwise unavailable. Note that there can be many ways a server can be specified, which may have different implications (e.g., by IP address, by host name, etc).
一方、クライアントがエージェントの背後から特定のサーバーを選択できる必要がある場合があります。たとえば、Diameterリクエストが複数ラウンドトリップ認証の一部である場合、またはDiameterの「セッション」の一部である場合、Diameterリクエストは、リクエストの処理を必要とするDestination-Host Attribute-Value Pair（AVP）を持つ場合があります。そのため、エージェントは、特定の上流サーバーが過負荷になっているか、そうでなければ利用できないことをクライアントに通知する必要がある場合があります。サーバーを指定する方法はいくつもあることに注意してください。これには、異なる影響（IPアドレス、ホスト名など）がある場合があります。
+------------------+ +------------------+
| | | |
| | | |
| Server 1 | | Server 2 |
| | | |
+--------+-`.------+ +------.'+---------+
`. .'
`. .'
`. .'
`. .'
+-------`.'--------+
| |
| |
| Agent |
| |
+--------+---------+
|
|
|
+--------+---------+
| |
| |
| Client |
| |
+------------------+
Figure 5: Multiple-Server Agent Scenario
図5：複数サーバーエージェントのシナリオ
Figure 6 shows a scenario where an agent routes requests to a set of servers for more than one Diameter realm and application. In this scenario, if Server 1 becomes overloaded or unavailable while Server 2 still has available capacity, the agent may effectively operate at reduced capacity for Application A but at full capacity for Application B. Therefore, the agent needs to be able to report that it is overloaded for one application but not for another.
図6は、エージェントが複数のDiameterレルムとアプリケーションのサーバーのセットにリクエストをルーティングするシナリオを示しています。このシナリオでは、サーバー2にまだ容量があるにもかかわらずサーバー1が過負荷または使用不可になった場合、エージェントはアプリケーションAの容量を減らして効果的に動作しますが、アプリケーションBの容量は最大になります。したがって、エージェントはそれを報告できる必要があります。あるアプリケーションではオーバーロードされますが、別のアプリケーションではオーバーロードされません。
+--------------------------------------------+
| Application A +----------------------+----------------------+
|+------------------+ | +----------------+ | +------------------+|
|| | | | | | | ||
|| | | | | | | ||
|| Server 1 | | | Server 2 | | | Server 3 ||
|| | | | | | | ||
|+---------+--------+ | +-------+--------+ | +--+---------------+|
| | | | | | |
+----------+----------+----------+-----------+ | |
| | | | |
| | | | Application B |
| +----------+-----------------+----------------+
| | |
``--.__ | _.
``-.__ | __.--''
`--.._ | _..--'
+----``-+.''-----+
| |
| |
| Agent |
| |
+-------+--------+
|
|
+-------+--------+
| |
| |
| Client |
| |
+----------------+
Figure 6: Multiple-Application Agent Scenario
図6：複数アプリケーションエージェントのシナリオ
Another scenario to consider when looking at Diameter overload is that of multiple network operators using Diameter components connected through an interconnect service, e.g., using IPX (IP Packet eXchange). IPX [IR.34] is an Inter-Operator IP Backbone that provides a roaming interconnection network between mobile operators and service providers. IPX is also used to transport Diameter signaling between operators [IR.88]. Figure 7 shows two network operators with an interconnect network between them. There could be any number of these networks between any two network operators' networks.
Diameterの過負荷を検討する際に考慮すべきもう1つのシナリオは、相互接続サービスを介して接続されたDiameterコンポーネントを使用する複数のネットワークオペレーター（IPX（IP Packet eXchange）など）のシナリオです。 IPX [IR.34]は、モバイルオペレーターとサービスプロバイダー間のローミング相互接続ネットワークを提供するInter-Operator IPバックボーンです。 IPXは、オペレーター間でDiameterシグナリングを転送するためにも使用されます[IR.88]。図7は、2つのネットワーク事業者と相互接続ネットワークを示しています。 2つのネットワーク事業者のネットワーク間には、これらのネットワークがいくつあってもかまいません。
+-------------------------------------------+
| Interconnect |
| |
| +--------------+ +--------------+ |
| | Server 3 |------| Server 4 | |
| +--------------+ +--------------+ |
| .' `. |
+------.-'--------------------------`.------+
.' `.
.-' `.
------------.'-----+ +----`.-------------
+----------+ | | +----------+
| Server 1 | | | | Server 2 |
+----------+ | | +----------+
| |
Network Operator 1 | | Network Operator 2
-------------------+ +-------------------
Figure 7: Two-Network Interconnect Scenario
図7：2つのネットワーク相互接続のシナリオ
The characteristics of the information that an operator would want to share over such a connection are different from the information shared between components within a network operator's network. For example, network operators may not want to convey topology or operational information; this would in turn limit how much overload and loading information can be sent. For the interconnect scenario shown in Figure 7, Server 2 may want to signal overload to Server 1, to affect traffic coming from Network Operator 1.
オペレーターがそのような接続を介して共有したい情報の特性は、ネットワークオペレーターのネットワーク内のコンポーネント間で共有される情報とは異なります。たとえば、ネットワークオペレータはトポロジや運用情報を伝えたくない場合があります。これにより、送信できるオーバーロードおよびロード情報の量が制限されます。図7に示す相互接続シナリオの場合、サーバー2はサーバー1に過負荷を通知して、ネットワークオペレーター1からのトラフィックに影響を与えることができます。
This case is distinct from those internal to a network operator's network, where there may be many more elements in a more complicated topology. Also, the elements in the interconnect network may not support Diameter overload control, and the network operators may not want the interconnect network to use overload or loading information. They may only want the information to pass through the interconnect network without further processing or action by the interconnect network, even if the elements in the interconnect network do support Diameter overload control.
このケースは、ネットワークオペレーターのネットワークの内部にあるケースとは異なります。ネットワークオペレーターのネットワークでは、より複雑なトポロジにさらに多くの要素が存在する可能性があります。また、相互接続ネットワークの要素はDiameter過負荷制御をサポートしていない場合があり、ネットワークオペレータは相互接続ネットワークが過負荷または負荷情報を使用することを望まない場合があります。相互接続ネットワーク内の要素がDiameter過負荷制御をサポートしている場合でも、相互接続ネットワークによる追加の処理やアクションなしに、情報が相互接続ネットワークを通過することだけが必要な場合があります。
As the number of smartphone devices that are Third Generation (3G) and Long Term Evolution (LTE) enabled continues to expand in mobile networks, there have been situations where high signaling traffic load led to overload events at the Diameter-based Home Location Registers (HLRs) and/or Home Subscriber Servers (HSS) [TR23.843]. The root causes of the HLR overload events were manifold but included hardware failure and procedural errors. The result was high signaling traffic load on the HLR and HSS.
第3世代（3G）とLong Term Evolution（LTE）が有効になっているスマートフォンデバイスの数はモバイルネットワークで拡大し続けているため、信号トラフィックの負荷が高く、Diameterベースのホームロケーションレジスタで過負荷イベントが発生する状況がありました（ HLR）および/またはホームサブスクライバーサーバー（HSS）[TR23.843]。 HLR過負荷イベントの根本的な原因は多種多様でしたが、ハードウェア障害と手順エラーが含まれていました。その結果、HLRとHSSでシグナリングトラフィックの負荷が高くなりました。
The 3GPP architecture [TS23.002] makes extensive use of Diameter. It is used for mobility management [TS29.272], the IP Multimedia Subsystem (IMS) [TS29.228], and policy and charging control [TS29.212], as well as other functions. The details of the architecture are out of scope for this document, but it is worth noting that there are quite a few Diameter applications, some with quite large amounts of Diameter signaling in deployed networks.
3GPPアーキテクチャ[TS23.002]は、Diameterを幅広く使用しています。モビリティ管理[TS29.272]、IPマルチメディアサブシステム（IMS）[TS29.228]、ポリシーと課金制御[TS29.212]、およびその他の機能に使用されます。アーキテクチャの詳細はこのドキュメントの範囲外ですが、導入されたネットワークで非常に大量のDiameterシグナリングを使用するDiameterアプリケーションがかなりあることは注目に値します。
The 3GPP specifications do not currently address overload for Diameter applications or provide a load control mechanism equivalent to those provided in the more traditional SS7 elements in the Global System for Mobile Communications (GSM); see [TS29.002]. The capabilities specified in the 3GPP standards do not adequately address the abnormal condition where excessively high signaling traffic load situations are experienced.
3GPP仕様は現在、Diameterアプリケーションの過負荷に対処しておらず、Global System for Mobile Communications（GSM）の従来のSS7要素で提供されるものと同等の負荷制御メカニズムを提供していません。 [TS29.002]を参照してください。 3GPP標準で指定された機能は、過度に高いシグナリングトラフィック負荷状況が発生する異常な状態に適切に対処していません。
Smartphones, which comprise an increasingly large percentage of mobile devices, contribute much more heavily, relative to non-smartphones, to the continuation of a registration surge, due to their very aggressive registration algorithms. Smartphone behavior contributes to network loading and can contribute to overload conditions. The aggressive smartphone logic is designed to:
ますます多くの割合のモバイルデバイスを構成するスマートフォンは、非常に積極的な登録アルゴリズムにより、スマートフォン以外に比べて、登録サージの継続に大きく貢献しています。スマートフォンの動作はネットワークの負荷に寄与し、過負荷状態に寄与する可能性があります。アグレッシブなスマートフォンロジックは、次のように設計されています。
a. always have voice and data registration, and
a. 常に音声とデータの登録があり、
b. constantly try to be on 3G or LTE data (and thus on 3G voice or Voice over LTE (VoLTE) [IR.92]) for their added benefits.
b. 追加の利点のために、常に3GまたはLTEデータ（したがって3G音声またはVoice over LTE（VoLTE）[IR.92]）を使用しようとします。
Non-smartphones typically have logic to wait for a time period after registering successfully on voice and data.
スマートフォン以外には、通常、音声とデータの登録に成功した後、しばらく待機するロジックがあります。
The aggressive smartphone registration is problematic in two ways:
スマートフォンの積極的な登録は、次の2つの点で問題があります。
o first, by generating excessive signaling load towards the HSS that is ten times the load from a non-smartphone, and
o 最初に、スマートフォン以外の負荷の10倍であるHSSへの過剰なシグナリング負荷を生成し、
o second, by causing continual registration attempts when a network failure affects registrations through the 3G data network.
o 2つ目は、ネットワーク障害が3Gデータネットワークを介した登録に影響を与えるときに、継続的な登録試行を引き起こすことです。
A study in the 3GPP System Aspects working group 2 (SA2) on core network overload has produced the technical report [TR23.843]. This enumerates several causes of overload in mobile core networks, including portions that are signaled using Diameter. [TR23.843] is a work in progress and is not complete. However, it is useful for pointing out scenarios and the general need for an overload control mechanism for Diameter.
コアネットワークの過負荷に関する3GPP System Aspectsワーキンググループ2（SA2）での調査により、テクニカルレポート[TR23.843]が作成されました。これは、Diameterを使用して通知される部分を含む、モバイルコアネットワークにおける過負荷のいくつかの原因を列挙します。 [TR23.843]は進行中の作業であり、完了していません。ただし、Diameterのオーバーロード制御メカニズムのシナリオや一般的な必要性を指摘するのに役立ちます。
It is common for mobile networks to employ more than one radio technology and to do so in an overlay fashion with multiple technologies present in the same location (such as 2nd or 3rd generation mobile technologies, along with LTE). This presents opportunities for traffic storms when issues occur on one overlay and not another as all devices that had been on the overlay with issues switch. This causes a large amount of Diameter traffic as locations and policies are updated.
モバイルネットワークでは、複数の無線技術を採用し、同じ場所に複数の技術（LTEとともに第2または第3世代のモバイル技術など）が存在するオーバーレイ方式でそれを行うのが一般的です。問題のあるオーバーレイ上にあったすべてのデバイスが切り替わるため、あるオーバーレイで問題が発生したときにトラフィックストームが発生する可能性があります。これにより、場所とポリシーが更新されるときに、Diameterトラフィックが大量に発生します。
Another scenario called out by this study is a flood of registration and mobility management events caused by some element in the core network failing. This flood of traffic from end nodes falls under the network-initiated traffic flood category. There is likely to also be traffic resulting directly from the component failure in this case. A similar flood can occur when elements or components recover as well.
この調査で指摘された別のシナリオは、コアネットワークの一部の要素の障害が原因で発生する大量の登録およびモビリティ管理イベントです。このエンドノードからのトラフィックのフラッドは、ネットワークが開始するトラフィックフラッドのカテゴリに分類されます。この場合、コンポーネントの障害から直接発生するトラフィックもある可能性があります。同様の洪水は、要素またはコンポーネントが回復したときにも発生する可能性があります。
Subscriber-initiated traffic floods are also indicated in this study as an overload mechanism where a large number of mobile devices are attempting to access services at the same time, such as in response to an entertainment event or a catastrophic event.
この調査では、加入者が開始するトラフィックフラッドも、エンターテインメントイベントや壊滅的なイベントへの応答など、多数のモバイルデバイスが同時にサービスにアクセスしようとする過負荷メカニズムとして示されています。
While this 3GPP study is concerned with the broader effects of these scenarios on wireless networks and their elements, they have implications specifically for Diameter signaling. One of the goals of this document is to provide guidance for a core mechanism that can be used to mitigate the scenarios called out by this study.
この3GPP調査は、ワイヤレスネットワークとその要素に対するこれらのシナリオのより広範な影響に関係していますが、特にDiameterシグナリングに影響を与えます。このドキュメントの目的の1つは、この調査で呼び出されたシナリオを軽減するために使用できるコアメカニズムのガイダンスを提供することです。
Diameter offers both implicit and explicit mechanisms for a Diameter node to learn that a peer is overloaded or unreachable. The implicit mechanism is simply the lack of responses to requests. If a client fails to receive a response in a certain time period, it assumes that the upstream peer is unavailable or is overloaded to the point of effective unavailability. The watchdog mechanism [RFC3539] ensures that transaction responses occur at a certain rate even when there is otherwise little or no other Diameter traffic.
Diameterは、ピアが過負荷または到達不能であることをDiameterノードが知るための暗黙的メカニズムと明示的メカニズムの両方を提供します。暗黙のメカニズムは、単に要求に対する応答がないことです。クライアントが一定の時間内に応答を受信できない場合、クライアントは、アップストリームピアが使用できないか、または過負荷状態になり、実質的に使用できなくなると想定します。ウォッチドッグメカニズム[RFC3539]は、他のDiameterトラフィックがほとんどまたはまったくない場合でも、トランザクション応答が特定のレートで発生するようにします。
The explicit mechanism can involve specific protocol error responses, where an agent or server tells a downstream peer that it is either too busy to handle a request (DIAMETER_TOO_BUSY) or unable to route a request to an upstream destination (DIAMETER_UNABLE_TO_DELIVER) perhaps because that destination itself is overloaded to the point of unavailability.
明示的なメカニズムには、特定のプロトコルエラー応答が含まれる場合があります。エージェントまたはサーバーがダウンストリームピアに、要求を処理するにはビジー状態であること（DIAMETER_TOO_BUSY）または上流の宛先に要求をルーティングできないこと（DIAMETER_UNABLE_TO_DELIVER）のいずれかであるため、宛先自体が原因である可能性があります。利用できなくなるまで過負荷です。
Another explicit mechanism, a DPR (Disconnect-Peer-Request) message, can be sent with a Disconnect-Cause of BUSY. This signals the sender's intent to close the transport connection and requests that the client not reconnect.
別の明示的なメカニズムであるDPR（Disconnect-Peer-Request）メッセージは、Disconnect-Cause of BUSYで送信できます。これは、トランスポート接続を閉じるという送信者の意図を示し、クライアントに再接続しないように要求します。
Once a Diameter node learns via one of these mechanisms that an upstream peer has become overloaded, it can then attempt to take action to reduce the load. This usually means forwarding traffic to an alternate destination, if available. If no alternate destination is available, the node must either reduce the number of messages it originates (in the case of a client) or inform the client to reduce traffic (in the case of an agent).
Diameterノードは、これらのメカニズムのいずれかを介して、アップストリームピアが過負荷になったことを学習すると、負荷を軽減するためのアクションを試みることができます。これは通常、可能な場合、トラフィックを別の宛先に転送することを意味します。代替の宛先が利用できない場合、ノードは発信するメッセージの数を減らすか（クライアントの場合）、クライアントにトラフィックを減らすように通知する必要があります（エージェントの場合）。
Diameter requires the use of a congestion-managed transport layer, currently TCP or SCTP, to mitigate network congestion. It is expected that these transports manage network congestion and that issues with transport (e.g., congestion propagation and window management) are managed at that level. But even with a congestion-managed transport, a Diameter node can become overloaded at the Diameter protocol or application layers due to the causes described in Section 1.2, and congestion-managed transports do not provide facilities (and are at the wrong level) to handle server overload. Transport-level congestion management is also not sufficient to address overload in cases of multi-hop and multi-destination signaling.
Diameterでは、ネットワークの輻輳を緩和するために、現在TCPまたはSCTPである輻輳管理のトランスポート層を使用する必要があります。これらのトランスポートはネットワークの輻輳を管理し、トランスポートの問題（輻輳の伝播やウィンドウ管理など）はそのレベルで管理されることが期待されています。ただし、輻輳管理のトランスポートを使用しても、セクション1.2で説明されている原因により、DiameterノードがDiameterプロトコルまたはアプリケーション層で過負荷になる可能性があり、輻輳管理のトランスポートは処理する機能を提供しません（レベルが正しくありません）。サーバーの過負荷。トランスポートレベルの輻輳管理も、マルチホップおよびマルチ宛先シグナリングの場合の過負荷に対処するには十分ではありません。
The currently available Diameter mechanisms for indicating an overload condition are not adequate to avoid service outages due to overload. This inadequacy may, in turn, contribute to broader impacts resulting from overload due to unresponsive Diameter nodes causing application-layer or transport-layer retransmissions. In particular, they do not allow a Diameter agent or server to shed load as it approaches overload. At best, a node can only indicate that it needs to entirely stop receiving requests, i.e., that it has effectively failed. Even that is problematic due to the inability to indicate durational validity on the transient errors available in the base Diameter protocol. Diameter offers no mechanism to allow a node to indicate different overload states for different categories of messages, for example, if it is overloaded for one Diameter application but not another.
過負荷状態を示すために現在利用可能なDiameterメカニズムは、過負荷によるサービスの停止を回避するには不十分です。この不適切性は、アプリケーションレイヤーまたはトランスポートレイヤーの再送信の原因となる無応答のDiameterノードが原因で発生する過負荷による広範な影響につながる可能性があります。特に、Diameterエージェントまたはサーバーが過負荷に近づくにつれて負荷を減らすことはできません。せいぜい、ノードは要求の受信を完全に停止する必要があること、つまり、ノードが事実上失敗したことを示すことができるだけです。これは、基本のDiameterプロトコルで利用可能な一時的なエラーの継続的な有効性を示すことができないため、問題があります。 Diameterには、たとえば、あるDiameterアプリケーションではオーバーロードされているが別のアプリケーションではオーバーロードされていない場合など、ノードがメッセージの異なるカテゴリの異なるオーバーロード状態を示すことができるメカニズムはありません。
The implicit mechanism doesn't allow an agent or server to inform the client of a problem until it is effectively too late to do anything about it. The client does not know that it needs to take action until the upstream node has effectively failed. A Diameter node has no opportunity to shed load early to avoid collapse in the first place.
暗黙のメカニズムでは、エージェントまたはサーバーがクライアントに問題を通知することはできません。問題が実際に遅すぎて、それについて何かを行うことができなくなるまでは。クライアントは、上流ノードが事実上失敗するまで、アクションを実行する必要があることを知りません。 Diameterノードには、そもそも崩壊を避けるために、負荷を早期に流す機会はありません。
Additionally, the implicit mechanism cannot distinguish between overload of a Diameter node and network congestion. Diameter treats the failure to receive an answer as a transport failure.
さらに、暗黙のメカニズムでは、Diameterノードの過負荷とネットワークの輻輳を区別できません。 Diameterは、応答の受信の失敗をトランスポートの失敗として扱います。
The Diameter specification is ambiguous on how a client should handle receipt of a DIAMETER_TOO_BUSY response. The base specification [RFC6733] indicates that the sending client should attempt to send the request to a different peer. It makes no suggestion that the receipt of a DIAMETER_TOO_BUSY response should affect future Diameter messages in any way.
Diameter仕様は、クライアントがDIAMETER_TOO_BUSY応答の受信を処理する方法についてあいまいです。基本仕様[RFC6733]は、送信クライアントが要求を別のピアに送信することを試みる必要があることを示しています。 DIAMETER_TOO_BUSY応答の受信が、将来のDiameterメッセージに何らかの影響を与えるはずであることを示唆していません。
The Authentication, Authorization, and Accounting (AAA) Transport Profile [RFC3539] recommends that a AAA node that receives a "Busy" response failover all remaining requests to a different agent or server. But while the Diameter base specification explicitly depends on [RFC3539] to define transport behavior, it does not refer to [RFC3539] in the description of behavior on receipt of a DIAMETER_TOO_BUSY error. There's a strong likelihood that at least some implementations will continue to send Diameter requests to an upstream peer even after receiving a DIAMETER_TOO_BUSY error.
認証、承認、アカウンティング（AAA）トランスポートプロファイル[RFC3539]は、「ビジー」応答を受信するAAAノードが、残りのすべての要求を別のエージェントまたはサーバーにフェイルオーバーすることを推奨しています。ただし、Diameter基本仕様は[RFC3539]に明示的に依存してトランスポートの動作を定義しますが、DIAMETER_TOO_BUSYエラーの受信時の動作の説明では[RFC3539]を参照していません。 DIAMETER_TOO_BUSYエラーを受信した後でも、少なくとも一部の実装がアップストリームピアにDiameterリクエストを送信し続ける可能性が非常に高いです。
BCP 41 [RFC2914] describes, among other things, how end-to-end application behavior can help avoid congestion collapse. In particular, an application should avoid sending messages that will never be delivered or processed. The DIAMETER_TOO_BUSY behavior as described in the Diameter base specification fails at this, since if an upstream node becomes overloaded, a client attempts each request and does not discover the need to failover the request until the initial attempt fails.
BCP 41 [RFC2914]は、特に、エンドツーエンドのアプリケーション動作が輻輳の崩壊を回避するのにどのように役立つかについて説明しています。特に、アプリケーションは、配信または処理されないメッセージの送信を回避する必要があります。 Diameter基本仕様で説明されているDIAMETER_TOO_BUSYの動作は失敗します。これは、上流ノードが過負荷になると、クライアントが各リクエストを試行し、最初の試行が失敗するまでリクエストをフェイルオーバーする必要があることを発見しないためです。
The situation is improved if implementations follow the [RFC3539] recommendation to keep state about upstream peer overload. But even then, the Diameter specification offers no guidance on how long a client should wait before retrying the overloaded destination. If an agent or server supports multiple realms and/or applications, DIAMETER_TOO_BUSY offers no way to indicate that it is overloaded for one application but not another. A DIAMETER_TOO_BUSY error can only indicate overload at a "whole server" scope.
実装がアップストリームピアの過負荷に関する状態を維持するために[RFC3539]勧告に従う場合、状況は改善されます。ただし、それでも、Diameter仕様では、過負荷の宛先を再試行する前にクライアントが待機する必要がある時間に関するガイダンスは提供されていません。エージェントまたはサーバーが複数のレルムまたはアプリケーション、あるいはその両方をサポートしている場合、DIAMETER_TOO_BUSYは、あるアプリケーションではオーバーロードされているが別のアプリケーションではオーバーロードされていないことを示す方法を提供していません。 DIAMETER_TOO_BUSYエラーは、「サーバー全体」のスコープでの過負荷のみを示すことができます。
Agent processing of a DIAMETER_TOO_BUSY response is also problematic as described in the base specification. DIAMETER_TOO_BUSY is defined as a protocol error. If an agent receives a protocol error, it may either handle it locally or forward the response back towards the downstream peer. If a downstream peer receives the DIAMETER_TOO_BUSY response, it may stop sending all requests to the agent for some period of time, even though the agent may still be able to deliver requests to other upstream peers.
基本仕様で説明されているように、DIAMETER_TOO_BUSY応答のエージェント処理にも問題があります。 DIAMETER_TOO_BUSYは、プロトコルエラーとして定義されます。エージェントがプロトコルエラーを受信した場合、それをローカルで処理するか、ダウンストリームピアに向けて応答を転送します。ダウンストリームピアがDIAMETER_TOO_BUSY応答を受信すると、エージェントが他のアップストリームピアに要求を配信できる場合でも、一定期間エージェントへのすべての要求の送信が停止することがあります。
DIAMETER_UNABLE_TO_DELIVER errors, or using DPR with cause code BUSY, also have no mechanisms for specifying the scope or cause of the failure, or the durational validity.
DIAMETER_UNABLE_TO_DELIVERエラー、または原因コードBUSYでDPRを使用する場合も、失敗のスコープまたは原因、または期間の有効性を指定するメカニズムがありません。
The issues with error responses described in [RFC6733] extend beyond the particular issues for overload control and have been addressed in an ad hoc fashion by various implementations. Addressing these in a standard way would be a useful exercise, but it is beyond the scope of this document.
[RFC6733]で説明されているエラー応答の問題は、過負荷制御の特定の問題を超えており、さまざまな実装によってその場限りの方法で対処されています。標準的な方法でこれらに対処することは有用な演習ですが、それはこのドキュメントの範囲を超えています。
Given the variety of scenarios in which Diameter elements can be deployed and the variety of roles they can fulfill with Diameter and other technologies, a single algorithm for handling overload may not be sufficient. For purposes of this discussion, an algorithm is inclusive of behavior for control of overload but does not encompass the general mechanism for transporting control information. This effort cannot anticipate all possible future scenarios and roles. Extensibility, particularly of algorithms used to deal with overload, will be important to cover these cases.
Diameterエレメントをデプロイできるさまざまなシナリオと、Diameterおよびその他のテクノロジーでそれらが果たすことができるさまざまな役割を考えると、過負荷を処理するための単一のアルゴリズムでは十分ではない場合があります。この説明では、アルゴリズムには過負荷を制御するための動作が含まれていますが、制御情報を転送するための一般的なメカニズムは含まれていません。この取り組みは、考えられるすべての将来のシナリオと役割を予測することはできません。これらのケースをカバーするには、拡張性、特に過負荷に対処するために使用されるアルゴリズムの拡張性が重要になります。
Similarly, the scopes to which overload information may apply may include cases that have not yet been considered. Extensibility in this area will also be important.
同様に、過負荷情報が適用される範囲には、まだ検討されていないケースが含まれる場合があります。この領域の拡張性も重要です。
The basic mechanism is intended to be application independent, that is, a Diameter node can use it across any existing and future Diameter applications and expect reasonable results. Certain Diameter applications might, however, benefit from application-specific behavior over and above the mechanism's defaults. For example, an application specification might specify relative priorities of messages or selection of a specific overload control algorithm.
基本的なメカニズムは、アプリケーションに依存しないことを目的としています。つまり、Diameterノードは、既存および将来のすべてのDiameterアプリケーションでそれを使用でき、妥当な結果を期待できます。ただし、特定のDiameterアプリケーションは、メカニズムのデフォルトに加えて、アプリケーション固有の動作から恩恵を受ける可能性があります。たとえば、アプリケーションの仕様では、メッセージの相対的な優先順位や特定の過負荷制御アルゴリズムの選択を指定できます。
This section proposes requirements for an improved mechanism to control Diameter overload, with the goals of addressing the issues described in Section 5 and supporting the scenarios described in Section 2. These requirements are stated primarily in terms of individual node behavior to inform the design of the improved mechanism; solution designers should keep in mind that the overall goal is improved overall system behavior across all the nodes involved, not just improved behavior from specific individual nodes.
このセクションでは、Diameterの過負荷を制御するための改善されたメカニズムの要件を提案し、セクション5で説明されている問題に対処し、セクション2で説明されているシナリオをサポートすることを目的とします。これらの要件は、主に個々のノードの動作に関して記述され、改善されたメカニズム;ソリューション設計者は、全体的な目標は、特定の個々のノードからの動作の改善だけでなく、関係するすべてのノードにわたるシステム全体の動作の改善であることを覚えておく必要があります。
REQ 1: The solution MUST provide a communication method for Diameter nodes to exchange load and overload information.
REQ 1：ソリューションは、Diameterノードが負荷情報と過負荷情報を交換するための通信方法を提供する必要があります。
REQ 2: The solution MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. Diameter clients and agents must be able to use the received load and overload information to support graceful behavior during an overload condition. Graceful behavior under overload conditions is best described by REQ 3.
REQ 2：ソリューションでは、DiameterノードがサポートするDiameterアプリケーションに関係なく、Diameterノードが過負荷制御をサポートできるようにする必要があります。 Diameterクライアントとエージェントは、受信した負荷と過負荷の情報を使用して、過負荷状態の間の正常な動作をサポートできる必要があります。過負荷状態での正常な動作は、REQ 3で最もよく説明されます。
REQ 3: The solution MUST limit the impact of overload on the overall useful throughput of a Diameter server, even when the incoming load on the network is far in excess of its capacity. The overall useful throughput under load is the ultimate measure of the value of a solution.
REQ 3：ソリューションは、Diameterサーバーの全体的な有効スループットに対する過負荷の影響を制限する必要があります（ネットワークの受信負荷がその容量をはるかに超えている場合でも）。負荷がかかった状態での全体的な有効スループットは、ソリューションの価値の最終的な尺度です。
REQ 4: Diameter allows requests to be sent from either side of a connection, and either side of a connection may have need to provide its overload status. The solution MUST allow each side of a connection to independently inform the other of its overload status.
REQ 4：Diameterでは、接続のどちら側からでも要求を送信できます。接続のどちら側でも、過負荷ステータスを提供する必要がある場合があります。ソリューションは、接続の各サイドがそのオーバーロードステータスを他方に独立して通知できるようにする必要があります。
REQ 5: Diameter allows nodes to determine their peers via dynamic discovery or manual configuration. The solution MUST work consistently without regard to how peers are determined.
REQ 5：Diameterにより、ノードは動的検出または手動構成を介してピアを決定できます。ソリューションは、ピアの決定方法に関係なく、一貫して機能する必要があります。
REQ 6: The solution designers SHOULD seek to minimize the amount of new configuration required in order to work. For example, it is better to allow peers to advertise or negotiate support for the solution, rather than to require that this knowledge be configured at each node.
REQ 6：ソリューション設計者は、機能するために必要な新しい構成の量を最小限に抑えるよう努めるべきです。たとえば、この知識を各ノードで構成することを要求するよりも、ピアがソリューションのサポートをアドバタイズまたはネゴシエートできるようにする方が適切です。
REQ 7: The solution and any associated default algorithm(s) MUST ensure that the system remains stable. At some point after an overload condition has ended, the solution MUST enable capacity to stabilize and become equal to what it would be in the absence of an overload condition. Note that this also requires that the solution MUST allow nodes to shed load without introducing non-converging oscillations during or after an overload condition.
REQ 7：ソリューションおよび関連するデフォルトのアルゴリズムは、システムが安定していることを保証する必要があります。過負荷状態が終了した後のある時点で、ソリューションは容量が安定し、過負荷状態がない場合と同じになるようにする必要があります。これはまた、ソリューションが過負荷状態の最中または後に非収束振動を導入することなくノードが負荷を取り除くことを許可する必要があることにも注意してください。
REQ 8: Supporting nodes MUST be able to distinguish current overload information from stale information.
REQ 8：サポートするノードは、現在のオーバーロード情報と古い情報を区別できなければなりません（MUST）。
REQ 9: The solution MUST function across fully loaded as well as quiescent transport connections. This is partially derived from the requirement for stability in REQ 7.
REQ 9：ソリューションは、完全にロードされた、および静止したトランスポート接続全体で機能する必要があります。これは、REQ 7の安定性の要件から部分的に派生しています。
REQ 10: Consumers of overload information MUST be able to determine when the overload condition improves or ends.
REQ 10：過負荷情報の利用者は、過負荷状態がいつ改善または終了するかを判断できなければなりません（MUST）。
REQ 11: The solution MUST be able to operate in networks of different sizes.
REQ 11：ソリューションは、異なるサイズのネットワークで動作できる必要があります。
REQ 12: When a single network node fails, goes into overload, or suffers from reduced processing capacity, the solution MUST make it possible to limit the impact of the affected node on other nodes in the network. This helps to prevent a small-scale failure from becoming a widespread outage.
REQ 12：単一のネットワークノードに障害が発生したり、過負荷になったり、処理能力が低下したりした場合、ソリューションは、影響を受けるノードがネットワーク内の他のノードに与える影響を制限できるようにする必要があります。これは、小規模な障害が広範囲にわたる停止になるのを防ぐのに役立ちます。
REQ 13: The solution MUST NOT introduce substantial additional work for a node in an overloaded state. For example, a requirement for an overloaded node to send overload information every time it received a new request would introduce substantial work.
REQ 13：ソリューションは、過負荷状態のノードに実質的な追加作業を導入してはなりません（MUST NOT）。たとえば、過負荷のノードが新しいリクエストを受信するたびに過負荷情報を送信する必要がある場合、かなりの作業が必要になります。
REQ 14: Some scenarios that result in overload involve a rapid increase of traffic with little time between normal levels and levels that induce overload. The solution SHOULD provide for rapid feedback when traffic levels increase.
REQ 14：過負荷を引き起こすいくつかのシナリオには、通常のレベルと過負荷を引き起こすレベルとの間の時間がほとんどない、トラフィックの急速な増加が含まれます。ソリューションは、トラフィックレベルが増加したときに迅速なフィードバックを提供する必要があります。
REQ 15: The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols. For example, a solution that opened additional TCP connections when the network is congested would reduce the effectiveness of the underlying congestion control mechanisms.
REQ 15：ソリューションは、基になるトランスポートプロトコルの輻輳制御メカニズムを妨害してはなりません。たとえば、ネットワークが輻輳しているときに追加のTCP接続を開くソリューションは、基盤となる輻輳制御メカニズムの有効性を低下させます。
REQ 16: The solution is likely to be deployed incrementally. The solution MUST support a mixed environment where some, but not all, nodes implement it.
REQ 16：ソリューションは段階的に展開される可能性があります。ソリューションは、すべてではなく一部のノードがそれを実装する混合環境をサポートする必要があります。
REQ 17: In a mixed environment with nodes that support the solution and nodes that do not, the solution MUST NOT result in materially less useful throughput during overload as would have resulted if the solution were not present. It SHOULD result in less severe overload in this environment.
REQ 17：ソリューションをサポートするノードとサポートしないノードが混在する環境では、ソリューションが存在しなかった場合のように、ソリューションが過負荷時に有用なスループットを大幅に低下させてはなりません。この環境では、過負荷が軽減されるはずです（SHOULD）。
REQ 18: In a mixed environment of nodes that support the solution and nodes that do not, the solution MUST NOT preclude elements that support overload control from treating elements that do not support overload control in an equitable fashion relative to those that do. Users and operators of nodes that do not support the solution MUST NOT unfairly benefit from the solution. The solution specification SHOULD provide guidance to implementors for dealing with elements not supporting overload control.
REQ 18：ソリューションをサポートするノードとサポートしないノードの混合環境では、ソリューションは、過負荷制御をサポートする要素を、過負荷制御をサポートしない要素と同等の方法で処理する要素から除外してはなりません。ソリューションをサポートしないノードのユーザーとオペレーターは、ソリューションから不当に利益を得てはなりません。ソリューション仕様は、過負荷制御をサポートしない要素を処理するためのガイダンスを実装者に提供する必要があります（SHOULD）。
REQ 19: It MUST be possible to use the solution between nodes in different realms and in different administrative domains.
REQ 19：異なるレルム内および異なる管理ドメイン内のノード間でソリューションを使用できる必要があります。
REQ 20: Any explicit overload indication MUST be clearly distinguishable from other errors reported via Diameter.
REQ 20：明示的な過負荷表示は、Diameterを介して報告される他のエラーと明確に区別できる必要があります。
REQ 21: In cases where a network node fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of overload. The solution MUST result in at least as much useful throughput as would have resulted if the solution were not in place.
REQ 21：ネットワークノードに障害が発生したり、負荷が高すぎてメッセージを処理できなかったり、ネットワーク障害が原因で通信できない場合、障害の性質や過負荷のレベルを明示的に示すことができない場合があります。ソリューションは、ソリューションが適切に配置されなかった場合に得られるであろうスループットと少なくとも同じくらいの有用なスループットをもたらす必要があります。
REQ 22: The solution MUST provide a way for a node to throttle the amount of traffic it receives from a peer node. This throttling SHOULD be graded so that it can be applied gradually as offered load increases. Overload is not a binary state; there may be degrees of overload.
REQ 22：ソリューションは、ノードがピアノードから受信するトラフィック量を抑制する方法をノードに提供する必要があります。このスロットリングは、提供される負荷が増加するにつれて徐々に適用できるように段階的に調整する必要があります（SHOULD）。オーバーロードはバイナリ状態ではありません。ある程度の過負荷が発生する可能性があります。
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：ソリューションは、過負荷状態でない場合でも、ノードが過負荷状態の発生を防ぐための決定を行うのを支援するために、負荷レベルを示すメカニズムを提供する必要があります。
REQ 25: The base specification for the solution SHOULD offer general guidance on which message types might be desirable to send or process over others during times of overload, based on application-specific considerations. For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. Some networks may have a requirement to give priority to requests associated with emergency sessions. Any normative or otherwise detailed definition of the relative priorities of message types during an overload condition will be the responsibility of the application specification.
REQ 25：ソリューションの基本仕様は、アプリケーション固有の考慮事項に基づいて、過負荷時に他のメッセージタイプに送信または処理することが望ましいメッセージタイプに関する一般的なガイダンスを提供する必要があります（SHOULD）。たとえば、新しいセッションの前に既存のセッションのメッセージを処理する方が有益な場合があります。一部のネットワークでは、緊急セッションに関連する要求を優先する必要がある場合があります。過負荷状態の間のメッセージタイプの相対的な優先順位の規範的またはその他の詳細な定義は、アプリケーション仕様の責任になります。
REQ 26: The solution MUST NOT prevent a node from prioritizing requests based on any local policy, so that certain requests are given preferential treatment, given additional retransmission, not throttled, or processed ahead of others.
REQ 26：ソリューションは、ノードがローカルポリシーに基づいてリクエストに優先順位を付けることを禁止してはなりません。これにより、特定のリクエストが優先的に処理され、追加の再送信が行われ、スロットルされないか、他のリクエストより先に処理されます。
REQ 27: The solution MUST NOT provide new vulnerabilities to malicious attack or increase the severity of any existing vulnerabilities. This includes vulnerabilities to DoS and DDoS attacks as well as replay and man-in-the-middle attacks. Note that the Diameter base specification [RFC6733] lacks end-to-end security, and this must be considered (see Security Considerations in this document (Section 8)). Note
REQ 27：ソリューションは、悪意のある攻撃に新しい脆弱性を提供したり、既存の脆弱性の重大度を上げたりしてはなりません。これには、DoS攻撃とDDoS攻撃の脆弱性、およびリプレイ攻撃と中間者攻撃が含まれます。 Diameter基本仕様[RFC6733]にはエンドツーエンドのセキュリティがないため、これを考慮する必要があります（このドキュメントのセキュリティに関する考慮事項（セクション8）を参照）。注意
that this requirement was expressed at a high level so as to not preclude any particular solution. Is is expected that the solution will address this in more detail.
この要件は、特定の解決策を妨げないように高レベルで表現されていること。ソリューションがこれにさらに詳しく対処することが期待されています。
REQ 28: The solution MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the solution to detect, or take countermeasures against, malicious nodes.
REQ 28：ソリューションは、すべてのDiameterノードが完全に信頼されている環境での展開に依存してはなりません。他のノードが悪意のある環境で可能な限り効果的に動作する必要があります。これには、悪意のあるノードがサービスの公平なシェア以上のものを取得するのを防ぐことが含まれます。これは、悪意のあるノードを検出または対策するソリューションに対する責任を意味するものではないことに注意してください。
REQ 29: It MUST be possible for a supporting node to make authorization decisions about what information will be sent to peer nodes based on the identity of those nodes. This allows a domain administrator who considers the load of their nodes to be sensitive information to restrict access to that information. Of course, in such cases, there is no expectation that the solution itself will help prevent overload from that peer node.
REQ 29：サポートしているノードが、それらのノードのIDに基づいてどの情報がピアノードに送信されるかについての承認決定を行うことが可能でなければなりません（MUST）。これにより、ノードの負荷を機密情報と見なすドメイン管理者は、その情報へのアクセスを制限できます。もちろん、そのような場合、ソリューション自体がそのピアノードからの過負荷を防ぐのに役立つとは期待されていません。
REQ 30: The solution MUST NOT interfere with any Diameter-compliant method that a node may use to protect itself from overload from non-supporting nodes or from denial-of-service attacks.
REQ 30：ソリューションは、ノードがサポートしていないノードからの過負荷またはサービス拒否攻撃から自身を保護するために使用するDiameter準拠のメソッドを妨害してはなりません（MUST NOT）。
REQ 31: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application" and MUST allow extensibility for others to be added in the future.
REQ 31：Diameterノードが特定の目的でオーバーロードされ、他の目的ではオーバーロードされない状況が複数あります。たとえば、これは、複数のアプリケーションをサポートするエージェントまたはサーバーで発生したり、サーバーが複数の外部リソースに依存している場合に発生します。ソリューションでは、Diameterノードが十分な粒度で過負荷を示して、利用可能な容量を不当に使用せずに過負荷のリソースに基づいてクライアントがアクションを実行できるようにする必要があります。ソリューションは、少なくとも「Diameterノード」、「レルム」、および「Diameterアプリケーション」の粒度でオーバーロード情報の仕様をサポートする必要があり、他の拡張性を将来追加できるようにする必要があります。
REQ 32: The solution MUST provide a method for extending the information communicated and the algorithms used for overload control.
REQ 32：ソリューションは、通信される情報を拡張する方法と、過負荷制御に使用されるアルゴリズムを提供する必要があります。
REQ 33: The solution MUST provide a default algorithm that is mandatory to implement.
REQ 33：ソリューションは、実装が必須のデフォルトアルゴリズムを提供する必要があります。
REQ 34: The solution SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the solution.
REQ 34：ソリューションは、ソリューションをサポートしない仲介者によって接続されている要素間で過負荷および負荷情報を交換する方法を提供する必要があります（SHOULD）。
A Diameter overload control mechanism is primarily concerned with the load-related and overload-related behavior of nodes in a Diameter network, and the information used to affect that behavior. Load and overload information is shared between nodes and directly affects the behavior, and thus the information is potentially vulnerable to a number of methods of attack.
Diameter過負荷制御メカニズムは、Diameterネットワーク内のノードの負荷関連および過負荷関連の動作と、その動作に影響を与えるために使用される情報に主に関係しています。負荷と過負荷の情報はノード間で共有され、動作に直接影響するため、情報は多くの攻撃方法に対して潜在的に脆弱です。
Load and overload information may also be sensitive from both business and network protection viewpoints. Operators of Diameter equipment want to control the visibility of load and overload information to keep it from being used for competitive intelligence or for targeting attacks. It is also important that the Diameter overload control mechanism not introduce any way in which any other information carried by Diameter is sent inappropriately.
負荷と過負荷の情報は、ビジネスとネットワークの両方の保護の観点からも重要な場合があります。 Diameter機器のオペレーターは、負荷および過負荷情報の可視性を制御して、競合情報や標的型攻撃に使用されないようにしたいと考えています。また、Diameterオーバーロード制御メカニズムが、Diameterによって伝送される他の情報が不適切に送信される方法を導入しないことも重要です。
Note that the Diameter base specification [RFC6733] lacks end-to-end security, making it difficult for non-adjacent nodes to verify the authenticity and ownership of load and overload information. Authentication of load and overload information helps to alleviate several of the security issues listed in this section.
Diameter基本仕様[RFC6733]にはエンドツーエンドのセキュリティが欠けているため、隣接していないノードがロードおよびオーバーロード情報の信頼性と所有権を検証することが困難になっていることに注意してください。ロードおよびオーバーロード情報の認証は、このセクションにリストされているいくつかのセキュリティ問題を軽減するのに役立ちます。
This document includes requirements intended to mitigate the effects of attacks and to protect the information used by the mechanism. This section discusses potential security considerations for overload control solutions. This discussion provides the motivation for several normative requirements described in Section 7. The discussion includes specific references to the normative requirements that apply for each issue.
このドキュメントには、攻撃の影響を軽減し、メカニズムによって使用される情報を保護することを目的とした要件が含まれています。このセクションでは、過負荷制御ソリューションの潜在的なセキュリティの考慮事項について説明します。このディスカッションは、セクション7で説明されているいくつかの規範的な要件の動機を提供します。ディスカッションには、各問題に適用される規範的な要件への特定の参照が含まれています。
To control the visibility of load and overload information, sending should be subject to some form of authentication and authorization of the receiver. It is also important to the receivers that they are confident the load and overload information they receive is from a legitimate source. REQ 28 requires that the solution work without assuming that all Diameter nodes in a network are trusted for the purposes of exchanging overload and load information. REQ 29 requires that the solution let nodes restrict unauthorized parties from seeing overload information. Note that this implies a certain amount of configurability on the nodes supporting the Diameter overload control mechanism.
負荷と過負荷情報の可視性を制御するには、送信は受信者の認証と承認の何らかの形に従う必要があります。また、受信者が受け取る負荷と過負荷の情報が正当なソースからのものであると確信していることも、受信者にとって重要です。 REQ 28は、ネットワーク内のすべてのDiameterノードが過負荷および負荷情報を交換する目的で信頼されていると想定せずにソリューションが機能することを要求します。 REQ 29は、ソリューションがノードに無許可のパーティが過負荷情報を見ることを制限することを許可することを要求します。これは、Diameter過負荷制御メカニズムをサポートするノードでのある程度の構成可能性を意味することに注意してください。
An overload control mechanism provides a very attractive target for denial-of-service attacks. A small number of messages may effect a large service disruption by falsely reporting overload conditions. Alternately, attacking servers nearing, or in, overload may also be facilitated by disrupting their overload indications, potentially preventing them from mitigating their overload condition.
過負荷制御メカニズムは、サービス拒否攻撃の非常に魅力的なターゲットを提供します。少数のメッセージは、過負荷状態を誤って報告することにより、大きなサービスの中断に影響を与える可能性があります。代わりに、過負荷に近づいた、または過負荷になっているサーバーへの攻撃は、過負荷の表示を乱すことによっても促進され、過負荷状態を緩和できない可能性があります。
A design goal for the Diameter overload control mechanism is to minimize or eliminate the possibility of using the mechanism for this type of attack. More strongly, REQ 27 forbids the solution from introducing new vulnerabilities to malicious attack. Additionally, REQ 30 stipulates that the solution not interfere with other mechanisms used for protection against denial-of-service attacks.
Diameter過負荷制御メカニズムの設計目標は、このタイプの攻撃にこのメカニズムを使用する可能性を最小化または排除することです。より強く、REQ 27は、ソリューションが悪意のある攻撃に新しい脆弱性を導入することを禁止します。さらに、REQ 30は、ソリューションがサービス拒否攻撃に対する保護に使用される他のメカニズムを妨害しないことを規定しています。
As the intent of some denial-of-service attacks is to induce overload conditions, an effective overload control mechanism should help to mitigate the effects of such an attack.
一部のサービス拒否攻撃の目的は過負荷状態を誘発することなので、効果的な過負荷制御メカニズムは、このような攻撃の影響を緩和するのに役立つはずです。
An attacker that has managed to obtain some messages from the overload control mechanism may attempt to affect the behavior of nodes supporting the mechanism by sending those messages at potentially inopportune times. In addition to time shifting, replay attacks may send messages to other nodes as well (target shifting).
過負荷制御メカニズムからいくつかのメッセージを取得した攻撃者は、これらのメッセージを不都合なときに送信することにより、メカニズムをサポートするノードの動作に影響を与える可能性があります。タイムシフトに加えて、リプレイアタックは他のノードにもメッセージを送信する可能性があります（ターゲットシフト）。
A design goal for the Diameter overload control solution is to minimize or eliminate the possibility of causing disruption by using a replay attack on the Diameter overload control mechanism. (Allowing a replay attack using the overload control solution would violate REQ 27.)
Diameter過負荷制御ソリューションの設計目標は、Diameter過負荷制御メカニズムに対するリプレイアタックを使用して、混乱を引き起こす可能性を最小化または排除することです。 （過負荷制御ソリューションを使用してリプレイ攻撃を許可すると、REQ 27に違反します。）
By inserting themselves between two nodes supporting the Diameter overload control mechanism, an attacker may potentially both access and alter the information sent between those nodes. This can be used for information gathering for business intelligence and attack targeting, as well as direct attacks.
Diameter過負荷制御メカニズムをサポートする2つのノードの間に自分自身を挿入することにより、攻撃者はこれらのノード間で送信された情報にアクセスして変更する可能性があります。これは、ビジネスインテリジェンスと攻撃の標的化のための情報収集、および直接攻撃に使用できます。
REQs 27, 28, and 29 imply a need to prevent man-in-the-middle attacks on the overload control solution. A transport using Transport Layer Security (TLS) and/or IPsec may be desirable for this purpose.
REQ 27、28、および29は、過負荷制御ソリューションに対する中間者攻撃を防ぐ必要があることを意味します。このためには、トランスポート層セキュリティ（TLS）やIPsecを使用したトランスポートが望ましい場合があります。
A compromised host that supports the Diameter overload control mechanism could be used for information gathering as well as for sending malicious information to any Diameter node that would normally accept information from it. While it is beyond the scope of the Diameter overload control mechanism to mitigate any operational interruption to the compromised host, REQs 28 and 29 imply a need to minimize the impact that a compromised host can have on other nodes through the use of the Diameter overload control mechanism. Of course, a compromised host could be used to cause damage in a number of other ways. This is out of scope for a Diameter overload control mechanism.
Diameter過負荷制御メカニズムをサポートする危険にさらされたホストは、情報収集や、通常はそこから情報を受け取るDiameterノードに悪意のある情報を送信するために使用できます。侵害されたホストへの操作上の中断を軽減することはDiameter過負荷制御メカニズムの範囲外ですが、REQ 28および29は、Diameter過負荷制御を使用して、侵害されたホストが他のノードに与える影響を最小限に抑える必要があることを意味します機構。もちろん、侵害されたホストは他の多くの方法で被害を与えるために使用される可能性があります。これは、Diameter過負荷制御メカニズムの範囲外です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733] Fajardo、V.、Arkko、J.、Loughney、J。、およびG. Zorn、「Diameter Base Protocol」、RFC 6733、2012年10月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3539] Aboba、B。およびJ. Wood、「Authentication、Authorization and Accounting（AAA）Transport Profile」、RFC 3539、2003年6月。
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008.
[RFC5390] Rosenberg、J。、「Session Initiation Protocolにおける過負荷の管理の要件」、RFC 5390、2008年12月。
[RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design Considerations for Session Initiation Protocol (SIP) Overload Control", RFC 6357, August 2011.
[RFC6357] Hilt、V.、Noel、E.、Shen、C。、およびA. Abdelal、「Session Initiation Protocol（SIP）Overload Controlに関する設計上の考慮事項」、RFC 6357、2011年8月。
[TR23.843] 3GPP, "Study on Core Network (CN) overload solutions", TR 23.843 1.2.0, Work in Progress, October 2013.
[TR23.843] 3GPP、「Study on Core Network（CN）overload solution」、TR 23.843 1.2.0、Work in Progress、2013年10月。
[IR.34] GSMA, "Inter-Service Provider IP Backbone Guidelines", IR 34 9.1, May 2013.
[IR.34] GSMA、「Inter-Service Provider IP Backbone Guidelines」、IR 34 9.1、2013年5月。
[IR.88] GSMA, "LTE Roaming Guidelines", IR 88 9.0, January 2013.
[IR.88] GSMA、LTEローミングガイドライン、IR 88 9.0、2013年1月。
[IR.92] GSMA, "IMS Profile for Voice and SMS", IR 92 7.0, March 2013.
[IR.92] GSMA、「音声とSMSのIMSプロファイル」、IR 92 7.0、2013年3月。
[TS23.002] 3GPP, "Network Architecture", TS 23.002 12.2.0, June 2013.
[TS23.002] 3GPP、「ネットワークアーキテクチャ」、TS 23.002 12.2.0、2013年6月。
[TS29.272] 3GPP, "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol", TS 29.272 12.2.0, September 2013.
[TS29.272] 3GPP、「Evolved Packet System（EPS）; Mobility Management Entity（MME）and Serving GPRS Support Node（SGSN）related interfaces based on Diameter protocol）」、TS 29.272 12.2.0、2013年9月。
[TS29.212] 3GPP, "Policy and Charging Control (PCC) over Gx/Sd reference point", TS 29.212 12.2.0, September 2013.
[TS29.212] 3GPP、「Policy and Charging Control（PCC）over Gx / Sd reference point」、TS 29.212 12.2.0、2013年9月。
[TS29.228] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", TS 29.228 12.0.0, September 2013.
[TS29.228] 3GPP、「IPマルチメディア（IM）サブシステムのCxおよびDxインターフェイス、シグナリングフローおよびメッセージコンテンツ」、TS 29.228 12.0.0、2013年9月。
[TS29.002] 3GPP, "Mobile Application Part (MAP) specification", TS 29.002 12.2.0, September 2013.
[TS29.002] 3GPP、「モバイルアプリケーションパーツ（MAP）仕様」、TS 29.002 12.2.0、2013年9月。
Significant contributions to this document were made by Adam Roach and Eric Noel.
このドキュメントへの重要な貢献は、Adam RoachとEric Noelによって行われました。
Review of, and contributions to, this specification by Martin Dolly, Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent Thiebaut, Andrew Booth, and Lionel Morand were most appreciated. We would like to thank them for their time and expertise.
Martin Dolly、Carolyn Johnson、Jianrong Wang、Imtiaz Shaikh、Jouni Korhonen、Robert Sparks、Dieter Jacobsohn、Janet Gunn、Jean-Jacques Trottin、Laurent Thiebaut、Andrew Booth、Lionel Morandによるこの仕様のレビューと貢献感謝。彼らの時間と専門知識に感謝します。
Authors' Addresses
著者のアドレス
Eric McMurry Oracle 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
エリックマクマリーオラクル17210キャンベルロードSuite 250ダラス、TX 75252 US
EMail: emcmurry@computer.org
Ben Campbell Oracle 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
ベンキャンベルオラクル17210キャンベルロードSuite 250ダラス、TX 75252 US
EMail: ben@nostrum.com