[要約] RFC 7944は、Diameterルーティングメッセージの優先度に関するガイドラインです。その目的は、Diameterネットワーク内でのメッセージの優先度設定と処理を改善することです。
Internet Engineering Task Force (IETF) S. Donovan
Request for Comments: 7944 Oracle
Category: Standards Track August 2016
ISSN: 2070-1721
Diameter Routing Message Priority
Diameterルーティングメッセージの優先度
Abstract
概要
When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information, Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions.
ルーティングとリソース割り当ての決定を行うとき、Diameterノードには現在、Diameterメッセージの相対的な優先度を決定する一般的なメカニズムがありません。このドキュメントでは、DiameterエンドポイントがDiameterトランザクションの相対的な優先度を示すことができるようにするメカニズムを定義することで、この問題に対処します。この情報により、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 http://www.rfc-editor.org/info/rfc7944.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7944で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. First-Responder-Related Signaling . . . . . . . . . . . . 6
5.2. Emergency-Call-Related Signaling . . . . . . . . . . . . 6
5.3. Differentiated Services . . . . . . . . . . . . . . . . . 7
5.4. Application-Specific Priorities . . . . . . . . . . . . . 7
6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 10
9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 12
9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 13
10. Considerations When Defining Application Priorities . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 15
12.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . 16
12.3. End-to-End Security Issues . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
The Diameter Overload Indication Conveyance (DOIC) solution [RFC7683] for Diameter overload control introduces scenarios where Diameter routing decisions made by Diameter nodes can be influenced by the overload state of other Diameter nodes. This includes the scenarios where Diameter endpoints and Diameter Agents can throttle requests as a result of the target for the request being overloaded.
Diameter過負荷制御用のDiameter過負荷表示伝達（DOIC）ソリューション[RFC7683]は、Diameterノードによって行われるDiameterルーティングの決定が他のDiameterノードの過負荷状態の影響を受けるシナリオを導入します。これには、リクエストのターゲットが過負荷になった結果として、DiameterエンドポイントとDiameterエージェントがリクエストを抑制できるシナリオが含まれます。
With currently available mechanisms, these Diameter nodes do not have a mechanism to differentiate request message priorities when making these throttling decisions. As such, all requests are treated the same, meaning that all requests have the same probability of being throttled.
現在利用可能なメカニズムでは、これらのDiameterノードには、これらのスロットル決定を行うときに要求メッセージの優先順位を区別するメカニズムがありません。そのため、すべてのリクエストは同じように処理されます。つまり、すべてのリクエストが抑制される確率は同じです。
There are scenarios where treating all requests the same can cause issues. For instance, it might be considered important to reduce the probability of transactions involving first responders being throttled during overload scenarios caused, for example, by a period of heavy signaling resulting from a natural disaster.
すべてのリクエストを同じように処理すると問題が発生する可能性があるシナリオがあります。たとえば、自然災害に起因する激しい信号の期間などが原因で発生する過負荷シナリオ中に、最初の応答者が関与するトランザクションが抑制される可能性を減らすことが重要と考えられます。
This document defines a mechanism that allows Diameter nodes to indicate the relative priority of Diameter transactions. With this information, other Diameter nodes can factor the relative priority of requests into routing and throttling decisions.
このドキュメントでは、DiameterノードがDiameterトランザクションの相対的な優先度を示すことができるメカニズムを定義します。この情報を使用して、他のDiameterノードは、リクエストの相対的な優先度をルーティングとスロットルの決定に含めることができます。
There are two primary considerations that must be addressed for the mechanism described in this document to work effectively. The first takes into consideration the fact that the Diameter base protocol defined in [RFC6733] is designed to transport multiple Diameter applications and that Diameter nodes can be implemented that support multiple applications. In order for the Diameter Routing Message Priority (DRMP) mechanism to work, the priorities defined for all messages across all applications used in a Diameter administrative domain must be defined in a consistent and coordinated fashion, taking the default priority into account. See Section 10 for a discussion of some of the considerations that need to be factored into the setting of DRMPs used by Diameter applications.
このドキュメントで説明されているメカニズムが効果的に機能するには、2つの主要な考慮事項に対処する必要があります。 1つ目は、[RFC6733]で定義されているDiameter基本プロトコルが複数のDiameterアプリケーションを転送するように設計されており、複数のアプリケーションをサポートするDiameterノードを実装できることを考慮しています。 Diameterルーティングメッセージプライオリティ（DRMP）メカニズムが機能するためには、Diameter管理ドメインで使用されるすべてのアプリケーションにわたってすべてのメッセージに対して定義されたプライオリティを、デフォルトのプライオリティを考慮して、一貫して調整して定義する必要があります。 Diameterアプリケーションで使用されるDRMPの設定に織り込む必要があるいくつかの考慮事項については、セクション10を参照してください。
Note that this consideration does not apply to Diameter networks where all Diameter nodes only support a single application.
この考慮事項は、すべてのDiameterノードが単一のアプリケーションのみをサポートするDiameterネットワークには適用されないことに注意してください。
Without this cross application priority design taken into consideration, it is possible for messages for one application to gain unwarranted preferential treatment over messages for other applications.
このアプリケーション間の優先度の設計を考慮しないと、あるアプリケーションのメッセージが他のアプリケーションのメッセージよりも不当に優先的に処理される可能性があります。
This mechanism also depends on all of the messages that carry the DRMP Attribute Value Pair (AVP) that are inserted into Diameter messages by trusted nodes within the Diameter administrative domain. As discussed in Section 12, misbehaving nodes have the ability to use the DRMP mechanism to gain unwarranted preferential treatment.
このメカニズムは、Diameter管理ドメイン内の信頼されたノードによってDiameterメッセージに挿入されるDRMP属性値ペア（AVP）を運ぶすべてのメッセージにも依存します。セクション12で説明したように、不正な動作をするノードには、DRMPメカニズムを使用して、不当な優先処理を行う機能があります。
When messages cross Diameter administrative boundaries, care should be taken to either strip or modify the DRMP values in these messages. If the priority definitions vary between the two Diameter administrative domains, then it is possible for messages from a foreign domain to gain unwarranted preferential treatment.
メッセージがDiameter管理境界を越える場合、これらのメッセージのDRMP値を削除または変更するように注意する必要があります。優先順位の定義が2つのDiameter管理ドメイン間で異なる場合、外部ドメインからのメッセージが不当な優先扱いを受ける可能性があります。
Diversion
転用
As defined in [RFC7683]. An overload abatement treatment where the reacting node selects alternate destinations or paths for requests.
[RFC7683]で定義されています。対応するノードが要求の代替宛先またはパスを選択する過負荷軽減処理。
DOIC
DOIC
Diameter Overload Indication Conveyance.
直径過負荷表示伝達。
DRMP
DRMP
Diameter Routing Message Priority.
Diameterルーティングメッセージの優先度。
Overload Abatement
過負荷軽減
As defined in [RFC7683]. Reaction to receipt of an overload report resulting in a reduction in traffic sent to the reporting node. Abatement actions include diversion and throttling.
[RFC7683]で定義されています。レポートノードに送信されるトラフィックの削減につながる過負荷レポートの受信に対する反応。削減アクションには、宛先変更とスロットリングが含まれます。
Priority
優先
The relative importance of a Diameter message. A lower-priority value implies a higher relative importance of the message.
Diameterメッセージの相対的な重要度。優先度の値が低いほど、メッセージの相対的な重要度が高くなります。
Throttling
スロットル
As defined in [RFC7683]. An abatement treatment that limits the number of requests sent by the DOIC reacting node. Throttling can include a Diameter Client choosing to not send requests or a Diameter Agent or Server rejecting requests with appropriate error responses. In both cases, the result of the throttling is a permanent rejection of the transaction.
[RFC7683]で定義されています。 DOIC反応ノードによって送信されるリクエストの数を制限する削減処理。スロットルには、要求を送信しないことを選択するDiameterクライアント、または適切なエラー応答を伴う要求を拒否するDiameterエージェントまたはサーバーを含めることができます。どちらの場合も、スロットリングの結果、トランザクションは永久に拒否されます。
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 described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The interpretation from RFC 2119 does not apply for the above listed words when they are not used in all caps.
RFC 2119の解釈は、上記の単語がすべて大文字で使用されていない場合には適用されません。
With the introduction of overload control mechanisms, Diameter nodes will be required to make decisions regarding which Diameter request messages should be throttled as a result of overloaded Diameter nodes.
過負荷制御メカニズムの導入により、Diameterノードは、過負荷のDiameterノードの結果としてどのDiameterリクエストメッセージを抑制すべきかを決定する必要があります。
There is currently no generic mechanism to indicate which request messages should be given preferential treatment when these throttling decisions are made.
現在、これらのスロットリングの決定が行われたときに、どの要求メッセージを優先的に処理する必要があるかを示す一般的なメカニズムはありません。
As a result, all messages are treated equally and, as such, have an equal probability of being throttled.
その結果、すべてのメッセージが平等に扱われ、スロットルされる確率が等しくなります。
There are a number of scenarios where it is appropriate for an application to mark a request as being of a higher priority than other application requests. These are discussed in the next section.
アプリケーションが要求を他のアプリケーション要求よりも高い優先度のものとしてマークすることが適切であるシナリオは多数あります。これらについては、次のセクションで説明します。
This document defines a mechanism for applications to indicate priority for individual transactions, reducing the probability of those transactions being throttled if there are other lower-priority transactions that are eligible for throttling treatment.
このドキュメントは、アプリケーションが個々のトランザクションの優先度を示すメカニズムを定義し、他の優先度の低いトランザクションがスロットル処理に適格である場合、それらのトランザクションがスロットルされる確率を減らします。
While the primary usage of DRMP-defined priorities is for input to throttling decisions related to Diameter overload control, it is also expected that the priority information could also be used for other routing-related functionality. This might include giving higher-priority transactions preferential treatment when selecting routes.
DRMPで定義された優先度の主な用途は、Diameter過負荷制御に関連するスロットル決定への入力ですが、優先度情報は他のルーティング関連機能にも使用できると予想されます。これには、ルートを選択するときに優先度の高いトランザクションを優先的に処理することが含まれる場合があります。
It is also envisioned that DRMP information could be used by Diameter endpoints to make resource allocation decisions. For instance, a Diameter Server might choose to use the priority information to treat higher-priority requests ahead of lower-priority requests. It might also use the priority information as a reason to fail a request as a result of insufficient resources.
また、DiameterエンドポイントがDRMP情報を使用して、リソース割り当てを決定できることも想定されています。たとえば、Diameterサーバーは優先度情報を使用して、優先度の低いリクエストよりも優先度の高いリクエストを処理する場合があります。また、リソースが不十分なために要求が失敗する理由として、優先順位情報を使用する場合もあります。
Note: There are a number of application-specific definitions indicating various views of application-level priority for different requests. Using these application-specific priority AVPs as input to throttling and other Diameter routing decisions would require Diameter Agents to understand all applications and do application-specific parsing of all messages in order to determine the priority of individual messages. This is considered an unacceptable level of complexity to put on elements whose primary responsibility is to route Diameter messages.
注：さまざまな要求に対するアプリケーションレベルの優先度のさまざまなビューを示す、アプリケーション固有の定義がいくつかあります。これらのアプリケーション固有の優先度AVPをスロットルや他のDiameterルーティング決定への入力として使用するには、Diameterエージェントがすべてのアプリケーションを理解し、すべてのメッセージのアプリケーション固有の解析を行って、個々のメッセージの優先度を決定する必要があります。これは、Diameterメッセージのルーティングを主な役割とする要素を配置することは、容認できないレベルの複雑さと見なされます。
This section discusses various scenarios where Diameter transactions can benefit from the use of priority information.
このセクションでは、Diameterトランザクションが優先度情報の使用からメリットを得られるさまざまなシナリオについて説明します。
It is important to note that for priority information to be reliably usable, the Diameter nodes sending and consuming DRMP AVPs must have pre-established trust relationships of the sort described in Section 12.
優先度情報を確実に使用できるようにするには、DRMP AVPを送信および消費するDiameterノードが、セクション12で説明する種類の事前に確立された信頼関係を持っている必要があることに注意することが重要です。
Natural disasters can result in a considerable increase in usage of network resources. This can be made worse if the disaster results in a loss of network capacity.
自然災害により、ネットワークリソースの使用量が大幅に増加する可能性があります。災害によりネットワークキャパシティが失われた場合、これはさらに悪化する可能性があります。
The combination of added load and reduced capacity can lead to Diameter nodes becoming overloaded and, as a result, the use of DOIC mechanisms to request a reduction in traffic. In turn, this results in requests being throttled in an attempt to control the overload scenario and prevent the overloaded node from failing.
追加の負荷と減少した容量の組み合わせにより、Diameterノードが過負荷になり、その結果、DOICメカニズムを使用してトラフィックの削減を要求できます。これにより、過負荷シナリオを制御し、過負荷ノードの失敗を防ぐために、リクエストが抑制されます。
There is the need for first responders and other individuals responsible for handling the after effects of the disaster to be assured that they can gain access to the network resources in order to communicate both between themselves and with other network resources.
ファーストレスポンダーと、災害後の影響を処理する責任を負う他の個人が、ネットワークリソースにアクセスして、他のネットワークリソースと通信できるようにする必要があります。
Signaling associated with first responders needs to be given a higher priority to help ensure they can most effectively do their jobs.
ファーストレスポンダーに関連付けられたシグナリングには、最も効果的に仕事を行えるように、より高い優先度を与える必要があります。
The United States Wireless Priority Services (WPS) and Government Emergency Telecommunications Service (GETS) are examples of systems designed to address the command and control aspects of these first responder needs.
米国の無線優先サービス（WPS）と政府の緊急通信サービス（GETS）は、これらのファーストレスポンダーのニーズのコマンドとコントロールの側面に対処するように設計されたシステムの例です。
Similar to the first responder scenario, there is also signaling associated with emergency calls. Given the critical nature of these emergency calls, this signaling should also be given preferential treatment when possible.
ファーストレスポンダーシナリオと同様に、緊急コールに関連付けられたシグナリングもあります。これらの緊急コールの重要な性質を考えると、このシグナリングは、可能な場合は優先的に処理する必要もあります。
Operators may desire to differentiate network-based services by providing a service level agreement (SLA) that includes preferential Diameter routing behavior. This might, for example, be modeled as Platinum, Gold, and Silver levels of service.
オペレーターは、優先的なDiameterルーティング動作を含むサービスレベルアグリーメント（SLA）を提供することにより、ネットワークベースのサービスを差別化したいと考える場合があります。これは、たとえば、プラチナ、ゴールド、シルバーのサービスレベルとしてモデル化できます。
In this scenario, an operator might offer a Platinum SLA that includes ensuring that all signaling for a customer who purchases the Platinum service is being marked as having a higher priority than signaling associated with Gold and Silver customers.
このシナリオでは、オペレーターはプラチナSLAを提供する場合があります。これには、プラチナサービスを購入する顧客のすべてのシグナリングが、ゴールドおよびシルバーの顧客に関連付けられたシグナリングよりも高い優先度としてマークされていることの確認が含まれます。
There are scenarios within Diameter applications where it might be appropriate to give a subset of the transactions for the application a higher priority than other transactions for that application.
Diameterアプリケーションには、アプリケーションのトランザクションのサブセットに、そのアプリケーションの他のトランザクションよりも高い優先度を与えることが適切なシナリオがあります。
For instance, when there is a series of transactions required for a user to gain access to network services, it might be appropriate to mark transactions that occur later in the series at a higher priority than those that occur early in the series. This would recognize that there was potentially significant work done by the network already that would be lost if those later transactions were throttled.
たとえば、ユーザーがネットワークサービスにアクセスするために必要な一連のトランザクションがある場合、シリーズの最初に発生するトランザクションよりも、シリーズの後半に発生するトランザクションを高い優先度でマークすることが適切な場合があります。これは、ネットワークによって実行された可能性のある重要な作業がすでに存在しており、その後のトランザクションが抑制された場合に失われることを認識します。
There are also scenarios where an agent cannot easily differentiate a request that starts a session from requests that update or end sessions. In these scenarios, it might be appropriate to mark the requests that establish new sessions with a lower priority than updates and session ending requests. This also recognizes that more work has already taken place for established sessions, and as a result, it might be more harmful from a signaling point of view if the session update and session ending requests were to be throttled.
また、エージェントが、セッションを開始する要求と、セッションを更新または終了する要求を簡単に区別できないシナリオもあります。これらのシナリオでは、新しいセッションを確立する要求を、更新およびセッション終了要求よりも低い優先度でマークすることが適切な場合があります。これはまた、確立されたセッションに対してより多くの作業がすでに行われていることを認識しており、その結果、セッションの更新とセッションの終了要求が抑制された場合、シグナリングの観点からはより有害になる可能性があります。
There are also scenarios where the priority of requests for individual command codes within an application depends on the context that exists when the request is sent. There isn't always information in the message from which this context can be determined by Diameter nodes other than the node that originates the request.
また、アプリケーション内の個々のコマンドコードに対する要求の優先順位が、要求の送信時に存在するコンテキストに依存するシナリオもあります。メッセージには、要求を発信したノード以外のDiameterノードがこのコンテキストを決定できる情報が常にあるとは限りません。
This is similar to the scenario where a series of requests are needed to access a network service. It is different in that the series of requests involves different application command codes. In this scenario, requests with the same command code have different implied priorities.
これは、ネットワークサービスにアクセスするために一連のリクエストが必要になるシナリオに似ています。一連の要求に異なるアプリケーションコマンドコードが含まれるという点で異なります。このシナリオでは、同じコマンドコードを使用したリクエストには、暗黙の優先順位が異なります。
One example of this is in the 3GPP application [S6a] where an Update Location Request (ULR) resulting from a Mobility Management Entity (MME) restoration procedure might be given a higher priority than a ULR resulting from an initial attach.
この1つの例は、3GPPアプリケーション[S6a]であり、モビリティ管理エンティティ（MME）の復元手順による更新ロケーション要求（ULR）には、最初の接続によるULRよりも高い優先順位が与えられます。
This section outlines the envisioned usage of DRMP.
このセクションでは、DRMPの想定される使用法について概説します。
The expected behavior depends on the role (request sender, agent, or request handler) of the Diameter node handling the request.
予想される動作は、要求を処理するDiameterノードの役割（要求の送信者、エージェント、または要求ハンドラ）によって異なります。
The following behavior is expected during the flow of a Diameter transaction.
Diameterトランザクションのフロー中に、次の動作が予想されます。
1. Request sender -- The sender of a request, be it a Diameter Client or a Diameter Server, determines the relative priority of the request and includes that priority information in the request. The method for determining the relative priority is application specific and is outside the scope of this specification. The request sender also saves the priority information with the transaction state. This will be used when handling the answer messages.
1. 要求の送信者-DiameterクライアントまたはDiameterサーバーなどの要求の送信者は、要求の相対的な優先度を決定し、その優先度情報を要求に含めます。相対的な優先順位を決定する方法はアプリケーション固有であり、この仕様の範囲外です。リクエストの送信者は、トランザクションの状態とともに優先度情報も保存します。これは、応答メッセージを処理するときに使用されます。
2. Agents handling the request -- Agents use the priority information when making routing decisions. This can include determining which requests to route first, which requests to throttle, and where the request is routed. For instance, requests with higher priority might have a lower probability of being throttled. The mechanism for how the agent determines which requests are candidates to be throttled is implementation dependent and is outside the scope of this document. Before forwarding request messages, agents generally do not modify the priority information present in the received request message nor include the priority information when absent in the received request message. However, in some scenarios, agents can modify the priority information, for example, edge agents modifying the priority values set by an adjacent operator. There might be other scenarios where a Diameter endpoint does not support the DRMP mechanism, and agents insert the priority information in the request messages for that non-supporting endpoint. When forwarding the request messages, the agent also saves the transaction priority in the transaction state either as locally managed state or using the Proxy-Info mechanism defined in [RFC6733]. This will be used when handling the associated answer message for the transaction.
2. リクエストを処理するエージェント-エージェントは、ルーティングを決定するときに優先度情報を使用します。これには、最初にルーティングする要求、スロットルする要求、および要求のルーティング先を決定することが含まれます。たとえば、優先度の高いリクエストほど、スロットルされる可能性が低くなります。どの要求が抑制される候補であるかをエージェントが判断する方法のメカニズムは実装に依存し、このドキュメントの範囲外です。要求メッセージを転送する前に、エージェントは通常、受信した要求メッセージに存在する優先順位情報を変更せず、受信した要求メッセージに存在しない場合は優先順位情報を含めません。ただし、一部のシナリオでは、エージェントは優先度情報を変更できます。たとえば、エッジエージェントは、隣接するオペレーターによって設定された優先度の値を変更します。 DiameterエンドポイントがDRMPメカニズムをサポートせず、エージェントがその非サポートエンドポイントの要求メッセージに優先度情報を挿入する他のシナリオが存在する場合があります。要求メッセージを転送するとき、エージェントはトランザクションの優先度をローカル管理状態として、または[RFC6733]で定義されているProxy-Infoメカニズムを使用してトランザクション状態に保存します。これは、トランザクションの関連する応答メッセージを処理するときに使用されます。
3. Request handler -- The handler of the request, be it a Diameter Server or a Diameter Client, can use the priority information to determine how to handle the request. This could include determining the order in which requests are handled and resources that are applied to the handling of the request.
3. リクエストハンドラ-DiameterサーバーまたはDiameterクライアントなどのリクエストのハンドラは、優先度情報を使用してリクエストの処理方法を決定できます。これには、要求が処理される順序と、要求の処理に適用されるリソースを決定することが含まれます。
4. Answer sender -- The handler of the request is also the sender of the answer. The answer sender uses the priority information received in the request message when sending the answer. This implies that answers for higher-priority transactions are given preferential treatment over lower-priority transactions. The answer sender also has the option of including priority information in the answer message. This is done when the answer message needs to have a different priority than the priority carried in the request message. The priority included by the answer sender is application specific.
4. 回答の送信者-リクエストのハンドラーは回答の送信者でもあります。回答の送信者は、回答を送信するときに、要求メッセージで受信した優先度情報を使用します。これは、優先度の高いトランザクションに対する回答が、優先度の低いトランザクションよりも優先的に処理されることを意味します。回答の送信者は、回答メッセージに優先度情報を含めるオプションもあります。これは、応答メッセージが要求メッセージで運ばれる優先度とは異なる優先度を持つ必要がある場合に行われます。回答の送信者によって含まれる優先度はアプリケーション固有です。
5. Agent handling the answer -- By default, agents handling answer messages use the priority information stored with the transaction state to determine the priority of relaying the answer message. However, priority information included in the answer message, when present, is used in place of the stored priority information. The use of priority information implies that answers for higher-priority transactions are given preferential treatment over lower-priority transactions. When forwarding the answer messages, agents generally do not modify the priority information present in the received answer messages nor include the priority information when absent in the received answer messages. However, in some scenarios, agents can modify the priority information, for example, edge agents modifying the priority values set by an adjacent operator. There might be other scenarios where a Diameter endpoint does not support the DRMP mechanism, and agents insert the priority information for that non-supporting endpoint.
5. 応答を処理するエージェント-デフォルトでは、応答メッセージを処理するエージェントは、トランザクション状態とともに保存された優先度情報を使用して、応答メッセージを中継する優先度を決定します。ただし、応答メッセージに含まれている優先度情報が存在する場合は、格納されている優先度情報の代わりに使用されます。優先度情報の使用は、優先度の高いトランザクションの回答が、優先度の低いトランザクションよりも優先的に処理されることを意味します。応答メッセージを転送するとき、エージェントは通常、受信した応答メッセージに存在する優先順位情報を変更せず、受信した応答メッセージに存在しない場合の優先順位情報を含めません。ただし、一部のシナリオでは、エージェントは優先度情報を変更できます。たとえば、エッジエージェントは、隣接するオペレーターによって設定された優先度の値を変更します。 DiameterエンドポイントがDRMPメカニズムをサポートせず、エージェントがその非サポートエンドポイントの優先度情報を挿入する他のシナリオが存在する可能性があります。
6. Answer handler -- The answer handler uses the same method as the agent to determine the priority of the answer message. By default, the handler of the answer message uses the priority saved in the transaction's state. Priority information in the answer message is used when present. The priority is used when allocating resources for processing that occurs after the receipt of the answer message.
6. 応答ハンドラ-応答ハンドラは、エージェントと同じメソッドを使用して、応答メッセージの優先度を決定します。デフォルトでは、応答メッセージのハンドラーは、トランザクションの状態に保存されている優先度を使用します。応答メッセージの優先順位情報が存在する場合はそれが使用されます。優先度は、応答メッセージの受信後に発生する処理にリソースを割り当てるときに使用されます。
This document does not define extensibility mechanisms that are specific to the DRMP mechanism. As a result, any extension that requires new AVPs will be required to use existing Diameter extensibility mechanisms defined in [RFC6733].
このドキュメントでは、DRMPメカニズムに固有の拡張メカニズムは定義していません。その結果、新しいAVPを必要とする拡張は、[RFC6733]で定義されている既存のDiameter拡張メカニズムを使用する必要があります。
This section contains the normative behavior associated with DRMP.
このセクションには、DRMPに関連する規範的な動作が含まれています。
When routing priority information is available, Diameter nodes SHOULD include Diameter routing message priority in the DRMP AVP in all Diameter request messages.
ルーティング優先度情報が利用可能な場合、Diameterノードは、すべてのDiameterリクエストメッセージのDRMP AVPにDiameterルーティングメッセージ優先度を含める必要があります（SHOULD）。
Note: The method of determining the priority value included in the request is application specific and is not in the scope of this specification.
注：リクエストに含まれる優先度の値を決定する方法はアプリケーション固有であり、この仕様の範囲外です。
The priority marking scheme does not require the Diameter Agents to understand application-specific AVPs.
プライオリティマーキングスキームでは、Diameterエージェントがアプリケーション固有のAVPを理解する必要はありません。
When available, Diameter nodes SHOULD use routing priority information included in the DRMP AVP when making Diameter overload throttling decisions.
使用可能な場合、Diameterノードは、Diameter過負荷スロットル決定を行うときに、DRMP AVPに含まれるルーティング優先度情報を使用する必要があります（SHOULD）。
Diameter Agents MAY use routing priority information included in the DRMP AVP when relaying request and answer messages. This includes the selection of routes and the ordering of messages relayed.
Diameterエージェントは、要求メッセージと応答メッセージをリレーするときに、DRMP AVPに含まれているルーティング優先度情報を使用できます（MAY）。これには、ルートの選択とリレーされるメッセージの順序が含まれます。
Note: The priority information included in the DRMP AVP in request messages applies to both the request message and, by default, the answer message associated with the transaction.
注：要求メッセージのDRMP AVPに含まれる優先度情報は、要求メッセージと、デフォルトではトランザクションに関連付けられた応答メッセージの両方に適用されます。
While done only in exceptional circumstances, Diameter Agents MAY modify priority information when relaying request and answer messages.
Diameter Agentは、例外的な状況でのみ実行されますが、要求および応答メッセージをリレーするときに優先度情報を変更する場合があります。
Note: There might be scenarios where a Diameter Agent does modify priority information. For instance, an edge agent might need to modify the priority values set by an adjacent operator.
注：Diameterエージェントが優先度情報を変更するシナリオがある場合があります。たとえば、エッジエージェントは、隣接するオペレーターによって設定された優先度の値を変更する必要がある場合があります。
While done only in exceptional circumstances, Diameter Agents MAY add priority information when relaying request and answer messages.
Diameter Agentは例外的な状況でのみ実行されますが、要求メッセージと応答メッセージを中継するときに優先情報を追加する場合があります。
Note: There might be scenarios where a Diameter endpoint does not support the DRMP mechanism, and agents insert priority information for that non-supporting endpoint.
注：DiameterエンドポイントがDRMPメカニズムをサポートせず、エージェントがその非サポートエンドポイントの優先度情報を挿入するシナリオがある場合があります。
Diameter endpoints MAY use routing priority information included in the DRMP AVP when making resource allocation decisions for the transaction associated with the request message that contains the DRMP information.
Diameterエンドポイントは、DRMP情報を含む要求メッセージに関連付けられたトランザクションのリソース割り当てを決定するときに、DRMP AVPに含まれるルーティング優先度情報を使用する場合があります。
Diameter endpoints MAY use routing priority information included in the DRMP AVP when making resource allocation decisions for the transaction associated with the answer messages using the DRMP information associated with the transaction.
Diameterエンドポイントは、トランザクションに関連付けられたDRMP情報を使用して、応答メッセージに関連付けられたトランザクションのリソース割り当てを決定するときに、DRMP AVPに含まれるルーティング優先度情報を使用する場合があります。
Diameter endpoints MAY include the DRMP AVP in answer messages. This is done when the priority for the answer message needs to have a different priority than the priority carried in the request message.
Diameterエンドポイントは、応答メッセージにDRMP AVPを含めることができます（MAY）。これは、応答メッセージの優先順位が、要求メッセージで伝達される優先順位とは異なる優先順位を持つ必要がある場合に行われます。
When determining the priority to apply to answer messages, Diameter nodes SHOULD use the priority indicated in the DRMP AVP carried in the answer message, if it exists. If there is not DRMP AVP in the answer message, then the Diameter node SHOULD use the priority indicated in the DRMP AVP of the associated request message.
応答メッセージに適用する優先度を決定するとき、Diameterノードは、応答メッセージに含まれるDRMP AVPに示されている優先度が存在する場合、それを使用する必要があります（SHOULD）。応答メッセージにDRMP AVPがない場合、Diameterノードは、関連する要求メッセージのDRMP AVPに示されている優先度を使用する必要があります（SHOULD）。
Note: One method to determine what priority to apply to an answer when there is no DRMP AVP in the answer message is to save the priority included in the request message in the state associated with the Diameter transaction. Another is to use the Proxy-Info mechanism defined in [RFC6733].
注：応答メッセージにDRMP AVPがない場合に回答に適用する優先順位を決定する1つの方法は、Diameterトランザクションに関連付けられた状態で要求メッセージに含まれる優先順位を保存することです。別の方法は、[RFC6733]で定義されているProxy-Infoメカニズムを使用することです。
Diameter nodes MUST have a default priority to apply to transactions that do not have an explicit priority set in the DRMP AVP.
Diameterノードは、DRMP AVPで明示的な優先順位が設定されていないトランザクションに適用するために、デフォルトの優先順位を持つ必要があります。
In order to guarantee consistent handling of messages from non-upgraded Diameter Clients, Diameter nodes SHOULD use the PRIORITY_10 priority as this default priority value.
アップグレードされていないDiameterクライアントからのメッセージの一貫した処理を保証するために、Diameterノードはこのデフォルトの優先度値としてPRIORITY_10優先度を使用する必要があります。
PRIORITY_10 is a midrange priority that corresponds to "normal" traffic and thus would be a suitable default for most deployments, while still allowing different Diameter applications to designate other priorities for lower- and higher-priority traffic.
PRIORITY_10は、「通常の」トラフィックに対応する中程度の優先度であるため、ほとんどの導入に適したデフォルトであり、優先度の低いトラフィックと優先度の高いトラフィックに対して別のDiameterアプリケーションで他の優先度を指定できます。
Note: This does not imply that a DRMP AVP is added to the message. Rather, the message is treated the same as a message that has a DRMP AVP with a priority value of PRIORITY_10.
注：これは、DRMP AVPがメッセージに追加されることを意味するものではありません。むしろ、メッセージは、PRIORITY_10の優先度値を持つDRMP AVPを持つメッセージと同じように扱われます。
Diameter nodes MUST support the ability for the default priority to be modified through local configuration interfaces.
Diameterノードは、ローカル設定インターフェースを介して変更されるデフォルトの優先度の機能をサポートする必要があります。
Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator-defined local policy would override the use of PRIORITY_10 as the default priority.
注：オペレーターが、明示的な優先順位を持たないトランザクションに対して異なるデフォルト値を指定したい場合があります。この場合、オペレーター定義のローカルポリシーは、デフォルトの優先度としてのPRIORITY_10の使用を上書きします。
When using DRMP information, Diameter nodes MUST use the default priority for transactions that do not have priority specified in a DRMP AVP.
DRMP情報を使用する場合、Diameterノードは、DRMP AVPで優先度が指定されていないトランザクションにはデフォルトの優先度を使用する必要があります。
Note: This guidance on the handling of messages without a priority does not result in a Diameter Agent inserting a DRMP AVP into the message. Rather, it gives guidance on how that specific transaction should be treated when its priority is compared with other requests. When a Diameter Agent relays the request, it will not insert a DRMP AVP with a priority value of 10.
注：優先度のないメッセージの処理に関するこのガイダンスでは、DiameterエージェントがDRMP AVPをメッセージに挿入することはありません。むしろ、その特定のトランザクションの優先順位が他の要求と比較されるときに、その特定のトランザクションがどのように扱われるべきかについてのガイダンスを提供します。 Diameterエージェントがリクエストをリレーするとき、優先度の値が10のDRMP AVPは挿入されません。
When setting and using priorities, for all integers x,y in [0,15], treat PRIORITY_<x> as lower priority than PRIORITY_<y> when y<x.
優先度を設定して使用する場合、[0,15]のすべての整数x、yについて、PRIORITY_ <x>をy <xの場合のPRIORITY_ <y>よりも低い優先度として扱います。
Note: As a result, PRIORITY_0 is the highest priority.
注：結果として、PRIORITY_0が最も優先されます。
This section describes the encoding and semantics of the Diameter Routing Message Priority AVP defined in this document.
このセクションでは、このドキュメントで定義されているDiameter Routing Message Priority AVPのエンコーディングとセマンティクスについて説明します。
The DRMP (AVP code 301) is of type Enumerated. The value of the AVP indicates the routing message priority for the transaction. The following values are defined:
DRMP（AVPコード301）は列挙型です。 AVPの値は、トランザクションのルーティングメッセージの優先度を示します。以下の値が定義されています。
PRIORITY_15 15 PRIORITY_15 is the lowest priority.
PRIORITY_15 15 PRIORITY_15は最も低い優先度です。
PRIORITY_14 14 PRIORITY_14 is a higher priority than PRIORITY_15 and a lower priority than PRIORITY_13.
PRIORITY_14 14 PRIORITY_14は、PRIORITY_15よりも優先度が高く、PRIORITY_13よりも優先度が低くなっています。
PRIORITY_13 13 PRIORITY_13 is a higher priority than PRIORITY_14 and a lower priority than PRIORITY_12.
PRIORITY_13 13 PRIORITY_13は、PRIORITY_14よりも優先度が高く、PRIORITY_12よりも優先度が低くなっています。
PRIORITY_12 12 PRIORITY_12 is a higher priority than PRIORITY_13 and a lower priority than PRIORITY_11.
PRIORITY_12 12 PRIORITY_12は、PRIORITY_13よりも優先度が高く、PRIORITY_11よりも優先度が低くなっています。
PRIORITY_11 11 PRIORITY_11 is a higher priority than PRIORITY_12 and a lower priority than PRIORITY_10.
PRIORITY_11 11 PRIORITY_11は、PRIORITY_12よりも優先度が高く、PRIORITY_10よりも優先度が低くなっています。
PRIORITY_10 10 PRIORITY_10 is a higher priority than PRIORITY_11 and a lower priority than PRIORITY_9.
PRIORITY_10 10 PRIORITY_10は、PRIORITY_11よりも優先度が高く、PRIORITY_9よりも優先度が低くなっています。
PRIORITY_9 9 PRIORITY_9 is a higher priority than PRIORITY_10 and a lower priority than PRIORITY_8.
PRIORITY_9 9 PRIORITY_9は、PRIORITY_10よりも優先度が高く、PRIORITY_8よりも優先度が低くなっています。
PRIORITY_8 8 PRIORITY_8 is a higher priority than PRIORITY_9 and a lower priority than PRIORITY_7.
PRIORITY_8 8 PRIORITY_8は、PRIORITY_9よりも優先度が高く、PRIORITY_7よりも優先度が低くなっています。
PRIORITY_7 7 PRIORITY_7 is a higher priority than PRIORITY_8 and a lower priority than PRIORITY_6.
PRIORITY_7 7 PRIORITY_7は、PRIORITY_8よりも優先度が高く、PRIORITY_6よりも優先度が低くなっています。
PRIORITY_6 6 PRIORITY_6 is a higher priority than PRIORITY_7 and a lower priority than PRIORITY_5.
PRIORITY_6 6 PRIORITY_6は、PRIORITY_7よりも優先度が高く、PRIORITY_5よりも優先度が低くなっています。
PRIORITY_5 5 PRIORITY_5 is a higher priority than PRIORITY_6 and a lower priority than PRIORITY_4.
PRIORITY_5 5 PRIORITY_5は、PRIORITY_6よりも優先度が高く、PRIORITY_4よりも優先度が低くなっています。
PRIORITY_4 4 PRIORITY_4 is a higher priority than PRIORITY_5 and a lower priority than PRIORITY_3.
PRIORITY_4 4 PRIORITY_4は、PRIORITY_5よりも優先度が高く、PRIORITY_3よりも優先度が低くなっています。
PRIORITY_3 3 PRIORITY_3 is a higher priority than PRIORITY_4 and a lower priority than PRIORITY_2.
PRIORITY_3 3 PRIORITY_3は、PRIORITY_4よりも優先度が高く、PRIORITY_2よりも優先度が低くなっています。
PRIORITY_2 2 PRIORITY_2 is a higher priority than PRIORITY_3 and a lower priority than PRIORITY_1.
PRIORITY_2 2 PRIORITY_2は、PRIORITY_3よりも優先度が高く、PRIORITY_1よりも優先度が低くなっています。
PRIORITY_1 1 PRIORITY_1 is a higher priority than PRIORITY_2 and a lower priority than PRIORITY_0.
PRIORITY_1 1 PRIORITY_1は、PRIORITY_2より高い優先度で、PRIORITY_0より低い優先度です。
PRIORITY_0 0 Priority 0 is the highest priority.
PRIORITY_0 0優先度0が最も高い優先度です。
+---------+
|AVP Flag |
|Rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------+----+----+
|DRMP 301 9.1 Enumerated | | V |
+--------------------------------------------------+----+----+
As discussed in Section 1.1, it is important that the definition of priority values used by all applications within a single Diameter administrative domain be done in a consistent and coordinated manner.
セクション1.1で説明したように、単一のDiameter管理ドメイン内のすべてのアプリケーションで使用される優先度の値の定義は、一貫して調整された方法で行われることが重要です。
The following are some things to be considered when defining the DRMPs to be used in Diameter networks that support Diameter nodes handling multiple applications.
以下は、複数のアプリケーションを処理するDiameterノードをサポートするDiameterネットワークで使用されるDRMPを定義するときに考慮すべきいくつかのことです。
1. As with any prioritization scheme, it is possible for higher-priority messages to block lower-priority messages from ever being handled. In a Diameter network, this will often result in those Diameter transactions being retried. This can result in more traffic than the network would have handled without use of the DRMP mechanism.
1. 他の優先順位付けスキームと同様に、優先度の高いメッセージが、優先度の低いメッセージの処理をブロックする可能性があります。 Diameterネットワークでは、これにより、それらのDiameterトランザクションが再試行されることがよくあります。これにより、DRMPメカニズムを使用せずにネットワークが処理するよりも多くのトラフィックが発生する可能性があります。
One potential guideline to prevent unwanted starving of lower-priority messages is to have higher-priority messages represent a relatively small portion of messages handled by the Diameter network under normal scenarios.
優先度の低いメッセージの不要な不足を防ぐための1つの潜在的なガイドラインは、優先度の高いメッセージが通常のシナリオでDiameterネットワークによって処理されるメッセージの比較的小さな部分を表すようにすることです。
Note that there are scenarios, such as first responder messages, where the blocking of lower-priority messages is a requirement.
ファーストレスポンダメッセージなど、優先度の低いメッセージのブロックが必要なシナリオがあることに注意してください。
2. When setting priorities for any of the use cases outlined in Section 5, it is important to use the same priority values across applications. For instance, when defining priority for the first responder use case discussed in Section 5.1 and the emergency call use case discussed in Section 5.2, one high-priority value might be used for all first responder messages, say PRIORITY_2, and a slightly lower-priority value, say PRIORITY_3, might be used for emergency-call-related messages. These values should be specified for these use cases across all applications used within the Diameter administrative domain.
2. セクション5で概説されているユースケースの優先度を設定する場合、アプリケーション間で同じ優先度の値を使用することが重要です。たとえば、セクション5.1で説明されているファーストレスポンダのユースケースとセクション5.2で説明されている緊急コールのユースケースの優先度を定義する場合、すべてのファーストレスポンダメッセージに1つの優先度の高い値、たとえばPRIORITY_2を使用し、わずかに優先度を低くすることができます。値、たとえばPRIORITY_3は、緊急コール関連のメッセージに使用される場合があります。これらの値は、Diameter管理ドメイン内で使用されるすべてのアプリケーションのこれらのユースケースに対して指定する必要があります。
Note that the values mentioned here are strictly for illustrative purposes. The actual values used for these use cases are likely to be different.
ここに記載されている値は、あくまでも例示を目的としたものです。これらの使用例に使用される実際の値は異なる可能性があります。
3. Messages without the DRMP AVP will be given default priority value treatment. This will include messages from Diameter Clients that have not been updated to support the DRMP mechanism. It might also include messages from foreign administrative domains if the DRMP AVPs are stripped from messages crossing the Diameter administrative domains.
3. DRMP AVPのないメッセージには、デフォルトの優先順位値の扱いが与えられます。これには、DRMPメカニズムをサポートするように更新されていないDiameterクライアントからのメッセージが含まれます。また、Diameter管理ドメインを通過するメッセージからDRMP AVPが取り除かれた場合、外部管理ドメインからのメッセージも含まれることがあります。
4. The process used to introduce the DRMP mechanism into a Diameter network should also be taken into consideration. Messages of the same type within the same application might get different treatment depending on whether those messages are sent from nodes that are upgraded to support the DRMP mechanism versus nodes that have not yet been upgraded to support the DRMP mechanism.
4. DRMPメカニズムをDiameterネットワークに導入するために使用されるプロセスも考慮する必要があります。同じアプリケーション内の同じタイプのメッセージは、DRMPメカニズムをサポートするようにアップグレードされたノードと、DRMPメカニズムをサポートするようにまだアップグレードされていないノードから送信されるメッセージによって、処理が異なる場合があります。
The new AVP defined by this specification is listed in Section 9. All AVP codes are allocated from the "AVP Codes" subregistry of the "Authentication, Authorization, and Accounting (AAA) Parameters" registry.
この仕様で定義された新しいAVPは、セクション9にリストされています。すべてのAVPコードは、「Authentication、Authorization、and Accounting（AAA）Parameters」レジストリの「AVP Codes」サブレジストリから割り当てられます。
DRMP gives Diameter nodes the ability to influence which requests are throttled during overload scenarios. In addition, DRMP can be used in determining the routing decisions for request messages. Improper use of the DRMP mechanism could result in the malicious Diameter node gaining preferential treatment, by reducing the probability of its requests being throttled, over other Diameter nodes. This would be achieved by the malicious node inserting priority values that are artificially high.
DRMPにより、Diameterノードは過負荷シナリオ時にどの要求が抑制されるかに影響を与えることができます。さらに、DRMPは、要求メッセージのルーティング決定を決定する際に使用できます。 DRMPメカニズムを不適切に使用すると、悪意のあるDiameterノードが他のDiameterノードよりもそのリクエストが抑制される確率が低下するため、優先的に処理される可能性があります。これは、悪意のあるノードが人為的に高い優先度の値を挿入することで実現されます。
Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This opens the possibility that malicious or compromised agents in the path of a request could modify the DRMP AVP to reflect a priority different than that asserted by the sender of the request.
Diameterには、エンドツーエンドの認証、整合性保護、または機密性を提供する機能は含まれていません。これにより、リクエストの経路にある悪意のあるエージェントまたは侵害されたエージェントがDRMP AVPを変更して、リクエストの送信者が表明した優先度とは異なる優先度を反映する可能性があります。
The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers; that is, they may share a direct transport (e.g., the Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP)) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), or IPsec to authenticate peers and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer.
Diameterプロトコルには、クライアントとサーバー間で交換される要求と応答の形式のトランザクションが含まれます。これらのクライアントとサーバーはピアである場合があります。つまり、直接トランスポート（TCP（Transmission Control Protocol）やSCTP（Stream Control Transmission Protocol）など）接続を共有するか、メッセージがDiameter Agentと呼ばれる1つ以上の仲介者を通過します。 Diameterノードは、トランスポート層セキュリティ（TLS）、データグラムトランスポート層セキュリティ（DTLS）、またはIPsecを使用してピアを認証し、ピア間のトラフィックの機密性と整合性を保護します。ノードは、トランスポート層で認証されたピアIDに基づいて承認を決定できます。
When agents are involved, this presents an effectively transitive trust model. That is, a Diameter Client or Server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer, agents can read, and perhaps modify, any part of a Diameter message, including the DRMP AVP.
エージェントが関与する場合、これは効果的に推移的な信頼モデルを示します。つまり、Diameterクライアントまたはサーバーは、特定のアクションに対してエージェントを承認できますが、そのエージェントを信頼して、ピアに関する適切な承認決定を行う必要があります。機密性と整合性の保護はトランスポート層で行われるため、エージェントは、DRMP AVPを含むDiameterメッセージの任意の部分を読み取り、場合によっては変更できます。
There are several ways an attacker might attempt to exploit the DRMP mechanism. A malicious or compromised Diameter node might insert invalid priority values resulting in either preferential treatment, resulting from higher values, or degraded treatment resulting from lower values, for that node.
攻撃者がDRMPメカニズムを悪用しようとする方法はいくつかあります。悪意のある、または侵害されたDiameterノードは、無効な優先度の値を挿入する可能性があり、その結果、そのノードに対して高い値による優先処理、または低い値による低下した処理のいずれかが発生します。
A similar attack involves a malicious or compromised Diameter Agent changing the priority value resulting in the sending Diameter node getting either preferential or degraded service.
同様の攻撃には、悪意のある、または侵害されたDiameterエージェントが優先度の値を変更し、送信Diameterノードが優先または低下したサービスを取得することを伴います。
The DRMP mechanism can be used to aid in overload throttling decisions. When this is the case, then the above attacks are limited in scope to when one or more Diameter nodes are in an overloaded state.
DRMPメカニズムは、過負荷スロットルの決定を支援するために使用できます。この場合、上記の攻撃の範囲は、1つ以上のDiameterノードが過負荷状態にある場合に限定されます。
The DRMP mechanism can also be used to influence the order in which Diameter messages are handled by Diameter nodes. The above attacks have a potentially greater impact in this scenario as the priority indication impacts the handling of all requests at all times, independent of the overload status of Diameter nodes in the Diameter network.
DRMPメカニズムは、DiameterメッセージがDiameterノードによって処理される順序に影響を与えるためにも使用できます。優先度の表示は、Diameterネットワーク内のDiameterノードの過負荷状態に関係なく、常にすべてのリクエストの処理に影響を与えるため、上記の攻撃はこのシナリオで潜在的に大きな影響を及ぼします。
The DRMP mechanism does not open direct denial-of-service attack vectors. Rather, it introduces a mechanism where a node can gain unwarranted preferential treatment. It also introduces a mechanism where a node can get degraded service in the scenario where a rogue agent changes the priority value included in messages.
DRMPメカニズムは、直接的なサービス拒否攻撃ベクトルを開きません。むしろ、ノードが不当な優先扱いを受けるメカニズムを導入します。また、不正なエージェントがメッセージに含まれる優先度の値を変更するシナリオで、ノードがサービスの質を低下させるメカニズムも導入されています。
The lack of end-to-end integrity features in Diameter [RFC6733] makes it difficult to establish trust in DRMP AVPs received from non-adjacent nodes. Any agents in the message path may insert or modify DRMP AVPs. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting DRMP MUST give operators the ability to select which peers are trusted to deliver DRMP AVPs, and whether they are trusted to forward the DRMP AVPs from non-adjacent nodes. Diameter nodes MUST strip DRMP AVPs from messages received from peers that are not trusted for DRMP purposes.
Diameter [RFC6733]にはエンドツーエンドの整合性機能がないため、隣接していないノードから受信したDRMP AVPで信頼を確立することが困難になります。メッセージパス内のエージェントは、DRMP AVPを挿入または変更できます。ノードは、隣接するピアがピアからの過負荷レポートに対して適切なチェックを実行することなどを信頼する必要があります。これにより、ノードのチェーンが長くなる可能性のある推移的な信頼要件が作成されます。ネットワークオペレーターは、この推移的な信頼要件が展開に受け入れられるかどうかを判断する必要があります。 DRMPをサポートするノードは、DRMP AVPを配信するために信頼されているピアを選択する能力と、隣接していないノードからDRMP AVPを転送することが信頼されているかどうかをオペレーターに選択しなければなりません（MUST）。 Diameterノードは、DRMPの目的で信頼されていないピアから受信したメッセージからDRMP AVPを取り除く必要があります。
It is expected that work on end-to-end Diameter security might make it easier to establish trust in non-adjacent nodes for DRMP purposes. Readers should be reminded, however, that the DRMP mechanism allows Diameter Agents to modify AVPs in existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. The details of using any future Diameter end-to-end security mechanism with DRMP will require careful consideration and are beyond the scope of this document.
エンドツーエンドのDiameterセキュリティでの作業により、隣接していないノードでDRMPの目的で信頼を確立しやすくなることが期待されます。ただし、DRMPメカニズムを使用すると、Diameterエージェントは他のノードから発信された既存のメッセージ内のAVPを変更できることに注意してください。エンドツーエンドのセキュリティが有効になっている場合、そのような変更が整合性保護に違反する危険性があります。 DRMPで将来のDiameterエンドツーエンドセキュリティメカニズムを使用する詳細は慎重に検討する必要があり、このドキュメントの範囲を超えています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6733] Fajardo、V.、Ed。、Arkko、J.、Loughney、J.、and G. Zorn、Ed。、 "Diameter Base Protocol"、RFC 6733、DOI 10.17487 / RFC6733、October 2012、<http：/ /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, <http://www.rfc-editor.org/info/rfc7683>.
[RFC7683] Korhonen、J.、Ed。、Donovan、S.、Ed。、Campbell、B.、and L. Morand、 "Diameter Overload Indication Conveyance"、RFC 7683、DOI 10.17487 / RFC7683、October 2015、<http： //www.rfc-editor.org/info/rfc7683>。
[S6a] 3GPP, "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol", 3GPP TS 29.272, 14.0.0, June 2016, <http://www.3gpp.org/ftp/Specs/html-info/29272.htm>.
[S6a] 3GPP、「Evolved Packet System（EPS）; Mobility Management Entity（MME）and Serving GPRS Support Node（SGSN）related interfaces based on Diameter protocol "」、3GPP TS 29.272、14.0.0、2016年6月、<http：/ /www.3gpp.org/ftp/Specs/html-info/29272.htm>。
Contributors
貢献者
The following person contributed substantial ideas, feedback, and discussion to this document:
次の人物は、このドキュメントに実質的なアイデア、フィードバック、および議論を提供しました。
o Janet P. Gunn
o ジャネット・P・ガン
Author's Address
著者のアドレス
Steve Donovan Oracle 7460 Warren Parkway Frisco, Texas 75034 United States of America
スティーブドノバンオラクル7460ウォーレンパークウェイフリスコ、テキサス75034アメリカ合衆国
Email: srdonovan@usdonovans.com