[要約] RFC 6733は、Diameterベースプロトコルの仕様を定義しており、Diameterネットワークでの認証、認可、アカウンティング（AAA）サービスを提供するためのプロトコルです。このRFCの目的は、Diameterプロトコルの基本的な動作とメッセージ交換の仕組みを明確にすることです。
Internet Engineering Task Force (IETF) V. Fajardo, Ed.
Request for Comments: 6733 Telcordia Technologies
Obsoletes: 3588, 5719 J. Arkko
Category: Standards Track Ericsson Research
ISSN: 2070-1721 J. Loughney
Nokia Research Center
G. Zorn, Ed.
Network Zen
October 2012
Diameter Base Protocol
Diameterベースプロトコル
Abstract
概要
The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations.
Diameter基本プロトコルは、ローカルおよびローミングの両方の状況でのネットワークアクセスやIPモビリティなどのアプリケーションに認証、承認、およびアカウンティング（AAA）フレームワークを提供することを目的としています。このドキュメントでは、すべてのDiameterアプリケーションで使用されるメッセージフォーマット、トランスポート、エラーレポート、アカウンティング、およびセキュリティサービスについて説明します。このドキュメントで定義されているDiameterベースプロトコルはRFC 3588およびRFC 5719を廃止し、すべての新しい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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6733.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6733で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの資料が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................7
1.1. Diameter Protocol ..........................................9
1.1.1. Description of the Document Set ....................10
1.1.2. Conventions Used in This Document ..................11
1.1.3. Changes from RFC 3588 ..............................11
1.2. Terminology ...............................................12
1.3. Approach to Extensibility .................................17
1.3.1. Defining New AVP Values ............................18
1.3.2. Creating New AVPs ..................................18
1.3.3. Creating New Commands ..............................18
1.3.4. Creating New Diameter Applications .................19
2. Protocol Overview ..............................................20
2.1. Transport .................................................22
2.1.1. SCTP Guidelines ....................................23
2.2. Securing Diameter Messages ................................24
2.3. Diameter Application Compliance ...........................24
2.4. Application Identifiers ...................................24
2.5. Connections vs. Sessions ..................................25
2.6. Peer Table ................................................26
2.7. Routing Table .............................................27
2.8. Role of Diameter Agents ...................................28
2.8.1. Relay Agents .......................................30
2.8.2. Proxy Agents .......................................31
2.8.3. Redirect Agents ....................................31
2.8.4. Translation Agents .................................32
2.9. Diameter Path Authorization ...............................33
3. Diameter Header ................................................34
3.1. Command Codes .............................................37
3.2. Command Code Format Specification .........................38
3.3. Diameter Command Naming Conventions .......................40
4. Diameter AVPs ..................................................40
4.1. AVP Header ................................................41
4.1.1. Optional Header Elements ...........................42
4.2. Basic AVP Data Formats ....................................43
4.3. Derived AVP Data Formats ..................................44
4.3.1. Common Derived AVP Data Formats ....................44
4.4. Grouped AVP Values ........................................51
4.4.1. Example AVP with a Grouped Data Type ...............52
4.5. Diameter Base Protocol AVPs ...............................55
5. Diameter Peers .................................................58
5.1. Peer Connections ..........................................58
5.2. Diameter Peer Discovery ...................................59
5.3. Capabilities Exchange .....................................60
5.3.1. Capabilities-Exchange-Request ......................62
5.3.2. Capabilities-Exchange-Answer .......................63
5.3.3. Vendor-Id AVP ......................................63
5.3.4. Firmware-Revision AVP ..............................64
5.3.5. Host-IP-Address AVP ................................64
5.3.6. Supported-Vendor-Id AVP ............................64
5.3.7. Product-Name AVP ...................................64
5.4. Disconnecting Peer Connections ............................64
5.4.1. Disconnect-Peer-Request ............................65
5.4.2. Disconnect-Peer-Answer .............................65
5.4.3. Disconnect-Cause AVP ...............................66
5.5. Transport Failure Detection ...............................66
5.5.1. Device-Watchdog-Request ............................67
5.5.2. Device-Watchdog-Answer .............................67
5.5.3. Transport Failure Algorithm ........................67
5.5.4. Failover and Failback Procedures ...................67
5.6. Peer State Machine ........................................68
5.6.1. Incoming Connections ...............................71
5.6.2. Events .............................................71
5.6.3. Actions ............................................72
5.6.4. The Election Process ...............................74
6. Diameter Message Processing ....................................74
6.1. Diameter Request Routing Overview .........................74
6.1.1. Originating a Request ..............................75
6.1.2. Sending a Request ..................................76
6.1.3. Receiving Requests .................................76
6.1.4. Processing Local Requests ..........................76
6.1.5. Request Forwarding .................................77
6.1.6. Request Routing ....................................77
6.1.7. Predictive Loop Avoidance ..........................77
6.1.8. Redirecting Requests ...............................78
6.1.9. Relaying and Proxying Requests .....................79
6.2. Diameter Answer Processing ................................80
6.2.1. Processing Received Answers ........................81
6.2.2. Relaying and Proxying Answers ......................81
6.3. Origin-Host AVP ...........................................81
6.4. Origin-Realm AVP ..........................................82
6.5. Destination-Host AVP ......................................82
6.6. Destination-Realm AVP .....................................82
6.7. Routing AVPs ..............................................83
6.7.1. Route-Record AVP ...................................83
6.7.2. Proxy-Info AVP .....................................83
6.7.3. Proxy-Host AVP .....................................83
6.7.4. Proxy-State AVP ....................................83
6.8. Auth-Application-Id AVP ...................................83
6.9. Acct-Application-Id AVP ...................................84
6.10. Inband-Security-Id AVP ...................................84
6.11. Vendor-Specific-Application-Id AVP .......................84
6.12. Redirect-Host AVP ........................................85
6.13. Redirect-Host-Usage AVP ..................................85
6.14. Redirect-Max-Cache-Time AVP ..............................87
7. Error Handling .................................................87
7.1. Result-Code AVP ...........................................89
7.1.1. Informational ......................................90
7.1.2. Success ............................................90
7.1.3. Protocol Errors ....................................90
7.1.4. Transient Failures .................................92
7.1.5. Permanent Failures .................................92
7.2. Error Bit .................................................95
7.3. Error-Message AVP .........................................96
7.4. Error-Reporting-Host AVP ..................................96
7.5. Failed-AVP AVP ............................................96
7.6. Experimental-Result AVP ...................................97
7.7. Experimental-Result-Code AVP ..............................97
8. Diameter User Sessions .........................................98
8.1. Authorization Session State Machine .......................99
8.2. Accounting Session State Machine .........................104
8.3. Server-Initiated Re-Auth .................................110
8.3.1. Re-Auth-Request ...................................110
8.3.2. Re-Auth-Answer ....................................110
8.4. Session Termination ......................................111
8.4.1. Session-Termination-Request .......................112
8.4.2. Session-Termination-Answer ........................113
8.5. Aborting a Session .......................................113
8.5.1. Abort-Session-Request .............................114
8.5.2. Abort-Session-Answer ..............................114
8.6. Inferring Session Termination from Origin-State-Id .......115
8.7. Auth-Request-Type AVP ....................................116
8.8. Session-Id AVP ...........................................116
8.9. Authorization-Lifetime AVP ...............................117
8.10. Auth-Grace-Period AVP ...................................118
8.11. Auth-Session-State AVP ..................................118
8.12. Re-Auth-Request-Type AVP ................................118
8.13. Session-Timeout AVP .....................................119
8.14. User-Name AVP ...........................................119
8.15. Termination-Cause AVP ...................................120
8.16. Origin-State-Id AVP .....................................120
8.17. Session-Binding AVP .....................................120
8.18. Session-Server-Failover AVP .............................121
8.19. Multi-Round-Time-Out AVP ................................122
8.20. Class AVP ...............................................122
8.21. Event-Timestamp AVP .....................................122
9. Accounting ....................................................123
9.1. Server Directed Model ....................................123
9.2. Protocol Messages ........................................124
9.3. Accounting Application Extension and Requirements ........124
9.4. Fault Resilience .........................................125
9.5. Accounting Records .......................................125
9.6. Correlation of Accounting Records ........................126
9.7. Accounting Command Codes .................................127
9.7.1. Accounting-Request ................................127
9.7.2. Accounting-Answer .................................128
9.8. Accounting AVPs ..........................................129
9.8.1. Accounting-Record-Type AVP ........................129
9.8.2. Acct-Interim-Interval AVP .........................130
9.8.3. Accounting-Record-Number AVP ......................131
9.8.4. Acct-Session-Id AVP ...............................131
9.8.5. Acct-Multi-Session-Id AVP .........................131
9.8.6. Accounting-Sub-Session-Id AVP .....................131
9.8.7. Accounting-Realtime-Required AVP ..................132
10. AVP Occurrence Tables ........................................132
10.1. Base Protocol Command AVP Table .........................133
10.2. Accounting AVP Table ....................................134
11. IANA Considerations ..........................................135
11.1. AVP Header ..............................................135
11.1.1. AVP Codes ........................................136
11.1.2. AVP Flags ........................................136
11.2. Diameter Header .........................................136
11.2.1. Command Codes ....................................136
11.2.2. Command Flags ....................................137
11.3. AVP Values ..............................................137
11.3.1. Experimental-Result-Code AVP .....................137
11.3.2. Result-Code AVP Values ...........................137
11.3.3. Accounting-Record-Type AVP Values ................137
11.3.4. Termination-Cause AVP Values .....................137
11.3.5. Redirect-Host-Usage AVP Values ...................137
11.3.6. Session-Server-Failover AVP Values ...............137
11.3.7. Session-Binding AVP Values .......................137
11.3.8. Disconnect-Cause AVP Values ......................138
11.3.9. Auth-Request-Type AVP Values .....................138
11.3.10. Auth-Session-State AVP Values ...................138
11.3.11. Re-Auth-Request-Type AVP Values .................138
11.3.12. Accounting-Realtime-Required AVP Values .........138
11.3.13. Inband-Security-Id AVP (code 299) ...............138
11.4. _diameters Service Name and Port Number Registration ....138
11.5. SCTP Payload Protocol Identifiers .......................139
11.6. S-NAPTR Parameters ......................................139
12. Diameter Protocol-Related Configurable Parameters ............139
13. Security Considerations ......................................140
13.1. TLS/TCP and DTLS/SCTP Usage .............................140
13.2. Peer-to-Peer Considerations .............................141
13.3. AVP Considerations ......................................141
14. References ...................................................142
14.1. Normative References ....................................142
14.2. Informative References ..................................144
Appendix A. Acknowledgements .....................................147
A.1. This Document .............................................147
A.2. RFC 3588 ..................................................148
Appendix B. S-NAPTR Example ......................................148
Appendix C. Duplicate Detection ..................................149
Appendix D. Internationalized Domain Names .......................151
Authentication, Authorization, and Accounting (AAA) protocols such as TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to provide dial-up PPP [RFC1661] and terminal server access. Over time, AAA support was needed on many new access technologies, the scale and complexity of AAA networks grew, and AAA was also used on new applications (such as voice over IP). This led to new demands on AAA protocols.
TACACS [RFC1492]やRADIUS [RFC2865]などの認証、承認、およびアカウンティング（AAA）プロトコルは、ダイヤルアップPPP [RFC1661]およびターミナルサーバーアクセスを提供するために最初に導入されました。時間の経過とともに、AAAサポートは多くの新しいアクセステクノロジーで必要になり、AAAネットワークの規模と複雑さが増大し、AAAは新しいアプリケーション（Voice over IPなど）でも使用されました。これにより、AAAプロトコルに対する新たな要求が生まれました。
Network access requirements for AAA protocols are summarized in Aboba, et al. [RFC2989]. These include:
AAAプロトコルのネットワークアクセス要件は、Abobaらにまとめられています。 [RFC2989]。これらには以下が含まれます：
Failover
フェイルオーバー
[RFC2865] does not define failover mechanisms and, as a result, failover behavior differs between implementations. In order to provide well-defined failover behavior, Diameter supports application-layer acknowledgements and defines failover algorithms and the associated state machine.
[RFC2865]はフェイルオーバーメカニズムを定義していないため、フェイルオーバーの動作は実装によって異なります。明確に定義されたフェイルオーバー動作を提供するために、Diameterはアプリケーション層の確認応答をサポートし、フェイルオーバーアルゴリズムと関連するステートマシンを定義します。
Transmission-level security
伝送レベルのセキュリティ
RADIUS [RFC2865] defines an application-layer authentication and integrity scheme that is required only for use with response packets. While [RFC2869] defines an additional authentication and integrity mechanism, use is only required during Extensible Authentication Protocol (EAP) [RFC3748] sessions. While attribute hiding is supported, [RFC2865] does not provide support for per-packet confidentiality. In accounting, [RFC2866] assumes that replay protection is provided by the backend billing server rather than within the protocol itself.
RADIUS [RFC2865]は、応答パケットでの使用にのみ必要なアプリケーション層認証および整合性スキームを定義します。 [RFC2869]は追加の認証および整合性メカニズムを定義していますが、使用が必要なのは、拡張認証プロトコル（EAP）[RFC3748]セッションの間だけです。属性非表示はサポートされていますが、[RFC2865]はパケットごとの機密性をサポートしていません。アカウンティングでは、[RFC2866]は、プロトコル自体ではなく、バックエンド課金サーバーによってリプレイ保護が提供されることを想定しています。
While [RFC3162] defines the use of IPsec with RADIUS, support for IPsec is not required. In order to provide universal support for transmission-level security, and enable both intra- and inter-domain AAA deployments, Diameter provides support for TLS/TCP and DTLS/SCTP. Security is discussed in Section 13.
[RFC3162]はRADIUSでのIPsecの使用を定義していますが、IPsecのサポートは必要ありません。 Diameterは、伝送レベルのセキュリティに対するユニバーサルサポートを提供し、ドメイン内およびドメイン間のAAA展開を可能にするために、TLS / TCPおよびDTLS / SCTPをサポートしています。セキュリティについては、セクション13で説明します。
Reliable transport
信頼できる輸送
RADIUS runs over UDP, and does not define retransmission behavior; as a result, reliability varies between implementations. As described in [RFC2975], this is a major issue in accounting, where packet loss may translate directly into revenue loss. In order to provide well-defined transport behavior, Diameter runs over reliable transport mechanisms (TCP, Stream Control Transmission Protocol (SCTP)) as defined in [RFC3539].
RADIUSはUDPで実行され、再送信動作を定義しません。その結果、信頼性は実装によって異なります。 [RFC2975]で説明されているように、これはアカウンティングの主要な問題であり、パケット損失は直接収益損失につながる可能性があります。明確に定義されたトランスポート動作を提供するために、Diameterは、[RFC3539]で定義されている信頼性の高いトランスポートメカニズム（TCP、ストリーム制御伝送プロトコル（SCTP））で実行されます。
Agent support
エージェントサポート
RADIUS does not provide for explicit support for agents, including proxies, redirects, and relays. Since the expected behavior is not defined, it varies between implementations. Diameter defines agent behavior explicitly; this is described in Section 2.8.
RADIUSは、プロキシ、リダイレクト、リレーなどのエージェントを明示的にサポートしていません。期待される動作は定義されていないため、実装によって異なります。 Diameterはエージェントの動作を明示的に定義します。これについては、セクション2.8で説明します。
Server-initiated messages
サーバー起動メッセージ
While server-initiated messages are defined in RADIUS [RFC5176], support is optional. This makes it difficult to implement features such as unsolicited disconnect or re-authentication/ re-authorization on demand across a heterogeneous deployment. To address this issue, support for server-initiated messages is mandatory in Diameter.
サーバー開始メッセージはRADIUS [RFC5176]で定義されていますが、サポートはオプションです。これにより、要求のない切断や再認証/再認証などの機能を、異種混合のデプロイメント全体でオンデマンドで実装することが困難になります。この問題に対処するには、Diameterでサーバー起動メッセージのサポートが必須です。
Transition support
移行サポート
While Diameter does not share a common protocol data unit (PDU) with RADIUS, considerable effort has been expended in enabling backward compatibility with RADIUS so that the two protocols may be deployed in the same network. Initially, it is expected that Diameter will be deployed within new network devices, as well as within gateways enabling communication between legacy RADIUS devices and Diameter agents. This capability enables Diameter support to be added to legacy networks, by addition of a gateway or server speaking both RADIUS and Diameter.
DiameterはRADIUSと共通のプロトコルデータユニット（PDU）を共有しませんが、RADIUSとの下位互換性を有効にするためにかなりの労力が費やされ、2つのプロトコルを同じネットワークに展開できるようになりました。最初は、Diameterが新しいネットワークデバイス内に配備されるだけでなく、レガシーRADIUSデバイスとDiameterエージェント間の通信を可能にするゲートウェイ内に配備されることが期待されています。この機能により、RADIUSとDiameterの両方を話すゲートウェイまたはサーバーを追加することにより、Diameterサポートをレガシーネットワークに追加できます。
In addition to addressing the above requirements, Diameter also provides support for the following:
上記の要件への対応に加えて、Diameterは以下のサポートも提供します。
Capability negotiation
能力交渉
RADIUS does not support error messages, capability negotiation, or a mandatory/non-mandatory flag for attributes. Since RADIUS clients and servers are not aware of each other's capabilities, they may not be able to successfully negotiate a mutually acceptable service or, in some cases, even be aware of what service has been implemented. Diameter includes support for error handling (Section 7), capability negotiation (Section 5.3), and mandatory/non-mandatory Attribute-Value Pairs (AVPs) (Section 4.1).
RADIUSは、エラーメッセージ、機能ネゴシエーション、または属性の必須/非必須フラグをサポートしていません。 RADIUSクライアントとサーバーは互いの機能を認識していないため、相互に受け入れ可能なサービスを正常にネゴシエートできなかったり、場合によっては、実装されているサービスを認識できなかったりすることがあります。 Diameterには、エラー処理（セクション7）、機能ネゴシエーション（セクション5.3）、および必須/非必須の属性値ペア（AVP）（セクション4.1）のサポートが含まれています。
Peer discovery and configuration
ピアの検出と構成
RADIUS implementations typically require that the name or address of servers or clients be manually configured, along with the corresponding shared secrets. This results in a large administrative burden and creates the temptation to reuse the RADIUS shared secret, which can result in major security vulnerabilities if the Request Authenticator is not globally and temporally unique as required in [RFC2865]. Through DNS, Diameter enables dynamic discovery of peers (see Section 5.2). Derivation of dynamic session keys is enabled via transmission-level security.
RADIUSの実装では、通常、サーバーまたはクライアントの名前またはアドレスを、対応する共有シークレットとともに手動で構成する必要があります。これにより、管理上の負担が大きくなり、RADIUS共有シークレットを再利用しようとする誘惑が生まれます。これは、[RFC2865]で要求されているように、リクエスト認証がグローバルかつ一時的に一意でない場合に、セキュリティ上の重大な脆弱性をもたらす可能性があります。 DiameterはDNSを通じて、ピアの動的な検出を可能にします（セクション5.2を参照）。動的セッションキーの派生は、伝送レベルのセキュリティによって有効になります。
Over time, the capabilities of Network Access Server (NAS) devices have increased substantially. As a result, while Diameter is a considerably more sophisticated protocol than RADIUS, it remains feasible to implement it within embedded devices.
時間の経過とともに、ネットワークアクセスサーバー（NAS）デバイスの機能は大幅に増加しました。その結果、DiameterはRADIUSよりもかなり高度なプロトコルですが、組み込みデバイス内に実装することは引き続き可能です。
The Diameter base protocol provides the following facilities:
Diameter基本プロトコルは、次の機能を提供します。
o Ability to exchange messages and deliver AVPs
o メッセージを交換し、AVPを配信する機能
o Capabilities negotiation
o 能力交渉
o Error notification
o エラー通知
o Extensibility, required in [RFC2989], through addition of new applications, commands, and AVPs
o 新しいアプリケーション、コマンド、およびAVPの追加による、[RFC2989]で必要な拡張性
o Basic services necessary for applications, such as the handling of user sessions or accounting
o ユーザーセッションの処理や課金など、アプリケーションに必要な基本的なサービス
All data delivered by the protocol is in the form of AVPs. Some of these AVP values are used by the Diameter protocol itself, while others deliver data associated with particular applications that employ Diameter. AVPs may be arbitrarily added to Diameter messages, the only restriction being that the Command Code Format (CCF) specification (Section 3.2) be satisfied. AVPs are used by the base Diameter protocol to support the following required features:
プロトコルによって配信されるすべてのデータは、AVPの形式です。これらのAVP値には、Diameterプロトコル自体で使用されるものと、Diameterを使用する特定のアプリケーションに関連するデータを提供するものがあります。 AVPは、Diameterメッセージに任意に追加できます。唯一の制限は、コマンドコードフォーマット（CCF）仕様（セクション3.2）が満たされていることです。 AVPは、以下の必須機能をサポートするために基本Diameterプロトコルによって使用されます。
o Transporting of user authentication information, for the purposes of enabling the Diameter server to authenticate the user
o Diameterサーバーがユーザーを認証できるようにするための、ユーザー認証情報の転送
o Transporting of service-specific authorization information, between client and servers, allowing the peers to decide whether a user's access request should be granted
o クライアントとサーバー間でのサービス固有の承認情報の転送。これにより、ピアはユーザーのアクセス要求を許可するかどうかを決定できます。
o Exchanging resource usage information, which may be used for accounting purposes, capacity planning, etc.
o 会計目的、容量計画などに使用される可能性のあるリソース使用情報の交換
o Routing, relaying, proxying, and redirecting of Diameter messages through a server hierarchy
o サーバー階層を介したDiameterメッセージのルーティング、リレー、プロキシ、リダイレクト
The Diameter base protocol satisfies the minimum requirements for a AAA protocol, as specified by [RFC2989]. The base protocol may be used by itself for accounting purposes only, or it may be used with a Diameter application, such as Mobile IPv4 [RFC4004], or network access [RFC4005]. It is also possible for the base protocol to be extended for use in new applications, via the addition of new commands or AVPs. The initial focus of Diameter was network access and accounting applications. A truly generic AAA protocol used by many applications might provide functionality not provided by Diameter. Therefore, it is imperative that the designers of new applications understand their requirements before using Diameter. See Section 1.3.4 for more information on Diameter applications.
Diameter基本プロトコルは、[RFC2989]で指定されているAAAプロトコルの最小要件を満たしています。基本プロトコルは、アカウンティングの目的でのみ単独で使用することも、モバイルIPv4 [RFC4004]やネットワークアクセス[RFC4005]などのDiameterアプリケーションで使用することもできます。新しいコマンドまたはAVPを追加することにより、基本プロトコルを拡張して新しいアプリケーションで使用することもできます。 Diameterの最初の焦点は、ネットワークアクセスおよびアカウンティングアプリケーションでした。多くのアプリケーションで使用されている真に一般的なAAAプロトコルは、Diameterで提供されていない機能を提供する場合があります。したがって、Diameterを使用する前に、新しいアプリケーションの設計者が要件を理解することが不可欠です。 Diameterアプリケーションの詳細については、セクション1.3.4を参照してください。
Any node can initiate a request. In that sense, Diameter is a peer-to-peer protocol. In this document, a Diameter client is a device at the edge of the network that performs access control, such as a Network Access Server (NAS) or a Foreign Agent (FA). A Diameter client generates Diameter messages to request authentication, authorization, and accounting services for the user. A Diameter agent is a node that does not provide local user authentication or authorization services; agents include proxies, redirects, and relay agents. A Diameter server performs authentication and/or authorization of the user. A Diameter node may act as an agent for certain requests while acting as a server for others.
どのノードでもリクエストを開始できます。その意味で、Diameterはピアツーピアプロトコルです。このドキュメントでは、Diameterクライアントは、ネットワークアクセスサーバー（NAS）や外部エージェント（FA）など、アクセス制御を実行するネットワークエッジのデバイスです。 Diameterクライアントは、Diameterメッセージを生成して、ユーザーの認証、承認、およびアカウンティングサービスを要求します。 Diameterエージェントは、ローカルユーザー認証または承認サービスを提供しないノードです。エージェントには、プロキシ、リダイレクト、およびリレーエージェントが含まれます。 Diameterサーバーは、ユーザーの認証や承認を実行します。 Diameterノードは、特定のリクエストのエージェントとして機能する一方で、他のリクエストのサーバーとして機能する場合があります。
The Diameter protocol also supports server-initiated messages, such as a request to abort service to a particular user.
Diameterプロトコルは、特定のユーザーへのサービスを中止する要求など、サーバーが開始するメッセージもサポートします。
The Diameter specification consists of an updated version of the base protocol specification (this document) and the Transport Profile [RFC3539]. This document obsoletes both RFC 3588 and RFC 5719. A summary of the base protocol updates included in this document can be found in Section 1.1.3.
Diameter仕様は、基本プロトコル仕様（このドキュメント）の更新バージョンとトランスポートプロファイル[RFC3539]で構成されています。このドキュメントはRFC 3588とRFC 5719の両方を廃止します。このドキュメントに含まれる基本プロトコルの更新の概要は、セクション1.1.3にあります。
This document defines the base protocol specification for AAA, which includes support for accounting. There are also a myriad of applications documents describing applications that use this base specification for Authentication, Authorization, and Accounting. These application documents specify how to use the Diameter protocol within the context of their application.
このドキュメントは、アカウンティングのサポートを含む、AAAの基本プロトコル仕様を定義しています。認証、承認、およびアカウンティングにこの基本仕様を使用するアプリケーションを説明する無数のアプリケーションドキュメントもあります。これらのアプリケーションドキュメントは、アプリケーションのコンテキスト内でDiameterプロトコルを使用する方法を指定します。
The Transport Profile document [RFC3539] discusses transport layer issues that arise with AAA protocols and recommendations on how to overcome these issues. This document also defines the Diameter failover algorithm and state machine.
トランスポートプロファイルドキュメント[RFC3539]では、AAAプロトコルで発生するトランスポート層の問題と、これらの問題を克服する方法に関する推奨事項について説明しています。このドキュメントでは、Diameterフェイルオーバーアルゴリズムとステートマシンも定義しています。
"Clarifications on the Routing of Diameter Request Based on the Username and the Realm" [RFC5729] defines specific behavior on how to route requests based on the content of the User-Name AVP (Attribute Value Pair).
「ユーザー名とレルムに基づくDiameterリクエストのルーティングに関する説明」[RFC5729]は、ユーザー名AVP（属性値ペア）の内容に基づいてリクエストをルーティングする方法に関する特定の動作を定義しています。
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]で説明されているように解釈されます。
This document obsoletes RFC 3588 but is fully backward compatible with that document. The changes introduced in this document focus on fixing issues that have surfaced during the implementation of Diameter (RFC 3588). An overview of some the major changes are given below.
このドキュメントはRFC 3588を廃止しますが、そのドキュメントと完全に下位互換性があります。このドキュメントで紹介する変更は、Diameter（RFC 3588）の実装中に発生した問題の修正に重点を置いています。主な変更点の概要を以下に示します。
o Deprecated the use of the Inband-Security AVP for negotiating Transport Layer Security (TLS) [RFC5246]. It has been generally considered that bootstrapping of TLS via Inband-Security AVP creates certain security risks because it does not completely protect the information carried in the CER/CEA (Capabilities-Exchange-Request/Capabilities-Exchange-Answer). This version of Diameter adopts the common approach of defining a well-known secured port that peers should use when communicating via TLS/TCP and DTLS/SCTP. This new approach augments the existing in-band security negotiation, but it does not completely replace it. The old method is kept for backward compatibility reasons.
o トランスポート層セキュリティ（TLS）[RFC5246]をネゴシエートするためのインバンドセキュリティAVPの使用を非推奨にしました。 Inband-Security AVPを介したTLSのブートストラップは、CER / CEA（Capabilities-Exchange-Request / Capabilities-Exchange-Answer）に含まれる情報を完全には保護しないため、特定のセキュリティリスクを生み出すと一般に考えられています。 Diameterのこのバージョンは、ピアがTLS / TCPおよびDTLS / SCTPを介して通信するときに使用する必要がある既知の保護されたポートを定義する一般的なアプローチを採用しています。この新しいアプローチは、既存のインバンドセキュリティネゴシエーションを強化しますが、完全に置き換えるわけではありません。古いメソッドは、下位互換性のために残されています。
o Deprecated the exchange of CER/CEA messages in the open state. This feature was implied in the peer state machine table of RFC 3588, but it was not clearly defined anywhere else in that document. As work on this document progressed, it became clear that the multiplicity of meaning and use of Application-Id AVPs in the CER/CEA messages (and the messages themselves) is seen as an abuse of the Diameter extensibility rules and thus required simplification. Capabilities exchange in the open state has been re-introduced in a separate specification [RFC6737], which clearly defines new commands for this feature.
o オープン状態でのCER / CEAメッセージの交換を非推奨にしました。この機能はRFC 3588のピアステートマシンテーブルに含まれていましたが、そのドキュメントの他の場所では明確に定義されていません。このドキュメントの作業が進むにつれて、CER / CEAメッセージ（およびメッセージ自体）でのApplication-Id AVPの多様性と使用が、Diameter拡張ルールの乱用と見なされ、簡略化が必要であることが明らかになりました。オープン状態での機能交換は、この機能の新しいコマンドを明確に定義する別の仕様[RFC6737]で再導入されました。
o Simplified security requirements. The use of a secured transport for exchanging Diameter messages remains mandatory. However, TLS/ TCP and DTLS/SCTP have become the primary methods of securing Diameter with IPsec as a secondary alternative. See Section 13 for details. The support for the End-to-End security framework (E2E-Sequence AVP and 'P'-bit in the AVP header) has also been deprecated.
o 簡素化されたセキュリティ要件。 Diameterメッセージを交換するためのセキュアなトランスポートの使用は、引き続き必須です。ただし、TLS / TCPおよびDTLS / SCTPは、二次的な代替手段としてIPsecでDiameterを保護する主要な方法になっています。詳細については、セクション13を参照してください。エンドツーエンドのセキュリティフレームワーク（E2E-Sequence AVPおよびAVPヘッダーの「P」ビット）のサポートも廃止されました。
o Changed Diameter extensibility. This includes fixes to the Diameter extensibility description (Section 1.3 and others) to better aid Diameter application designers; in addition, the new specification relaxes the policy with respect to the allocation of Command Codes for vendor-specific uses.
o Diameterの拡張性が変更されました。これには、Diameterアプリケーションの設計者を支援するためのDiameter拡張性の説明（セクション1.3など）の修正が含まれます。さらに、新しい仕様では、ベンダー固有の使用のためのコマンドコードの割り当てに関するポリシーが緩和されています。
o Clarified Application Id usage. Clarify the proper use of Application Id information, which can be found in multiple places within a Diameter message. This includes correlating Application Ids found in the message headers and AVPs. These changes also clearly specify the proper Application Id value to use for specific base protocol messages (ASR/ASA, STR/STA) as well as clarify the content and use of Vendor-Specific-Application-Id.
o アプリケーションIDの使用法を明確にしました。 Diameterメッセージ内の複数の場所にあるアプリケーションID情報の適切な使用を明確にします。これには、メッセージヘッダーとAVPで見つかったアプリケーションIDの関連付けが含まれます。これらの変更により、特定の基本プロトコルメッセージ（ASR / ASA、STR / STA）に使用する適切なアプリケーションID値が明確に指定され、ベンダー固有のアプリケーションIDの内容と使用が明確になります。
o Clarified routing fixes. This document more clearly specifies what information (AVPs and Application Ids) can be used for making general routing decisions. A rule for the prioritization of redirect routing criteria when multiple route entries are found via redirects has also been added (see Section 6.13).
o ルーティングの修正を明確にしました。このドキュメントでは、一般的なルーティングの決定に使用できる情報（AVPおよびアプリケーションID）をより明確に規定しています。リダイレクトを介して複数のルートエントリが見つかった場合のリダイレクトルーティング基準の優先順位付けのルールも追加されました（セクション6.13を参照）。
o Simplified Diameter peer discovery. The Diameter discovery process now supports only widely used discovery schemes; the rest have been deprecated (see Section 5.2 for details).
o 簡略化されたDiameterピアの検出。 Diameter検出プロセスは、広く使用されている検出スキームのみをサポートするようになりました。残りは廃止されました（詳細はセクション5.2を参照）。
There are many other miscellaneous fixes that have been introduced in this document that may not be considered significant, but they have value nonetheless. Examples are removal of obsolete types, fixes to the state machine, clarification of the election process, message validation, fixes to Failed-AVP and Result-Code AVP values, etc. All of the errata filed against RFC 3588 prior to the publication of this document have been addressed. A comprehensive list of changes is not shown here for practical reasons.
このドキュメントで紹介されている他の多くの修正には、重要とは見なされないものもありますが、それでも価値があります。例としては、廃止されたタイプの削除、状態マシンの修正、選出プロセスの明確化、メッセージ検証、Failed-AVPとResult-Code AVP値の修正などがあります。これが公開される前にRFC 3588に対して提出されたすべての正誤表ドキュメントが対処されました。変更の包括的なリストは、実際的な理由のため、ここでは示されていません。
AAA
AAA
Authentication, Authorization, and Accounting.
認証、承認、およびアカウンティング。
ABNF
ABNF
Augmented Backus-Naur Form [RFC5234]. A metalanguage with its own formal syntax and rules. It is based on the Backus-Naur Form and is used to define message exchanges in a bi-directional communications protocol.
拡張バッカスナウアフォーム[RFC5234]。独自の正式な構文とルールを持つメタ言語。これはBackus-Naurフォームに基づいており、双方向通信プロトコルでメッセージ交換を定義するために使用されます。
Accounting
経理
The act of collecting information on resource usage for the purpose of capacity planning, auditing, billing, or cost allocation.
キャパシティプランニング、監査、請求、またはコスト割り当てのために、リソース使用状況に関する情報を収集する行為。
Accounting Record
会計記録
An accounting record represents a summary of the resource consumption of a user over the entire session. Accounting servers creating the accounting record may do so by processing interim accounting events or accounting events from several devices serving the same user.
アカウンティングレコードは、セッション全体にわたるユーザーのリソース消費の概要を表します。アカウンティングレコードを作成するアカウンティングサーバーは、同じユーザーにサービスを提供している複数のデバイスからの中間アカウンティングイベントまたはアカウンティングイベントを処理することによって、そうすることができます。
Authentication
認証
The act of verifying the identity of an entity (subject).
エンティティ（サブジェクト）の身元を確認する行為。
Authorization
認可
The act of determining whether a requesting entity (subject) will be allowed access to a resource (object).
要求エンティティ（サブジェクト）がリソース（オブジェクト）へのアクセスを許可されるかどうかを決定する行為。
Attribute-Value Pair (AVP)
属性値ペア（AVP）
The Diameter protocol consists of a header followed by one or more Attribute-Value-Pairs (AVPs). An AVP includes a header and is used to encapsulate protocol-specific data (e.g., routing information) as well as authentication, authorization, or accounting information.
Diameterプロトコルは、ヘッダーとそれに続く1つ以上の属性値ペア（AVP）で構成されます。 AVPにはヘッダーが含まれており、プロトコル固有のデータ（ルーティング情報など）だけでなく、認証、承認、またはアカウンティング情報をカプセル化するために使用されます。
Command Code Format (CCF)
コマンドコードフォーマット（CCF）
A modified form of ABNF used to define Diameter commands (see Section 3.2).
Diameterコマンドの定義に使用されるABNFの変更された形式（セクション3.2を参照）。
Diameter Agent
直径エージェント
A Diameter Agent is a Diameter node that provides relay, proxy, redirect, or translation services.
Diameterエージェントは、リレー、プロキシ、リダイレクト、または変換サービスを提供するDiameterノードです。
Diameter Client
Diameterクライアント
A Diameter client is a Diameter node that supports Diameter client applications as well as the base protocol. Diameter clients are often implemented in devices situated at the edge of a network and provide access control services for that network. Typical examples of Diameter clients include the Network Access Server (NAS) and the Mobile IP Foreign Agent (FA).
Diameterクライアントは、Diameterクライアントアプリケーションと基本プロトコルをサポートするDiameterノードです。 Diameterクライアントは、多くの場合、ネットワークのエッジにあるデバイスに実装され、そのネットワークにアクセス制御サービスを提供します。 Diameterクライアントの一般的な例には、ネットワークアクセスサーバー（NAS）やモバイルIPフォーリンエージェント（FA）などがあります。
Diameter Node
ぢあめてｒ ので
A Diameter node is a host process that implements the Diameter protocol and acts as either a client, an agent, or a server.
Diameterノードは、Diameterプロトコルを実装するホストプロセスであり、クライアント、エージェント、またはサーバーとして機能します。
Diameter Peer
直径ピア
Two Diameter nodes sharing a direct TCP or SCTP transport connection are called Diameter peers.
直接TCPまたはSCTPトランスポート接続を共有する2つのDiameterノードは、Diameterピアと呼ばれます。
Diameter Server
Diameterサーバー
A Diameter server is a Diameter node that handles authentication, authorization, and accounting requests for a particular realm. By its very nature, a Diameter server must support Diameter server applications in addition to the base protocol.
Diameterサーバーは、特定のレルムの認証、承認、およびアカウンティング要求を処理するDiameterノードです。その性質上、Diameterサーバーは、基本プロトコルに加えてDiameterサーバーアプリケーションをサポートする必要があります。
Downstream
下流
Downstream is used to identify the direction of a particular Diameter message from the home server towards the Diameter client.
ダウンストリームは、特定のDiameterメッセージのホームサーバーからDiameterクライアントへの方向を識別するために使用されます。
Home Realm
ホームレルム
A Home Realm is the administrative domain with which the user maintains an account relationship.
ホームレルムは、ユーザーがアカウント関係を維持するための管理ドメインです。
Home Server
ホームサーバー
A Diameter server that serves the Home Realm.
ホームレルムを提供するDiameterサーバー。
Interim Accounting
中間会計
An interim accounting message provides a snapshot of usage during a user's session. Typically, it is implemented in order to provide for partial accounting of a user's session in case a device reboot or other network problem prevents the delivery of a session summary message or session record.
中間アカウンティングメッセージは、ユーザーのセッション中の使用状況のスナップショットを提供します。通常、デバイスの再起動またはその他のネットワークの問題によりセッションサマリーメッセージまたはセッションレコードの配信が妨げられた場合に、ユーザーのセッションの部分的なアカウンティングを提供するために実装されます。
Local Realm
ローカルレルム
A local realm is the administrative domain providing services to a user. An administrative domain may act as a local realm for certain users while being a home realm for others.
ローカルレルムは、ユーザーにサービスを提供する管理ドメインです。管理ドメインは、他のユーザーのホームレルムでありながら、特定のユーザーのローカルレルムとして機能する場合があります。
Multi-session
マルチセッション
A multi-session represents a logical linking of several sessions. Multi-sessions are tracked by using the Acct-Multi-Session-Id. An example of a multi-session would be a Multi-link PPP bundle. Each leg of the bundle would be a session while the entire bundle would be a multi-session.
マルチセッションは、いくつかのセッションの論理的なリンクを表します。マルチセッションは、Acct-Multi-Session-Idを使用して追跡されます。マルチセッションの例は、マルチリンクPPPバンドルです。バンドルの各レッグはセッションであり、バンドル全体はマルチセッションです。
Network Access Identifier
ネットワークアクセス識別子
The Network Access Identifier, or NAI [RFC4282], is used in the Diameter protocol to extract a user's identity and realm. The identity is used to identify the user during authentication and/or authorization while the realm is used for message routing purposes.
ネットワークアクセス識別子（NAI [RFC4282]）は、DiameterプロトコルでユーザーのIDと領域を抽出するために使用されます。 IDは、認証や許可の際にユーザーを識別するために使用され、レルムはメッセージルーティングの目的で使用されます。
Proxy Agent or Proxy
プロキシエージェントまたはプロキシ
In addition to forwarding requests and responses, proxies make policy decisions relating to resource usage and provisioning. Typically, this is accomplished by tracking the state of NAS devices. While proxies usually do not respond to client requests prior to receiving a response from the server, they may originate Reject messages in cases where policies are violated. As a result, proxies need to understand the semantics of the messages passing through them, and they may not support all Diameter applications.
リクエストとレスポンスの転送に加えて、プロキシはリソースの使用とプロビジョニングに関連するポリシー決定を行います。通常、これはNASデバイスの状態を追跡することによって行われます。プロキシは通常、サーバーからの応答を受信する前にクライアントの要求に応答しませんが、ポリシーに違反している場合は拒否メッセージを発信することがあります。その結果、プロキシはメッセージを通過するメッセージのセマンティクスを理解する必要があり、すべてのDiameterアプリケーションをサポートするわけではありません。
Realm
レルム
The string in the NAI that immediately follows the '@' character. NAI realm names are required to be unique and are piggybacked on the administration of the DNS namespace. Diameter makes use of the realm, also loosely referred to as domain, to determine whether messages can be satisfied locally or whether they must be routed or redirected. In RADIUS, realm names are not necessarily piggybacked on the DNS namespace but may be independent of it.
「@」文字の直後に続くNAIの文字列。 NAIレルム名は一意である必要があり、DNS名前空間の管理に便乗します。 Diameterは、ドメインとも呼ばれるレルムを使用して、メッセージをローカルで満たすことができるかどうか、またはメッセージをルーティングまたはリダイレクトする必要があるかどうかを決定します。 RADIUSでは、レルム名は必ずしもDNSネームスペースに便乗しているわけではありませんが、DNSネームスペースから独立している場合があります。
Real-Time Accounting
リアルタイム会計
Real-time accounting involves the processing of information on resource usage within a defined time window. Typically, time constraints are imposed in order to limit financial risk. The Diameter Credit-Control Application [RFC4006] is an example of an application that defines real-time accounting functionality.
リアルタイムアカウンティングには、定義された時間枠内のリソース使用量に関する情報の処理が含まれます。通常、財務上のリスクを制限するために時間的な制約が課されます。 Diameter Credit-Controlアプリケーション[RFC4006]は、リアルタイムのアカウンティング機能を定義するアプリケーションの例です。
Relay Agent or Relay
リレーエージェントまたはリレー
Relays forward requests and responses based on routing-related AVPs and routing table entries. Since relays do not make policy decisions, they do not examine or alter non-routing AVPs. As a result, relays never originate messages, do not need to understand the semantics of messages or non-routing AVPs, and are capable of handling any Diameter application or message type. Since relays make decisions based on information in routing AVPs and realm forwarding tables, they do not keep state on NAS resource usage or sessions in progress.
リレーは、ルーティング関連のAVPとルーティングテーブルエントリに基づいて要求と応答を転送します。リレーはポリシー決定を行わないため、非ルーティングAVPを検査または変更しません。その結果、リレーはメッセージを発信することはなく、メッセージまたは非ルーティングAVPのセマンティクスを理解する必要がなく、Diameterアプリケーションまたはメッセージタイプを処理できます。リレーは、ルーティングAVPとレルム転送テーブルの情報に基づいて決定を行うため、NASリソースの使用状況や進行中のセッションの状態は保持されません。
Redirect Agent
リダイレクトエージェント
Rather than forwarding requests and responses between clients and servers, redirect agents refer clients to servers and allow them to communicate directly. Since redirect agents do not sit in the forwarding path, they do not alter any AVPs transiting between client and server. Redirect agents do not originate messages and are capable of handling any message type, although they may be configured only to redirect messages of certain types, while acting as relay or proxy agents for other types. As with relay agents, redirect agents do not keep state with respect to sessions or NAS resources.
リダイレクトエージェントは、クライアントとサーバー間で要求と応答を転送するのではなく、クライアントをサーバーに参照させ、直接通信できるようにします。リダイレクトエージェントは転送パスに存在しないため、クライアントとサーバー間を通過するAVPは変更されません。リダイレクトエージェントはメッセージを生成せず、任意のメッセージタイプを処理できますが、他のタイプのリレーエージェントまたはプロキシエージェントとして機能する一方で、特定のタイプのメッセージをリダイレクトするようにのみ設定できます。リレーエージェントと同様に、リダイレクトエージェントはセッションやNASリソースに関して状態を保持しません。
Session
セッション
A session is a related progression of events devoted to a particular activity. Diameter application documents provide guidelines as to when a session begins and ends. All Diameter packets with the same Session-Id are considered to be part of the same session.
セッションは、特定のアクティビティに特化したイベントの関連する進行です。 Diameterアプリケーションドキュメントは、セッションの開始と終了に関するガイドラインを提供します。同じセッションIDを持つすべてのDiameterパケットは、同じセッションの一部と見なされます。
Stateful Agent
ステートフルエージェント
A stateful agent is one that maintains session state information, by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered active either until it is notified otherwise or until expiration.
ステートフルエージェントは、承認されたすべてのアクティブセッションを追跡することにより、セッション状態情報を維持するエージェントです。承認された各セッションは特定のサービスにバインドされており、その状態は、他の方法で通知されるまで、または有効期限が切れるまでアクティブと見なされます。
Sub-session
サブセッション
A sub-session represents a distinct service (e.g., QoS or data characteristics) provided to a given session. These services may happen concurrently (e.g., simultaneous voice and data transfer during the same session) or serially. These changes in sessions are tracked with the Accounting-Sub-Session-Id.
サブセッションは、特定のセッションに提供される個別のサービス（QoSやデータの特性など）を表します。これらのサービスは、並行して（たとえば、同じセッション中に音声とデータの同時転送）または連続して発生する可能性があります。セッションのこれらの変更は、Accounting-Sub-Session-Idで追跡されます。
Transaction State
トランザクション状態
The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, the Hop-by-Hop Identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state.
Diameterプロトコルでは、エージェントがフェイルオーバーの目的で使用されるトランザクション状態を維持する必要があります。トランザクション状態は、要求を転送するとホップバイホップ識別子が保存されることを意味します。フィールドはローカルで一意の識別子に置き換えられ、対応する回答を受信すると元の値に復元されます。リクエストの状態は、回答を受け取ると解放されます。ステートレスエージェントは、トランザクション状態のみを維持するエージェントです。
Translation Agent
翻訳エージェント
A translation agent (TLA in Figure 4) is a stateful Diameter node that performs protocol translation between Diameter and another AAA protocol, such as RADIUS.
変換エージェント（図4のTLA）は、DiameterとRADIUSなどの別のAAAプロトコルとの間のプロトコル変換を実行するステートフルDiameterノードです。
Upstream
上流の
Upstream is used to identify the direction of a particular Diameter message from the Diameter client towards the home server.
アップストリームは、Diameterクライアントからホームサーバーへの特定のDiameterメッセージの方向を識別するために使用されます。
User
ユーザー
The entity or device requesting or using some resource, in support of which a Diameter client has generated a request.
Diameterクライアントがリクエストを生成したことをサポートするリソースをリクエストまたは使用しているエンティティまたはデバイス。
The Diameter protocol is designed to be extensible, using several mechanisms, including:
Diameterプロトコルは、以下を含むいくつかのメカニズムを使用して、拡張できるように設計されています。
o Defining new AVP values
o 新しいAVP値の定義
o Creating new AVPs
o 新しいAVPの作成
o Creating new commands
o 新しいコマンドを作成する
o Creating new applications From the point of view of extensibility, Diameter authentication, authorization, and accounting applications are treated in the same way.
o新しいアプリケーションの作成拡張性の観点から、Diameterの認証、承認、およびアカウンティングアプリケーションは同じ方法で処理されます。
Note: Protocol designers should try to reuse existing functionality, namely AVP values, AVPs, commands, and Diameter applications. Reuse simplifies standardization and implementation. To avoid potential interoperability issues, it is important to ensure that the semantics of the reused features are well understood. Given that Diameter can also carry RADIUS attributes as Diameter AVPs, such reuse considerations also apply to existing RADIUS attributes that may be useful in a Diameter application.
注：プロトコル設計者は、AVP値、AVP、コマンド、Diameterアプリケーションなどの既存の機能を再利用する必要があります。再利用により、標準化と実装が簡素化されます。潜在的な相互運用性の問題を回避するには、再利用される機能のセマンティクスが十分に理解されていることを確認することが重要です。 DiameterはRADIUS属性をDiameter AVPとしても伝送できるため、このような再利用に関する考慮事項は、Diameterアプリケーションで役立つ可能性がある既存のRADIUS属性にも適用されます。
In order to allocate a new AVP value for AVPs defined in the Diameter base protocol, the IETF needs to approve a new RFC that describes the AVP value. IANA considerations for these AVP values are discussed in Section 11.3.
Diameter基本プロトコルで定義されたAVPに新しいAVP値を割り当てるために、IETFはAVP値を説明する新しいRFCを承認する必要があります。これらのAVP値に関するIANAの考慮事項については、セクション11.3で説明します。
The allocation of AVP values for other AVPs is guided by the IANA considerations of the document that defines those AVPs. Typically, allocation of new values for an AVP defined in an RFC would require IETF Review [RFC5226], whereas values for vendor-specific AVPs can be allocated by the vendor.
他のAVPに対するAVP値の割り当ては、それらのAVPを定義するドキュメントのIANAの考慮事項によって導かれます。通常、RFCで定義されたAVPの新しい値の割り当てにはIETFレビュー[RFC5226]が必要ですが、ベンダー固有のAVPの値はベンダーが割り当てることができます。
A new AVP being defined MUST use one of the data types listed in Sections 4.2 or 4.3. If an appropriate derived data type is already defined, it SHOULD be used instead of a base data type to encourage reusability and good design practice.
定義される新しいAVPは、セクション4.2または4.3にリストされているデータ型のいずれかを使用する必要があります。適切な派生データ型が既に定義されている場合は、再利用性と優れた設計手法を促進するために、基本データ型の代わりにそれを使用する必要があります（SHOULD）。
In the event that a logical grouping of AVPs is necessary, and multiple "groups" are possible in a given command, it is recommended that a Grouped AVP be used (see Section 4.4).
AVPの論理グループ化が必要で、特定のコマンドで複数の「グループ」が可能である場合は、グループ化されたAVPを使用することをお勧めします（セクション4.4を参照）。
The creation of new AVPs can happen in various ways. The recommended approach is to define a new general-purpose AVP in a Standards Track RFC approved by the IETF. However, as described in Section 11.1.1, there are other mechanisms.
新しいAVPの作成は、さまざまな方法で行われます。推奨されるアプローチは、IETFによって承認されたStandards Track RFCで新しい汎用AVPを定義することです。ただし、セクション11.1.1で説明されているように、他のメカニズムがあります。
A new Command Code MUST be allocated when required AVPs (those indicated as {AVP} in the CCF definition) are added to, deleted from, or redefined in (for example, by changing a required AVP into an optional one) an existing command.
必要なAVP（CCF定義で{AVP}と示されているもの）が既存のコマンドに追加、削除、または再定義された場合（たとえば、必要なAVPをオプションのAVPに変更することにより）、新しいコマンドコードを割り当てる必要があります。
Furthermore, if the transport characteristics of a command are changed (for example, with respect to the number of round trips required), a new Command Code MUST be registered.
さらに、コマンドの転送特性が変更された場合（たとえば、必要なラウンドトリップの数に関して）、新しいコマンドコードを登録する必要があります。
A change to the CCF of a command, such as described above, MUST result in the definition of a new Command Code. This subsequently leads to the need to define a new Diameter application for any application that will use that new command.
上記のように、コマンドのCCFを変更すると、新しいコマンドコードが定義される必要があります。これにより、その新しいコマンドを使用するすべてのアプリケーションに対して、新しいDiameterアプリケーションを定義する必要が生じます。
The IANA considerations for Command Codes are discussed in Section 3.1.
コマンドコードに関するIANAの考慮事項については、セクション3.1で説明します。
Every Diameter application specification MUST have an IANA-assigned Application Id (see Section 2.4). The managed Application ID space is flat, and there is no relationship between different Diameter applications with respect to their Application Ids. As such, there is no versioning support provided by these Application Ids themselves; every Diameter application is a standalone application. If the application has a relationship with other Diameter applications, such a relationship is not known to Diameter.
すべてのDiameterアプリケーション仕様には、IANAによって割り当てられたアプリケーションIDが必要です（セクション2.4を参照）。管理対象のアプリケーションIDスペースはフラットであり、アプリケーションIDに関して異なるDiameterアプリケーション間に関係はありません。そのため、これらのアプリケーションID自体によって提供されるバージョン管理のサポートはありません。すべてのDiameterアプリケーションはスタンドアロンアプリケーションです。アプリケーションに他のDiameterアプリケーションとの関係がある場合、そのような関係はDiameterにはわかりません。
Before describing the rules for creating new Diameter applications, it is important to discuss the semantics of the AVP occurrences as stated in the CCF and the M-bit flag (Section 4.1) for an AVP. There is no relationship imposed between the two; they are set independently.
新しいDiameterアプリケーションを作成するためのルールを説明する前に、CCFおよびAVPのMビットフラグ（セクション4.1）に記載されているAVPオカレンスのセマンティクスについて説明することが重要です。 2つの間に課される関係はありません。それらは独立して設定されます。
o The CCF indicates what AVPs are placed into a Diameter command by the sender of that command. Often, since there are multiple modes of protocol interactions, many of the AVPs are indicated as optional.
o CCFは、そのコマンドの送信者によってDiameterコマンドに配置されるAVPを示します。多くの場合、プロトコルの相互作用には複数のモードがあるため、AVPの多くはオプションとして示されます。
o The M-bit allows the sender to indicate to the receiver whether or not understanding the semantics of an AVP and its content is mandatory. If the M-bit is set by the sender and the receiver does not understand the AVP or the values carried within that AVP, then a failure is generated (see Section 7).
o Mビットにより、AVPのセマンティクスとその内容の理解が必須かどうかを送信者が受信者に示すことができます。 Mビットが送信側によって設定され、受信側がAVPまたはそのAVP内で伝送される値を理解できない場合、障害が生成されます（セクション7を参照）。
It is the decision of the protocol designer when to develop a new Diameter application rather than extending Diameter in other ways. However, a new Diameter application MUST be created when one or more of the following criteria are met: M-bit Setting
Diameterを他の方法で拡張するのではなく、新しいDiameterアプリケーションをいつ開発するかは、プロトコル設計者の決定です。ただし、次の基準の1つ以上が満たされた場合、新しいDiameterアプリケーションを作成する必要があります。Mビット設定
An AVP with the M-bit in the MUST column of the AVP flag table is added to an existing Command/Application. An AVP with the M-bit in the MAY column of the AVP flag table is added to an existing Command/Application.
AVPフラグテーブルのMUST列にMビットを持つAVPが既存のコマンド/アプリケーションに追加されます。 AVPフラグテーブルのMAY列にMビットを持つAVPが、既存のコマンド/アプリケーションに追加されます。
Note: The M-bit setting for a given AVP is relevant to an Application and each command within that application that includes the AVP. That is, if an AVP appears in two commands for application Foo and the M-bit settings are different in each command, then there should be two AVP flag tables describing when to set the M-bit.
注：特定のAVPのMビット設定は、アプリケーションと、AVPを含むそのアプリケーション内の各コマンドに関連しています。つまり、アプリケーションFooの2つのコマンドにAVPが表示され、Mビット設定が各コマンドで異なる場合、Mビットを設定するタイミングを説明する2つのAVPフラグテーブルが必要です。
Commands
コマンド
A new command is used within the existing application because either an additional command is added, an existing command has been modified so that a new Command Code had to be registered, or a command has been deleted.
追加のコマンドが追加されるか、既存のコマンドが変更されて新しいコマンドコードを登録する必要があるか、またはコマンドが削除されたため、既存のアプリケーション内で新しいコマンドが使用されています。
AVP Flag bits
AVPフラグビット
If an existing application changes the meaning/semantics of its AVP Flags or adds new flag bits, then a new Diameter application MUST be created.
既存のアプリケーションがAVPフラグの意味/セマンティクスを変更するか、新しいフラグビットを追加する場合、新しいDiameterアプリケーションを作成する必要があります。
If the CCF definition of a command allows it, an implementation may add arbitrary optional AVPs with the M-bit cleared (including vendor-specific AVPs) to that command without needing to define a new application. Please refer to Section 11.1.1 for details.
コマンドのCCF定義で許可されている場合、実装は、Mビットがクリアされた任意のオプションのAVP（ベンダー固有のAVPを含む）をそのコマンドに追加できます。新しいアプリケーションを定義する必要はありません。詳細については、セクション11.1.1を参照してください。
The base Diameter protocol concerns itself with establishing connections to peers, capabilities negotiation, how messages are sent and routed through peers, and how the connections are eventually torn down. The base protocol also defines certain rules that apply to all message exchanges between Diameter nodes.
基本Diameterプロトコルは、ピアへの接続の確立、機能のネゴシエーション、メッセージがピアを介して送信およびルーティングされる方法、および接続が最終的に切断される方法に関係しています。基本プロトコルは、Diameterノード間のすべてのメッセージ交換に適用される特定のルールも定義します。
Communication between Diameter peers begins with one peer sending a message to another Diameter peer. The set of AVPs included in the message is determined by a particular Diameter application. One AVP that is included to reference a user's session is the Session-Id.
Diameterピア間の通信は、あるピアが別のDiameterピアにメッセージを送信することから始まります。メッセージに含まれるAVPのセットは、特定のDiameterアプリケーションによって決定されます。ユーザーのセッションを参照するために含まれている1つのAVPは、Session-Idです。
The initial request for authentication and/or authorization of a user would include the Session-Id AVP. The Session-Id is then used in all subsequent messages to identify the user's session (see Section 8 for
ユーザーの認証または承認、あるいはその両方の最初の要求には、Session-Id AVPが含まれます。その後、Session-Idは後続のすべてのメッセージで使用され、ユーザーのセッションを識別します（セクション8
more information). The communicating party may accept the request or reject it by returning an answer message with the Result-Code AVP set to indicate that an error occurred. The specific behavior of the Diameter server or client receiving a request depends on the Diameter application employed.
詳しくは）。通信側は、エラーが発生したことを示すためにResult-Code AVPが設定された応答メッセージを返すことにより、要求を受け入れるか拒否することができます。リクエストを受信するDiameterサーバーまたはクライアントの特定の動作は、採用されているDiameterアプリケーションによって異なります。
Session state (associated with a Session-Id) MUST be freed upon receipt of the Session-Termination-Request, Session-Termination-Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular Diameter application.
（Session-Idに関連付けられた）セッション状態は、Session-Termination-Request、Session-Termination-Answer、Session-Timeout AVPでの承認されたサービス時間の満了時に、特定のDiameterで確立されたルールに従って解放する必要があります応用。
The base Diameter protocol may be used by itself for accounting applications. For authentication and authorization, it is always extended for a particular application.
基本のDiameterプロトコルは、それ自体で会計アプリケーションに使用できます。認証と承認のために、それは常に特定のアプリケーションのために拡張されます。
Diameter clients MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement the client's service, e.g., Network Access Server Requirements (NASREQ) [RFC2881] and/or Mobile IPv4. A Diameter client MUST be referred to as "Diameter X Client" where X is the application that it supports and not a "Diameter Client".
Diameterクライアントは、アカウンティングを含む基本プロトコルをサポートする必要があります。さらに、ネットワークアクセスサーバー要件（NASREQ）[RFC2881]やモバイルIPv4など、クライアントのサービスを実装するために必要な各Diameterアプリケーションを完全にサポートする必要があります。 Diameterクライアントは、「Diameter Xクライアント」として参照する必要があります。ここで、Xは、サポートするアプリケーションであり、「Diameterクライアント」ではありません。
Diameter servers MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement the intended service, e.g., NASREQ and/or Mobile IPv4. A Diameter server MUST be referred to as "Diameter X Server" where X is the application that it supports, and not a "Diameter Server".
Diameterサーバーは、アカウンティングを含む基本プロトコルをサポートする必要があります。さらに、NASREQやモバイルIPv4などの目的のサービスを実装するために必要な各Diameterアプリケーションを完全にサポートする必要があります。 Diameterサーバーは、「Diameter Xサーバー」として参照する必要があります。Xは、Diameterサーバーではなく、サポートするアプリケーションです。
Diameter relays and redirect agents are transparent to the Diameter applications, but they MUST support the Diameter base protocol, which includes accounting, and all Diameter applications.
Diameterリレーとリダイレクトエージェントは、Diameterアプリケーションに対して透過的ですが、アカウンティングを含むDiameter基本プロトコルとすべてのDiameterアプリケーションをサポートする必要があります。
Diameter proxies MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement proxied services, e.g., NASREQ and/or Mobile IPv4. A Diameter proxy MUST be referred to as "Diameter X Proxy" where X is the application which it supports, and not a "Diameter Proxy".
Diameterプロキシは、アカウンティングを含む基本プロトコルをサポートする必要があります。さらに、NASREQやモバイルIPv4などのプロキシサービスの実装に必要な各Diameterアプリケーションを完全にサポートする必要があります。 Diameterプロキシは、「Diameter Xプロキシ」として参照する必要があります。Xは、サポートするアプリケーションであり、「Diameterプロキシ」ではありません。
The Diameter Transport profile is defined in [RFC3539].
Diameter Transportプロファイルは[RFC3539]で定義されています。
The base Diameter protocol is run on port 3868 for both TCP [RFC0793] and SCTP [RFC4960]. For TLS [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347], a Diameter node that initiates a connection prior to any message exchanges MUST run on port 5658. It is assumed that TLS is run on top of TCP when it is used, and DTLS is run on top of SCTP when it is used.
基本Diameterプロトコルは、TCP [RFC0793]とSCTP [RFC4960]の両方でポート3868で実行されます。 TLS [RFC5246]およびデータグラムトランスポート層セキュリティ（DTLS）[RFC6347]の場合、メッセージ交換の前に接続を開始するDiameterノードは、ポート5658で実行する必要があります。TLSは、TCPの上で実行されると想定されます。 、およびDTLSは、使用時にSCTPの上で実行されます。
If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP connections on port 5658 (i.e., the peer complies only with RFC 3588), then the initiator MAY revert to using TCP or SCTP on port 3868. Note that this scheme is kept only for the purpose of backward compatibility and that there are inherent security vulnerabilities when the initial CER/CEA messages are sent unprotected (see Section 5.6).
Diameterピアがポート5658でのTLS / TCPおよびDTLS / SCTP接続の受信をサポートしていない場合（つまり、ピアがRFC 3588にのみ準拠している場合）、イニシエーターはポート3868でTCPまたはSCTPを使用するように戻すことができます。このスキームは下位互換性の目的でのみ保持され、最初のCER / CEAメッセージが保護されずに送信される場合、固有のセキュリティ脆弱性があります（セクション5.6を参照）。
Diameter clients MUST support either TCP or SCTP; agents and servers SHOULD support both.
DiameterクライアントはTCPまたはSCTPをサポートする必要があります。エージェントとサーバーは両方をサポートする必要があります。
A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and it MUST always be prepared to receive connections on port 3868 for TCP or SCTP and port 5658 for TLS/TCP and DTLS/SCTP connections. When DNS-based peer discovery (Section 5.2) is used, the port numbers received from SRV records take precedence over the default ports (3868 and 5658).
Diameterノードは、着信接続の受け入れを宣言したソースポート以外のソースポートから接続を開始する場合があり、TCPまたはSCTPの場合はポート3868、TLS / TCPおよびDTLS / SCTPの場合はポート5658で接続を受信できるように常に準備しておく必要があります。接続。 DNSベースのピア検出（セクション5.2）を使用する場合、SRVレコードから受信したポート番号は、デフォルトのポート（3868および5658）よりも優先されます。
A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer, in which, case a separate connection per process is allowed.
ピアに複数のインスタンスが存在しない場合を除き、ピアステートマシンの特定のDiameterインスタンスは、特定のピアとの通信に複数のトランスポート接続を使用してはなりません。この場合、プロセスごとに個別の接続が許可されます。
When no transport connection exists with a peer, an attempt to connect SHOULD be made periodically. This behavior is handled via the Tc timer (see Section 12 for details), whose recommended value is 30 seconds. There are certain exceptions to this rule, such as when a peer has terminated the transport connection stating that it does not wish to communicate.
ピアとのトランスポート接続が存在しない場合、接続の試行は定期的に行われる必要があります（SHOULD）。この動作は、推奨値が30秒のTcタイマー（詳細はセクション12を参照）を介して処理されます。このルールには特定の例外があります。たとえば、通信したくないとピアがトランスポート接続を終了した場合などです。
When connecting to a peer and either zero or more transports are specified, TLS SHOULD be tried first, followed by DTLS, then by TCP, and finally by SCTP. See Section 5.2 for more information on peer discovery.
ピアに接続し、0個以上のトランスポートが指定されている場合は、最初にTLSを試し、次にDTLS、次にTCP、最後にSCTPを試す必要があります。ピア検出の詳細については、セクション5.2を参照してください。
Diameter implementations SHOULD be able to interpret ICMP protocol port unreachable messages as explicit indications that the server is not reachable, subject to security policy on trusting such messages. Further guidance regarding the treatment of ICMP errors can be found in [RFC5927] and [RFC5461]. Diameter implementations SHOULD also be able to interpret a reset from the transport and timed-out connection attempts. If Diameter receives data from the lower layer that cannot be parsed or identified as a Diameter error made by the peer, the stream is compromised and cannot be recovered. The transport connection MUST be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT message (graceful closure is compromised).
Diameter実装は、ICMPプロトコルポート到達不能メッセージを、そのようなメッセージを信頼することに関するセキュリティポリシーに従って、サーバーに到達できないことを明示的に示すものとして解釈できる必要があります（SHOULD）。 ICMPエラーの処理に関する詳細なガイダンスは、[RFC5927]と[RFC5461]にあります。 Diameter実装は、トランスポートからのリセットおよびタイムアウトした接続試行を解釈できる必要もあります（SHOULD）。 Diameterが下位層からデータを受信した場合、ピアが作成したDiameterエラーとして解析または識別できない場合、ストリームは危険にさらされており、回復できません。トランスポート接続は、RESET呼び出し（TCP RSTビットを送信）またはSCTP ABORTメッセージ（正常なクローズが損なわれる）を使用してクローズする必要があります。
Diameter messages SHOULD be mapped into SCTP streams in a way that avoids head-of-the-line (HOL) blocking. Among different ways of performing the mapping that fulfill this requirement it is RECOMMENDED that a Diameter node send every Diameter message (request or response) over stream zero with the unordered flag set. However, Diameter nodes MAY select and implement other design alternatives for avoiding HOL blocking such as using multiple streams with the unordered flag cleared (as originally instructed in RFC 3588). On the receiving side, a Diameter entity MUST be ready to receive Diameter messages over any stream, and it is free to return responses over a different stream. This way, both sides manage the available streams in the sending direction, independently of the streams chosen by the other side to send a particular Diameter message. These messages can be out-of-order and belong to different Diameter sessions.
Diameterメッセージは、ヘッドオブザライン（HOL）ブロッキングを回避する方法でSCTPストリームにマップする必要があります（SHOULD）。この要件を満たすマッピングを実行するさまざまな方法の中で、Diameterノードは、順序付けられていないフラグが設定されたストリーム0を介してすべてのDiameterメッセージ（要求または応答）を送信することをお勧めします。ただし、Diameterノードは、（RFC 3588で最初に指示されたように）順序付けされていないフラグがクリアされた複数のストリームを使用するなど、HOLブロッキングを回避する他の代替設計を選択および実装できます（MAY）。受信側では、Diameterエンティティは任意のストリームでDiameterメッセージを受信する準備ができていなければならず、別のストリームで自由に応答を返すことができます。このようにして、特定のDiameterメッセージを送信するために相手側が選択したストリームとは無関係に、送信側で利用可能なストリームを両側が管理します。これらのメッセージは順不同で、異なるDiameterセッションに属している可能性があります。
Out-of-order delivery has special concerns during a connection establishment and termination. When a connection is established, the responder side sends a CEA message and moves to R-Open state as specified in Section 5.6. If an application message is sent shortly after the CEA and delivered out-of-order, the initiator side, still in Wait-I-CEA state, will discard the application message and close the connection. In order to avoid this race condition, the receiver side SHOULD NOT use out-of-order delivery methods until the first message has been received from the initiator, proving that it has moved to I-Open state. To trigger such a message, the receiver side could send a DWR immediately after sending a CEA. Upon reception of the corresponding DWA, the receiver side should start using out-of-order delivery methods to counter the HOL blocking.
順不同配信は、接続の確立と終了時に特別な懸念があります。接続が確立されると、レスポンダー側はCEAメッセージを送信し、セクション5.6で指定されているR-Open状態に移行します。アプリケーションメッセージがCEAの直後に送信され、順序どおりに配信されない場合、イニシエーター側はまだWait-I-CEA状態であり、アプリケーションメッセージを破棄して接続を閉じます。この競合状態を回避するために、受信側は、最初のメッセージがイニシエーターから受信され、I-Open状態に移行したことを証明するまで、順不同の配信方法を使用してはなりません（SHOULD NOT）。このようなメッセージをトリガーするために、受信側はCEAを送信した直後にDWRを送信できます。対応するDWAを受信すると、受信側は、順序が正しくない配信方法を使用して、HOLブロッキングに対抗する必要があります。
Another race condition may occur when DPR and DPA messages are used. Both DPR and DPA are small in size; thus, they may be delivered to the peer faster than application messages when an out-of-order delivery mechanism is used. Therefore, it is possible that a DPR/DPA exchange completes while application messages are still in transit, resulting in a loss of these messages. An implementation could mitigate this race condition, for example, using timers, and wait for a short period of time for pending application level messages to arrive before proceeding to disconnect the transport connection. Eventually, lost messages are handled by the retransmission mechanism described in Section 5.5.4.
DPRおよびDPAメッセージを使用すると、別の競合状態が発生する可能性があります。 DPRとDPAはどちらもサイズが小さいです。したがって、順不同の配信メカニズムを使用すると、アプリケーションメッセージよりも速くピアに配信される可能性があります。したがって、アプリケーションメッセージがまだ転送中にDPR / DPA交換が完了し、これらのメッセージが失われる可能性があります。実装は、たとえばタイマーを使用してこの競合状態を緩和し、保留中のアプリケーションレベルのメッセージが到着するまでしばらく待ってから、トランスポート接続の切断に進むことができます。最終的に、失われたメッセージは、セクション5.5.4で説明されている再送信メカニズムによって処理されます。
A Diameter agent SHOULD use dedicated payload protocol identifiers (PPIDs) for clear text and encrypted SCTP DATA chunks instead of only using the unspecified payload protocol identifier (value 0). For this purpose, two PPID values are allocated: the PPID value 46 is for Diameter messages in clear text SCTP DATA chunks, and the PPID value 47 is for Diameter messages in protected DTLS/SCTP DATA chunks.
Diameterエージェントは、未指定のペイロードプロトコル識別子（値0）のみを使用する代わりに、クリアテキストと暗号化されたSCTP DATAチャンクに専用のペイロードプロトコル識別子（PPID）を使用する必要があります（SHOULD）。この目的のために、2つのPPID値が割り当てられます。PPID値46はクリアテキストSCTP DATAチャンクのDiameterメッセージ用であり、PPID値47は保護されたDTLS / SCTP DATAチャンクのDiameterメッセージ用です。
Connections between Diameter peers SHOULD be protected by TLS/TCP and DTLS/SCTP. All Diameter base protocol implementations MUST support the use of TLS/TCP and DTLS/SCTP. If desired, alternative security mechanisms that are independent of Diameter, such as IPsec [RFC4301], can be deployed to secure connections between peers. The Diameter protocol MUST NOT be used without one of TLS, DTLS, or IPsec.
Diameterピア間の接続は、TLS / TCPおよびDTLS / SCTPによって保護する必要があります（SHOULD）。すべてのDiameterベースプロトコルの実装は、TLS / TCPおよびDTLS / SCTPの使用をサポートする必要があります。必要に応じて、IPsec [RFC4301]などのDiameterに依存しない代替のセキュリティメカニズムを導入して、ピア間の接続を保護できます。 Diameterプロトコルは、TLS、DTLS、またはIPsecのいずれかなしで使用してはなりません（MUST NOT）。
Application Ids are advertised during the capabilities exchange phase (see Section 5.3). Advertising support of an application implies that the sender supports the functionality specified in the respective Diameter application specification.
アプリケーションIDは、機能交換フェーズ中に通知されます（セクション5.3を参照）。アプリケーションのアドバタイズサポートは、送信者がそれぞれのDiameterアプリケーション仕様で指定された機能をサポートすることを意味します。
Implementations MAY add arbitrary optional AVPs with the M-bit cleared (including vendor-specific AVPs) to a command defined in an application, but only if the command's CCF syntax specification allows for it. Please refer to Section 11.1.1 for details.
実装は、Mビットがクリアされた任意のオプションのAVP（ベンダー固有のAVPを含む）をアプリケーションで定義されたコマンドに追加できます（ただし、コマンドのCCF構文仕様で許可されている場合のみ）。詳細については、セクション11.1.1を参照してください。
Each Diameter application MUST have an IANA-assigned Application ID. The base protocol does not require an Application Id since its support is mandatory. During the capabilities exchange, Diameter nodes inform their peers of locally supported applications. Furthermore, all Diameter messages contain an Application Id, which is used in the message forwarding process.
各Diameterアプリケーションには、IANAによって割り当てられたアプリケーションIDが必要です。基本プロトコルはサポートが必須であるため、アプリケーションIDを必要としません。機能の交換中に、Diameterノードはローカルでサポートされているアプリケーションをピアに通知します。さらに、すべてのDiameterメッセージには、メッセージ転送プロセスで使用されるアプリケーションIDが含まれています。
The following Application Id values are defined:
次のアプリケーションID値が定義されています。
Diameter common message 0 Diameter base accounting 3 Relay 0xffffffff
Diameter共通メッセージ0 Diameterベースアカウンティング3リレー0xffffffff
Relay and redirect agents MUST advertise the Relay Application ID, while all other Diameter nodes MUST advertise locally supported applications. The receiver of a Capabilities Exchange message advertising relay service MUST assume that the sender supports all current and future applications.
リレーおよびリダイレクトエージェントは、リレーアプリケーションIDをアドバタイズする必要がありますが、他のすべてのDiameterノードは、ローカルでサポートされるアプリケーションをアドバタイズする必要があります。 Capabilities Exchangeメッセージアドバタイズリレーサービスの受信者は、送信者が現在および将来のすべてのアプリケーションをサポートしていると想定する必要があります。
Diameter relay and proxy agents are responsible for finding an upstream server that supports the application of a particular message. If none can be found, an error message is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
Diameterリレーおよびプロキシエージェントは、特定のメッセージのアプリケーションをサポートするアップストリームサーバーを見つける責任があります。何も見つからない場合は、Result-Code AVPがDIAMETER_UNABLE_TO_DELIVERに設定されたエラーメッセージが返されます。
This section attempts to provide the reader with an understanding of the difference between "connection" and "session", which are terms used extensively throughout this document.
このセクションは、「接続」と「セッション」の違いを読者に理解してもらうことを目的としています。これらは、このドキュメント全体で広く使用されている用語です。
A connection refers to a transport-level connection between two peers that is used to send and receive Diameter messages. A session is a logical concept at the application layer that exists between the Diameter client and the Diameter server; it is identified via the Session-Id AVP.
接続とは、Diameterメッセージの送受信に使用される2つのピア間のトランスポートレベルの接続を指します。セッションとは、DiameterクライアントとDiameterサーバーの間に存在するアプリケーション層の論理的な概念です。これは、Session-Id AVPを介して識別されます。
+--------+ +-------+ +--------+
| Client | | Relay | | Server |
+--------+ +-------+ +--------+
<----------> <---------->
peer connection A peer connection B
<----------------------------->
User session x
Figure 1: Diameter Connections and Sessions
図1：Diameter接続とセッション
In the example provided in Figure 1, peer connection A is established between the client and the relay. Peer connection B is established between the relay and the server. User session X spans from the client via the relay to the server. Each "user" of a service causes an auth request to be sent, with a unique session identifier. Once accepted by the server, both the client and the server are aware of the session.
図1の例では、クライアントとリレーの間にピア接続Aが確立されています。ピア接続Bがリレーとサーバー間で確立されます。ユーザーセッションXは、クライアントからリレーを経由してサーバーに及びます。サービスの「ユーザー」ごとに、一意のセッション識別子を使用して認証リクエストが送信されます。サーバーに受け入れられると、クライアントとサーバーの両方がセッションを認識します。
It is important to note that there is no relationship between a connection and a session, and that Diameter messages for multiple sessions are all multiplexed through a single connection. Also, note that Diameter messages pertaining to the session, both application-specific and those that are defined in this document such as ASR/ASA, RAR/RAA, and STR/STA, MUST carry the Application Id of the application. Diameter messages pertaining to peer connection establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA MUST carry an Application Id of zero (0).
接続とセッションの間に関係はなく、複数のセッションのDiameterメッセージはすべて単一の接続を介して多重化されることに注意することが重要です。また、セッションに関連するDiameterメッセージは、アプリケーション固有のものと、ASR / ASA、RAR / RAA、STR / STAなど、このドキュメントで定義されているものの両方で、アプリケーションのアプリケーションIDを伝える必要があります。 CER / CEA、DWR / DWA、DPR / DPAなどのピア接続の確立と保守に関連するDiameterメッセージは、アプリケーションIDがゼロ（0）である必要があります。
The Diameter peer table is used in message forwarding and is referenced by the routing table. A peer table entry contains the following fields:
Diameterピアテーブルはメッセージ転送で使用され、ルーティングテーブルによって参照されます。ピアテーブルエントリには、次のフィールドが含まれます。
Host Identity
ホストID
Following the conventions described for the DiameterIdentity-derived AVP data format in Section 4.3.1, this field contains the contents of the Origin-Host (Section 6.3) AVP found in the CER or CEA message.
セクション4.3.1のDiameterIdentity派生AVPデータ形式について説明した規則に従って、このフィールドには、CERまたはCEAメッセージにあるOrigin-Host（セクション6.3）AVPの内容が含まれます。
StatusT
StatusT
This is the state of the peer entry, and it MUST match one of the values listed in Section 5.6.
これはピアエントリの状態であり、セクション5.6にリストされている値のいずれかに一致する必要があります。
Static or Dynamic
静的または動的
Specifies whether a peer entry was statically configured or dynamically discovered.
ピアエントリが静的に構成されたか、動的に検出されたかを指定します。
Expiration Time
有効期限
Specifies the time at which dynamically discovered peer table entries are to be either refreshed or expired. If public key certificates are used for Diameter security (e.g., with TLS), this value MUST NOT be greater than the expiry times in the relevant certificates.
動的に検出されたピアテーブルエントリが更新または期限切れになる時刻を指定します。公開鍵証明書がDiameterのセキュリティ（TLSなど）に使用されている場合、この値は、関連する証明書の有効期限を超えてはなりません（MUST NOT）。
TLS/TCP and DTLS/SCTP Enabled
TLS / TCPおよびDTLS / SCTPが有効
Specifies whether TLS/TCP and DTLS/SCTP is to be used when communicating with the peer.
ピアとの通信時にTLS / TCPおよびDTLS / SCTPを使用するかどうかを指定します。
Additional security information, when needed (e.g., keys, certificates).
必要な場合の追加のセキュリティ情報（キー、証明書など）。
All Realm-Based routing lookups are performed against what is commonly known as the routing table (see Section 12). Each routing table entry contains the following fields:
すべてのレルムベースのルーティングルックアップは、一般にルーティングテーブルと呼ばれるものに対して実行されます（セクション12を参照）。各ルーティングテーブルエントリには、次のフィールドが含まれています。
Realm Name
レルム名
This is the field that MUST be used as a primary key in the routing table lookups. Note that some implementations perform their lookups based on longest-match-from-the-right on the realm rather than requiring an exact match.
これは、ルーティングテーブルのルックアップで主キーとして使用する必要があるフィールドです。一部の実装では、完全な一致を要求するのではなく、レルムでの最長一致に基づいてルックアップを実行することに注意してください。
Application Identifier
アプリケーション識別子
An application is identified by an Application Id. A route entry can have a different destination based on the Application Id in the message header. This field MUST be used as a secondary key field in routing table lookups.
アプリケーションはアプリケーションIDによって識別されます。ルートエントリは、メッセージヘッダーのアプリケーションIDに基づいて異なる宛先を持つことができます。このフィールドは、ルーティングテーブルルックアップのセカンダリキーフィールドとして使用する必要があります。
Local Action
ローカルアクション
The Local Action field is used to identify how a message should be treated. The following actions are supported:
ローカルアクションフィールドは、メッセージの処理方法を識別するために使用されます。次のアクションがサポートされています。
1. LOCAL - Diameter messages that can be satisfied locally and do not need to be routed to another Diameter entity.
1. LOCAL-ローカルで満たすことができ、別のDiameterエンティティにルーティングする必要がないDiameterメッセージ。
2. RELAY - All Diameter messages that fall within this category MUST be routed to a next-hop Diameter entity that is indicated by the identifier described below. Routing is done without modifying any non-routing AVPs. See Section 6.1.9 for relaying guidelines.
2. RELAY-このカテゴリに該当するすべてのDiameterメッセージは、以下で説明する識別子によって示されるネクストホップDiameterエンティティにルーティングされる必要があります。ルーティングは、非ルーティングAVPを変更せずに実行されます。リレーのガイドラインについては、セクション6.1.9を参照してください。
3. PROXY - All Diameter messages that fall within this category MUST be routed to a next Diameter entity that is indicated by the identifier described below. The local server MAY apply its local policies to the message by including new AVPs to the message prior to routing. See Section 6.1.9 for proxying guidelines.
3. プロキシ-このカテゴリに該当するすべてのDiameterメッセージは、以下で説明する識別子によって示される次のDiameterエンティティにルーティングされる必要があります。ローカルサーバーは、ルーティングの前にメッセージに新しいAVPを含めることにより、メッセージにローカルポリシーを適用できます（MAY）。プロキシのガイドラインについては、セクション6.1.9を参照してください。
4. REDIRECT - Diameter messages that fall within this category MUST have the identity of the home Diameter server(s) appended, and returned to the sender of the message. See Section 6.1.8 for redirection guidelines.
4. REDIRECT-このカテゴリに該当するDiameterメッセージには、ホームDiameterサーバーのIDが追加され、メッセージの送信者に返される必要があります。リダイレクトのガイドラインについては、セクション6.1.8を参照してください。
Server Identifier
サーバー識別子
The identity of one or more servers to which the message is to be routed. This identity MUST also be present in the Host Identity field of the peer table (Section 2.6). When the Local Action is set to RELAY or PROXY, this field contains the identity of the server(s) to which the message MUST be routed. When the Local Action field is set to REDIRECT, this field contains the identity of one or more servers to which the message MUST be redirected.
メッセージがルーティングされる1つ以上のサーバーのID。このIDは、ピアテーブルのホストIDフィールドにも存在する必要があります（セクション2.6）。ローカルアクションがRELAYまたはPROXYに設定されている場合、このフィールドには、メッセージのルーティング先であるサーバーのIDが含まれます。 Local ActionフィールドがREDIRECTに設定されている場合、このフィールドには、メッセージのリダイレクト先である1つ以上のサーバーのIDが含まれます。
Static or Dynamic
静的または動的
Specifies whether a route entry was statically configured or dynamically discovered.
ルートエントリが静的に構成されたか動的に検出されたかを指定します。
Expiration Time
有効期限
Specifies the time at which a dynamically discovered route table entry expires. If public key certificates are used for Diameter security (e.g., with TLS), this value MUST NOT be greater than the expiry time in the relevant certificates.
動的に検出されたルートテーブルエントリの有効期限が切れる時刻を指定します。公開鍵証明書がDiameterのセキュリティ（TLSなど）に使用されている場合、この値は、関連する証明書の有効期限を超えてはなりません（MUST NOT）。
It is important to note that Diameter agents MUST support at least one of the LOCAL, RELAY, PROXY, or REDIRECT modes of operation. Agents do not need to support all modes of operation in order to conform with the protocol specification, but they MUST follow the protocol compliance guidelines in Section 2. Relay agents and proxies MUST NOT reorder AVPs.
Diameterエージェントは、LOCAL、RELAY、PROXY、またはREDIRECTモードの操作の少なくとも1つをサポートする必要があることに注意することが重要です。エージェントは、プロトコル仕様に準拠するためにすべての動作モードをサポートする必要はありませんが、セクション2のプロトコルコンプライアンスガイドラインに従う必要があります。リレーエージェントとプロキシは、AVPを並べ替えてはなりません。
The routing table MAY include a default entry that MUST be used for any requests not matching any of the other entries. The routing table MAY consist of only such an entry.
ルーティングテーブルには、他のどのエントリとも一致しない要求に使用する必要があるデフォルトのエントリを含めることができます。ルーティングテーブルは、そのようなエントリのみで構成されている場合があります。
When a request is routed, the target server MUST have advertised the Application Id (see Section 2.4) for the given message or have advertised itself as a relay or proxy agent. Otherwise, an error is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
リクエストがルーティングされるとき、ターゲットサーバーは、指定されたメッセージのアプリケーションID（セクション2.4を参照）をアドバタイズするか、それ自体をリレーまたはプロキシエージェントとしてアドバタイズしている必要があります。そうでない場合、Result-Code AVPがDIAMETER_UNABLE_TO_DELIVERに設定された状態でエラーが返されます。
In addition to clients and servers, the Diameter protocol introduces relay, proxy, redirect, and translation agents, each of which is defined in Section 1.2. Diameter agents are useful for several reasons:
クライアントとサーバーに加えて、Diameterプロトコルはリレー、プロキシ、リダイレクト、および変換エージェントを導入します。それぞれのエージェントはセクション1.2で定義されています。 Diameterエージェントは、いくつかの理由で役立ちます。
o They can distribute administration of systems to a configurable grouping, including the maintenance of security associations.
o 彼らは、セキュリティアソシエーションのメンテナンスなど、システムの管理を構成可能なグループに分散できます。
o They can be used for concentration of requests from a number of co-located or distributed NAS equipment sets to a set of like user groups.
o それらは、多数の同じ場所に配置または分散されたNAS機器セットから、同様のユーザーグループのセットへの要求の集中に使用できます。
o They can do value-added processing to the requests or responses.
o 要求または応答に付加価値処理を実行できます。
o They can be used for load balancing.
o ロードバランシングに使用できます。
o A complex network will have multiple authentication sources, they can sort requests and forward towards the correct target.
o 複雑なネットワークには複数の認証ソースがあり、リクエストを並べ替えて正しいターゲットに転送できます。
The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, its Hop-by-Hop Identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state.
Diameterプロトコルでは、エージェントがフェイルオーバーの目的で使用されるトランザクション状態を維持する必要があります。トランザクション状態は、要求を転送すると、そのホップバイホップ識別子が保存されることを意味します。フィールドはローカルで一意の識別子に置き換えられ、対応する回答を受信すると元の値に復元されます。リクエストの状態は、回答を受け取ると解放されます。ステートレスエージェントは、トランザクション状態のみを維持するエージェントです。
The Proxy-Info AVP allows stateless agents to add local state to a Diameter request, with the guarantee that the same state will be present in the answer. However, the protocol's failover procedures require that agents maintain a copy of pending requests.
Proxy-Info AVPにより、ステートレスエージェントはローカル状態をDiameterリクエストに追加でき、同じ状態が応答に存在することが保証されます。ただし、プロトコルのフェイルオーバー手順では、エージェントが保留中の要求のコピーを維持する必要があります。
A stateful agent is one that maintains session state information by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered active until either the agent is notified otherwise or the session expires. Each authorized session has an expiration, which is communicated by Diameter servers via the Session-Timeout AVP.
ステートフルエージェントは、承認されたすべてのアクティブセッションを追跡することにより、セッション状態情報を維持するエージェントです。承認された各セッションは特定のサービスにバインドされ、その状態は、エージェントに通知されるか、セッションの有効期限が切れるまでアクティブと見なされます。承認された各セッションには有効期限があり、これはセッションタイムアウトAVPを介してDiameterサーバーによって通知されます。
Maintaining session state may be useful in certain applications, such as:
セッション状態の維持は、次のような特定のアプリケーションで役立ちます。
o Protocol translation (e.g., RADIUS <-> Diameter)
o プロトコル変換（例：RADIUS <-> Diameter）
o Limiting resources authorized to a particular user
o 特定のユーザーに許可されたリソースを制限する
o Per-user or per-transaction auditing
o ユーザーごとまたはトランザクションごとの監査
A Diameter agent MAY act in a stateful manner for some requests and be stateless for others. A Diameter implementation MAY act as one type of agent for some requests and as another type of agent for others.
Diameterエージェントは、一部のリクエストではステートフルな方法で動作し、他のリクエストではステートレスになる場合があります。 Diameterの実装は、一部の要求では1つのタイプのエージェントとして機能し、他のタイプでは別のタイプのエージェントとして機能する場合があります。
Relay agents are Diameter agents that accept requests and route messages to other Diameter nodes based on information found in the messages (e.g., the value of the Destination-Realm AVP Section 6.6). This routing decision is performed using a list of supported realms and known peers. This is known as the routing table, as is defined further in Section 2.7.
リレーエージェントは、要求を受け入れ、メッセージ内の情報（たとえば、宛先レルムAVPセクション6.6の値）に基づいて他のDiameterノードにメッセージをルーティングするDiameterエージェントです。このルーティングの決定は、サポートされているレルムと既知のピアのリストを使用して実行されます。セクション2.7でさらに定義されるように、これはルーティングテーブルと呼ばれます。
Relays may, for example, be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (Point of Presence, POP). The use of relays is advantageous since it eliminates the need for NASes to be configured with the necessary security information they would otherwise require to communicate with Diameter servers in other realms. Likewise, this reduces the configuration load on Diameter servers that would otherwise be necessary when NASes are added, changed, or deleted.
リレーは、たとえば、共通の地理的領域（Point of Presence、POP）内の複数のネットワークアクセスサーバー（NAS）からの要求を集約するために使用できます。リレーを使用すると、他のレルムのDiameterサーバーと通信するために必要となる必要なセキュリティ情報をNASに構成する必要がなくなるため、利点があります。同様に、これにより、NASが追加、変更、または削除されたときに必要となるDiameterサーバーの構成負荷が軽減されます。
Relays modify Diameter messages by inserting and removing routing information, but they do not modify any other portion of a message. Relays SHOULD NOT maintain session state but MUST maintain transaction state.
リレーは、ルーティング情報を挿入および削除することによりDiameterメッセージを変更しますが、メッセージの他の部分は変更しません。リレーはセッション状態を維持するべきではありませんが、トランザクション状態を維持する必要があります。
+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 2. Request | |
| NAS | | DRL | | HMS |
| | 4. Answer | | 3. Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 2: Relaying of Diameter messages
図2：Diameterメッセージのリレー
The example provided in Figure 2 depicts a request issued from a NAS, which is an access device, for the user bob@example.com. Prior to issuing the request, the NAS performs a Diameter route lookup, using "example.com" as the key, and determines that the message is to be relayed to a DRL, which is a Diameter relay. The DRL performs the same route lookup as the NAS, and relays the message to the HMS, which is example.com's home server. The HMS identifies that the request can be locally supported (via the realm), processes the authentication and/or authorization request, and replies with an answer, which is routed back to the NAS using saved transaction state.
図2の例は、アクセスデバイスであるNASからユーザーbob@example.comに対して発行されたリクエストを示しています。 NASはリクエストを発行する前に、「example.com」をキーとして使用してDiameterルートルックアップを実行し、メッセージがDiameterリレーであるDRLにリレーされることを決定します。 DRLはNASと同じルートルックアップを実行し、メッセージをexample.comのホームサーバーであるHMSにリレーします。 HMSは、要求がローカルで（レルムを介して）サポートできることを識別し、認証および/または許可要求を処理し、保存されたトランザクション状態を使用してNASにルーティングされる応答で応答します。
Since relays do not perform any application-level processing, they provide relaying services for all Diameter applications; therefore, they MUST advertise the Relay Application Id.
リレーはアプリケーションレベルの処理を実行しないため、すべてのDiameterアプリケーションにリレーサービスを提供します。したがって、リレーアプリケーションIDを通知する必要があります。
Similar to relays, proxy agents route Diameter messages using the Diameter routing table. However, they differ since they modify messages to implement policy enforcement. This requires that proxies maintain the state of their downstream peers (e.g., access devices) to enforce resource usage, provide admission control, and provide provisioning.
リレーと同様に、プロキシエージェントはDiameterルーティングテーブルを使用してDiameterメッセージをルーティングします。ただし、ポリシーを実施するためにメッセージを変更するため、両者は異なります。これには、リソースの使用を強制し、アドミッションコントロールを提供し、プロビジョニングを提供するために、プロキシがダウンストリームピア（アクセスデバイスなど）の状態を維持する必要があります。
Proxies may, for example, be used in call control centers or access ISPs that provide outsourced connections; they can monitor the number and type of ports in use and make allocation and admission decisions according to their configuration.
プロキシは、たとえば、外部接続を提供する呼制御センターまたはアクセスISPで使用できます。使用中のポートの数とタイプを監視し、構成に応じて割り当てとアドミッションの決定を行うことができます。
Since enforcing policies requires an understanding of the service being provided, proxies MUST only advertise the Diameter applications they support.
ポリシーを適用するには、提供されるサービスを理解する必要があるため、プロキシは、サポートするDiameterアプリケーションのみを通知する必要があります。
Redirect agents are useful in scenarios where the Diameter routing configuration needs to be centralized. An example is a redirect agent that provides services to all members of a consortium, but does not wish to be burdened with relaying all messages between realms. This scenario is advantageous since it does not require that the consortium provide routing updates to its members when changes are made to a member's infrastructure.
リダイレクトエージェントは、Diameterルーティング構成を集中化する必要があるシナリオで役立ちます。例としては、コンソーシアムのすべてのメンバーにサービスを提供するが、レルム間ですべてのメッセージを中継する負担をかけたくないリダイレクトエージェントがあります。このシナリオは、メンバーのインフラストラクチャに変更が加えられたときにコンソーシアムがメンバーにルーティング更新を提供する必要がないため、有利です。
Since redirect agents do not relay messages, and only return an answer with the information necessary for Diameter agents to communicate directly, they do not modify messages. Since redirect agents do not receive answer messages, they cannot maintain session state.
リダイレクトエージェントはメッセージをリレーせず、Diameterエージェントが直接通信するために必要な情報を含む応答のみを返すため、メッセージは変更されません。リダイレクトエージェントは応答メッセージを受信しないため、セッション状態を維持できません。
The example provided in Figure 3 depicts a request issued from the access device, NAS, for the user bob@example.com. The message is forwarded by the NAS to its relay, DRL, which does not have a routing entry in its Diameter routing table for example.com. The DRL has a default route configured to DRD, which is a redirect agent that returns a redirect notification to DRL, as well as the HMS' contact information. Upon receipt of the redirect notification, the DRL establishes a transport connection with the HMS, if one doesn't already exist, and forwards the request to it.
図3の例は、アクセスデバイスであるNASからユーザーbob@example.comに対して発行されたリクエストを示しています。メッセージはNASによってリレーDRLに転送されます。DRLは、example.comのDiameterルーティングテーブルにルーティングエントリがありません。 DRLには、DRDに構成されたデフォルトルートがあります。これは、DRLにリダイレクト通知を返すリダイレクトエージェントであり、HMSの連絡先情報です。リダイレクト通知を受信すると、DRLはHMSとのトランスポート接続を確立し（存在しない場合）、要求を転送します。
+------+
| |
| DRD |
| |
+------+
^ |
2. Request | | 3. Redirection
| | Notification
| v
+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 4. Request | |
| NAS | | DRL | | HMS |
| | 6. Answer | | 5. Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 3: Redirecting a Diameter Message
図3：Diameterメッセージのリダイレクト
Since redirect agents do not perform any application-level processing, they provide relaying services for all Diameter applications; therefore, they MUST advertise the Relay Application ID.
リダイレクトエージェントはアプリケーションレベルの処理を実行しないため、すべてのDiameterアプリケーションにリレーサービスを提供します。したがって、リレーアプリケーションIDを通知する必要があります。
A translation agent is a device that provides translation between two protocols (e.g., RADIUS<->Diameter, TACACS+<->Diameter). Translation agents are likely to be used as aggregation servers to communicate with a Diameter infrastructure, while allowing for the embedded systems to be migrated at a slower pace.
変換エージェントは、2つのプロトコル（RADIUS <-> Diameter、TACACS + <-> Diameterなど）間の変換を提供するデバイスです。翻訳エージェントは、Diameterインフラストラクチャと通信するための集約サーバーとして使用される可能性が高く、組み込みシステムをより遅いペースで移行できます。
Given that the Diameter protocol introduces the concept of long-lived authorized sessions, translation agents MUST be session stateful and MUST maintain transaction state.
Diameterプロトコルが長期間の承認済みセッションの概念を導入していることを考えると、変換エージェントはセッションステートフルである必要があり、トランザクション状態を維持する必要があります。
Translation of messages can only occur if the agent recognizes the application of a particular request; therefore, translation agents MUST only advertise their locally supported applications.
メッセージの翻訳は、エージェントが特定のリクエストの適用を認識した場合にのみ発生します。したがって、翻訳エージェントは、ローカルでサポートされているアプリケーションのみを宣伝する必要があります。
+------+ ---------> +------+ ---------> +------+
| | RADIUS Request | | Diameter Request | |
| NAS | | TLA | | HMS |
| | RADIUS Answer | | Diameter Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 4: Translation of RADIUS to Diameter
図4：RADIUSからDiameterへの変換
As noted in Section 2.2, Diameter provides transmission-level security for each connection using TLS/TCP and DTLS/SCTP. Therefore, each connection can be authenticated and can be replay and integrity protected.
セクション2.2で述べたように、DiameterはTLS / TCPおよびDTLS / SCTPを使用する各接続に伝送レベルのセキュリティを提供します。したがって、各接続を認証し、再生と整合性を保護できます。
In addition to authenticating each connection, the entire session MUST also be authorized. Before initiating a connection, a Diameter peer MUST check that its peers are authorized to act in their roles. For example, a Diameter peer may be authentic, but that does not mean that it is authorized to act as a Diameter server advertising a set of Diameter applications.
各接続を認証することに加えて、セッション全体も承認されなければなりません（MUST）。接続を開始する前に、Diameterピアは、そのピアが役割で動作することを承認されていることを確認する必要があります。たとえば、Diameterピアは本物である可能性がありますが、これは、DiameterアプリケーションのセットをアドバタイズするDiameterサーバーとして機能することが承認されていることを意味しません。
Prior to bringing up a connection, authorization checks are performed at each connection along the path. Diameter capabilities negotiation (CER/CEA) also MUST be carried out, in order to determine what Diameter applications are supported by each peer. Diameter sessions MUST be routed only through authorized nodes that have advertised support for the Diameter application required by the session.
接続を開始する前に、パスに沿った各接続で承認チェックが実行されます。各ピアでサポートされているDiameterアプリケーションを判別するために、Diameter機能のネゴシエーション（CER / CEA）も実行する必要があります。 Diameterセッションは、そのセッションで必要なDiameterアプリケーションのサポートをアドバタイズした承認済みノードを介してのみルーティングする必要があります。
As noted in Section 6.1.9, a relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer from which the request was received.
セクション6.1.9で述べたように、リレーまたはプロキシエージェントは、転送されるすべてのリクエストにルートレコードAVPを追加する必要があります。 AVPには、要求の受信元のピアのIDが含まれています。
The home Diameter server, prior to authorizing a session, MUST check the Route-Record AVPs to make sure that the route traversed by the request is acceptable. For example, administrators within the home realm may not wish to honor requests that have been routed through an untrusted realm. By authorizing a request, the home Diameter server is implicitly indicating its willingness to engage in the business transaction as specified by any contractual relationship between the server and the previous hop. A DIAMETER_AUTHORIZATION_REJECTED error message (see Section 7.1.5) is sent if the route traversed by the request is unacceptable.
ホームDiameterサーバーは、セッションを承認する前に、ルートレコードAVPをチェックして、リクエストが通過したルートが受け入れ可能であることを確認する必要があります。たとえば、ホームレルム内の管理者は、信頼されていないレルムを介してルーティングされたリクエストを受け入れたくない場合があります。リクエストを承認することにより、ホームDiameterサーバーは、サーバーと前のホップとの間の契約関係によって指定されたビジネストランザクションに従事する意思を暗黙的に示します。要求が通過したルートが受け入れられない場合、DIAMETER_AUTHORIZATION_REJECTEDエラーメッセージ（セクション7.1.5を参照）が送信されます。
A home realm may also wish to check that each accounting request message corresponds to a Diameter response authorizing the session. Accounting requests without corresponding authorization responses SHOULD be subjected to further scrutiny, as should accounting requests indicating a difference between the requested and provided service.
ホームレルムは、各アカウンティング要求メッセージがセッションを許可するDiameter応答に対応することを確認することもできます。対応する承認応答のないアカウンティング要求は、要求されたサービスと提供されたサービスの違いを示すアカウンティング要求と同様に、さらに精査される必要があります。
Forwarding of an authorization response is considered evidence of a willingness to take on financial risk relative to the session. A local realm may wish to limit this exposure, for example, by establishing credit limits for intermediate realms and refusing to accept responses that would violate those limits. By issuing an accounting request corresponding to the authorization response, the local realm implicitly indicates its agreement to provide the service indicated in the authorization response. If the service cannot be provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error message MUST be sent within the accounting request; a Diameter client receiving an authorization response for a service that it cannot perform MUST NOT substitute an alternate service and then send accounting requests for the alternate service instead.
承認応答の転送は、セッションに関連して財務リスクを引き受ける意思の証拠と見なされます。ローカルレルムは、たとえば、中間レルムのクレジット制限を設定し、それらの制限に違反する応答を受け入れることを拒否することにより、このエクスポージャーを制限したい場合があります。許可応答に対応するアカウンティング要求を発行することにより、ローカルレルムは、許可応答で示されたサービスを提供することへの同意を暗黙的に示します。ローカルレルムでサービスを提供できない場合は、DIAMETER_UNABLE_TO_COMPLYエラーメッセージをアカウンティング要求内で送信する必要があります。実行できないサービスの承認応答を受信するDiameterクライアントは、代替サービスを代用してはならず、代わりに代替サービスのアカウンティング要求を送信してはなりません（MUST NOT）。
A summary of the Diameter header format is shown below. The fields are transmitted in network byte order.
Diameterヘッダー形式の概要を以下に示します。フィールドはネットワークバイトオーダーで送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Flags | Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop-by-Hop Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-End Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Version
バージョン
This Version field MUST be set to 1 to indicate Diameter Version 1.
Diameterバージョン1を示すには、このバージョンフィールドを1に設定する必要があります。
Message Length
メッセージの長さ
The Message Length field is three octets and indicates the length of the Diameter message including the header fields and the padded AVPs. Thus, the Message Length field is always a multiple of 4.
メッセージ長フィールドは3オクテットで、ヘッダーフィールドとパディングされたAVPを含むDiameterメッセージの長さを示します。したがって、メッセージ長フィールドは常に4の倍数になります。
Command Flags
コマンドフラグ
The Command Flags field is eight bits. The following bits are assigned:
コマンドフラグフィールドは8ビットです。以下のビットが割り当てられています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R P E T r r r r|
+-+-+-+-+-+-+-+-+
R(equest)
リクエスト）
If set, the message is a request. If cleared, the message is an answer.
設定されている場合、メッセージは要求です。クリアされている場合、メッセージは回答です。
P(roxiable)
P（roxiable）
If set, the message MAY be proxied, relayed, or redirected. If cleared, the message MUST be locally processed.
設定されている場合、メッセージはプロキシ、リレー、またはリダイレクトされる場合があります。クリアした場合、メッセージはローカルで処理する必要があります。
E(rror)
エラー）
If set, the message contains a protocol error, and the message will not conform to the CCF described for this command. Messages with the 'E' bit set are commonly referred to as error messages. This bit MUST NOT be set in request messages (see Section 7.2).
設定されている場合、メッセージにはプロトコルエラーが含まれ、メッセージはこのコマンドで説明されているCCFに準拠しません。 「E」ビットが設定されたメッセージは、一般にエラーメッセージと呼ばれます。このビットはリクエストメッセージで設定してはいけません（セクション7.2を参照）。
T(Potentially retransmitted message)
T（潜在的に再送信されたメッセージ）
This flag is set after a link failover procedure, to aid the removal of duplicate requests. It is set when resending requests not yet acknowledged, as an indication of a possible duplicate due to a link failure. This bit MUST be cleared when sending a request for the first time; otherwise, the sender MUST set this flag. Diameter agents only need to be concerned about the number of requests they send based on a single received request; retransmissions by other entities need not be tracked. Diameter agents that receive a request with the T flag set, MUST keep the T flag set in the forwarded request. This flag MUST NOT be set if an error answer message (e.g., a protocol error) has been received for the earlier message. It can be set only in cases where no answer has been received from the server for a request, and the request has been sent again. This flag MUST NOT be set in answer messages.
このフラグは、リンクフェイルオーバー手順の後に設定され、重複した要求の削除を支援します。これは、まだ確認されていない要求を再送信するときに設定されます。これは、リンク障害による重複の可能性を示しています。初めてリクエストを送信するときは、このビットをクリアする必要があります。それ以外の場合、送信者はこのフラグを設定する必要があります。 Diameterエージェントは、受信した単一の要求に基づいて送信する要求の数を考慮するだけで済みます。他のエンティティによる再送信を追跡する必要はありません。 Tフラグが設定されたリクエストを受信するDiameterエージェントは、転送されたリクエストでTフラグが設定された状態を維持する必要があります。以前のメッセージに対してエラー応答メッセージ（プロトコルエラーなど）が受信された場合、このフラグを設定してはなりません（MUST NOT）。これは、サーバーから要求に対する応答がなく、要求が再送信された場合にのみ設定できます。このフラグは、応答メッセージで設定してはなりません（MUST NOT）。
r(eserved)
予約済み）
These flag bits are reserved for future use; they MUST be set to zero and ignored by the receiver.
これらのフラグビットは将来の使用のために予約されています。それらはゼロに設定されなければならず、受信者によって無視されなければなりません。
Command Code
コマンドコード
The Command Code field is three octets and is used in order to communicate the command associated with the message. The 24-bit address space is managed by IANA (see Section 3.1). Command Code values 16,777,214 and 16,777,215 (hexadecimal values FFFFFE-FFFFFF) are reserved for experimental use (see Section 11.2).
コマンドコードフィールドは3オクテットであり、メッセージに関連付けられたコマンドを伝達するために使用されます。 24ビットのアドレス空間はIANAによって管理されます（セクション3.1を参照）。コマンドコード値16,777,214および16,777,215（16進値FFFFFE-FFFFFF）は実験用に予約されています（セクション11.2を参照）。
Application-ID
アプリケーションID
Application-ID is four octets and is used to identify for which application the message is applicable. The application can be an authentication application, an accounting application, or a vendor-specific application.
Application-IDは4オクテットであり、メッセージが適用されるアプリケーションを識別するために使用されます。アプリケーションは、認証アプリケーション、会計アプリケーション、またはベンダー固有のアプリケーションです。
The value of the Application-ID field in the header MUST be the same as any relevant Application-Id AVPs contained in the message.
ヘッダーのApplication-IDフィールドの値は、メッセージに含まれる関連するApplication-Id AVPと同じである必要があります。
Hop-by-Hop Identifier
ホップバイホップ識別子
The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) that aids in matching requests and replies. The sender MUST ensure that the Hop-by-Hop Identifier in a request is unique on a given connection at any given time, and it MAY attempt to ensure that the number is unique across reboots. The sender of an answer message MUST ensure that the Hop-by-Hop Identifier field contains the same value that was found in the corresponding request. The Hop-by-Hop Identifier is normally a monotonically increasing number, whose start value was randomly generated. An answer message that is received with an unknown Hop-by-Hop Identifier MUST be discarded.
ホップバイホップ識別子は、リクエストと応答の照合を支援する（ネットワークバイト順の）符号なし32ビット整数フィールドです。送信者は、リクエスト内のホップバイホップ識別子が常に特定の接続で一意であることを確認する必要があり、再起動全体で番号が一意であることを確認しようとする場合があります。応答メッセージの送信者は、Hop-by-Hop Identifierフィールドに、対応する要求で見つかったのと同じ値が含まれていることを確認する必要があります。ホップバイホップ識別子は通常、単調に増加する数値であり、その開始値はランダムに生成されました。不明なホップバイホップ識別子を使用して受信した応答メッセージは破棄する必要があります。
End-to-End Identifier
エンドツーエンド識別子
The End-to-End Identifier is an unsigned 32-bit integer field (in network byte order) that is used to detect duplicate messages. Upon reboot, implementations MAY set the high order 12 bits to contain the low order 12 bits of current time, and the low order 20 bits to a random value. Senders of request messages MUST insert a unique identifier on each message. The identifier MUST remain locally unique for a period of at least 4 minutes, even across reboots. The originator of an answer message MUST ensure that the End-to-End Identifier field contains the same value that was found in the corresponding request. The End-to-End Identifier MUST NOT be modified by Diameter agents of any kind. The combination of the Origin-Host AVP (Section 6.3) and this field is used to detect duplicates. Duplicate requests SHOULD cause the same answer to be transmitted (modulo the Hop-by-Hop Identifier field and any routing AVPs that may be present), and they MUST NOT affect any state that was set when the original request was processed. Duplicate answer messages that are to be locally consumed (see Section 6.2) SHOULD be silently discarded.
エンドツーエンド識別子は、重複するメッセージを検出するために使用される（ネットワークバイト順の）符号なし32ビット整数フィールドです。再起動時に、実装は、上位12ビットを現在時刻の下位12ビットを含むように設定し、下位20ビットをランダムな値に設定してもよい（MAY）。要求メッセージの送信者は、各メッセージに一意の識別子を挿入する必要があります。識別子は、再起動後でも、少なくとも4分間はローカルで一意である必要があります。応答メッセージの発信者は、End-to-End Identifierフィールドに、対応する要求で見つかったのと同じ値が含まれていることを確認する必要があります。エンドツーエンド識別子は、いかなる種類のDiameterエージェントによっても変更してはなりません。 Origin-Host AVP（セクション6.3）とこのフィールドの組み合わせは、重複を検出するために使用されます。重複するリクエストは同じ応答を送信する必要があり（SHOULD）、（ホップバイホップ識別子フィールドと存在するルーティングAVPを法として）元のリクエストが処理されたときに設定された状態に影響を与えてはなりません（MUST NOT）。ローカルで消費される重複した応答メッセージ（セクション6.2を参照）は、通知なく破棄されるべきです（SHOULD）。
AVPs
AVP
AVPs are a method of encapsulating information relevant to the Diameter message. See Section 4 for more information on AVPs.
AVPは、Diameterメッセージに関連する情報をカプセル化する方法です。 AVPの詳細については、セクション4を参照してください。
Each command Request/Answer pair is assigned a Command Code, and the sub-type (i.e., request or answer) is identified via the 'R' bit in the Command Flags field of the Diameter header.
各コマンド要求/応答ペアにはコマンドコードが割り当てられ、サブタイプ（要求または応答）は、Diameterヘッダーのコマンドフラグフィールドの「R」ビットを介して識別されます。
Every Diameter message MUST contain a Command Code in its header's Command Code field, which is used to determine the action that is to be taken for a particular message. The following Command Codes are defined in the Diameter base protocol:
すべてのDiameterメッセージには、ヘッダーのコマンドコードフィールドにコマンドコードが含まれている必要があります。これは、特定のメッセージに対して実行するアクションを決定するために使用されます。次のコマンドコードは、Diameter基本プロトコルで定義されています。
Section
Command Name Abbrev. Code Reference
--------------------------------------------------------
Abort-Session-Request ASR 274 8.5.1
Abort-Session-Answer ASA 274 8.5.2
Accounting-Request ACR 271 9.7.1
Accounting-Answer ACA 271 9.7.2
Capabilities-Exchange- CER 257 5.3.1
Request
Capabilities-Exchange- CEA 257 5.3.2
Answer
Device-Watchdog-Request DWR 280 5.5.1
Device-Watchdog-Answer DWA 280 5.5.2
Disconnect-Peer-Request DPR 282 5.4.1
Disconnect-Peer-Answer DPA 282 5.4.2
Re-Auth-Request RAR 258 8.3.1
Re-Auth-Answer RAA 258 8.3.2
Session-Termination- STR 275 8.4.1
Request
Session-Termination- STA 275 8.4.2
Answer
Every Command Code defined MUST include a corresponding Command Code Format (CCF) specification, which is used to define the AVPs that MUST or MAY be present when sending the message. The following ABNF specifies the CCF used in the definition:
定義されたすべてのコマンドコードには、対応するコマンドコードフォーマット（CCF）仕様を含める必要があります。これは、メッセージを送信するときに存在する必要があるまたは存在する可能性のあるAVPを定義するために使用されます。次のABNFは、定義で使用されるCCFを指定しています。
command-def = "<" command-name ">" "::=" diameter-message
command-name = diameter-name
diameter-name = ALPHA *(ALPHA / DIGIT / "-")
diameter-message = header *fixed *required *optional
header = "<Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
application-id = 1*DIGIT
command-id = 1*DIGIT
; The Command Code assigned to the command.
r-bit = ", REQ"
; If present, the 'R' bit in the Command
; Flags is set, indicating that the message
; is a request as opposed to an answer.
p-bit = ", PXY"
; If present, the 'P' bit in the Command
; Flags is set, indicating that the message
; is proxiable.
e-bit = ", ERR"
; If present, the 'E' bit in the Command
; Flags is set, indicating that the answer
; message contains a Result-Code AVP in
; the "protocol error" class.
fixed = [qual] "<" avp-spec ">"
; Defines the fixed position of an AVP.
required = [qual] "{" avp-spec "}"
; The AVP MUST be present and can appear
; anywhere in the message.
optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name that is included
; in a fixed or required rule. The AVP can
; appear anywhere in the message.
;
; NOTE: "[" and "]" have a slightly different
; meaning than in ABNF. These braces
; cannot be used to express optional fixed rules
; (such as an optional ICV at the end). To do
; this, the convention is '0*1fixed'.
qual = [min] "*" [max]
; See ABNF conventions, RFC 5234, Section 4.
; The absence of any qualifier depends on
; whether it precedes a fixed, required, or
; optional rule. If a fixed or required rule has
; no qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be
; present. If an optional rule has a qualifier,
; then the value of min MUST be 0 if present.
min = 1*DIGIT
; The minimum number of times the element may
; be present. If absent, the default value is 0
; for fixed and optional rules and 1 for
; required rules. The value MUST be at least 1
; for required rules.
max = 1*DIGIT
; The maximum number of times the element may
; be present. If absent, the default value is
; infinity. A value of 0 implies the AVP MUST
; NOT be present.
avp-spec = diameter-name
; The avp-spec has to be an AVP Name, defined
; in the base or extended Diameter
; specifications.
avp-name = avp-spec / "AVP"
; The string "AVP" stands for *any* arbitrary AVP
; Name, not otherwise listed in that Command Code
; definition. The inclusion of this string
; is recommended for all CCFs to allow for
; extensibility.
The following is a definition of a fictitious Command Code:
以下は、架空のコマンドコードの定義です。
Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
{ User-Name }
1* { Origin-Host }
* [ AVP ]
Diameter command names typically includes one or more English words followed by the verb "Request" or "Answer". Each English word is delimited by a hyphen. A three-letter acronym for both the request and answer is also normally provided.
Diameterコマンド名には、通常、1つ以上の英語の単語の後に「Request」または「Answer」という動詞が続きます。各英単語はハイフンで区切られています。通常、要求と応答の両方の3文字の頭字語も提供されます。
An example is a message set used to terminate a session. The command name is Session-Terminate-Request and Session-Terminate-Answer, while the acronyms are STR and STA, respectively.
たとえば、セッションを終了するために使用されるメッセージセットです。コマンド名はSession-Terminate-RequestおよびSession-Terminate-Answerで、頭字語はそれぞれSTRおよびSTAです。
Both the request and the answer for a given command share the same Command Code. The request is identified by the R(equest) bit in the Diameter header set to one (1), to ask that a particular action be performed, such as authorizing a user or terminating a session. Once the receiver has completed the request, it issues the corresponding answer, which includes a result code that communicates one of the following:
特定のコマンドの要求と応答の両方が同じコマンドコードを共有します。リクエストは、DiameterヘッダーのR（equest）ビットが1に設定されていることで識別され、ユーザーの承認やセッションの終了など、特定のアクションの実行を要求します。受信側が要求を完了すると、対応する応答が発行されます。これには、次のいずれかを伝える結果コードが含まれます。
o The request was successful
o リクエストは成功しました
o The request failed
o リクエストは失敗しました
o An additional request has to be sent to provide information the peer requires prior to returning a successful or failed answer.
o 成功または失敗した回答を返す前に、ピアが必要とする情報を提供するために追加のリクエストを送信する必要があります。
o The receiver could not process the request, but provides information about a Diameter peer that is able to satisfy the request, known as redirect.
o 受信側は要求を処理できませんでしたが、リダイレクトと呼ばれる、要求を満たすことができるDiameterピアに関する情報を提供します。
Additional information, encoded within AVPs, may also be included in answer messages.
AVP内でエンコードされた追加情報も、応答メッセージに含まれる場合があります。
Diameter AVPs carry specific authentication, accounting, authorization, and routing information as well as configuration details for the request and reply.
Diameter AVPは、特定の認証、アカウンティング、許可、ルーティング情報、および要求と応答の構成の詳細を伝達します。
Each AVP of type OctetString MUST be padded to align on a 32-bit boundary, while other AVP types align naturally. A number of zero-valued bytes are added to the end of the AVP Data field until a word boundary is reached. The length of the padding is not reflected in the AVP Length field.
タイプOctetStringの各AVPは、32ビット境界で整列するようにパディングする必要がありますが、他のAVPタイプは自然に整列します。ワード境界に達するまで、ゼロ値のバイトがAVPデータフィールドの最後に追加されます。パディングの長さは、AVP長さフィールドには反映されません。
The fields in the AVP header MUST be sent in network byte order. The format of the header is:
AVPヘッダーのフィールドは、ネットワークバイトオーダーで送信する必要があります。ヘッダーの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
AVPコード
The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for reuse of RADIUS attributes, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA (see Section 11.1.1).
AVPコードとVendor-Idフィールドを組み合わせて、属性を一意に識別します。 AVP番号1〜255は、Vendor-Idフィールドを設定せずに、RADIUS属性の再利用のために予約されています。 Diameterには、AANAによって割り当てられたAVP番号256以上が使用されます（セクション11.1.1を参照）。
AVP Flags
AVPフラグ
The AVP Flags field informs the receiver how each attribute must be handled. New Diameter applications SHOULD NOT define additional AVP Flag bits. However, note that new Diameter applications MAY define additional bits within the AVP header, and an unrecognized bit SHOULD be considered an error. The sender of the AVP MUST set 'R' (reserved) bits to 0 and the receiver SHOULD ignore all 'R' (reserved) bits. The 'P' bit has been reserved for future usage of end-to-end security. At the time of writing, there are no end-to-end security mechanisms specified; therefore, the 'P' bit SHOULD be set to 0.
AVPフラグフィールドは、各属性の処理方法を受信者に通知します。新しいDiameterアプリケーションでは、追加のAVPフラグビットを定義しないでください。ただし、新しいDiameterアプリケーションはAVPヘッダー内に追加のビットを定義する場合があり（MAY）、認識されないビットはエラーと見なされるべきであることに注意してください。 AVPの送信側は「R」（予約済み）ビットを0に設定する必要があり、受信側はすべての「R」（予約済み）ビットを無視する必要があります（SHOULD）。 「P」ビットは、将来のエンドツーエンドセキュリティの使用のために予約されています。現時点では、エンドツーエンドのセキュリティメカニズムは指定されていません。したがって、「P」ビットは0に設定する必要があります。
The 'M' bit, known as the Mandatory bit, indicates whether the receiver of the AVP MUST parse and understand the semantics of the AVP including its content. The receiving entity MUST return an appropriate error message if it receives an AVP that has the M-bit set but does not understand it. An exception applies when the AVP is embedded within a Grouped AVP. See Section 4.4 for details. Diameter relay and redirect agents MUST NOT reject messages with unrecognized AVPs.
必須ビットと呼ばれる「M」ビットは、AVPの受信者がその内容を含むAVPのセマンティクスを解析および理解する必要があるかどうかを示します。受信エンティティは、Mビットが設定されているがそれを理解できないAVPを受信した場合、適切なエラーメッセージを返さなければなりません（MUST）。例外は、AVPがグループ化されたAVPに組み込まれている場合に適用されます。詳細については、4.4項を参照してください。 Diameterリレーおよびリダイレクトエージェントは、認識されないAVPを含むメッセージを拒否してはなりません（MUST NOT）。
The 'M' bit MUST be set according to the rules defined in the application specification that introduces or reuses this AVP. Within a given application, the M-bit setting for an AVP is defined either for all command types or for each command type.
「M」ビットは、このAVPを導入または再利用するアプリケーション仕様で定義された規則に従って設定する必要があります。特定のアプリケーション内で、AVPのMビット設定は、すべてのコマンドタイプまたは各コマンドタイプに対して定義されます。
AVPs with the 'M' bit cleared are informational only; a receiver that receives a message with such an AVP that is not supported, or whose value is not supported, MAY simply ignore the AVP.
「M」ビットがクリアされたAVPは、情報提供のみを目的としています。サポートされていないか、その値がサポートされていないAVPを持つメッセージを受信する受信者は、単にAVPを無視してもよい（MAY）。
The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set, the AVP Code belongs to the specific vendor code address space.
Vendor-Specificビットと呼ばれる「V」ビットは、オプションのVendor-IDフィールドがAVPヘッダーに存在するかどうかを示します。設定すると、AVPコードは特定のベンダーコードアドレス空間に属します。
AVP Length
AVPの長さ
The AVP Length field is three octets, and indicates the number of octets in this AVP including the AVP Code field, AVP Length field, AVP Flags field, Vendor-ID field (if present), and the AVP Data field. If a message is received with an invalid attribute length, the message MUST be rejected.
AVP長さフィールドは3オクテットであり、AVPコードフィールド、AVP長さフィールド、AVPフラグフィールド、ベンダーIDフィールド（存在する場合）、およびAVPデータフィールドを含む、このAVPのオクテット数を示します。無効な属性長でメッセージを受信した場合、メッセージは拒否されなければなりません（MUST）。
The AVP header contains one optional field. This field is only present if the respective bit-flag is enabled.
AVPヘッダーには、オプションのフィールドが1つ含まれています。このフィールドは、それぞれのビットフラグが有効な場合にのみ存在します。
Vendor-ID
ベンダーID
The Vendor-ID field is present if the 'V' bit is set in the AVP Flags field. The optional four-octet Vendor-ID field contains the IANA-assigned "SMI Network Management Private Enterprise Codes" [ENTERPRISE] value, encoded in network byte order. Any vendors or standardization organizations that are also treated like vendors in the IANA-managed "SMI Network Management Private Enterprise Codes" space wishing to implement a vendor-specific Diameter AVP MUST use their own Vendor-ID along with their privately managed AVP address space, guaranteeing that they will not collide with any other vendor's vendor-specific AVP(s) or with future IETF AVPs.
ベンダーIDフィールドは、「V」ビットがAVPフラグフィールドに設定されている場合に存在します。オプションの4オクテットベンダーIDフィールドには、ネットワークバイトオーダーでエンコードされた、IANA割り当ての「SMIネットワーク管理プライベートエンタープライズコード」[エンタープライズ]値が含まれます。ベンダー固有のDiameter AVPの実装を希望するIANA管理の「SMIネットワーク管理プライベートエンタープライズコード」スペースのベンダーと同様に扱われるベンダーまたは標準化組織は、プライベートに管理されたAVPアドレススペースとともに独自のベンダーIDを使用する必要があります。他のベンダーのベンダー固有のAVPまたは将来のIETF AVPと衝突しないことを保証します。
A Vendor-ID value of zero (0) corresponds to the IETF-adopted AVP values, as managed by IANA. Since the absence of the Vendor-ID field implies that the AVP in question is not vendor specific, implementations MUST NOT use the value of zero (0) for the Vendor-ID field.
ベンダーID値ゼロ（0）は、IANAが管理するIETF採用AVP値に対応します。 Vendor-IDフィールドがないことは、問題のAVPがベンダー固有ではないことを意味するため、実装はVendor-IDフィールドにゼロ（0）の値を使用してはなりません（MUST NOT）。
The Data field is zero or more octets and contains information specific to the Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the Data field MUST be one of the following base data types or a data type derived from the base data types. In the event that a new Basic AVP Data Format is needed, a new version of this RFC MUST be created.
データフィールドは0オクテット以上で、属性に固有の情報が含まれています。データフィールドの形式と長さは、AVPコードフィールドとAVP長さフィールドによって決まります。データフィールドの形式は、次の基本データタイプのいずれか、または基本データタイプから派生したデータタイプである必要があります。新しい基本AVPデータ形式が必要な場合は、このRFCの新しいバージョンを作成する必要があります。
OctetString
ByteString
The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary.
データには、可変長の任意のデータが含まれます。特に明記しない限り、AVP長さフィールドは少なくとも8（「V」ビットが有効な場合は12）に設定する必要があります。長さが4オクテットの倍数ではないこのタイプのAVP値の後に、次のAVP（存在する場合）が32ビット境界で開始するように、必要なパディングが続きます。
Integer32
Integer32
32-bit signed value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled).
ネットワークバイトオーダーの32ビットの符号付き値。 AVP長さフィールドは12に設定する必要があります（ 'V'ビットが有効な場合は16）。
Integer64
Integer64
64-bit signed value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled).
ネットワークバイトオーダーの64ビット符号付き値。 AVP長さフィールドは16に設定する必要があります（「V」ビットが有効な場合は20）。
Unsigned32
署名なし32
32-bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled).
ネットワークバイトオーダーの32ビット符号なし値。 AVP長さフィールドは12に設定する必要があります（ 'V'ビットが有効な場合は16）。
Unsigned64
Unsigned64
64-bit unsigned value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled).
ネットワークバイトオーダーの64ビット符号なし値。 AVP長さフィールドは16に設定する必要があります（「V」ビットが有効な場合は20）。
Float32
Float32
This represents floating point values of single precision as described by [FLOATPOINT]. The 32-bit value is transmitted in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled).
これは、[FLOATPOINT]で説明されている単精度の浮動小数点値を表します。 32ビット値は、ネットワークバイトオーダーで送信されます。 AVP長さフィールドは12に設定する必要があります（ 'V'ビットが有効な場合は16）。
Float64
Float64
This represents floating point values of double precision as described by [FLOATPOINT]. The 64-bit value is transmitted in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled).
これは、[FLOATPOINT]で説明されている倍精度の浮動小数点値を表します。 64ビット値は、ネットワークバイトオーダーで送信されます。 AVP長さフィールドは16に設定する必要があります（「V」ビットが有効な場合は20）。
Grouped
グループ化
The Data field is specified as a sequence of AVPs. These AVPs are concatenated -- including their headers and padding -- in the order in which they are specified and the result encapsulated in the Data field. The AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the total length of all included AVPs, including their headers and padding. Thus, the AVP Length field of an AVP of type Grouped is always a multiple of 4.
データフィールドは、AVPのシーケンスとして指定されます。これらのAVPは、ヘッダーとパディングを含め、指定された順序で連結され、結果はデータフィールドにカプセル化されます。 AVP長さフィールドは、8（「V」ビットが有効な場合は12）に、ヘッダーとパディングを含む、含まれるすべてのAVPの全長を加えたものに設定されます。したがって、GroupedタイプのAVPのAVP Lengthフィールドは常に4の倍数です。
In addition to using the Basic AVP Data Formats, applications may define data formats derived from the Basic AVP Data Formats. An application that defines new Derived AVP Data Formats MUST include them in a section titled "Derived AVP Data Formats", using the same format as the definitions below. Each new definition MUST be either defined or listed with a reference to the RFC that defines the format.
アプリケーションは、基本AVPデータ形式の使用に加えて、基本AVPデータ形式から派生したデータ形式を定義できます。新しい派生AVPデータ形式を定義するアプリケーションは、以下の定義と同じ形式を使用して、「派生AVPデータ形式」というタイトルのセクションにそれらを含める必要があります。それぞれの新しい定義は、フォーマットを定義するRFCへの参照を使用して定義またはリストする必要があります。
The following are commonly used Derived AVP Data Formats.
以下は、一般的に使用される派生AVPデータ形式です。
Address
住所
The Address format is derived from the OctetString Basic AVP Format. It is a discriminated union representing, for example, a 32-bit (IPv4) [RFC0791] or 128-bit (IPv6) [RFC4291] address, most significant octet first. The first two octets of the Address AVP represent the AddressType, which contains an Address Family, defined in [IANAADFAM]. The AddressType is used to discriminate the content and format of the remaining octets.
アドレス形式はOctetString Basic AVP Formatから派生しています。これは、たとえば、32ビット（IPv4）[RFC0791]または128ビット（IPv6）[RFC4291]のアドレスを表す、最も重要なオクテットが最初の識別された共用体です。アドレスAVPの最初の2つのオクテットは、[IANAADFAM]で定義されたアドレスファミリを含むAddressTypeを表します。 AddressTypeは、残りのオクテットの内容と形式を区別するために使用されます。
Time
時間
The Time format is derived from the OctetString Basic AVP Format. The string MUST contain four octets, in the same format as the first four bytes are in the NTP timestamp format. The NTP timestamp format is defined in Section 3 of [RFC5905].
時間形式はOctetString Basic AVP Formatから派生しています。文字列には、最初の4バイトがNTPタイムスタンプ形式であるのと同じ形式で、4つのオクテットを含める必要があります。 NTPタイムスタンプの形式は、[RFC5905]のセクション3で定義されています。
This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC).
これは、協定世界時（UTC）に関して、1900年1月1日0時からの秒数を表します。
On 6h 28m 16s UTC, 7 February 2036, the time value will overflow. Simple Network Time Protocol (SNTP) [RFC5905] describes a procedure to extend the time to 2104. This procedure MUST be supported by all Diameter nodes.
2036年2月7日の6時間28分16秒UTCでは、時間値がオーバーフローします。 Simple Network Time Protocol（SNTP）[RFC5905]は、時間を2104に延長する手順を説明しています。この手順は、すべてのDiameterノードでサポートされている必要があります。
UTF8String
UTF8String
The UTF8String format is derived from the OctetString Basic AVP Format. This is a human-readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an OctetString using the UTF-8 transformation format [RFC3629].
UTF8String形式は、OctetString Basic AVP Formatから派生しています。これは、ISO / IEC IS 10646-1文字セットを使用して表される人間が読める文字列であり、UTF-8変換形式[RFC3629]を使用してOctetStringとしてエンコードされます。
Since additional code points are added by amendments to the 10646 standard from time to time, implementations MUST be prepared to encounter any code point from 0x00000001 to 0x7fffffff. Byte sequences that do not correspond to the valid encoding of a code point into UTF-8 charset or are outside this range are prohibited.
追加のコードポイントは時々10646標準の修正によって追加されるため、実装は0x00000001から0x7fffffffまでのコードポイントに遭遇するように準備する必要があります。コードポイントのUTF-8文字セットへの有効なエンコードに対応していない、またはこの範囲外のバイトシーケンスは禁止されています。
The use of control codes SHOULD be avoided. When it is necessary to represent a new line, the control code sequence CR LF SHOULD be used.
制御コードの使用は避けるべきです。新しい行を表す必要がある場合は、制御コードシーケンスCR LF SHOULDを使用する必要があります。
The use of leading or trailing white space SHOULD be avoided.
先頭または末尾の空白の使用は避けてください。
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, MAY be provided.
ユーザーインターフェイスハードウェアまたはソフトウェアで直接サポートされていないコードポイントの場合、16進数などの入力と表示の代替手段を提供できます。
For information encoded in 7-bit US-ASCII, the UTF-8 charset is identical to the US-ASCII charset.
7ビットUS-ASCIIでエンコードされた情報の場合、UTF-8文字セットはUS-ASCII文字セットと同じです。
UTF-8 may require multiple bytes to represent a single character / code point; thus, the length of a UTF8String in octets may be different from the number of characters encoded.
UTF-8では、単一の文字/コードポイントを表すために複数のバイトが必要になる場合があります。したがって、オクテット単位のUTF8Stringの長さは、エンコードされた文字数とは異なる場合があります。
Note that the AVP Length field of an UTF8String is measured in octets not characters.
UTF8StringのAVP長さフィールドは、文字ではなくオクテットで測定されることに注意してください。
DiameterIdentity
DiameterIdentity
The DiameterIdentity format is derived from the OctetString Basic AVP Format.
DiameterIdentity形式は、OctetString Basic AVP Formatから派生しています。
DiameterIdentity = FQDN/Realm
The DiameterIdentity value is used to uniquely identify either:
DiameterIdentity値は、次のいずれかを一意に識別するために使用されます。
* A Diameter node for purposes of duplicate connection and routing loop detection.
* 重複した接続とルーティングループの検出を目的としたDiameterノード。
* A Realm to determine whether messages can be satisfied locally or whether they must be routed or redirected.
* メッセージをローカルで満たすことができるかどうか、またはメッセージをルーティングまたはリダイレクトする必要があるかどうかを決定するレルム。
When a DiameterIdentity value is used to identify a Diameter node, the contents of the string MUST be the Fully Qualified Domain Name (FQDN) of the Diameter node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter node can be identified by several FQDNs, a single FQDN should be picked at startup and used as the only DiameterIdentity for that node, whatever the connection on which it is sent. In this document, note that DiameterIdentity is in ASCII form in order to be compatible with existing DNS infrastructure. See Appendix D for interactions between the Diameter protocol and Internationalized Domain Names (IDNs).
DiameterIdentity値を使用してDiameterノードを識別する場合、文字列の内容はDiameterノードの完全修飾ドメイン名（FQDN）である必要があります。同じホスト上で複数のDiameterノードが実行されている場合、各Diameterノードには一意のDiameterIdentityを割り当てる必要があります。 Diameterノードを複数のFQDNで識別できる場合は、起動時に単一のFQDNを選択し、送信先の接続が何であれ、そのノードの唯一のDiameterIdentityとして使用する必要があります。このドキュメントでは、既存のDNSインフラストラクチャとの互換性を保つために、DiameterIdentityがASCII形式であることに注意してください。 Diameterプロトコルと国際化ドメイン名（IDN）の間の相互作用については、付録Dを参照してください。
DiameterURI
ぢ編めてるり
The DiameterURI MUST follow the Uniform Resource Identifiers (RFC 3986) syntax [RFC3986] rules specified below:
DiameterURIは、以下に指定するUniform Resource Identifiers（RFC 3986）構文[RFC3986]の規則に従う必要があります。
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
; No transport security
;輸送セキュリティなし
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transport security used
;使用されるトランスポートセキュリティ
FQDN = < Fully Qualified Domain Name >
port = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections.
; If absent, the default Diameter port
; (3868) is assumed if no transport
; security is used and port 5658 when
; transport security (TLS/TCP and DTLS/SCTP)
; is used.
transport = ";transport=" transport-protocol
; One of the transports used to listen
; for incoming connections. If absent,
; the default protocol is assumed to be TCP.
; UDP MUST NOT be used when the aaa-protocol
; field is set to diameter.
transport-protocol = ( "tcp" / "sctp" / "udp" )
protocol = ";protocol=" aaa-protocol
; If absent, the default AAA protocol ; is Diameter.
;存在しない場合、デフォルトのAAAプロトコル。直径です。
aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
The following are examples of valid Diameter host identities:
次に、有効なDiameterホストIDの例を示します。
aaa://host.example.com;transport=tcp
aaa://host.example.com:6666;transport=tcp
aaa://host.example.com;protocol=diameter
aaa://host.example.com:6666;protocol=diameter
aaa://host.example.com:6666;transport=tcp;protocol=diameter
aaa://host.example.com:1813;transport=udp;protocol=radius
Enumerated
列挙
The Enumerated format is derived from the Integer32 Basic AVP Format. The definition contains a list of valid values and their interpretation and is described in the Diameter application introducing the AVP.
列挙型フォーマットは、Integer32 Basic AVP Formatから派生しています。定義には有効な値とその解釈のリストが含まれ、AVPを導入するDiameterアプリケーションで説明されています。
IPFilterRule
IPFilterRule
The IPFilterRule format is derived from the OctetString Basic AVP Format and uses the ASCII charset. The rule syntax is a modified subset of ipfw(8) from FreeBSD. Packets may be filtered based on the following information that is associated with it:
IPFilterRule形式はOctetString Basic AVP Formatから派生し、ASCII文字セットを使用します。ルールの構文は、FreeBSDのipfw（8）の修正サブセットです。パケットは、それに関連付けられている次の情報に基づいてフィルタリングできます。
Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types
方向（インまたはアウト）送信元および宛先IPアドレス（マスクされる可能性があります）プロトコル送信元および宛先ポート（リストまたは範囲）TCPフラグIPフラグメントフラグIPオプションICMPタイプ
Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny.
適切な方向のルールが順番に評価され、最初に一致したルールが評価を終了します。各パケットは一度評価されます。一致するルールがない場合、最後に評価されたルールが許可の場合、パケットはドロップされ、最後のルールが拒否の場合、パケットは通過します。
IPFilterRule filters MUST follow the format:
IPFilterRuleフィルターは次の形式に従う必要があります。
action dir proto from src to dst [options]
action dir proto srcからdst [オプション]
action permit - Allow packets that match the rule. deny - Drop packets that match the rule.
action permit-ルールに一致するパケットを許可します。 deny-ルールに一致するパケットをドロップします。
dir "in" is from the terminal, "out" is to the terminal.
dir "in"は端末からのもので、 "out"は端末へのものです。
proto An IP protocol specified by number. The "ip" keyword means any protocol will match.
proto番号で指定されたIPプロトコル。 「ip」キーワードは、すべてのプロトコルが一致することを意味します。
src and dst <address/mask> [ports]
The <address/mask> may be specified as: ipno An IPv4 or IPv6 number in dotted-quad or canonical IPv6 form. Only this exact IP number will match the rule.
<address / mask>は次のように指定できます。ipnoドット付きクワッド形式または正規のIPv6形式のIPv4またはIPv6番号。この正確なIP番号のみがルールに一致します。
ipno/bits An IP number as above with a mask width of the form 192.0.2.10/24. In this case, all IP numbers from 192.0.2.0 to 192.0.2.255 will match. The bit width MUST be valid for the IP version, and the IP number MUST NOT have bits set beyond the mask. For a match to occur, the same IP version must be present in the packet that was used in describing the IP address. To test for a particular IP version, the bits part can be set to zero. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. For IPv4, a typical first rule is often "deny in ip! assigned".
ipno / bits 192.0.2.10/24の形式のマスク幅を持つ上記のIP番号。この場合、192.0.2.0から192.0.2.255までのすべてのIP番号が一致します。ビット幅はIPバージョンに対して有効である必要があり、IP番号はマスクを超えて設定されたビットを持っていてはなりません。一致が発生するには、IPアドレスの記述に使用されたパケットに同じIPバージョンが存在する必要があります。特定のIPバージョンをテストするには、ビット部分をゼロに設定できます。キーワード「any」は0.0.0.0/0またはIPv6と同等です。キーワード「割り当て済み」は、端末に割り当てられたアドレスまたはアドレスのセットです。 IPv4の場合、一般的な最初のルールは「deny in ip！割り当て」であることがよくあります。
The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers.
アドレスの前にnot修飾子（！）を付けることで一致の意味を逆にでき、代わりに他のすべてのアドレスが一致します。これはポート番号の選択には影響しません。
With the TCP, UDP, and SCTP protocols, optional ports may be specified as:
TCP、UDP、およびSCTPプロトコルでは、オプションのポートを次のように指定できます。
{port/port-port}[,ports[,...]]
The '-' notation specifies a range of ports (including boundaries).
「-」表記は、ポートの範囲（境界を含む）を指定します。
Fragmented packets that have a non-zero offset (i.e., not the first fragment) will never match a rule that has one or more port specifications. See the frag option for details on matching fragmented packets.
ゼロ以外のオフセット（つまり、最初のフラグメントではない）を持つ断片化されたパケットは、1つ以上のポート指定を持つルールに一致することはありません。フラグメント化されたパケットの照合の詳細については、fragオプションを参照してください。
options: frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications.
オプション：fragパケットがフラグメントであり、これがデータグラムの最初のフラグメントでない場合に一致します。 fragは、tcpflagsまたはTCP / UDPポート指定と組み合わせて使用することはできません。
ipoptions spec Match if the IP header contains the comma-separated list of options specified in spec. The supported IP options are:
ipoptions spec IPヘッダーに、specで指定されたオプションのコンマ区切りリストが含まれている場合に一致します。サポートされているIPオプションは次のとおりです。
ssrr (strict source route), lsrr (loose source route), rr (record packet route), and ts (timestamp). The absence of a particular option may be denoted with a '!'.
ssrr（厳密なソースルート）、lsrr（ルーズソースルート）、rr（レコードパケットルート）、およびts（タイムスタンプ）。特定のオプションがないことは、「！」で示される場合があります。
tcpoptions spec Match if the TCP header contains the comma-separated list of options specified in spec. The supported TCP options are:
tcpoptions spec TCPヘッダーにspecで指定されたオプションのコンマ区切りリストが含まれている場合に一致します。サポートされているTCPオプションは次のとおりです。
mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp), and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'.
mss（最大セグメントサイズ）、ウィンドウ（tcpウィンドウアドバタイズ）、sack（選択的ack）、ts（rfc1323タイムスタンプ）、およびcc（rfc1644 t / tcp接続カウント）。特定のオプションがないことは、「！」で示される場合があります。
established TCP packets only. Match packets that have the RST or ACK bits set.
確立されたTCPパケットのみ。 RSTまたはACKビットが設定されているパケットを照合します。
setup TCP packets only. Match packets that have the SYN bit set but no ACK bit.
TCPパケットのみをセットアップします。 SYNビットが設定されているがACKビットがないパケットに一致します。
tcpflags spec TCP packets only. Match if the TCP header contains the comma-separated list of flags specified in spec. The supported TCP flags are:
tcpflags spec TCPパケットのみ。 TCPヘッダーに、specで指定されたフラグのコンマ区切りリストが含まれている場合に一致します。サポートされるTCPフラグは次のとおりです。
fin, syn, rst, psh, ack, and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets.
fin、syn、rst、psh、ack、urg。特定のフラグがないことは、 '！'で表すことができます。 tcpflags指定を含むルールは、ゼロ以外のオフセットを持つフラグメント化されたパケットと一致することはできません。フラグメント化されたパケットの照合の詳細については、fragオプションを参照してください。
icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17), and address mask reply (18).
icmptypesは、ICMPパケットのみをタイプします。 ICMPタイプがリストタイプにある場合に一致します。リストは、範囲の任意の組み合わせ、またはコンマで区切られた個々のタイプとして指定できます。以下の数値と記号値の両方を使用できます。サポートされるICMPタイプは、エコー応答（0）、宛先到達不能（3）、送信元抑制（4）、リダイレクト（5）、エコー要求（8）、ルーター通知（9）、ルーター要請（10）、期限-ライブ超過（11）、IPヘッダー不良（12）、タイムスタンプ要求（13）、タイムスタンプ応答（14）、情報要求（15）、情報応答（16）、アドレスマスク要求（17）、およびアドレスマスク応答（ 18）。
There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls.
アクセスデバイスが常に破棄しなければならないパケットには、フラグメントオフセットが1のIPフラグメントがあります。これは有効なパケットですが、ファイアウォールを回避するための1つの用途しかありません。
An access device that is unable to interpret or apply a deny rule MUST terminate the session. An access device that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. An access device MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure.
拒否ルールを解釈または適用できないアクセスデバイスは、セッションを終了する必要があります。許可ルールを解釈または適用できないアクセスデバイスは、より制限的なルールを適用できます。アクセスデバイスは、たとえばアクセスデバイスの所有者のインフラストラクチャを保護するために、提供されたルールの前に独自の拒否ルールを適用してもよい（MAY）。
The Diameter protocol allows AVP values of type 'Grouped'. This implies that the Data field is actually a sequence of AVPs. It is possible to include an AVP with a Grouped type within a Grouped type, that is, to nest them. AVPs within an AVP of type Grouped have the same padding requirements as non-Grouped AVPs, as defined in Section 4.4.
Diameterプロトコルでは、「グループ化」タイプのAVP値を使用できます。これは、データフィールドが実際にはAVPのシーケンスであることを意味します。 Groupedタイプの中にAVPをGroupedタイプに含めることができます。つまり、それらをネストすることができます。セクション4.4で定義されているように、グループ化されたタイプのAVP内のAVPには、グループ化されていないAVPと同じパディング要件があります。
The AVP Code numbering space of all AVPs included in a Grouped AVP is the same as for non-Grouped AVPs. Receivers of a Grouped AVP that does not have the 'M' (mandatory) bit set and one or more of the encapsulated AVPs within the group has the 'M' (mandatory) bit set MAY simply be ignored if the Grouped AVP itself is unrecognized. The rule applies even if the encapsulated AVP with its 'M' (mandatory) bit set is further encapsulated within other sub-groups, i.e., other Grouped AVPs embedded within the Grouped AVP.
グループ化されたAVPに含まれるすべてのAVPのAVPコード番号付けスペースは、グループ化されていないAVPの場合と同じです。 「M」（必須）ビットが設定されておらず、グループ内の1つ以上のカプセル化されたAVPに「M」（必須）ビットが設定されているグループ化されたAVPの受信者は、グループ化されたAVP自体が認識されない場合、単に無視される場合があります。 。 「M」（必須）ビットセットのカプセル化されたAVPが他のサブグループ、つまり、グループ化されたAVPに埋め込まれた他のグループ化されたAVP内にさらにカプセル化されている場合でも、ルールは適用されます。
Every Grouped AVP definition MUST include a corresponding grammar, using ABNF [RFC5234] (with modifications), as defined below.
グループ化されたすべてのAVP定義には、以下に定義されているように、ABNF [RFC5234]（変更あり）を使用して、対応する文法を含める必要があります。
grouped-avp-def = "<" name ">" "::=" avp
name-fmt = ALPHA *(ALPHA / DIGIT / "-")
name = name-fmt
; The name has to be the name of an AVP,
; defined in the base or extended Diameter
; specifications.
avp = header *fixed *required *optional
header = "<" "AVP-Header:" avpcode [vendor] ">"
avpcode = 1*DIGIT
; The AVP Code assigned to the Grouped AVP.
vendor = 1*DIGIT
; The Vendor-ID assigned to the Grouped AVP.
; If absent, the default value of zero is
; used.
The Example-AVP (AVP Code 999999) is of type Grouped and is used to clarify how Grouped AVP values work. The Grouped Data field has the following CCF grammar:
Example-AVP（AVPコード999999）はGroupedタイプであり、Grouped AVP値がどのように機能するかを明確にするために使用されます。 Grouped Dataフィールドには、次のCCF文法があります。
Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ]
An Example-AVP with Grouped Data follows.
グループ化されたデータを使用したAVPの例を次に示します。
The Origin-Host AVP (Section 6.3) is required. In this case:
Origin-Host AVP（セクション6.3）が必要です。この場合：
Origin-Host = "example.com".
Origin-Host = "example.com"。
One or more Session-Ids must follow. Here there are two:
1つ以上のセッションIDが続く必要があります。ここには2つあります。
Session-Id =
"grump.example.com:33041;23432;893;0AF3B81"
Session-Id =
"grump.example.com:33054;23561;2358;0AF3B82"
optional AVPs included are
含まれるオプションのAVPは
Recovery-Policy = <binary>
2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
Futuristic-Acct-Record = <binary>
fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
d3427475e49968f841
The data for the optional AVPs is represented in hexadecimal form since the format of these AVPs is not known at the time of definition of the Example-AVP group nor (likely) at the time when the example instance of this AVP is interpreted -- except by Diameter implementations that support the same set of AVPs. The encoding example illustrates how padding is used and how length fields are calculated. Also, note that AVPs may be present in the Grouped AVP value that the receiver cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record AVPs). The length of the Example-AVP is the sum of all the length of the member AVPs, including their padding, plus the Example-AVP header size.
オプションのAVPのデータは16進数形式で表されます。これは、これらのAVPの形式が、サンプルAVPグループの定義時には不明であるか、このAVPのサンプルインスタンスが解釈される時点では（おそらく）不明であるためです。同じAVPセットをサポートするDiameter実装によって。エンコードの例は、パディングの使用方法と長さフィールドの計算方法を示しています。また、AVPは、受信者が解釈できないグループ化されたAVP値に存在する可能性があることに注意してください（ここでは、Recover-PolicyおよびFuturistic-Acct-Record AVP）。 Example-AVPの長さは、メンバーAVPのパディングを含むすべての長さの合計に、Example-AVPヘッダーサイズを加えたものです。
This AVP would be encoded as follows:
このAVPは次のようにエンコードされます。
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
0 | Example AVP Header (AVP Code = 999999), Length = 496 |
+-------+-------+-------+-------+-------+-------+-------+-------+
8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
+-------+-------+-------+-------+-------+-------+-------+-------+
16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
+-------+-------+-------+-------+-------+-------+-------+-------+
24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
32 | (AVP Code = 263), Length = 49 | 'g' | 'r' | 'u' | 'm' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
72 | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
80 | Session-Id AVP Header (AVP Code = 263), Length = 50 |
+-------+-------+-------+-------+-------+-------+-------+-------+
88 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
120| '5' | '8' | ';' | '0' | 'A' | 'F' | '3' | 'B' |
+-------+-------+-------+-------+-------+-------+-------+-------+
128| '8' | '2' |Padding|Padding| Recovery-Policy Header (AVP |
+-------+-------+-------+-------+-------+-------+-------+-------+
136| Code = 8341), Length = 223 | 0x21 | 0x63 | 0xbc | 0x1d |
+-------+-------+-------+-------+-------+-------+-------+-------+
144| 0x0a | 0xd8 | 0x23 | 0x71 | 0xf6 | 0xbc | 0x09 | 0x48 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
352| 0x8c | 0x7f | 0x92 |Padding| Futuristic-Acct-Record Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
328|(AVP Code = 15930),Length = 137| 0xfe | 0x19 | 0xda | 0x58 |
+-------+-------+-------+-------+-------+-------+-------+-------+
336| 0x02 | 0xac | 0xd9 | 0x8b | 0x07 | 0xa5 | 0xb8 | 0xc6 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
488| 0xe4 | 0x99 | 0x68 | 0xf8 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, and possible flag values.
次の表は、基本プロトコルで定義されているDiameter AVP、それらのAVPコード値、タイプ、および可能なフラグ値について説明しています。
Due to space constraints, the short form DiamIdent is used to represent DiameterIdentity.
スペースの制約により、DiamIdentityを表すために短い形式のDiamIdentが使用されています。
+----------+
| AVP Flag |
| rules |
|----+-----|
AVP Section | |MUST |
Attribute Name Code Defined Data Type |MUST| NOT |
-----------------------------------------|----+-----|
Acct- 85 9.8.2 Unsigned32 | M | V |
Interim-Interval | | |
Accounting- 483 9.8.7 Enumerated | M | V |
Realtime-Required | | |
Acct- 50 9.8.5 UTF8String | M | V |
Multi-Session-Id | | |
Accounting- 485 9.8.3 Unsigned32 | M | V |
Record-Number | | |
Accounting- 480 9.8.1 Enumerated | M | V |
Record-Type | | |
Acct- 44 9.8.4 OctetString| M | V |
Session-Id | | |
Accounting- 287 9.8.6 Unsigned64 | M | V |
Sub-Session-Id | | |
Acct- 259 6.9 Unsigned32 | M | V |
Application-Id | | |
Auth- 258 6.8 Unsigned32 | M | V |
Application-Id | | |
Auth-Request- 274 8.7 Enumerated | M | V |
Type | | |
Authorization- 291 8.9 Unsigned32 | M | V |
Lifetime | | |
Auth-Grace- 276 8.10 Unsigned32 | M | V |
Period | | |
Auth-Session- 277 8.11 Enumerated | M | V |
State | | |
Re-Auth-Request- 285 8.12 Enumerated | M | V |
Type | | |
Class 25 8.20 OctetString| M | V |
Destination-Host 293 6.5 DiamIdent | M | V |
Destination- 283 6.6 DiamIdent | M | V |
Realm | | |
Disconnect-Cause 273 5.4.3 Enumerated | M | V |
Error-Message 281 7.3 UTF8String | | V,M |
Error-Reporting- 294 7.4 DiamIdent | | V,M |
Host | | |
Event-Timestamp 55 8.21 Time | M | V |
Experimental- 297 7.6 Grouped | M | V |
Result | | |
-----------------------------------------|----+-----|
+----------+
| AVP Flag |
| rules |
|----+-----|
AVP Section | |MUST |
Attribute Name Code Defined Data Type |MUST| NOT |
-----------------------------------------|----+-----|
Experimental- 298 7.7 Unsigned32 | M | V |
Result-Code | | |
Failed-AVP 279 7.5 Grouped | M | V |
Firmware- 267 5.3.4 Unsigned32 | | V,M |
Revision | | |
Host-IP-Address 257 5.3.5 Address | M | V |
Inband-Security | M | V |
-Id 299 6.10 Unsigned32 | | |
Multi-Round- 272 8.19 Unsigned32 | M | V |
Time-Out | | |
Origin-Host 264 6.3 DiamIdent | M | V |
Origin-Realm 296 6.4 DiamIdent | M | V |
Origin-State-Id 278 8.16 Unsigned32 | M | V |
Product-Name 269 5.3.7 UTF8String | | V,M |
Proxy-Host 280 6.7.3 DiamIdent | M | V |
Proxy-Info 284 6.7.2 Grouped | M | V |
Proxy-State 33 6.7.4 OctetString| M | V |
Redirect-Host 292 6.12 DiamURI | M | V |
Redirect-Host- 261 6.13 Enumerated | M | V |
Usage | | |
Redirect-Max- 262 6.14 Unsigned32 | M | V |
Cache-Time | | |
Result-Code 268 7.1 Unsigned32 | M | V |
Route-Record 282 6.7.1 DiamIdent | M | V |
Session-Id 263 8.8 UTF8String | M | V |
Session-Timeout 27 8.13 Unsigned32 | M | V |
Session-Binding 270 8.17 Unsigned32 | M | V |
Session-Server- 271 8.18 Enumerated | M | V |
Failover | | |
Supported- 265 5.3.6 Unsigned32 | M | V |
Vendor-Id | | |
Termination- 295 8.15 Enumerated | M | V |
Cause | | |
User-Name 1 8.14 UTF8String | M | V |
Vendor-Id 266 5.3.3 Unsigned32 | M | V |
Vendor-Specific- 260 6.11 Grouped | M | V |
Application-Id | | |
-----------------------------------------|----+-----|
This section describes how Diameter nodes establish connections and communicate with peers.
このセクションでは、Diameterノードがどのように接続を確立し、ピアと通信するかについて説明します。
Connections between diameter peers are established using their valid DiameterIdentity. A Diameter node initiating a connection to a peer MUST know the peer's DiameterIdentity. Methods for discovering a Diameter peer can be found in Section 5.2.
直径ピア間の接続は、有効なDiameterIdentityを使用して確立されます。ピアへの接続を開始するDiameterノードは、ピアのDiameterIdentityを認識している必要があります。 Diameterピアを検出する方法については、セクション5.2を参照してください。
Although a Diameter node may have many possible peers with which it is able to communicate, it may not be economical to have an established connection to all of them. At a minimum, a Diameter node SHOULD have an established connection with two peers per realm, known as the primary and secondary peers. Of course, a node MAY have additional connections, if it is deemed necessary. Typically, all messages for a realm are sent to the primary peer but, in the event that failover procedures are invoked, any pending requests are sent to the secondary peer. However, implementations are free to load balance requests between a set of peers.
Diameterノードには、通信可能なピアが多数ありますが、それらのすべてへの接続を確立するのは経済的ではない場合があります。 Diameterノードには、プライマリピアとセカンダリピアと呼ばれる、レルムごとに2つのピアとの接続が確立されている必要があります（SHOULD）。もちろん、必要と思われる場合、ノードには追加の接続があります。通常、レルムのすべてのメッセージはプライマリピアに送信されますが、フェイルオーバー手順が呼び出された場合、保留中の要求はすべてセカンダリピアに送信されます。ただし、実装はピアのセット間でリクエストを自由にロードバランスできます。
Note that a given peer MAY act as a primary for a given realm while acting as a secondary for another realm.
特定のピアが特定のレルムのプライマリとして機能し、別のレルムのセカンダリとして機能する場合があることに注意してください。
When a peer is deemed suspect, which could occur for various reasons, including not receiving a DWA within an allotted time frame, no new requests should be forwarded to the peer, but failover procedures are invoked. When an active peer is moved to this mode, additional connections SHOULD be established to ensure that the necessary number of active connections exists.
ピアが疑わしいと見なされると、割り当てられた時間枠内にDWAを受信しないなど、さまざまな理由で発生する可能性があります。ピアに新しい要求を転送する必要はありませんが、フェイルオーバー手順が呼び出されます。アクティブなピアがこのモードに移行すると、追加の接続を確立して、必要な数のアクティブな接続が存在することを確認する必要があります。
There are two ways that a peer is removed from the suspect peer list:
ピアが疑わしいピアリストから削除される方法は2つあります。
1. The peer is no longer reachable, causing the transport connection to be shut down. The peer is moved to the closed state.
1. ピアに到達できなくなったため、トランスポート接続がシャットダウンされました。ピアがクローズ状態に移行しました。
2. Three watchdog messages are exchanged with accepted round-trip times, and the connection to the peer is considered stabilized.
2. 3つのウォッチドッグメッセージが受け入れられた往復時間で交換され、ピアへの接続は安定していると見なされます。
In the event the peer being removed is either the primary or secondary, an alternate peer SHOULD replace the deleted peer and assume the role of either primary or secondary.
削除されるピアがプライマリまたはセカンダリのいずれかである場合、代替ピアは削除されたピアを置き換え、プライマリまたはセカンダリのいずれかの役割を担う必要があります（SHOULD）。
Allowing for dynamic Diameter agent discovery makes possible simpler and more robust deployment of Diameter services. In order to promote interoperable implementations of Diameter peer discovery, the following mechanisms (manual configuration and DNS) are described. These are based on existing IETF standards. Both mechanisms MUST be supported by all Diameter implementations; either MAY be used.
動的なDiameterエージェントの検出を可能にすることで、Diameterサービスのデプロイメントがより簡単で堅牢になります。 Diameterピアディスカバリの相互運用可能な実装を促進するために、次のメカニズム（手動構成とDNS）について説明します。これらは、既存のIETF標準に基づいています。両方のメカニズムは、すべてのDiameter実装でサポートされている必要があります。どちらを使用してもかまいません。
There are two cases where Diameter peer discovery may be performed. The first is when a Diameter client needs to discover a first-hop Diameter agent. The second case is when a Diameter agent needs to discover another agent for further handling of a Diameter operation. In both cases, the following 'search order' is recommended:
Diameterピアディスカバリが実行されるケースは2つあります。 1つ目は、Diameterクライアントが最初のホップのDiameterエージェントを検出する必要がある場合です。 2番目のケースは、Diameter操作をさらに処理するために、Diameterエージェントが別のエージェントを検出する必要がある場合です。どちらの場合も、次の「検索順序」が推奨されます。
1. The Diameter implementation consults its list of statically (manually) configured Diameter agent locations. These will be used if they exist and respond.
1. Diameterの実装は、静的（手動）に構成されたDiameterエージェントの場所のリストを調べます。これらは、存在して応答する場合に使用されます。
2. The Diameter implementation performs a NAPTR query for a server in a particular realm. The Diameter implementation has to know, in advance, in which realm to look for a Diameter agent. This could be deduced, for example, from the 'realm' in an NAI on which a Diameter implementation needed to perform a Diameter operation.
2. Diameter実装は、特定のレルムのサーバーに対してNAPTRクエリを実行します。 Diameterの実装では、Diameterエージェントを探すレルムを事前に知っておく必要があります。これは、たとえば、Diameter実装がDiameter操作を実行するために必要なNAIの「レルム」から推定できます。
The NAPTR usage in Diameter follows the S-NAPTR DDDS application [RFC3958] in which the SERVICE field includes tags for the desired application and supported application protocol. The application service tag for a Diameter application is 'aaa' and the supported application protocol tags are 'diameter.tcp', 'diameter.sctp', 'diameter.dtls', or 'diameter.tls.tcp' [RFC6408].
DiameterでのNAPTRの使用は、S-NAPTR DDDSアプリケーション[RFC3958]に従います。このサービスでは、SERVICEフィールドに目的のアプリケーションとサポートされているアプリケーションプロトコルのタグが含まれています。 Diameterアプリケーションのアプリケーションサービスタグは「aaa」で、サポートされているアプリケーションプロトコルタグは「diameter.tcp」、「diameter.sctp」、「diameter.dtls」、または「diameter.tls.tcp」です[RFC6408]。
The client can follow the resolution process defined by the S-NAPTR DDDS [RFC3958] application to find a matching SRV, A, or AAAA record of a suitable peer. The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. An example can be found in Appendix B.
クライアントは、S-NAPTR DDDS [RFC3958]アプリケーションで定義された解決プロセスに従って、適切なピアの一致するSRV、A、またはAAAAレコードを見つけることができます。 NAPTR置換フィールドのドメインサフィックスは、元のクエリのドメインと一致する必要があります（SHOULD）。例は付録Bにあります。
3. If no NAPTR records are found, the requester directly queries for one of the following SRV records: for Diameter over TCP, use "_diameter._tcp.realm"; for Diameter over TLS, use "_diameters._tcp.realm"; for Diameter over SCTP, use "_diameter._sctp.realm"; for Diameter over DTLS, use "_diameters._sctp.realm". If SRV records are found, then the requester can perform address record query (A RR's and/or AAAA RR's) for the target hostname specified in the SRV records following the rules given in [RFC2782]. If no SRV records are found, the requester gives up.
3. NAPTRレコードが見つからない場合、リクエスターは次のSRVレコードのいずれかを直接照会します。Diameterover TCPの場合は、「_ diameter._tcp.realm」を使用します。 Diameter over TLSの場合、 "_ diameters._tcp.realm"を使用します。 Diameter over SCTPの場合は、「_ diameter._sctp.realm」を使用します。 Diameter over DTLSの場合は、「_ diameters._sctp.realm」を使用します。 SRVレコードが見つかった場合、リクエスタは、[RFC2782]で規定されているルールに従って、SRVレコードで指定されたターゲットホスト名に対してアドレスレコードクエリ（A RRおよび/またはAAAA RR）を実行できます。 SRVレコードが見つからない場合、要求者はあきらめます。
If the server is using a site certificate, the domain name in the NAPTR query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS/TCP and DTLS/SCTP or Internet Key Exchange Protocol (IKE) exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate whether this was the desired behavior or the result of an attack.
サーバーがサイト証明書を使用している場合、NAPTRクエリのドメイン名と置換フィールドのドメイン名は両方とも、TLS / TCPおよびDTLS / SCTPまたはインターネットキーでサーバーから渡されたサイト証明書に基づいて有効である必要がありますExchange Protocol（IKE）交換。同様に、SRVクエリのドメイン名とSRVレコードのターゲットのドメイン名は、どちらも同じサイト証明書に基づいて有効である必要があります。そうでない場合、攻撃者はDNSレコードを変更して別のドメインの置換値を含めることができ、クライアントはこれが望ましい動作であるか攻撃の結果であるかを検証できません。
Also, the Diameter peer MUST check to make sure that the discovered peers are authorized to act in its role. Authentication via IKE or TLS/TCP and DTLS/SCTP, or validation of DNS RRs via DNSSEC is not sufficient to conclude this. For example, a web server may have obtained a valid TLS/TCP and DTLS/SCTP certificate, and secured RRs may be included in the DNS, but this does not imply that it is authorized to act as a Diameter server.
また、Diameterピアは、検出されたピアがその役割で動作することを承認されていることを確認する必要があります。 IKEまたはTLS / TCPおよびDTLS / SCTPによる認証、またはDNSSECによるDNS RRの検証は、これを結論付けるのに十分ではありません。たとえば、Webサーバーが有効なTLS / TCPおよびDTLS / SCTP証明書を取得していて、セキュリティで保護されたRRがDNSに含まれている場合がありますが、これは、Diameterサーバーとして機能する権限があることを意味するものではありません。
Authorization can be achieved, for example, by the configuration of a Diameter server Certification Authority (CA). The server CA issues a certificate to the Diameter server, which includes an Object Identifier (OID) to indicate the subject is a Diameter server in the Extended Key Usage extension [RFC5280]. This certificate is then used during TLS/TCP, DTLS/SCTP, or IKE security negotiation. However, note that, at the time of writing, no Diameter server Certification Authorities exist.
承認は、たとえば、Diameterサーバー認証局（CA）の構成によって実現できます。サーバーCAは、サブジェクトが拡張キー使用法拡張[RFC5280]のDiameterサーバーであることを示すオブジェクト識別子（OID）を含む証明書をDiameterサーバーに発行します。この証明書は、TLS / TCP、DTLS / SCTP、またはIKEのセキュリティネゴシエーション中に使用されます。ただし、これを書いている時点では、Diameterサーバー認証局は存在しないことに注意してください。
A dynamically discovered peer causes an entry in the peer table (see Section 2.6) to be created. Note that entries created via DNS MUST expire (or be refreshed) within the DNS Time to Live (TTL). If a peer is discovered outside of the local realm, a routing table entry (see Section 2.7) for the peer's realm is created. The routing table entry's expiration MUST match the peer's expiration value.
動的に検出されたピアにより、ピアテーブル（2.6節を参照）にエントリが作成されます。 DNSを介して作成されたエントリは、DNS存続可能時間（TTL）内に期限切れになる（または更新される）必要があります。ピアがローカルレルムの外部で検出されると、ピアのレルムのルーティングテーブルエントリ（セクション2.7を参照）が作成されます。ルーティングテーブルエントリの有効期限は、ピアの有効期限値と一致する必要があります。
When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages, as specified in the peer state machine (see Section 5.6). This message allows the discovery of a peer's identity and its capabilities (protocol version number, the identifiers of supported Diameter applications, security mechanisms, etc.).
2つのDiameterピアがトランスポート接続を確立するとき、ピアステートマシンで指定されているように、Capabilities Exchangeメッセージを交換する必要があります（セクション5.6を参照）。このメッセージにより、ピアのIDとその機能（プロトコルバージョン番号、サポートされるDiameterアプリケーションの識別子、セキュリティメカニズムなど）を検出できます。
The receiver only issues commands to its peers that have advertised support for the Diameter application that defines the command. A Diameter node MUST cache the supported Application Ids in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer.
レシーバーは、コマンドを定義するDiameterアプリケーションのサポートをアドバタイズしたピアにのみコマンドを発行します。 Diameterノードは、認識されていないコマンドやAVPが不必要にピアに送信されないようにするために、サポートされているアプリケーションIDをキャッシュする必要があります。
A receiver of a Capabilities-Exchange-Request (CER) message that does not have any applications in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION and SHOULD disconnect the transport layer connection. Note that receiving a CER or CEA from a peer advertising itself as a relay (see Section 2.4) MUST be interpreted as having common applications with the peer.
送信者と共通のアプリケーションを持たないCapabilities-Exchange-Request（CER）メッセージの受信者は、Result-Code AVPがDIAMETER_NO_COMMON_APPLICATIONに設定されたCapabilities-Exchange-Answer（CEA）を返さなければならず、トランスポート層を切断する必要があります（SHOULD）接続。自身をリレーとしてアドバタイズするピアからCERまたはCEAを受信すると（セクション2.4を参照）、ピアとの共通のアプリケーションがあると解釈する必要があることに注意してください。
The receiver of the Capabilities-Exchange-Request (CER) MUST determine common applications by computing the intersection of its own set of supported Application Ids against all of the Application-Id AVPs (Auth-Application-Id, Acct-Application-Id, and Vendor-Specific-Application-Id) present in the CER. The value of the Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used during computation. The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include all of its supported applications as a hint to the receiver regarding all of its application capabilities.
Capabilities-Exchange-Request（CER）の受信者は、すべてのApplication-Id AVP（Auth-Application-Id、Acct-Application-Id、およびVendor-Specific-Application-Id）がCERに存在します。 Vendor-Specific-Application-IdのVendor-Id AVPの値は、計算中に使用してはなりません（MUST NOT）。 Capabilities-Exchange-Answer（CEA）の送信者は、すべてのアプリケーション機能に関する受信者へのヒントとして、サポートされているすべてのアプリケーションを含める必要があります（SHOULD）。
Diameter implementations SHOULD first attempt to establish a TLS/TCP and DTLS/SCTP connection prior to the CER/CEA exchange. This protects the capabilities information of both peers. To support older Diameter implementations that do not fully conform to this document, the transport security MAY still be negotiated via an Inband-Security AVP. In this case, the receiver of a Capabilities-Exchange-Request (CER) message that does not have any security mechanisms in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY and SHOULD disconnect the transport layer connection.
Diameter実装は、CER / CEA交換の前に、最初にTLS / TCPおよびDTLS / SCTP接続の確立を試みる必要があります（SHOULD）。これにより、両方のピアの機能情報が保護されます。このドキュメントに完全に準拠していない古いDiameter実装をサポートするために、トランスポートセキュリティはインバンドセキュリティAVPを介して交渉される場合があります。この場合、送信者と共通のセキュリティメカニズムを持たないCapabilities-Exchange-Request（CER）メッセージの受信者は、Result-Code AVPがDIAMETER_NO_COMMON_SECURITYに設定されたCapabilities-Exchange-Answer（CEA）を返さなければなりません。トランスポート層の接続を切断する必要があります。
CERs received from unknown peers MAY be silently discarded, or a CEA MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. In both cases, the transport connection is closed. If the local policy permits receiving CERs from unknown hosts, a successful CEA MAY be returned. If a CER from an unknown peer is answered with a successful CEA, the lifetime of the peer entry is equal to the lifetime of the transport connection. In case of a transport failure, all the pending transactions destined to the unknown peer can be discarded.
不明なピアから受信したCERは通知なく破棄される場合があります。または、結果コードAVPがDIAMETER_UNKNOWN_PEERに設定されたCEAが発行される場合があります。どちらの場合も、トランスポート接続は閉じられます。ローカルポリシーが不明なホストからのCERの受信を許可している場合、成功したCEAが返される場合があります。不明なピアからのCERがCEAで成功した場合、ピアエントリのライフタイムはトランスポート接続のライフタイムと同じです。トランスポート障害が発生した場合、不明なピアを宛先とする保留中のトランザクションをすべて破棄できます。
The CER and CEA messages MUST NOT be proxied, redirected, or relayed.
CERおよびCEAメッセージは、プロキシ、リダイレクト、またはリレーしてはなりません。
Since the CER/CEA messages cannot be proxied, it is still possible that an upstream agent will receive a message for which it has no available peers to handle the application that corresponds to the Command Code. In such instances, the 'E' bit is set in the answer message (Section 7) with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER to inform the downstream agent to take action (e.g., re-routing request to an alternate peer).
CER / CEAメッセージはプロキシできないため、コマンドコードに対応するアプリケーションを処理するために使用できるピアがないメッセージを上流のエージェントが受信する可能性があります。このような場合、結果メッセージAVPがDIAMETER_UNABLE_TO_DELIVERに設定された応答メッセージ（セクション7）で「E」ビットが設定され、アクション（たとえば、代替ピアへの再ルーティング要求）をダウンストリームエージェントに通知します。
With the exception of the Capabilities-Exchange-Request message, a message of type Request that includes the Auth-Application-Id or Acct-Application-Id AVPs, or a message with an application-specific Command Code MAY only be forwarded to a host that has explicitly advertised support for the application (or has advertised the Relay Application Id).
Capabilities-Exchange-Requestメッセージを除いて、Auth-Application-IdまたはAcct-Application-Id AVPを含むリクエストタイプのメッセージ、またはアプリケーション固有のコマンドコードを含むメッセージは、ホストにのみ転送できます。アプリケーションのサポートを明示的にアドバタイズした（またはリレーアプリケーションIDをアドバタイズした）。
The Capabilities-Exchange-Request (CER), indicated by the Command Code set to 257 and the Command Flags' 'R' bit set, is sent to exchange local capabilities. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.
コマンドコードが257に設定され、コマンドフラグの「R」ビットがセットされていることで示されるCapabilities-Exchange-Request（CER）は、ローカル機能を交換するために送信されます。トランスポート障害の検出時に、このメッセージを代替ピアに送信してはならない（MUST NOT）。
When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083], which allow for connections to span multiple interfaces and multiple IP addresses, the Capabilities-Exchange-Request message MUST contain one Host-IP-Address AVP for each potential IP address that MAY be locally used when transmitting Diameter messages.
DiameterがSCTP [RFC4960]またはDTLS / SCTP [RFC6083]で実行される場合、接続が複数のインターフェースと複数のIPアドレスにまたがることができるため、Capabilities-Exchange-Requestメッセージには、潜在的なIPごとに1つのホストIPアドレスAVPが含まれているDiameterメッセージを送信するときにローカルで使用できるアドレス。
Message Format
メッセージフォーマット
<CER> ::= < Diameter Header: 257, REQ >
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]
The Capabilities-Exchange-Answer (CEA), indicated by the Command Code set to 257 and the Command Flags' 'R' bit cleared, is sent in response to a CER message.
コマンドコードが257に設定され、コマンドフラグの「R」ビットがクリアされていることで示されるCapabilities-Exchange-Answer（CEA）は、CERメッセージに応答して送信されます。
When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083], which allow connections to span multiple interfaces, hence, multiple IP addresses, the Capabilities-Exchange-Answer message MUST contain one Host-IP-Address AVP for each potential IP address that MAY be locally used when transmitting Diameter messages.
DiameterがSCTP [RFC4960]またはDTLS / SCTP [RFC6083]で実行されている場合、接続が複数のインターフェース、つまり複数のIPアドレスにまたがることができるため、Capabilities-Exchange-Answerメッセージには、可能性ごとに1つのホストIPアドレスAVPが含まれているDiameterメッセージの送信時にローカルで使用できるIPアドレス。
Message Format
メッセージフォーマット
<CEA> ::= < Diameter Header: 257 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
[ Error-Message ]
[ Failed-AVP ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]
The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [ENTERPRISE] value assigned to the Diameter Software vendor. It is envisioned that the combination of the Vendor-Id, Product-Name (Section 5.3.7), and Firmware-Revision (Section 5.3.4) AVPs may provide useful debugging information.
Vendor-Id AVP（AVPコード266）はタイプUnsigned32であり、Diameterソフトウェアベンダーに割り当てられたIANA "SMI Network Management Private Enterprise Codes" [ENTERPRISE]値が含まれています。 Vendor-Id、Product-Name（セクション5.3.7）、およびFirmware-Revision（セクション5.3.4）AVPの組み合わせは、有用なデバッグ情報を提供することが想定されています。
A Vendor-Id value of zero in the CER or CEA message is reserved and indicates that this field is ignored.
CERまたはCEAメッセージのVendor-Id値がゼロで予約されており、このフィールドが無視されることを示しています。
The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is used to inform a Diameter peer of the firmware revision of the issuing device.
ファームウェアリビジョンAVP（AVPコード267）はタイプUnsigned32であり、Diameterピアに発行デバイスのファームウェアリビジョンを通知するために使用されます。
For devices that do not have a firmware revision (general-purpose computers running Diameter software modules, for instance), the revision of the Diameter software module may be reported instead.
ファームウェアリビジョンのないデバイス（たとえば、Diameterソフトウェアモジュールを実行している汎用コンピューター）では、Diameterソフトウェアモジュールのリビジョンが代わりに報告される場合があります。
The Host-IP-Address AVP (AVP Code 257) is of type Address and is used to inform a Diameter peer of the sender's IP address. All source addresses that a Diameter node expects to use with SCTP [RFC4960] or DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages by including a Host-IP-Address AVP for each address.
Host-IP-Address AVP（AVPコード257）はアドレスタイプで、Diameterピアに送信者のIPアドレスを通知するために使用されます。 DiameterノードがSCTP [RFC4960]またはDTLS / SCTP [RFC6083]で使用することを期待しているすべての送信元アドレスは、各アドレスのホストIPアドレスAVPを含めることにより、CERおよびCEAメッセージでアドバタイズされなければなりません。
The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [ENTERPRISE] value assigned to a vendor other than the device vendor but including the application vendor. This is used in the CER and CEA messages in order to inform the peer that the sender supports (a subset of) the Vendor-Specific AVPs defined by the vendor identified in this AVP. The value of this AVP MUST NOT be set to zero. Multiple instances of this AVP containing the same value SHOULD NOT be sent.
Supported-Vendor-Id AVP（AVPコード265）はUnsigned32タイプであり、デバイスベンダー以外のベンダーに割り当てられたIANA "SMI Network Management Private Enterprise Codes" [ENTERPRISE]値が含まれていますが、アプリケーションベンダーも含まれます。これは、送信者がこのAVPで識別されたベンダーによって定義されたベンダー固有のAVP（のサブセット）をサポートすることをピアに通知するために、CERおよびCEAメッセージで使用されます。このAVPの値はゼロに設定してはなりません（MUST NOT）。同じ値を含むこのAVPの複数のインスタンスは送信してはなりません（SHOULD NOT）。
The Product-Name AVP (AVP Code 269) is of type UTF8String and contains the vendor-assigned name for the product. The Product-Name AVP SHOULD remain constant across firmware revisions for the same product.
Product-Name AVP（AVPコード269）はUTF8Stringタイプであり、ベンダーが割り当てた製品名が含まれています。 Product-Name AVPは、同じ製品のファームウェアリビジョン間で一定である必要があります（SHOULD）。
When a Diameter node disconnects one of its transport connections, its peer cannot know the reason for the disconnect and will most likely assume that a connectivity problem occurred or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in Section 2.1. In the event that the disconnect was a result of either a shortage of internal resources or simply that the node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future, a periodic connection request would not be welcomed. The Disconnection-Reason AVP contains the reason the Diameter node issued the Disconnect-Peer-Request message.
Diameterノードがトランスポート接続の1つを切断すると、そのピアは切断の理由を知ることができず、接続の問題が発生したか、ピアが再起動したと想定します。これらの場合、2.1節で述べたように、ピアは定期的に再接続を試みる場合があります。切断が内部リソースの不足の結果であった場合、または問題のノードが予見可能な将来にピアにDiameterメッセージを転送する意図がない場合、定期的な接続要求は歓迎されません。 Disconnection-Reason AVPには、DiameterノードがDisconnect-Peer-Requestメッセージを発行した理由が含まれています。
The Disconnect-Peer-Request message is used by a Diameter node to inform its peer of its intent to disconnect the transport layer and that the peer shouldn't reconnect unless it has a valid reason to do so (e.g., message to be forwarded). Upon receipt of the message, the Disconnect-Peer-Answer message is returned, which SHOULD contain an error if messages have recently been forwarded, and are likely in flight, which would otherwise cause a race condition.
Disconnect-Peer-Requestメッセージは、Diameterノードによって使用され、トランスポート層を切断する意図と、正当な理由がある場合（転送されるメッセージなど）がない限り、ピアが再接続してはならないことをピアに通知します。 。メッセージを受信すると、Disconnect-Peer-Answerメッセージが返されます。メッセージが最近転送された場合はエラーが含まれているはずであり、飛行中の可能性が高いため、競合状態が発生する可能性があります。
The receiver of the Disconnect-Peer-Answer message initiates the transport disconnect. The sender of the Disconnect-Peer-Answer message should be able to detect the transport closure and clean up the connection.
Disconnect-Peer-Answerメッセージの受信者は、トランスポートの切断を開始します。 Disconnect-Peer-Answerメッセージの送信者は、トランスポートの閉鎖を検出し、接続をクリーンアップできる必要があります。
The Disconnect-Peer-Request (DPR), indicated by the Command Code set to 282 and the Command Flags' 'R' bit set, is sent to a peer to inform it of its intentions to shut down the transport connection. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.
The Disconnect-Peer-Request (DPR), indicated by the Command Code set to 282 and the Command Flags' 'R' bit set, is sent to a peer to inform it of its intentions to shut down the transport connection. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.
Message Format
メッセージフォーマット
<DPR> ::= < Diameter Header: 282, REQ >
{ Origin-Host }
{ Origin-Realm }
{ Disconnect-Cause }
* [ AVP ]
The Disconnect-Peer-Answer (DPA), indicated by the Command Code set to 282 and the Command Flags' 'R' bit cleared, is sent as a response to the Disconnect-Peer-Request message. Upon receipt of this message, the transport connection is shut down.
Disconnect-Peer-Requestメッセージへの応答として、コマンドコードが282に設定され、コマンドフラグの「R」ビットがクリアされることで示されるDisconnect-Peer-Answer（DPA）が送信されます。このメッセージを受信すると、トランスポート接続がシャットダウンされます。
Message Format
メッセージフォーマット
<DPA> ::= < Diameter Header: 282 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
[ Failed-AVP ]
* [ AVP ]
The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A Diameter node MUST include this AVP in the Disconnect-Peer-Request message to inform the peer of the reason for its intention to shut down the transport connection. The following values are supported:
Disconnect-Cause AVP（AVPコード273）は列挙型です。 Diameterノードは、トランスポート接続をシャットダウンする意図の理由をピアに通知するために、Disconnect-Peer-RequestメッセージにこのAVPを含める必要があります。次の値がサポートされています。
REBOOTING 0 A scheduled reboot is imminent. A receiver of a DPR with above result code MAY attempt reconnection.
再起動0スケジュールされた再起動が間近に迫っています。上記の結果コードを持つDPRの受信者は、再接続を試みる場合があります。
BUSY 1 The peer's internal resources are constrained, and it has determined that the transport connection needs to be closed. A receiver of a DPR with above result code SHOULD NOT attempt reconnection.
BUSY 1ピアの内部リソースに制約があり、トランスポート接続を閉じる必要があると判断しました。上記の結果コードを持つDPRの受信者は、再接続を試みるべきではありません（SHOULD NOT）。
DO_NOT_WANT_TO_TALK_TO_YOU 2 The peer has determined that it does not see a need for the transport connection to exist, since it does not expect any messages to be exchanged in the near future. A receiver of a DPR with above result code SHOULD NOT attempt reconnection.
DO_NOT_WANT_TO_TALK_TO_YOU 2ピアは、近い将来メッセージが交換されることを予期していないため、トランスポート接続が存在する必要がないと判断しました。上記の結果コードを持つDPRの受信者は、再接続を試みるべきではありません（SHOULD NOT）。
Given the nature of the Diameter protocol, it is recommended that transport failures be detected as soon as possible. Detecting such failures will minimize the occurrence of messages sent to unavailable agents, resulting in unnecessary delays, and will provide better failover performance. The Device-Watchdog-Request and Device-Watchdog-Answer messages, defined in this section, are used to pro-actively detect transport failures.
Diameterプロトコルの性質を考えると、トランスポート障害はできるだけ早く検出することをお勧めします。このような障害を検出すると、使用できないエージェントに送信されるメッセージの発生が最小限に抑えられ、不要な遅延が発生し、フェイルオーバーのパフォーマンスが向上します。このセクションで定義されているDevice-Watchdog-RequestおよびDevice-Watchdog-Answerメッセージは、トランスポート障害を予防的に検出するために使用されます。
The Device-Watchdog-Request (DWR), indicated by the Command Code set to 280 and the Command Flags' 'R' bit set, is sent to a peer when no traffic has been exchanged between two peers (see Section 5.5.3). Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.
280に設定されたコマンドコードとコマンドフラグの「R」ビットセットで示されるデバイスウォッチドッグ要求（DWR）は、2つのピア間でトラフィックが交換されていない場合にピアに送信されます（セクション5.5.3を参照）。 。トランスポート障害の検出時に、このメッセージを代替ピアに送信してはならない（MUST NOT）。
Message Format
メッセージフォーマット
<DWR> ::= < Diameter Header: 280, REQ >
{ Origin-Host }
{ Origin-Realm }
[ Origin-State-Id ]
* [ AVP ]
The Device-Watchdog-Answer (DWA), indicated by the Command Code set to 280 and the Command Flags' 'R' bit cleared, is sent as a response to the Device-Watchdog-Request message.
コマンドコードが280に設定され、コマンドフラグの「R」ビットがクリアされることで示されるデバイスウォッチドッグ応答（DWA）は、デバイスウォッチドッグ要求メッセージへの応答として送信されます。
Message Format
メッセージフォーマット
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
[ Failed-AVP ]
[ Origin-State-Id ]
* [ AVP ]
The transport failure algorithm is defined in [RFC3539]. All Diameter implementations MUST support the algorithm defined in that specification in order to be compliant to the Diameter base protocol.
トランスポート障害アルゴリズムは、[RFC3539]で定義されています。すべてのDiameter実装は、Diameter基本プロトコルに準拠するために、その仕様で定義されたアルゴリズムをサポートする必要があります。
In the event that a transport failure is detected with a peer, it is necessary for all pending request messages to be forwarded to an alternate agent, if possible. This is commonly referred to as "failover".
ピアでトランスポート障害が検出された場合、可能であれば、保留中のすべての要求メッセージを代替エージェントに転送する必要があります。これは一般に「フェイルオーバー」と呼ばれます。
In order for a Diameter node to perform failover procedures, it is necessary for the node to maintain a pending message queue for a given peer. When an answer message is received, the corresponding request is removed from the queue. The Hop-by-Hop Identifier field is used to match the answer with the queued request.
Diameterノードがフェイルオーバー手順を実行するには、ノードが特定のピアの保留メッセージキューを維持する必要があります。応答メッセージが受信されると、対応する要求がキューから削除されます。ホップバイホップ識別子フィールドは、応答をキューに入れられた要求と照合するために使用されます。
When a transport failure is detected, if possible, all messages in the queue are sent to an alternate agent with the T flag set. On booting a Diameter client or agent, the T flag is also set on any remaining records in non-volatile storage that are still waiting to be transmitted. An example of a case where it is not possible to forward the message to an alternate server is when the message has a fixed destination, and the unavailable peer is the message's final destination (see Destination-Host AVP). Such an error requires that the agent return an answer message with the 'E' bit set and the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
トランスポート障害が検出されると、可能であれば、キュー内のすべてのメッセージがTフラグが設定された代替エージェントに送信されます。 Diameterクライアントまたはエージェントの起動時に、Tフラグは、送信を待機している不揮発性ストレージの残りのレコードにも設定されます。メッセージを代替サーバーに転送できない場合の例は、メッセージの宛先が固定で、利用できないピアがメッセージの最終宛先である場合です（宛先ホストAVPを参照）。このようなエラーでは、エージェントが「E」ビットが設定され、Result-Code AVPがDIAMETER_UNABLE_TO_DELIVERに設定された応答メッセージを返す必要があります。
It is important to note that multiple identical requests or answers MAY be received as a result of a failover. The End-to-End Identifier field in the Diameter header along with the Origin-Host AVP MUST be used to identify duplicate messages.
フェイルオーバーの結果として、複数の同一の要求または応答が受信される場合があることに注意することが重要です。 DiameterヘッダーのEnd-to-End IdentifierフィールドとOrigin-Host AVPを使用して、重複メッセージを識別しなければなりません（MUST）。
As described in Section 2.1, a connection request should be periodically attempted with the failed peer in order to re-establish the transport connection. Once a connection has been successfully established, messages can once again be forwarded to the peer. This is commonly referred to as "failback".
セクション2.1で説明したように、トランスポート接続を再確立するために、障害が発生したピアで接続要求を定期的に試行する必要があります。接続が正常に確立されると、メッセージを再びピアに転送できます。これは一般に「フェイルバック」と呼ばれます。
This section contains a finite state machine that MUST be observed by all Diameter implementations. Each Diameter node MUST follow the state machine described below when communicating with each peer. Multiple actions are separated by commas, and may continue on succeeding lines, as space requires. Similarly, state and next state may also span multiple lines, as space requires.
このセクションには、すべてのDiameter実装で監視する必要がある有限状態マシンが含まれています。各Diameterノードは、各ピアと通信するときに、以下で説明するステートマシンに従う必要があります。複数のアクションはコンマで区切られ、スペースが必要なため、後続の行に続く場合があります。同様に、状態に応じて、状態と次の状態も複数の行にまたがることがあります。
This state machine is closely coupled with the state machine described in [RFC3539], which is used to open, close, failover, probe, and reopen transport connections. In particular, note that [RFC3539] requires the use of watchdog messages to probe connections. For Diameter, DWR and DWA messages are to be used.
このステートマシンは、[RFC3539]で説明されているステートマシンと密接に結合しており、トランスポート接続のオープン、クローズ、フェイルオーバー、プローブ、および再オープンに使用されます。特に、[RFC3539]では、接続を調査するためにウォッチドッグメッセージを使用する必要があることに注意してください。 Diameterの場合、DWRおよびDWAメッセージが使用されます。
The I- prefix is used to represent the initiator (connecting) connection, while the R- prefix is used to represent the responder (listening) connection. The lack of a prefix indicates that the event or action is the same regardless of the connection on which the event occurred.
I-プレフィックスはイニシエーター（接続）接続を表すために使用され、R-プレフィックスはレスポンダー（リスニング）接続を表すために使用されます。接頭辞がないことは、イベントが発生した接続に関係なく、イベントまたはアクションが同じであることを示します。
The stable states that a state machine may be in are Closed, I-Open, and R-Open; all other states are intermediate. Note that I-Open and R-Open are equivalent except for whether the initiator or responder transport connection is used for communication.
ステートマシンが存在する可能性のある安定状態は、Closed、I-Open、およびR-Openです。他のすべての状態は中間です。 I-OpenとR-Openは、通信にイニシエータートランスポート接続とレスポンダートランスポート接続のどちらを使用するかを除いて同等であることに注意してください。
A CER message is always sent on the initiating connection immediately after the connection request is successfully completed. In the case of an election, one of the two connections will shut down. The responder connection will survive if the Origin-Host of the local Diameter entity is higher than that of the peer; the initiator connection will survive if the peer's Origin-Host is higher. All subsequent messages are sent on the surviving connection. Note that the results of an election on one peer are guaranteed to be the inverse of the results on the other.
CERメッセージは、接続要求が正常に完了した直後に、常に開始接続で送信されます。選挙の場合、2つの接続のうちの1つがシャットダウンします。ローカルDiameterエンティティのOrigin-HostがピアのOrigin-Hostよりも高い場合、レスポンダ接続は存続します。ピアのOrigin-Hostの方が高い場合、イニシエーター接続は存続します。後続のすべてのメッセージは、残っている接続で送信されます。 1つのピアでの選挙の結果は、他のピアでの結果の逆になることが保証されていることに注意してください。
For TLS/TCP and DTLS/SCTP usage, a TLS/TCP and DTLS/SCTP handshake SHOULD begin when both ends are in the closed state prior to any Diameter message exchanges. The TLS/TCP and DTLS/SCTP connection SHOULD be established before sending any CER or CEA message to secure and protect the capabilities information of both peers. The TLS/TCP and DTLS/SCTP connection SHOULD be disconnected when the state machine moves to the closed state. When connecting to responders that do not conform to this document (i.e., older Diameter implementations that are not prepared to received TLS/TCP and DTLS/ SCTP connections in the closed state), the initial TLS/TCP and DTLS/ SCTP connection attempt will fail. The initiator MAY then attempt to connect via TCP or SCTP and initiate the TLS/TCP and DTLS/SCTP handshake when both ends are in the open state. If the handshake is successful, all further messages will be sent via TLS/TCP and DTLS/ SCTP. If the handshake fails, both ends move to the closed state.
TLS / TCPおよびDTLS / SCTPを使用する場合、TLS / TCPおよびDTLS / SCTPハンドシェイクは、Diameterメッセージ交換の前に両端がクローズ状態にあるときに開始する必要があります（SHOULD）。 TLS / TCPおよびDTLS / SCTP接続は、両方のピアの機能情報を保護および保護するために、CERまたはCEAメッセージを送信する前に確立する必要があります（SHOULD）。状態マシンがクローズ状態に移行するとき、TLS / TCPおよびDTLS / SCTP接続を切断する必要があります（SHOULD）。このドキュメントに準拠していないレスポンダに接続すると（つまり、クローズ状態でTLS / TCPおよびDTLS / SCTP接続を受信する準備ができていない古いDiameter実装）、最初のTLS / TCPおよびDTLS / SCTP接続の試行は失敗します。次に、イニシエーターは、TCPまたはSCTPを介して接続を試み、両端がオープン状態のときにTLS / TCPおよびDTLS / SCTPハンドシェイクを開始することができます。ハンドシェイクが成功した場合、以降のすべてのメッセージはTLS / TCPおよびDTLS / SCTPを介して送信されます。ハンドシェイクが失敗すると、両端がクローズ状態に移行します。
The state machine constrains only the behavior of a Diameter implementation as seen by Diameter peers through events on the wire.
ステートマシンは、Diameterピアがワイヤ上のイベントを介して見たときに、Diameter実装の動作のみを制約します。
Any implementation that produces equivalent results is considered compliant.
同等の結果を生成する実装は、準拠していると見なされます。
state event action next state
-----------------------------------------------------------------
Closed Start I-Snd-Conn-Req Wait-Conn-Ack
R-Conn-CER R-Accept, R-Open
Process-CER,
R-Snd-CEA
Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA I-Rcv-Conn-Nack Cleanup Closed R-Conn-CER R-Accept, Wait-Conn-Ack/ Process-CER Elect Timeout Error Closed
Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA I-Rcv-Conn-Nack Cleanup Closed R-Conn-CER R-Accept、Wait-Conn-Ack / Process-CER Electタイムアウトエラーが終了しました
Wait-I-CEA I-Rcv-CEA Process-CEA I-Open R-Conn-CER R-Accept, Wait-Returns Process-CER, Elect I-Peer-Disc I-Disc Closed I-Rcv-Non-CEA Error Closed Timeout Error Closed
Wait-I-CEA I-Rcv-CEA Process-CEA I-Open R-Conn-CER R-Accept、Wait-Returns Process-CER、Elect I-Peer-Disc I-Disc Closed I-Rcv-Non-CEA Errorクローズタイムアウトエラークローズ
Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open R-Peer-Disc R-Disc Wait-Conn-Ack R-Conn-CER R-Reject Wait-Conn-Ack/ Elect Timeout Error Closed
Wait-Conn-Ack / I-Rcv-Conn-Ack I-Snd-CER、Elect Wait-Returns Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open R-Peer-Disc R-Disc Wait-Conn -Ack R-Conn-CER R-Reject Wait-Conn-Ack / Elect Timeout Error Closed
Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open I-Peer-Disc I-Disc, R-Open R-Snd-CEA I-Rcv-CEA R-Disc I-Open R-Peer-Disc R-Disc Wait-I-CEA R-Conn-CER R-Reject Wait-Returns Timeout Error Closed
Win-Election I-Disc、R-Snd-CEA R-Open I-Peer-Disc I-Disc、R-Open R-Snd-CEA I-Rcv-CEA R-Disc I-Open R-Peer-ディスクR-ディスク待機-I-CEA R-接続-CER R-拒否待機-戻りタイムアウトエラーが終了しました
R-Open Send-Message R-Snd-Message R-Open R-Rcv-Message Process R-Open R-Rcv-DWR Process-DWR, R-Open R-Snd-DWA R-Rcv-DWA Process-DWA R-Open R-Conn-CER R-Reject R-Open Stop R-Snd-DPR Closing R-Rcv-DPR R-Snd-DPA Closing R-Peer-Disc R-Disc Closed
R-Open Send-Message R-Snd-Message R-Open R-Rcv-Message Process R-Open R-Rcv-DWR Process-DWR、R-Open R-Snd-DWA R-Rcv-DWA Process-DWA R-オープンR-Conn-CER R-リジェクトR-オープンストップR-Snd-DPRクローズR-Rcv-DPR R-Snd-DPAクローズR-Peer-Disc R-Discクローズ
I-Open Send-Message I-Snd-Message I-Open I-Rcv-Message Process I-Open I-Rcv-DWR Process-DWR, I-Open I-Snd-DWA I-Rcv-DWA Process-DWA I-Open R-Conn-CER R-Reject I-Open Stop I-Snd-DPR Closing I-Rcv-DPR I-Snd-DPA Closing I-Peer-Disc I-Disc Closed
I-Open Send-Message I-Snd-Message I-Open I-Rcv-Message Process I-Open I-Rcv-DWR Process-DWR、I-Open I-Snd-DWA I-Rcv-DWA Process-DWA I-オープンR-Conn-CER R-リジェクトI-オープンストップI-Snd-DPRクローズI-Rcv-DPR I-Snd-DPAクローズI-ピア-ディスクI-ディスククローズ
Closing I-Rcv-DPA I-Disc Closed R-Rcv-DPA R-Disc Closed Timeout Error Closed I-Peer-Disc I-Disc Closed R-Peer-Disc R-Disc Closed
クローズI-Rcv-DPA I-Disc Closed R-Rcv-DPA R-Disc ClosedタイムアウトエラーClosed I-Peer-Disc I-Disc Closed R-Peer-Disc R-Disc Closed
When a connection request is received from a Diameter peer, it is not, in the general case, possible to know the identity of that peer until a CER is received from it. This is because host and port determine the identity of a Diameter peer; the source port of an incoming connection is arbitrary. Upon receipt of a CER, the identity of the connecting peer can be uniquely determined from the Origin-Host.
接続要求がDiameterピアから受信された場合、一般的には、CERが受信されるまで、そのピアのIDを知ることはできません。これは、ホストとポートがDiameterピアのIDを決定するためです。着信接続の送信元ポートは任意です。 CERを受信すると、接続ピアのIDは、Origin-Hostから一意に決定できます。
For this reason, a Diameter peer must employ logic separate from the state machine to receive connection requests, accept them, and await the CER. Once the CER arrives on a new connection, the Origin-Host that identifies the peer is used to locate the state machine associated with that peer, and the new connection and CER are passed to the state machine as an R-Conn-CER event.
このため、Diameterピアは、ステートマシンとは別のロジックを使用して、接続要求を受信し、それらを受け入れ、CERを待機する必要があります。 CERが新しい接続に到着すると、ピアを識別するOrigin-Hostを使用して、そのピアに関連付けられたステートマシンが検索され、新しい接続とCERがR-Conn-CERイベントとしてステートマシンに渡されます。
The logic that handles incoming connections SHOULD close and discard the connection if any message other than a CER arrives or if an implementation-defined timeout occurs prior to receipt of CER.
着信接続を処理するロジックは、CER以外のメッセージが到着した場合、またはCERの受信前に実装定義のタイムアウトが発生した場合、接続を閉じて破棄する必要があります（SHOULD）。
Because handling of incoming connections up to and including receipt of a CER requires logic, separate from that of any individual state machine associated with a particular peer, it is described separately in this section rather than in the state machine above.
CERの受信までの着信接続の処理には、特定のピアに関連付けられた個々のステートマシンとは別のロジックが必要であるため、上記のステートマシンではなく、このセクションで個別に説明します。
Transitions and actions in the automaton are caused by events. In this section, we will ignore the I- and R- prefixes, since the actual event would be identical, but it would occur on one of two possible connections.
Transitions and actions in the automaton are caused by events. In this section, we will ignore the I- and R- prefixes, since the actual event would be identical, but it would occur on one of two possible connections.
Start The Diameter application has signaled that a connection should be initiated with the peer.
開始Diameterアプリケーションが、ピアとの接続を開始する必要があることを通知しました。
R-Conn-CER An acknowledgement is received stating that the transport connection has been established, and the associated CER has arrived.
R-Conn-CERトランスポート接続が確立され、関連するCERが到着したことを示す確認が受信されます。
Rcv-Conn-Ack A positive acknowledgement is received confirming that the transport connection is established.
Rcv-Conn-Ackトランスポート接続が確立されたことを確認する肯定応答が受信されます。
Rcv-Conn-Nack A negative acknowledgement was received stating that the transport connection was not established.
Rcv-Conn-Nackトランスポート接続が確立されなかったことを示す否定応答が受信されました。
Timeout An application-defined timer has expired while waiting for some event.
タイムアウト何らかのイベントを待機している間に、アプリケーション定義のタイマーが満了しました。
Rcv-CER A CER message from the peer was received.
Rcv-CERピアからのCERメッセージが受信されました。
Rcv-CEA A CEA message from the peer was received.
Rcv-CEAピアからのCEAメッセージを受信しました。
Rcv-Non-CEA A message, other than a CEA, from the peer was received.
Rcv-Non-CEAピアからCEA以外のメッセージが受信されました。
Peer-Disc A disconnection indication from the peer was received.
Peer-Discピアからの切断指示を受信しました。
Rcv-DPR A DPR message from the peer was received.
Rcv-DPRピアからのDPRメッセージが受信されました。
Rcv-DPA A DPA message from the peer was received.
Rcv-DPAピアからのDPAメッセージが受信されました。
Win-Election An election was held, and the local node was the winner.
勝利選挙選挙が行われ、ローカルノードが勝者となりました。
Send-Message A message is to be sent.
Send-Messageメッセージが送信されます。
Rcv-Message A message other than CER, CEA, DPR, DPA, DWR, or DWA was received.
Rcv-Message CER、CEA、DPR、DPA、DWR、またはDWA以外のメッセージが受信されました。
Stop The Diameter application has signaled that a connection should be terminated (e.g., on system shutdown).
停止Diameterアプリケーションが、接続を終了する必要があることを通知しました（システムのシャットダウン時など）。
Actions in the automaton are caused by events and typically indicate the transmission of packets and/or an action to be taken on the connection. In this section, we will ignore the I- and R- prefixes, since the actual action would be identical, but it would occur on one of two possible connections.
オートマトンのアクションはイベントによって引き起こされ、通常はパケットの送信や接続で行われるアクションを示します。このセクションでは、実際のアクションは同じであるため、I-およびR-プレフィックスは無視しますが、2つの可能な接続のいずれかで発生します。
Snd-Conn-Req A transport connection is initiated with the peer.
Snd-Conn-Reqトランスポート接続がピアで開始されました。
Accept The incoming connection associated with the R-Conn-CER is accepted as the responder connection.
Accept R-Conn-CERに関連付けられた着信接続は、レスポンダ接続として受け入れられます。
Reject The incoming connection associated with the R-Conn-CER is disconnected.
拒否R-Conn-CERに関連付けられた着信接続が切断されます。
Process-CER The CER associated with the R-Conn-CER is processed.
Process-CER R-Conn-CERに関連付けられたCERが処理されます。
Snd-CER A CER message is sent to the peer.
Snd-CER CERメッセージがピアに送信されます。
Snd-CEA A CEA message is sent to the peer.
Snd-CEA A CEA message is sent to the peer.
Cleanup If necessary, the connection is shut down, and any local resources are freed.
クリーンアップ必要に応じて、接続がシャットダウンされ、ローカルリソースが解放されます。
Error The transport layer connection is disconnected, either politely or abortively, in response to an error condition. Local resources are freed.
エラートランスポート層接続は、エラー状態に応じて、丁寧にまたは中止して切断されます。ローカルリソースが解放されます。
Process-CEA A received CEA is processed.
Process-CEA受信したCEAが処理されます。
Snd-DPR A DPR message is sent to the peer.
Snd-DPR DPRメッセージがピアに送信されます。
Snd-DPA A DPA message is sent to the peer.
Snd-DPA DPAメッセージがピアに送信されます。
Disc The transport layer connection is disconnected, and local resources are freed.
Discトランスポート層の接続が切断され、ローカルリソースが解放されます。
Elect An election occurs (see Section 5.6.4 for more information).
選出選挙が行われます（詳細は、セクション5.6.4を参照）。
Snd-Message A message is sent.
Snd-Messageメッセージが送信されます。
Snd-DWR A DWR message is sent.
Snd-DWR DWRメッセージが送信されます。
Snd-DWA A DWA message is sent.
Snd-DWA A DWA message is sent.
Process-DWR The DWR message is serviced.
Process-DWR DWRメッセージが処理されます。
Process-DWA The DWA message is serviced.
Process-DWA DWAメッセージが処理されます。
Process A message is serviced.
プロセスメッセージが処理されます。
The election is performed on the responder. The responder compares the Origin-Host received in the CER with its own Origin-Host as two streams of octets. If the local Origin-Host lexicographically succeeds the received Origin-Host, a Win-Election event is issued locally. Diameter identities are in ASCII form; therefore, the lexical comparison is consistent with DNS case insensitivity, where octets that fall in the ASCII range 'a' through 'z' MUST compare equally to their uppercase counterparts between 'A' and 'Z'. See Appendix D for interactions between the Diameter protocol and Internationalized Domain Name (IDNs).
選挙はレスポンダーで行われます。レスポンダは、CERで受信したOrigin-Hostを、オクテットの2つのストリームとして独自のOrigin-Hostと比較します。ローカルのOrigin-Hostが辞書順に受信されたOrigin-Hostを継承すると、Win-Electionイベントがローカルで発行されます。直径IDはASCII形式です。したがって、字句の比較はDNSの大文字と小文字を区別しないことに一致します。ASCIIの範囲「a」から「z」に入るオクテットは、「A」と「Z」の間の対応する大文字と同等に比較する必要があります。 Diameterプロトコルと国際化ドメイン名（IDN）の間の相互作用については、付録Dを参照してください。
The winner of the election MUST close the connection it initiated. Historically, maintaining the responder side of a connection was more efficient than maintaining the initiator side. However, current practices makes this distinction irrelevant.
選挙の勝者は、それが開始した接続を閉じる必要があります。従来、接続のレスポンダー側を維持する方が、イニシエーター側を維持するよりも効率的でした。ただし、現在の慣行では、この区別は重要ではありません。
This section describes how Diameter requests and answers are created and processed.
このセクションでは、Diameter要求と応答がどのように作成および処理されるかについて説明します。
A request is sent towards its final destination using one of the following three combinations of the Destination-Realm and Destination-Host AVPs:
Destination-RealmとDestination-Host AVPの次の3つの組み合わせのいずれかを使用して、リクエストが最終的な宛先に送信されます。
o A request that is not able to be proxied (such as a CER) MUST NOT contain either Destination-Realm or Destination-Host AVPs.
o プロキシできないリクエスト（CERなど）には、Destination-RealmまたはDestination-Host AVPを含めることはできません。
o A request that needs to be sent to a home server serving a specific realm, but not to a specific server (such as the first request of a series of round trips), MUST contain a Destination-Realm AVP but MUST NOT contain a Destination-Host AVP. For Diameter clients, the value of the Destination-Realm AVP MAY be extracted from the User-Name AVP, or other methods.
o A request that needs to be sent to a home server serving a specific realm, but not to a specific server (such as the first request of a series of round trips), MUST contain a Destination-Realm AVP but MUST NOT contain a Destination-Host AVP. For Diameter clients, the value of the Destination-Realm AVP MAY be extracted from the User-Name AVP, or other methods.
o Otherwise, a request that needs to be sent to a specific home server among those serving a given realm MUST contain both the Destination-Realm and Destination-Host AVPs.
o それ以外の場合、特定のレルムにサービスを提供しているサーバーの中で特定のホームサーバーに送信する必要がある要求には、Destination-RealmとDestination-Host AVPの両方が含まれている必要があります。
The Destination-Host AVP is used as described above when the destination of the request is fixed, which includes:
Destination-Host AVPは、リクエストの宛先が次のように固定されている場合に、上記のように使用されます。
o Authentication requests that span multiple round trips.
o 複数のラウンドトリップにまたがる認証リクエスト。
o A Diameter message that uses a security mechanism that makes use of a pre-established session key shared between the source and the final destination of the message.
o メッセージの送信元と最終的な送信先の間で共有される事前に確立されたセッションキーを利用するセキュリティメカニズムを使用するDiameterメッセージ。
o Server-initiated messages that MUST be received by a specific Diameter client (e.g., access device), such as the Abort-Session-Request message, which is used to request that a particular user's session be terminated.
o 特定のユーザーのセッションの終了を要求するために使用されるAbort-Session-Requestメッセージなど、特定のDiameterクライアント（アクセスデバイスなど）が受信する必要があるサーバー起動メッセージ。
Note that an agent can only forward a request to a host described in the Destination-Host AVP if the host in question is included in its peer table (see Section 2.6). Otherwise, the request is routed based on the Destination-Realm only (see Section 6.1.6).
問題のホストがそのピアテーブルに含まれている場合（セクション2.6を参照）、エージェントはDestination-Host AVPに記述されているホストにのみリクエストを転送できることに注意してください。それ以外の場合、要求は宛先レルムのみに基づいてルーティングされます（セクション6.1.6を参照）。
When a message is received, the message is processed in the following order:
メッセージを受信すると、メッセージは次の順序で処理されます。
o If the message is destined for the local host, the procedures listed in Section 6.1.4 are followed.
o メッセージの宛先がローカルホストの場合は、セクション6.1.4に記載されている手順に従います。
o If the message is intended for a Diameter peer with whom the local host is able to directly communicate, the procedures listed in Section 6.1.5 are followed. This is known as "Request Forwarding".
o メッセージがローカルホストが直接通信できるDiameterピアを対象としている場合は、セクション6.1.5に記載されている手順に従います。これは「リクエスト転送」として知られています。
o The procedure listed in Section 6.1.6 is followed, which is known as "Request Routing".
o セクション6.1.6にリストされている手順に従います。これは「リクエストルーティング」として知られています。
o If none of the above are successful, an answer is returned with the Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the 'E' bit set.
o 上記のいずれも成功しなかった場合は、結果コードがDIAMETER_UNABLE_TO_DELIVERに設定され、「E」ビットが設定された応答が返されます。
For routing of Diameter messages to work within an administrative domain, all Diameter nodes within the realm MUST be peers.
Diameterメッセージのルーティングが管理ドメイン内で機能するには、レルム内のすべてのDiameterノードがピアである必要があります。
The overview contained in this section (6.1) is intended to provide general guidelines to Diameter developers. Implementations are free to use different methods than the ones described here as long as they conform to the requirements specified in Sections 6.1.1 through 6.1.9. See Section 7 for more details on error handling.
このセクション（6.1）に含まれる概要は、Diameter開発者に一般的なガイドラインを提供することを目的としています。実装は、セクション6.1.1から6.1.9で指定された要件に準拠している限り、ここで説明されている方法とは異なる方法を自由に使用できます。エラー処理の詳細については、セクション7を参照してください。
When creating a request, in addition to any other procedures described in the application definition for that specific request, the following procedures MUST be followed: o the Command Code is set to the appropriate value;
リクエストを作成するときは、その特定のリクエストのアプリケーション定義で説明されている他の手順に加えて、次の手順に従う必要があります。oコマンドコードが適切な値に設定されている。
o the 'R' bit is set;
o 「R」ビットが設定されます。
o the End-to-End Identifier is set to a locally unique value;
o エンドツーエンド識別子はローカルで一意の値に設定されます。
o the Origin-Host and Origin-Realm AVPs MUST be set to the appropriate values, used to identify the source of the message; and
o Origin-HostおよびOrigin-Realm AVPは、メッセージのソースを識別するために使用される適切な値に設定する必要があります。そして
o the Destination-Host and Destination-Realm AVPs MUST be set to the appropriate values, as described in Section 6.1.
o セクション6.1で説明されているように、宛先ホストと宛先レルムAVPは適切な値に設定する必要があります。
When sending a request, originated either locally or as the result of a forwarding or routing operation, the following procedures SHOULD be followed:
ローカルで、または転送またはルーティング操作の結果として発生した要求を送信するときは、次の手順に従う必要があります。
o The Hop-by-Hop Identifier SHOULD be set to a locally unique value.
o ホップバイホップ識別子は、ローカルで一意の値に設定する必要があります（SHOULD）。
o The message SHOULD be saved in the list of pending requests.
o メッセージは、保留中のリクエストのリストに保存する必要があります（SHOULD）。
Other actions to perform on the message based on the particular role the agent is playing are described in the following sections.
次のセクションでは、エージェントが果たしている特定の役割に基づいてメッセージに対して実行するその他のアクションについて説明します。
A relay or proxy agent MUST check for forwarding loops when receiving requests. A loop is detected if the server finds its own identity in a Route-Record AVP. When such an event occurs, the agent MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.
リレーまたはプロキシエージェントは、リクエストを受信したときに転送ループをチェックする必要があります。サーバーがRoute-Record AVPで独自のIDを見つけた場合、ループが検出されます。このようなイベントが発生した場合、エージェントは、結果コードAVPをDIAMETER_LOOP_DETECTEDに設定して応答する必要があります。
A request is known to be for local consumption when one of the following conditions occurs:
次のいずれかの条件が発生した場合、リクエストはローカルでの消費であることがわかっています。
o The Destination-Host AVP contains the local host's identity;
o Destination-Host AVPには、ローカルホストのIDが含まれています。
o The Destination-Host AVP is not present, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported; or
o Destination-Host AVPが存在せず、Destination-Realm AVPには、サーバーがローカルで処理するように構成されているレルムが含まれており、Diameterアプリケーションがローカルでサポートされている。または
o Both the Destination-Host and the Destination-Realm are not present.
o 宛先ホストと宛先レルムの両方が存在しません。
When a request is locally processed, the rules in Section 6.2 should be used to generate the corresponding answer.
リクエストがローカルで処理される場合、セクション6.2のルールを使用して、対応する回答を生成する必要があります。
Request forwarding is done using the Diameter peer table. The Diameter peer table contains all of the peers with which the local node is able to directly communicate.
要求の転送は、Diameterピアテーブルを使用して行われます。 Diameterピアテーブルには、ローカルノードが直接通信できるすべてのピアが含まれています。
When a request is received, and the host encoded in the Destination-Host AVP is one that is present in the peer table, the message SHOULD be forwarded to the peer.
リクエストが受信され、Destination-Host AVPでエンコードされたホストがピアテーブルに存在する場合、メッセージはピアに転送されるべきです（SHOULD）。
Diameter request message routing is done via realms and Application Ids. A Diameter message that may be forwarded by Diameter agents (proxies, redirect agents, or relay agents) MUST include the target realm in the Destination-Realm AVP. Request routing SHOULD rely on the Destination-Realm AVP and the Application Id present in the request message header to aid in the routing decision. The realm MAY be retrieved from the User-Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP.
Diameterリクエストメッセージのルーティングは、レルムとアプリケーションIDを介して行われます。 Diameterエージェント（プロキシ、リダイレクトエージェント、またはリレーエージェント）によって転送されるDiameterメッセージには、Destination-Realm AVPにターゲットレルムを含める必要があります。リクエストルーティングは、ルーティングの決定を支援するために、リクエストメッセージヘッダーにある宛先レルムAVPとアプリケーションIDに依存する必要があります（SHOULD）。レルムは、ネットワークアクセス識別子（NAI）の形式のユーザー名AVPから取得できます（MAY）。 NAIのレルム部分は、宛先レルムAVPに挿入されます。
Diameter agents MAY have a list of locally supported realms and applications, and they MAY have a list of externally supported realms and applications. When a request is received that includes a realm and/or application that is not locally supported, the message is routed to the peer configured in the routing table (see Section 2.7).
Diameterエージェントは、ローカルでサポートされているレルムとアプリケーションのリストを持っている場合があり（MAY）、外部でサポートされているレルムとアプリケーションのリストを持っている場合があります（MAY）。ローカルでサポートされていないレルムやアプリケーションを含む要求を受信すると、メッセージはルーティングテーブルで構成されたピアにルーティングされます（セクション2.7を参照）。
Realm names and Application Ids are the minimum supported routing criteria, additional information may be needed to support redirect semantics.
レルム名とアプリケーションIDは、サポートされる最小のルーティング基準です。リダイレクトセマンティクスをサポートするには、追加情報が必要になる場合があります。
Before forwarding or routing a request, Diameter agents, in addition to performing the processing described in Section 6.1.3, SHOULD check for the presence of a candidate route's peer identity in any of the Route-Record AVPs. In the event of the agent detecting the presence of a candidate route's peer identity in a Route-Record AVP, the agent MUST ignore such a route for the Diameter request message and attempt alternate routes if any exist. In case all the candidate routes are eliminated by the above criteria, the agent SHOULD return a DIAMETER_UNABLE_TO_DELIVER message.
Diameterエージェントは、リクエストを転送またはルーティングする前に、セクション6.1.3で説明されている処理を実行することに加えて、ルートレコードAVPのいずれかに候補ルートのピアIDが存在するかどうかを確認する必要があります。エージェントがRoute-Record AVPで候補ルートのピアIDの存在を検出した場合、エージェントは、Diameterリクエストメッセージのそのようなルートを無視し、存在する場合は代替ルートを試行する必要があります。上記の基準によってすべての候補ルートが削除された場合、エージェントはDIAMETER_UNABLE_TO_DELIVERメッセージを返す必要があります。
When a redirect agent receives a request whose routing entry is set to REDIRECT, it MUST reply with an answer message with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header, and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of the servers associated with the routing entry are added in a separate Redirect-Host AVP.
リダイレクトエージェントは、ルーティングエントリがREDIRECTに設定されている要求を受信すると、ヘッダーにホップバイホップ識別子を維持しながら、「E」ビットが設定された応答メッセージで応答し、結果コードAVPを含める必要があります。 DIAMETER_REDIRECT_INDICATIONに。ルーティングエントリに関連付けられている各サーバーは、個別のリダイレクトホストAVPに追加されます。
+------------------+
| Diameter |
| Redirect Agent |
+------------------+
^ | 2. command + 'E' bit
1. Request | | Result-Code =
joe@example.com | | DIAMETER_REDIRECT_INDICATION +
| | Redirect-Host AVP(s)
| v
+-------------+ 3. Request +-------------+
| example.com |------------->| example.net |
| Relay | | Diameter |
| Agent |<-------------| Server |
+-------------+ 4. Answer +-------------+
Figure 5: Diameter Redirect Agent
Figure 5: Diameter Redirect Agent
The receiver of an answer message with the 'E' bit set and the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the Hop-by-Hop Identifier in the Diameter header to identify the request in the pending message queue (see Section 5.5.4) that is to be redirected. If no transport connection exists with the new peer, one is created, and the request is sent directly to it.
「E」ビットが設定され、Result-Code AVPがDIAMETER_REDIRECT_INDICATIONに設定された応答メッセージの受信者は、Diameterヘッダーのホップバイホップ識別子を使用して、保留中のメッセージキュー内の要求を識別します（5.5.4を参照）リダイレクトされます。新しいピアとのトランスポート接続が存在しない場合は、トランスポート接続が作成され、要求が直接ピアに送信されます。
Multiple Redirect-Host AVPs are allowed. The receiver of the answer message with the 'E' bit set selects exactly one of these hosts as the destination of the redirected message.
複数のリダイレクトホストAVPが許可されます。 「E」ビットが設定された応答メッセージの受信者は、リダイレクトされたメッセージの宛先としてこれらのホストの1つだけを選択します。
When the Redirect-Host-Usage AVP included in the answer message has a non-zero value, a route entry for the redirect indications is created and cached by the receiver. The redirect usage for such a route entry is set by the value of Redirect-Host-Usage AVP and the lifetime of the cached route entry is set by Redirect-Max-Cache-Time AVP value.
応答メッセージに含まれるRedirect-Host-Usage AVPの値がゼロ以外の場合、リダイレクトインジケーションのルートエントリが作成され、レシーバーによってキャッシュされます。このようなルートエントリのリダイレクトの使用は、Redirect-Host-Usage AVPの値によって設定され、キャッシュされたルートエントリのライフタイムは、Redirect-Max-Cache-Time AVP値によって設定されます。
It is possible that multiple redirect indications can create multiple cached route entries differing only in their redirect usage and the peer to forward messages to. As an example, two(2) route entries that are created by two(2) redirect indications results in two(2) cached routes for the same realm and Application Id. However, one has a redirect usage of ALL_SESSION, where matching requests will be forwarded to one peer; the other has a redirect usage of ALL_REALM, where request are forwarded to another peer. Therefore, an incoming request that matches the realm and Application Id of both routes will need additional resolution. In such a case, a routing precedence rule MUST be used against the redirect usage value to resolve the contention. The precedence rule can be found in Section 6.13.
複数のリダイレクト指示が、リダイレクトの使用法とメッセージの転送先のピアのみが異なる複数のキャッシュされたルートエントリを作成する可能性があります。例として、two（2）リダイレクト指示によって作成されたtwo（2）ルートエントリは、同じレルムとアプリケーションIDのtwo（2）キャッシュされたルートになります。ただし、ALL_SESSIONのリダイレクト使用法があり、一致する要求が1つのピアに転送されます。もう1つはALL_REALMのリダイレクト使用法で、リクエストは別のピアに転送されます。したがって、両方のルートのレルムとアプリケーションIDに一致する受信リクエストは、追加の解決が必要になります。このような場合、競合を解決するために、リダイレクト使用量の値に対してルーティング優先ルールを使用する必要があります。優先ルールはセクション6.13にあります。
A relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer from which the request was received.
リレーまたはプロキシエージェントは、転送されるすべてのリクエストにRoute-Record AVPを追加する必要があります。 AVPには、要求の受信元のピアのIDが含まれています。
The Hop-by-Hop Identifier in the request is saved and replaced with a locally unique value. The source of the request is also saved, which includes the IP address, port, and protocol.
リクエスト内のホップバイホップ識別子は保存され、ローカルで一意の値に置き換えられます。リクエストのソースも保存されます。これには、IPアドレス、ポート、プロトコルが含まれます。
A relay or proxy agent MAY include the Proxy-Info AVP in requests if it requires access to any local state information when the corresponding response is received. The Proxy-Info AVP has security implications as state information is distributed to other entities. As such, it is RECOMMENDED that the content of the Proxy-Info AVP be protected with cryptographic mechanisms, for example, by using a keyed message digest such as HMAC-SHA1 [RFC2104]. Such a mechanism, however, requires the management of keys, although only locally at the Diameter server. Still, a full description of the management of the keys used to protect the Proxy-Info AVP is beyond the scope of this document. Below is a list of common recommendations:
リレーまたはプロキシエージェントは、対応する応答を受信したときにローカル状態情報にアクセスする必要がある場合、リクエストにProxy-Info AVPを含めることができます。状態情報が他のエンティティに配信されるため、Proxy-Info AVPはセキュリティに影響します。そのため、Proxy-Info AVPのコンテンツは、たとえばHMAC-SHA1 [RFC2104]などのキー付きメッセージダイジェストを使用することによって、暗号化メカニズムで保護することをお勧めします。ただし、このようなメカニズムでは、Diameterサーバーでのみローカルにキーを管理する必要があります。それでも、Proxy-Info AVPを保護するために使用されるキーの管理の完全な説明は、このドキュメントの範囲を超えています。以下は、一般的な推奨事項のリストです。
o The keys should be generated securely following the randomness recommendations in [RFC4086].
o 鍵は、[RFC4086]のランダム性の推奨事項に従って安全に生成する必要があります。
o The keys and cryptographic protection algorithms should be at least 128 bits in strength.
o 鍵と暗号保護アルゴリズムは、少なくとも128ビットの強度である必要があります。
o The keys should not be used for any other purpose than generating and verifying instances of the Proxy-Info AVP.
o キーは、Proxy-Info AVPのインスタンスの生成と検証以外の目的で使用しないでください。
o The keys should be changed regularly.
o キーは定期的に変更する必要があります。
o The keys should be changed if the AVP format or cryptographic protection algorithms change.
o AVP形式または暗号化保護アルゴリズムが変更された場合は、キーを変更する必要があります。
The message is then forwarded to the next hop, as identified in the routing table.
次に、メッセージはルーティングテーブルで識別された次のホップに転送されます。
Figure 6 provides an example of message routing using the procedures listed in these sections.
図6は、これらのセクションにリストされている手順を使用したメッセージルーティングの例を示しています。
(Origin-Host=nas.example.net) (Origin-Host=nas.example.net)
(Origin-Realm=example.net) (Origin-Realm=example.net)
(Destination-Realm=example.com) (Destination-Realm=example.com)
(Route-Record=nas.example.net)
+------+ ------> +------+ ------> +------+
| | (Request) | | (Request) | |
| NAS +-------------------+ DRL +-------------------+ HMS |
| | | | | |
+------+ <------ +------+ <------ +------+
example.net (Answer) example.net (Answer) example.com
(Origin-Host=hms.example.com) (Origin-Host=hms.example.com)
(Origin-Realm=example.com) (Origin-Realm=example.com)
Figure 6: Routing of Diameter messages
図6：Diameterメッセージのルーティング
Relay and proxy agents are not required to perform full inspection of incoming messages. At a minimum, validation of the message header and relevant routing AVPs has to be done when relaying messages. Proxy agents may optionally perform more in-depth message validation for applications in which it is interested.
リレーおよびプロキシエージェントは、着信メッセージの完全な検査を実行する必要はありません。メッセージをリレーする場合、少なくとも、メッセージヘッダーと関連するルーティングAVPの検証を行う必要があります。プロキシエージェントは、必要に応じて、アプリケーションの詳細なメッセージ検証をオプションで実行できます。
When a request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command:
リクエストがローカルで処理されるとき、コマンドを定義するDiameterアプリケーションで説明される可能性がある追加の手順に加えて、関連する回答を作成するために次の手順を適用する必要があります。
o The same Hop-by-Hop Identifier in the request is used in the answer.
o リクエストでは同じホップバイホップ識別子が回答で使用されます。
o The local host's identity is encoded in the Origin-Host AVP.
o ローカルホストのIDは、Origin-Host AVPでエンコードされます。
o The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message.
o Destination-HostおよびDestination-Realm AVPは、応答メッセージに存在してはなりません。
o The Result-Code AVP is added with its value indicating success or failure.
o Result-Code AVPに、成功または失敗を示す値が追加されます。
o If the Session-Id is present in the request, it MUST be included in the answer.
o リクエストにSession-Idが存在する場合は、それを回答に含める必要があります。
o Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request.
o 要求内のすべてのProxy-Info AVPは、要求内に存在したのと同じ順序で、応答メッセージに追加する必要があります。
o The 'P' bit is set to the same value as the one in the request.
o 「P」ビットは、要求のビットと同じ値に設定されます。
o The same End-to-End identifier in the request is used in the answer.
o 要求では、同じエンドツーエンド識別子が応答で使用されます。
Note that the error messages (see Section 7) are also subjected to the above processing rules.
エラーメッセージ（セクション7を参照）も上記の処理規則に従うことに注意してください。
A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an answer received against the list of pending requests. The corresponding message should be removed from the list of pending requests. It SHOULD ignore answers received that do not match a known Hop-by-Hop Identifier.
Diameterクライアントまたはプロキシは、保留中のリクエストのリストに対して受信した応答のホップバイホップ識別子と一致する必要があります。対応するメッセージは、保留中のリクエストのリストから削除する必要があります。既知のホップバイホップ識別子と一致しない受信した回答は無視する必要があります。
If the answer is for a request that was proxied or relayed, the agent MUST restore the original value of the Diameter header's Hop-by-Hop Identifier field.
応答がプロキシまたはリレーされた要求に対するものである場合、エージェントは、Diameterヘッダーのホップバイホップ識別子フィールドの元の値を復元する必要があります。
If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded.
メッセージ内の最後のProxy-Info AVPがローカルDiameterサーバーを対象としている場合、回答が転送される前にAVPを削除する必要があります。
If a relay or proxy agent receives an answer with a Result-Code AVP indicating a failure, it MUST NOT modify the contents of the AVP. Any additional local errors detected SHOULD be logged but not reflected in the Result-Code AVP. If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST modify the Result-Code AVP to contain the appropriate error in the message destined towards the access device as well as include the Error-Reporting-Host AVP; it MUST also issue an STR on behalf of the access device towards the Diameter server.
リレーまたはプロキシエージェントが、失敗を示す結果コードAVPを含む応答を受信した場合、AVPの内容を変更してはなりません。検出された追加のローカルエラーはログに記録される必要がありますが、結果コードAVPには反映されません。エージェントが成功を示すResult-Code AVPを含む応答メッセージを受信し、エラーを示すようにAVPを変更したい場合、アクセスデバイス宛てのメッセージに適切なエラーが含まれるようにResult-Code AVPを変更する必要があります。 Error-Reporting-Host AVPも含まれます。また、アクセスデバイスの代わりにDiameterサーバーに向けてSTRを発行する必要があります。
The agent MUST then send the answer to the host that it received the original request from.
その後、エージェントは、元の要求を受け取ったホストに応答を送信する必要があります。
The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and it MUST be present in all Diameter messages. This AVP identifies the endpoint that originated the Diameter message. Relay agents MUST NOT modify this AVP.
Origin-Host AVP（AVPコード264）はDiameterIdentityタイプであり、すべてのDiameterメッセージに存在する必要があります。このAVPは、Diameterメッセージを発信したエンドポイントを識別します。リレーエージェントはこのAVPを変更してはなりません。
The value of the Origin-Host AVP is guaranteed to be unique within a single host.
Origin-Host AVPの値は、単一のホスト内で一意であることが保証されています。
Note that the Origin-Host AVP may resolve to more than one address as the Diameter peer may support more than one address.
Diameterピアが複数のアドレスをサポートしている場合があるため、Origin-Host AVPは複数のアドレスに解決される場合があることに注意してください。
This AVP SHOULD be placed as close to the Diameter header as possible.
このAVPは、Diameterヘッダーのできるだけ近くに配置する必要があります（SHOULD）。
The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity. This AVP contains the Realm of the originator of any Diameter message and MUST be present in all messages.
The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity. This AVP contains the Realm of the originator of any Diameter message and MUST be present in all messages.
This AVP SHOULD be placed as close to the Diameter header as possible.
このAVPは、Diameterヘッダーのできるだけ近くに配置する必要があります（SHOULD）。
The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. This AVP MUST be present in all unsolicited agent initiated messages, MAY be present in request messages, and MUST NOT be present in answer messages.
宛先ホストAVP（AVPコード293）のタイプはDiameterIdentityです。このAVPは、要請されていないエージェントが開始したすべてのメッセージに存在する必要があり、要求メッセージに存在する場合があり、応答メッセージに存在してはならない（MUST NOT）。
The absence of the Destination-Host AVP will cause a message to be sent to any Diameter server supporting the application within the realm specified in Destination-Realm AVP.
Destination-Host AVPがない場合、Destination-Realm AVPで指定されたレルム内のアプリケーションをサポートするすべてのDiameterサーバーにメッセージが送信されます。
This AVP SHOULD be placed as close to the Diameter header as possible.
このAVPは、Diameterヘッダーのできるだけ近くに配置する必要があります（SHOULD）。
The Destination-Realm AVP (AVP Code 283) is of type DiameterIdentity and contains the realm to which the message is to be routed. The Destination-Realm AVP MUST NOT be present in answer messages. Diameter clients insert the realm portion of the User-Name AVP. Diameter servers initiating a request message use the value of the Origin-Realm AVP from a previous message received from the intended target host (unless it is known a priori). When present, the Destination-Realm AVP is used to perform message routing decisions.
Destination-Realm AVP（AVPコード283）のタイプはDiameterIdentityで、メッセージのルーティング先のレルムが含まれています。 Destination-Realm AVPは、応答メッセージに存在してはなりません。 Diameterクライアントは、User-Name AVPのレルム部分を挿入します。要求メッセージを開始するDiameterサーバーは、（事前にわかっている場合を除いて）対象のターゲットホストから受信した前のメッセージのOrigin-Realm AVPの値を使用します。存在する場合、宛先レルムAVPはメッセージルーティングの決定を実行するために使用されます。
The CCF for a request message that includes the Destination-Realm AVP SHOULD list the Destination-Realm AVP as a required AVP (an AVP indicated as {AVP}); otherwise, the message is inherently a non-routable message.
Destination-Realm AVPを含む要求メッセージのCCFは、Destination-Realm AVPを必須のAVP（{AVP}として示されるAVP）としてリストする必要があります（SHOULD）。それ以外の場合、メッセージは本質的にルーティング不可能なメッセージです。
This AVP SHOULD be placed as close to the Diameter header as possible.
このAVPは、Diameterヘッダーのできるだけ近くに配置する必要があります（SHOULD）。
The AVPs defined in this section are Diameter AVPs used for routing purposes. These AVPs change as Diameter messages are processed by agents.
The AVPs defined in this section are Diameter AVPs used for routing purposes. These AVPs change as Diameter messages are processed by agents.
The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The identity added in this AVP MUST be the same as the one received in the Origin-Host of the Capabilities Exchange message.
The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The identity added in this AVP MUST be the same as the one received in the Origin-Host of the Capabilities Exchange message.
The Proxy-Info AVP (AVP Code 284) is of type Grouped. This AVP contains the identity and local state information of the Diameter node that creates and adds it to a message. The Grouped Data field has the following CCF grammar:
Proxy-Info AVP（AVPコード284）のタイプはGroupedです。このAVPには、メッセージを作成してメッセージに追加するDiameterノードのIDとローカル状態情報が含まれています。 Grouped Dataフィールドには、次のCCF文法があります。
Proxy-Info ::= < AVP Header: 284 >
{ Proxy-Host }
{ Proxy-State }
* [ AVP ]
The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. This AVP contains the identity of the host that added the Proxy-Info AVP.
Proxy-Host AVP（AVPコード280）のタイプはDiameterIdentityです。このAVPには、Proxy-Info AVPを追加したホストのIDが含まれています。
The Proxy-State AVP (AVP Code 33) is of type OctetString. It contains state information that would otherwise be stored at the Diameter entity that created it. As such, this AVP MUST be treated as opaque data by other Diameter entities.
Proxy-State AVP（AVPコード33）のタイプはOctetStringです。これには、それを作成したDiameterエンティティに保存されるはずの状態情報が含まれています。そのため、このAVPは他のDiameterエンティティによって不透明なデータとして扱われる必要があります。
The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used in order to advertise support of the Authentication and Authorization portion of an application (see Section 2.4). If present in a message other than CER and CEA, the value of the Auth-Application-Id AVP MUST match the Application Id present in the Diameter message header.
Auth-Application-Id AVP（AVPコード258）はタイプUnsigned32であり、アプリケーションの認証および承認部分のサポートをアドバタイズするために使用されます（セクション2.4を参照）。 CERおよびCEA以外のメッセージに存在する場合、Auth-Application-Id AVPの値は、Diameterメッセージヘッダーに存在するアプリケーションIDと一致する必要があります。
The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and is used in order to advertise support of the accounting portion of an application (see Section 2.4). If present in a message other than CER and CEA, the value of the Acct-Application-Id AVP MUST match the Application Id present in the Diameter message header.
Acct-Application-Id AVP（AVPコード259）はタイプUnsigned32であり、アプリケーションのアカウンティング部分のサポートをアドバタイズするために使用されます（セクション2.4を参照）。 CERおよびCEA以外のメッセージに存在する場合、Acct-Application-Id AVPの値は、Diameterメッセージヘッダーに存在するアプリケーションIDと一致する必要があります。
The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and is used in order to advertise support of the security portion of the application. The use of this AVP in CER and CEA messages is NOT RECOMMENDED. Instead, discovery of a Diameter entity's security capabilities can be done either through static configuration or via Diameter Peer Discovery as described in Section 5.2.
Inband-Security-Id AVP（AVPコード299）はタイプUnsigned32であり、アプリケーションのセキュリティ部分のサポートをアドバタイズするために使用されます。このAVPをCERおよびCEAメッセージで使用することはお勧めしません。代わりに、セクション5.2で説明されているように、Diameterエンティティのセキュリティ機能の検出は、静的構成またはDiameterピア検出のいずれかを介して実行できます。
The following values are supported:
次の値がサポートされています。
NO_INBAND_SECURITY 0
NO_INBAND_SECURITY 0
This peer does not support TLS/TCP and DTLS/SCTP. This is the default value, if the AVP is omitted.
This peer does not support TLS/TCP and DTLS/SCTP. This is the default value, if the AVP is omitted.
TLS 1
TLS 1
This node supports TLS/TCP [RFC5246] and DTLS/SCTP [RFC6083] security.
このノードは、TLS / TCP [RFC5246]およびDTLS / SCTP [RFC6083]セキュリティをサポートします。
The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter application. Exactly one instance of either Auth-Application-Id or Acct-Application-Id AVP MUST be present. The Application Id carried by either Auth-Application-Id or Acct-Application-Id AVP MUST comply with vendor-specific Application Id assignment described in Section 11.3. It MUST also match the Application Id present in the Diameter header except when used in a CER or CEA message.
Vendor-Specific-Application-Id AVP（AVPコード260）はGroupedタイプであり、ベンダー固有のDiameterアプリケーションのサポートをアドバタイズするために使用されます。 Auth-Application-IdまたはAcct-Application-Id AVPのいずれか1つのインスタンスが存在する必要があります。 Auth-Application-IdまたはAcct-Application-Id AVPのいずれかによって運ばれるアプリケーションIDは、セクション11.3で説明されているベンダー固有のアプリケーションID割り当てに準拠する必要があります。また、CERまたはCEAメッセージで使用される場合を除いて、Diameterヘッダーに存在するアプリケーションIDと一致する必要があります。
The Vendor-Id AVP is an informational AVP pertaining to the vendor who may have authorship of the vendor-specific Diameter application. It MUST NOT be used as a means of defining a completely separate vendor-specific Application Id space.
Vendor-Id AVPは、ベンダー固有のDiameterアプリケーションの作成者である可能性があるベンダーに関連する情報AVPです。完全に別個のベンダー固有のアプリケーションIDスペースを定義する手段として使用してはなりません（MUST NOT）。
The Vendor-Specific-Application-Id AVP SHOULD be placed as close to the Diameter header as possible.
The Vendor-Specific-Application-Id AVP SHOULD be placed as close to the Diameter header as possible.
AVP Format
AVPフォーマット
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
{ Vendor-Id }
[ Auth-Application-Id ]
[ Acct-Application-Id ]
A Vendor-Specific-Application-Id AVP MUST contain exactly one of either Auth-Application-Id or Acct-Application-Id. If a Vendor-Specific-Application-Id is received without one of these two AVPs, then the recipient SHOULD issue an answer with a Result-Code set to DIAMETER_MISSING_AVP. The answer SHOULD also include a Failed-AVP, which MUST contain an example of an Auth-Application-Id AVP and an Acct-Application-Id AVP.
Vendor-Specific-Application-Id AVPには、Auth-Application-IdまたはAcct-Application-Idのいずれか1つを含める必要があります。 Vendor-Specific-Application-Idがこれら2つのAVPのいずれかなしで受信された場合、受信者はResult-CodeをDIAMETER_MISSING_AVPに設定して応答を発行する必要があります。回答には、Failed-AVPも含まれる必要があります。これには、Auth-Application-Id AVPとAcct-Application-Id AVPの例が含まれている必要があります。
If a Vendor-Specific-Application-Id is received that contains both Auth-Application-Id and Acct-Application-Id, then the recipient MUST issue an answer with Result-Code set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer MUST also include a Failed-AVP, which MUST contain the received Auth-Application-Id AVP and Acct-Application-Id AVP.
Auth-Application-IdとAcct-Application-Idの両方を含むVendor-Specific-Application-Idを受信した場合、受信者はResult-CodeをDIAMETER_AVP_OCCURS_TOO_MANY_TIMESに設定して応答を発行する必要があります。回答にはFailed-AVPも含める必要があります。これには、受信したAuth-Application-Id AVPおよびAcct-Application-Id AVPが含まれている必要があります。
The Redirect-Host AVP (AVP Code 292) is of type DiameterURI. One or more instances of this AVP MUST be present if the answer message's 'E' bit is set and the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
The Redirect-Host AVP (AVP Code 292) is of type DiameterURI. One or more instances of this AVP MUST be present if the answer message's 'E' bit is set and the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
Upon receiving the above, the receiving Diameter node SHOULD forward the request directly to one of the hosts identified in these AVPs. The server contained in the selected Redirect-Host AVP SHOULD be used for all messages matching the criteria set by the Redirect-Host-Usage AVP.
上記を受信すると、受信側のDiameterノードは、これらのAVPで識別されたホストの1つにリクエストを直接転送する必要があります（SHOULD）。選択されたRedirect-Host AVPに含まれるサーバーは、Redirect-Host-Usage AVPによって設定された基準に一致するすべてのメッセージに使用されるべきです（SHOULD）。
The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated. This AVP MAY be present in answer messages whose 'E' bit is set and the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
Redirect-Host-Usage AVP（AVPコード261）は、列挙型です。このAVPは、「E」ビットが設定され、結果コードAVPがDIAMETER_REDIRECT_INDICATIONに設定されている応答メッセージに存在する場合があります。
When present, this AVP provides hints about how the routing entry resulting from the Redirect-Host is to be used. The following values are supported: DONT_CACHE 0
存在する場合、このAVPは、Redirect-Hostに起因するルーティングエントリがどのように使用されるかについてのヒントを提供します。次の値がサポートされています：DONT_CACHE 0
The host specified in the Redirect-Host AVP SHOULD NOT be cached. This is the default value.
Redirect-Host AVPで指定されたホストはキャッシュされるべきではない（SHOULD NOT）。これがデフォルト値です。
ALL_SESSION 1
ALL_SESSION 1
All messages within the same session, as defined by the same value of the Session-ID AVP SHOULD be sent to the host specified in the Redirect-Host AVP.
同じセッション内のすべてのメッセージは、Session-ID AVPの同じ値で定義されているように、Redirect-Host AVPで指定されたホストに送信する必要があります（SHOULD）。
ALL_REALM 2
ALL_REALM 2
All messages destined for the realm requested SHOULD be sent to the host specified in the Redirect-Host AVP.
レルム宛てのすべてのメッセージは、リダイレクトホストAVPで指定されたホストに送信する必要があります（SHOULD）。
REALM_AND_APPLICATION 3
REALM_AND_APPLICATION 3
All messages for the application requested to the realm specified SHOULD be sent to the host specified in the Redirect-Host AVP.
指定されたレルムに要求されたアプリケーションのすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信される必要があります。
ALL_APPLICATION 4
ALL_APPLICATION 4
All messages for the application requested SHOULD be sent to the host specified in the Redirect-Host AVP.
要求されたアプリケーションのすべてのメッセージは、リダイレクトホストAVPで指定されたホストに送信する必要があります（SHOULD）。
ALL_HOST 5
ALL_HOST 5
All messages that would be sent to the host that generated the Redirect-Host SHOULD be sent to the host specified in the Redirect-Host AVP.
Redirect-Hostを生成したホストに送信されるすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信される必要があります（SHOULD）。
ALL_USER 6
ALL_USER 6
All messages for the user requested SHOULD be sent to the host specified in the Redirect-Host AVP.
要求されたユーザーのすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信する必要があります（SHOULD）。
When multiple cached routes are created by redirect indications and they differ only in redirect usage and peers to forward requests to (see Section 6.1.8), a precedence rule MUST be applied to the redirect usage values of the cached routes during normal routing to resolve contentions that may occur. The precedence rule is the order that dictate which redirect usage should be considered before any other as they appear. The order is as follows: 1. ALL_SESSION
リダイレクトインジケーションによって複数のキャッシュされたルートが作成され、リダイレクトの使用法とリクエストを転送するピアのみが異なる場合（セクション6.1.8を参照）、解決するために、通常のルーティング中にキャッシュされたルートのリダイレクト使用値に優先ルールを適用する必要があります。発生する可能性のある競合。優先ルールは、どのリダイレクトの使用が他のどの表示よりも先に考慮されるかを決定する順序です。順序は次のとおりです。1. ALL_SESSION
2. ALL_USER
2. すべてのユーザー
3. REALM_AND_APPLICATION
3. REALM_AND_APPLICATION
4. ALL_REALM
4. ALL_REALM
5. ALL_APPLICATION
5. ALL_APPLICATION
6. ALL_HOST
6. ALL_HOST
The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32. This AVP MUST be present in answer messages whose 'E' bit is set, whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and whose Redirect-Host-Usage AVP set to a non-zero value.
Redirect-Max-Cache-Time AVP（AVPコード262）のタイプはUnsigned32です。このAVPは、「E」ビットが設定され、Result-Code AVPがDIAMETER_REDIRECT_INDICATIONに設定され、Redirect-Host-Usage AVPがゼロ以外の値に設定された応答メッセージに存在する必要があります。
This AVP contains the maximum number of seconds the peer and route table entries, created as a result of the Redirect-Host, SHOULD be cached. Note that once a host is no longer reachable, any associated cache, peer, and routing table entries MUST be deleted.
このAVPには、リダイレクトホストの結果として作成されたピアおよびルートテーブルエントリの最大秒数が含まれており、キャッシュする必要があります（SHOULD）。ホストに到達できなくなったら、関連するキャッシュ、ピア、ルーティングテーブルのエントリを削除する必要があることに注意してください。
There are two different types of errors in Diameter; protocol errors and application errors. A protocol error is one that occurs at the base protocol level and MAY require per-hop attention (e.g., a message routing error). Application errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application (e.g., user authentication, missing AVP).
Diameterには2種類のエラーがあります。プロトコルエラーとアプリケーションエラー。プロトコルエラーは、ベースプロトコルレベルで発生するエラーであり、ホップごとの注意が必要になる場合があります（メッセージルーティングエラーなど）。一方、アプリケーションエラーは、Diameterアプリケーションで指定された機能の問題（ユーザー認証、AVPの欠落など）が原因で発生します。
Result-Code AVP values that are used to report protocol errors MUST only be present in answer messages whose 'E' bit is set. When a request message is received that causes a protocol error, an answer message is returned with the 'E' bit set, and the Result-Code AVP is set to the appropriate protocol error value. As the answer is sent back towards the originator of the request, each proxy or relay agent MAY take action on the message.
プロトコルエラーの報告に使用されるResult-Code AVP値は、「E」ビットが設定されている応答メッセージにのみ存在する必要があります。プロトコルエラーの原因となる要求メッセージが受信されると、「E」ビットが設定された応答メッセージが返され、結果コードAVPが適切なプロトコルエラー値に設定されます。応答が要求の発信者に返送されると、各プロキシまたはリレーエージェントはメッセージに対してアクションを実行できます（MAY）。
1. Request +---------+ Link Broken
+-------------------------->|Diameter |----///----+
| +---------------------| | v
+------+--+ | 2. answer + 'E' set | Relay 2 | +--------+
|Diameter |<-+ (Unable to Forward) +---------+ |Diameter|
| | | Home |
| Relay 1 |--+ +---------+ | Server |
+---------+ | 3. Request |Diameter | +--------+
+-------------------->| | ^
| Relay 3 |-----------+
+---------+
Figure 7: Example of Protocol Error Causing Answer Message
図7：応答メッセージを引き起こすプロトコルエラーの例
Figure 7 provides an example of a message forwarded upstream by a Diameter relay. When the message is received by Relay 2, and it detects that it cannot forward the request to the home server, an answer message is returned with the 'E' bit set and the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the protocol error category, Relay 1 would take special action, and given the error, attempt to route the message through its alternate Relay 3.
図7は、Diameterリレーによってアップストリームに転送されるメッセージの例を示しています。メッセージがリレー2によって受信され、ホームサーバーに要求を転送できないことが検出されると、「E」ビットが設定され、結果コードAVPがDIAMETER_UNABLE_TO_DELIVERに設定された応答メッセージが返されます。このエラーがプロトコルエラーカテゴリに該当する場合、リレー1は特別なアクションを実行し、エラーが発生すると、代替のリレー3を介してメッセージをルーティングしようとします。
+---------+ 1. Request +---------+ 2. Request +---------+
| Access |------------>|Diameter |------------>|Diameter |
| | | | | Home |
| Device |<------------| Relay |<------------| Server |
+---------+ 4. Answer +---------+ 3. Answer +---------+
(Missing AVP) (Missing AVP)
Figure 8: Example of Application Error Answer Message
図8：アプリケーションエラー応答メッセージの例
Figure 8 provides an example of a Diameter message that caused an application error. When application errors occur, the Diameter entity reporting the error clears the 'R' bit in the Command Flags and adds the Result-Code AVP with the proper value. Application errors do not require any proxy or relay agent involvement; therefore, the message would be forwarded back to the originator of the request.
図8に、アプリケーションエラーの原因となったDiameterメッセージの例を示します。アプリケーションエラーが発生すると、エラーを報告しているDiameterエンティティがコマンドフラグの「R」ビットをクリアし、適切な値で結果コードAVPを追加します。アプリケーションエラーは、プロキシまたはリレーエージェントの関与を必要としません。したがって、メッセージは要求の発信者に転送されます。
In the case where the answer message itself contains errors, any related session SHOULD be terminated by sending an STR or ASR message. The Termination-Cause AVP in the STR MAY be filled with the appropriate value to indicate the cause of the error. An application MAY also send an application-specific request instead of an STR or ASR message to signal the error in the case where no state is maintained or to allow for some form of error recovery with the corresponding Diameter entity.
応答メッセージ自体にエラーが含まれている場合、関連するセッションはSTRまたはASRメッセージを送信して終了する必要があります（SHOULD）。 STRのTermination-Cause AVPに、エラーの原因を示す適切な値を入力できます（MAY）。また、アプリケーションは、STRまたはASRメッセージの代わりにアプリケーション固有の要求を送信して、状態が維持されていない場合にエラーを通知するか、対応するDiameterエンティティで何らかの形式のエラー回復を許可する場合があります。
There are certain Result-Code AVP application errors that require additional AVPs to be present in the answer. In these cases, the Diameter node that sets the Result-Code AVP to indicate the error MUST add the AVPs. Examples are as follows:
回答に追加のAVPが存在する必要がある特定の結果コードAVPアプリケーションエラーがあります。これらの場合、結果コードAVPを設定してエラーを示すDiameterノードは、AVPを追加する必要があります。次に例を示します。
o A request with an unrecognized AVP is received with the 'M' bit (Mandatory bit) set causes an answer to be sent with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED and the Failed-AVP AVP containing the offending AVP.
o 'M'ビット（必須ビット）が設定された認識されないAVPを持つ要求を受信すると、結果コードAVPがDIAMETER_AVP_UNSUPPORTEDに設定された応答が送信され、問題のAVPを含むFailed-AVP AVPが送信されます。
o A request with an AVP that is received with an unrecognized value causes an answer to be returned with the Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing the AVP causing the error.
o 認識されない値で受信されたAVPを含むリクエストにより、Result-Code AVPがDIAMETER_INVALID_AVP_VALUEに設定された応答が返され、Failed-AVP AVPにエラーの原因となったAVPが含まれます。
o A received command that is missing AVPs that are defined as required in the commands CCF; examples are AVPs indicated as {AVP}. The receiver issues an answer with the Result-Code set to DIAMETER_MISSING_AVP and creates an AVP with the AVP Code and other fields set as expected in the missing AVP. The created AVP is then added to the Failed-AVP AVP.
o コマンドCCFで必要と定義されているAVPが欠落している受信コマンド。例は、{AVP}として示されるAVPです。受信者は、Result-CodeをDIAMETER_MISSING_AVPに設定して回答を発行し、欠落しているAVPで予想されるAVPコードとその他のフィールドが設定されたAVPを作成します。作成されたAVPは、Failed-AVP AVPに追加されます。
The Result-Code AVP describes the error that the Diameter node encountered in its processing. In case there are multiple errors, the Diameter node MUST report only the first error it encountered (detected possibly in some implementation-dependent order). The specific errors that can be described by this AVP are described in the following section.
Result-Code AVPは、Diameterノードが処理中に発生したエラーを示します。複数のエラーがある場合、Diameterノードは最初に発生したエラーのみを報告する必要があります（実装依存の順序で検出される可能性があります）。このAVPで説明できる特定のエラーについては、次のセクションで説明します。
The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whether a particular request was completed successfully or an error occurred. All Diameter answer messages in IETF-defined Diameter application specifications MUST include one Result-Code AVP. A non-successful Result-Code AVP (one containing a non-2xxx value other than DIAMETER_REDIRECT_INDICATION) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP.
結果コードAVP（AVPコード268）はタイプUnsigned32であり、特定の要求が正常に完了したか、エラーが発生したかを示します。 IETFで定義されたDiameterアプリケーション仕様のすべてのDiameter応答メッセージには、1つの結果コードAVPを含める必要があります。成功しないResult-Code AVP（DIAMETER_REDIRECT_INDICATION以外の2xxx以外の値を含むもの）は、Result-Code AVPを設定するホストがOrigin-Host AVPでエンコードされたIDと異なる場合、Error-Reporting-Host AVPを含める必要があります。 。
The Result-Code data field contains an IANA-managed 32-bit address space representing errors (see Section 11.3.2). Diameter provides the following classes of errors, all identified by the thousands digit in the decimal notation: o 1xxx (Informational)
結果コードデータフィールドには、エラーを表すIANA管理の32ビットアドレス空間が含まれます（セクション11.3.2を参照）。 Diameterは、次のエラークラスを提供します。これらはすべて、10進表記の数千桁で識別されます。o 1xxx（情報のみ）
o 2xxx (Success)
o 2xxx（成功）
o 3xxx (Protocol Errors)
o 3xxx（プロトコルエラー）
o 4xxx (Transient Failures)
o 4xxx（一時的な障害）
o 5xxx (Permanent Failure)
o 5xxx（永続的な障害）
An unrecognized class (one whose first digit is not defined in this section) MUST be handled as a permanent failure.
認識されないクラス（このセクションで最初の桁が定義されていないクラス）は、永続的な障害として処理する必要があります。
Errors that fall within this category are used to inform the requester that a request could not be satisfied, and additional action is required on its part before access is granted.
Errors that fall within this category are used to inform the requester that a request could not be satisfied, and additional action is required on its part before access is granted.
DIAMETER_MULTI_ROUND_AUTH 1001
DIAMETER_MULTI_ROUND_AUTH 1001
This informational error is returned by a Diameter server to inform the access device that the authentication mechanism being used requires multiple round trips, and a subsequent request needs to be issued in order for access to be granted.
この情報エラーはDiameterサーバーによって返され、使用されている認証メカニズムに複数のラウンドトリップが必要であること、およびアクセスを許可するために後続のリクエストを発行する必要があることをアクセスデバイスに通知します。
Errors that fall within the Success category are used to inform a peer that a request has been successfully completed.
成功カテゴリに含まれるエラーは、リクエストが正常に完了したことをピアに通知するために使用されます。
DIAMETER_SUCCESS 2001
DIAMETER_SUCCESS 2001
The request was successfully completed.
リクエストは正常に完了しました。
DIAMETER_LIMITED_SUCCESS 2002
DIAMETER_LIMITED_SUCCESS 2002
When returned, the request was successfully completed, but additional processing is required by the application in order to provide service to the user.
返されると、要求は正常に完了しましたが、ユーザーにサービスを提供するために、アプリケーションによる追加の処理が必要です。
Errors that fall within the Protocol Error category SHOULD be treated on a per-hop basis, and Diameter proxies MAY attempt to correct the error, if it is possible. Note that these errors MUST only be used in answer messages whose 'E' bit is set.
プロトコルエラーカテゴリに該当するエラーは、ホップごとに処理する必要があり（SHOULD）、Diameterプロキシは、可能であればエラーを修正しようとする場合があります（MAY）。これらのエラーは、「E」ビットが設定されている応答メッセージでのみ使用する必要があることに注意してください。
DIAMETER_COMMAND_UNSUPPORTED 3001
DIAMETER_COMMAND_UNSUPPORTED 3001
This error code is used when a Diameter entity receives a message with a Command Code that it does not support.
このエラーコードは、Diameterエンティティが、サポートしていないコマンドコードを含むメッセージを受信したときに使用されます。
DIAMETER_UNABLE_TO_DELIVER 3002
DIAMETER_UNABLE_TO_DELIVER 3002
This error is given when Diameter cannot deliver the message to the destination, either because no host within the realm supporting the required application was available to process the request or because the Destination-Host AVP was given without the associated Destination-Realm AVP.
このエラーは、要求を処理するために必要なアプリケーションをサポートするレルム内のホストが利用できなかったか、関連付けられた宛先レルムAVPなしで宛先ホストAVPが与えられたために、Diameterが宛先にメッセージを配信できない場合に発生します。
DIAMETER_REALM_NOT_SERVED 3003
DIAMETER_REALM_NOT_SERVED 3003
The intended realm of the request is not recognized.
要求の意図されたレルムが認識されていません。
DIAMETER_TOO_BUSY 3004
DIAMETER_TOO_BUSY 3004
When returned, a Diameter node SHOULD attempt to send the message to an alternate peer. This error MUST only be used when a specific server is requested, and it cannot provide the requested service.
返されたとき、Diameterノードは、代替ピアにメッセージを送信しようとする必要があります。このエラーは、特定のサーバーが要求されたときにのみ使用する必要があり、要求されたサービスを提供できません。
DIAMETER_LOOP_DETECTED 3005
DIAMETER_LOOP_DETECTED 3005
An agent detected a loop while trying to get the message to the intended recipient. The message MAY be sent to an alternate peer, if one is available, but the peer reporting the error has identified a configuration problem.
意図された受信者にメッセージを送信しようとしたときに、エージェントがループを検出しました。メッセージが使用可能な場合、代替ピアにメッセージを送信できますが、エラーを報告しているピアが構成の問題を識別しています。
DIAMETER_REDIRECT_INDICATION 3006
DIAMETER_REDIRECT_INDICATION 3006
A redirect agent has determined that the request could not be satisfied locally, and the initiator of the request SHOULD direct the request directly to the server, whose contact information has been added to the response. When set, the Redirect-Host AVP MUST be present.
リダイレクトエージェントは、リクエストをローカルで満たすことができなかったと判断し、リクエストのイニシエーターはリクエストをサーバーに直接転送する必要があります（SHOULD）。設定されている場合、Redirect-Host AVPが存在する必要があります。
DIAMETER_APPLICATION_UNSUPPORTED 3007
DIAMETER_APPLICATION_UNSUPPORTED 3007
A request was sent for an application that is not supported.
サポートされていないアプリケーションのリクエストが送信されました。
DIAMETER_INVALID_HDR_BITS 3008
DIAMETER_INVALID_HDR_BITS 3008
A request was received whose bits in the Diameter header were set either to an invalid combination or to a value that is inconsistent with the Command Code's definition.
A request was received whose bits in the Diameter header were set either to an invalid combination or to a value that is inconsistent with the Command Code's definition.
DIAMETER_INVALID_AVP_BITS 3009
DIAMETER_INVALID_AVP_BITS 3009
A request was received that included an AVP whose flag bits are set to an unrecognized value or that is inconsistent with the AVP's definition.
フラグビットが認識されない値に設定されているAVPを含む要求、またはAVPの定義と矛盾する要求が受信されました。
DIAMETER_UNKNOWN_PEER 3010
DIAMETER_UNKNOWN_PEER 3010
A CER was received from an unknown peer.
不明なピアからCERを受信しました。
Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received but MAY be able to satisfy the request in the future. Note that these errors MUST be used in answer messages whose 'E' bit is not set.
一時的な障害のカテゴリに該当するエラーは、要求が受信されたときに要求を満たせなかったが、将来は要求を満たすことができる場合があることをピアに通知するために使用されます。これらのエラーは、「E」ビットが設定されていない応答メッセージで使用する必要があることに注意してください。
DIAMETER_AUTHENTICATION_REJECTED 4001
DIAMETER_AUTHENTICATION_REJECTED 4001
The authentication process for the user failed, most likely due to an invalid password used by the user. Further attempts MUST only be tried after prompting the user for a new password.
ユーザーの認証プロセスが失敗しました。おそらくユーザーが無効なパスワードを使用したことが原因です。ユーザーに新しいパスワードを要求した後にのみ、それ以上の試行を試行する必要があります。
DIAMETER_OUT_OF_SPACE 4002
DIAMETER_OUT_OF_SPACE 4002
A Diameter node received the accounting request but was unable to commit it to stable storage due to a temporary lack of space.
A Diameter node received the accounting request but was unable to commit it to stable storage due to a temporary lack of space.
ELECTION_LOST 4003
ELECTION_LOST 4003
The peer has determined that it has lost the election process and has therefore disconnected the transport connection.
ピアは、選択プロセスを失ったと判断したため、トランスポート接続を切断しました。
Errors that fall within the permanent failures category are used to inform the peer that the request failed and should not be attempted again. Note that these errors SHOULD be used in answer messages whose 'E' bit is not set. In error conditions where it is not possible or efficient to compose application-specific answer grammar, answer messages with the 'E' bit set and which comply to the grammar described in Section 7.2 MAY also be used for permanent errors.
永続的な障害のカテゴリに含まれるエラーは、要求が失敗したため、再試行しないことをピアに通知するために使用されます。これらのエラーは、「E」ビットが設定されていない応答メッセージで使用する必要があることに注意してください。アプリケーション固有の応答文法を作成することが不可能または効率的ではないエラー状態では、「E」ビットが設定された応答メッセージは、セクション7.2で説明されている文法に準拠していても、永続的なエラーに使用できます。
DIAMETER_AVP_UNSUPPORTED 5001
DIAMETER_AVP_UNSUPPORTED 5001
The peer received a message that contained an AVP that is not recognized or supported and was marked with the 'M' (Mandatory) bit. A Diameter message with this error MUST contain one or more Failed-AVP AVPs containing the AVPs that caused the failure.
The peer received a message that contained an AVP that is not recognized or supported and was marked with the 'M' (Mandatory) bit. A Diameter message with this error MUST contain one or more Failed-AVP AVPs containing the AVPs that caused the failure.
DIAMETER_UNKNOWN_SESSION_ID 5002
DIAMETER_UNKNOWN_SESSION_ID 5002
The request contained an unknown Session-Id.
リクエストに不明なセッションIDが含まれていました。
DIAMETER_AUTHORIZATION_REJECTED 5003
DIAMETER_AUTHORIZATION_REJECTED 5003
A request was received for which the user could not be authorized. This error could occur if the service requested is not permitted to the user.
ユーザーを許可できない要求を受け取りました。このエラーは、要求されたサービスがユーザーに許可されていない場合に発生する可能性があります。
DIAMETER_INVALID_AVP_VALUE 5004
DIAMETER_INVALID_AVP_VALUE 5004
The request contained an AVP with an invalid value in its data portion. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP.
リクエストのデータ部分に無効な値を持つAVPが含まれていました。このエラーを示すDiameterメッセージには、Failed-AVP AVP内の問題のAVPが含まれている必要があります。
DIAMETER_MISSING_AVP 5005
DIAMETER_MISSING_AVP 5005
The request did not contain an AVP that is required by the Command Code definition. If this value is sent in the Result-Code AVP, a Failed-AVP AVP SHOULD be included in the message. The Failed-AVP AVP MUST contain an example of the missing AVP complete with the Vendor-Id if applicable. The value field of the missing AVP should be of correct minimum length and contain zeroes.
The request did not contain an AVP that is required by the Command Code definition. If this value is sent in the Result-Code AVP, a Failed-AVP AVP SHOULD be included in the message. The Failed-AVP AVP MUST contain an example of the missing AVP complete with the Vendor-Id if applicable. The value field of the missing AVP should be of correct minimum length and contain zeroes.
DIAMETER_RESOURCES_EXCEEDED 5006
DIAMETER_RESOURCES_EXCEEDED 5006
A request was received that cannot be authorized because the user has already expended allowed resources. An example of this error condition is when a user that is restricted to one dial-up PPP port attempts to establish a second PPP connection.
ユーザーが既に許可されたリソースを消費しているため、許可できない要求を受け取りました。このエラー状態の例は、1つのダイヤルアップPPPポートに制限されているユーザーが2番目のPPP接続を確立しようとした場合です。
DIAMETER_CONTRADICTING_AVPS 5007
DIAMETER_CONTRADICTING_AVPS 5007
The Home Diameter server has detected AVPs in the request that contradicted each other, and it is not willing to provide service to the user. The Failed-AVP AVP MUST be present, which contain the AVPs that contradicted each other.
Home Diameterサーバーは、互いに矛盾する要求でAVPを検出しました。ユーザーにサービスを提供する意思はありません。 Failed-AVP AVPが存在する必要があります。これには、互いに矛盾するAVPが含まれています。
DIAMETER_AVP_NOT_ALLOWED 5008
DIAMETER_AVP_NOT_ALLOWED 5008
A message was received with an AVP that MUST NOT be present. The Failed-AVP AVP MUST be included and contain a copy of the offending AVP.
存在してはならないAVPを含むメッセージが受信されました。 Failed-AVP AVPが含まれていて、問題のAVPのコピーを含んでいる必要があります。
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
A message was received that included an AVP that appeared more often than permitted in the message definition. The Failed-AVP AVP MUST be included and contain a copy of the first instance of the offending AVP that exceeded the maximum number of occurrences.
メッセージ定義で許可されているよりも頻繁に出現するAVPを含むメッセージが受信されました。 Failed-AVP AVPが含まれている必要があり、最大発生数を超えた問題のAVPの最初のインスタンスのコピーが含まれている必要があります。
DIAMETER_NO_COMMON_APPLICATION 5010
DIAMETER_NO_COMMON_APPLICATION 5010
This error is returned by a Diameter node that receives a CER whereby no applications are common between the CER sending peer and the CER receiving peer.
このエラーは、CERを受信するDiameterノードによって返され、CER送信ピアとCER受信ピアの間で共通のアプリケーションはありません。
DIAMETER_UNSUPPORTED_VERSION 5011
DIAMETER_UNSUPPORTED_VERSION 5011
This error is returned when a request was received, whose version number is unsupported.
このエラーは、サポートされていないバージョン番号のリクエストを受け取ったときに返されます。
DIAMETER_UNABLE_TO_COMPLY 5012
DIAMETER_UNABLE_TO_COMPLY 5012
This error is returned when a request is rejected for unspecified reasons.
このエラーは、不特定の理由でリクエストが拒否された場合に返されます。
DIAMETER_INVALID_BIT_IN_HEADER 5013
DIAMETER_INVALID_BIT_IN_HEADER 5013
This error is returned when a reserved bit in the Diameter header is set to one (1) or the bits in the Diameter header are set incorrectly.
このエラーは、Diameterヘッダーの予約済みビットが1に設定されているか、Diameterヘッダーのビットが正しく設定されていない場合に返されます。
DIAMETER_INVALID_AVP_LENGTH 5014
DIAMETER_INVALID_AVP_LENGTH 5014
The request contained an AVP with an invalid length. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. In cases where the erroneous AVP length value exceeds the message length or is less than the minimum AVP header length, it is sufficient to include the offending AVP header and a zero filled payload of the minimum required length for the payloads data type. If the AVP is a Grouped AVP, the Grouped AVP header with an empty payload would be sufficient to indicate the offending AVP. In the case where the offending AVP header cannot be fully decoded when the AVP length is less than the minimum AVP header length, it is sufficient to include an offending AVP header that is formulated by padding the incomplete AVP header with zero up to the minimum AVP header length.
リクエストに無効な長さのAVPが含まれていました。このエラーを示すDiameterメッセージには、Failed-AVP AVP内の問題のAVPが含まれている必要があります。誤ったAVP長の値がメッセージ長を超えるか、AVPヘッダーの最小長より短い場合は、問題のAVPヘッダーと、ペイロードデータタイプに必要な最小長のゼロで埋められたペイロードを含めるだけで十分です。 AVPがグループ化されたAVPである場合、ペイロードが空のグループ化AVPヘッダーで問題のAVPを示すのに十分です。 AVPの長さが最小AVPヘッダー長よりも短いときに問題のAVPヘッダーを完全にデコードできない場合は、不完全なAVPヘッダーにゼロから最小AVPまでパディングすることによって作成された問題のAVPヘッダーを含めるだけで十分です。ヘッダーの長さ。
DIAMETER_INVALID_MESSAGE_LENGTH 5015
DIAMETER_INVALID_MESSAGE_LENGTH 5015
This error is returned when a request is received with an invalid message length.
このエラーは、無効なメッセージ長でリクエストを受信した場合に返されます。
DIAMETER_INVALID_AVP_BIT_COMBO 5016
DIAMETER_INVALID_AVP_BIT_COMBO 5016
The request contained an AVP with which is not allowed to have the given value in the AVP Flags field. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP.
リクエストには、AVPフラグフィールドに指定された値を持つことが許可されていないAVPが含まれていました。このエラーを示すDiameterメッセージには、Failed-AVP AVP内の問題のAVPが含まれている必要があります。
DIAMETER_NO_COMMON_SECURITY 5017
DIAMETER_NO_COMMON_SECURITY 5017
This error is returned when a CER message is received, and there are no common security mechanisms supported between the peers. A Capabilities-Exchange-Answer (CEA) message MUST be returned with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY.
このエラーは、CERメッセージが受信されたときに返され、ピア間でサポートされる共通のセキュリティメカニズムはありません。 Capabilities-Exchange-Answer（CEA）メッセージは、結果コードAVPがDIAMETER_NO_COMMON_SECURITYに設定された状態で返される必要があります。
The 'E' (Error Bit) in the Diameter header is set when the request caused a protocol-related error (see Section 7.1.3). A message with the 'E' bit MUST NOT be sent as a response to an answer message. Note that a message with the 'E' bit set is still subjected to the processing rules defined in Section 6.2. When set, the answer message will not conform to the CCF specification for the command; instead, it and will conform to the following CCF:
Diameterヘッダーの「E」（エラービット）は、リクエストがプロトコル関連のエラーを引き起こしたときに設定されます（セクション7.1.3を参照）。 「E」ビットを含むメッセージは、応答メッセージへの応答として送信してはなりません。 「E」ビットが設定されたメッセージは、セクション6.2で定義された処理ルールに従うことに注意してください。設定すると、応答メッセージはコマンドのCCF仕様に準拠しなくなります。代わりに、次のCCFに準拠します。
Message Format
メッセージフォーマット
<answer-message> ::= < Diameter Header: code, ERR [, PXY] >
0*1< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Experimental-Result ]
* [ Proxy-Info ]
* [ AVP ]
Note that the code used in the header is the same than the one found in the request message, but with the 'R' bit cleared and the 'E' bit set. The 'P' bit in the header is set to the same value as the one found in the request message.
ヘッダーで使用されるコードは要求メッセージで見つかったものと同じですが、「R」ビットがクリアされ、「E」ビットが設定されていることに注意してください。ヘッダーの「P」ビットは、要求メッセージにあるものと同じ値に設定されます。
The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY accompany a Result-Code AVP as a human-readable error message. The Error-Message AVP is not intended to be useful in an environment where error messages are processed automatically. It SHOULD NOT be expected that the content of this AVP be parsed by network entities.
エラーメッセージAVP（AVPコード281）のタイプはUTF8Stringです。人間が読めるエラーメッセージとしてResult-Code AVPを伴う場合があります。エラーメッセージAVPは、エラーメッセージが自動的に処理される環境での使用を意図したものではありません。このAVPのコンテンツがネットワークエンティティによって解析されることを期待すべきではありません。
The Error-Reporting-Host AVP (AVP Code 294) is of type DiameterIdentity. This AVP contains the identity of the Diameter host that sent the Result-Code AVP to a value other than 2001 (Success), only if the host setting the Result-Code is different from the one encoded in the Origin-Host AVP. This AVP is intended to be used for troubleshooting purposes, and it MUST be set when the Result-Code AVP indicates a failure.
Error-Reporting-Host AVP（AVPコード294）のタイプはDiameterIdentityです。このAVPには、Result-Codeを設定するホストがOrigin-Host AVPでエンコードされたものと異なる場合にのみ、Result-Code AVPを2001（成功）以外の値に送信したDiameterホストのIDが含まれます。このAVPはトラブルシューティングの目的で使用することを目的としており、Result-Code AVPが失敗を示すときに設定する必要があります。
The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides debugging information in cases where a request is rejected or not fully processed due to erroneous information in a specific AVP. The value of the Result-Code AVP will provide information on the reason for the Failed-AVP AVP. A Diameter answer message SHOULD contain an instance of the Failed-AVP AVP that corresponds to the error indicated by the Result-Code AVP. For practical purposes, this Failed-AVP would typically refer to the first AVP processing error that a Diameter node encounters.
Failed-AVP AVP（AVPコード279）はグループ化されたタイプであり、特定のAVPの誤った情報が原因でリクエストが拒否された場合や完全に処理されなかった場合のデバッグ情報を提供します。 Result-Code AVPの値は、Failed-AVP AVPの理由に関する情報を提供します。 Diameter応答メッセージには、Result-Code AVPによって示されるエラーに対応するFailed-AVP AVPのインスタンスが含まれる必要があります（SHOULD）。実際には、このFailed-AVPは通常、Diameterノードで発生する最初のAVP処理エラーを参照します。
The possible reasons for this AVP are the presence of an improperly constructed AVP, an unsupported or unrecognized AVP, an invalid AVP value, the omission of a required AVP, the presence of an explicitly excluded AVP (see tables in Section 10) or the presence of two or more occurrences of an AVP that is restricted to 0, 1, or 0-1 occurrences.
このAVPの考えられる理由は、不適切に構築されたAVPの存在、サポートされていない、または認識されていないAVP、無効なAVP値、必要なAVPの省略、明示的に除外されたAVPの存在（セクション10の表を参照）または存在です。 0、1、または0-1の発生に制限されているAVPの2つ以上の発生の。
A Diameter message SHOULD contain one Failed-AVP AVP, containing the entire AVP that could not be processed successfully. If the failure reason is omission of a required AVP, an AVP with the missing AVP code, the missing Vendor-Id, and a zero-filled payload of the minimum required length for the omitted AVP will be added. If the failure reason is an invalid AVP length where the reported length is less than the minimum AVP header length or greater than the reported message length, a copy of the offending AVP header and a zero-filled payload of the minimum required length SHOULD be added.
Diameterメッセージには、正常に処理できなかったAVP全体を含むFailed-AVP AVPが1つ含まれる必要があります（SHOULD）。失敗の理由が必要なAVPの省略である場合は、AVPコードが欠落しているAVP、欠落しているベンダーID、および省略されたAVPに必要な最小長のゼロで満たされたペイロードが追加されます。失敗の理由が無効なAVPの長さであり、報告された長さが最小のAVPヘッダー長よりも短いか、報告されたメッセージの長さよりも長い場合、問題のAVPヘッダーのコピーとゼロで埋められた最小必要長のペイロードを追加する必要があります（SHOULD） 。
In the case where the offending AVP is embedded within a Grouped AVP, the Failed-AVP MAY contain the grouped AVP, which in turn contains the single offending AVP. The same method MAY be employed if the grouped AVP itself is embedded in yet another grouped AVP and so on. In this case, the Failed-AVP MAY contain the grouped AVP hierarchy up to the single offending AVP. This enables the recipient to detect the location of the offending AVP when embedded in a group.
問題のAVPがグループ化されたAVPに埋め込まれている場合、Failed-AVPにはグループ化されたAVPが含まれている可能性があり、これには順番に単一の問題のAVPが含まれています。グループ化されたAVP自体がさらに別のグループ化されたAVPに埋め込まれている場合などは、同じ方法を使用できます。この場合、Failed-AVPには、単一の問題のAVPまでのグループ化されたAVP階層が含まれる場合があります。これにより、受信者は、グループに埋め込まれたときに問題のAVPの場所を検出できます。
AVP Format
AVPフォーマット
<Failed-AVP> ::= < AVP Header: 279 >
1* {AVP}
The Experimental-Result AVP (AVP Code 297) is of type Grouped, and indicates whether a particular vendor-specific request was completed successfully or whether an error occurred. This AVP has the following structure:
The Experimental-Result AVP (AVP Code 297) is of type Grouped, and indicates whether a particular vendor-specific request was completed successfully or whether an error occurred. This AVP has the following structure:
AVP Format
AVPフォーマット
Experimental-Result ::= < AVP Header: 297 >
{ Vendor-Id }
{ Experimental-Result-Code }
The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP identifies the vendor responsible for the assignment of the result code that follows. All Diameter answer messages defined in vendor-specific applications MUST include either one Result-Code AVP or one Experimental-Result AVP.
このグループ化されたAVPのVendor-Id AVP（セクション5.3.3を参照）は、後続の結果コードの割り当てを担当するベンダーを識別します。ベンダー固有のアプリケーションで定義されているすべてのDiameter応答メッセージには、1つのResult-Code AVPまたは1つのExperimental-Result AVPを含める必要があります。
The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32 and contains a vendor-assigned value representing the result of processing the request.
試験的結果コードAVP（AVPコード298）はタイプUnsigned32であり、リクエストの処理結果を表すベンダー割り当て値が含まれています。
It is recommended that vendor-specific result codes follow the same conventions given for the Result-Code AVP regarding the different types of result codes and the handling of errors (for non-2xxx values).
ベンダー固有の結果コードは、さまざまなタイプの結果コードとエラーの処理（-2xxx以外の値の場合）に関して、結果コードAVPに指定された同じ規則に従うことをお勧めします。
In general, Diameter can provide two different types of services to applications. The first involves authentication and authorization, and it can optionally make use of accounting. The second only makes use of accounting.
一般に、Diameterは2つの異なるタイプのサービスをアプリケーションに提供できます。 1つ目は認証と承認を含み、オプションでアカウンティングを利用できます。 2つ目はアカウンティングのみを使用します。
When a service makes use of the authentication and/or authorization portion of an application, and a user requests access to the network, the Diameter client issues an auth request to its local server. The auth request is defined in a service-specific Diameter application (e.g., NASREQ). The request contains a Session-Id AVP, which is used in subsequent messages (e.g., subsequent authorization, accounting, etc.) relating to the user's session. The Session-Id AVP is a means for the client and servers to correlate a Diameter message with a user session.
サービスがアプリケーションの認証および/または承認部分を利用し、ユーザーがネットワークへのアクセスをリクエストすると、Diameterクライアントはローカルサーバーに認証リクエストを発行します。認証要求は、サービス固有のDiameterアプリケーション（NASREQなど）で定義されます。リクエストには、ユーザーのセッションに関連する後続のメッセージ（たとえば、後続の承認、アカウンティングなど）で使用されるSession-Id AVPが含まれています。 Session-Id AVPは、クライアントとサーバーがDiameterメッセージをユーザーセッションと関連付けるための手段です。
When a Diameter server authorizes a user to implement network resources for a finite amount of time, and it is willing to extend the authorization via a future request, it MUST add the Authorization- Lifetime AVP to the answer message. The Authorization-Lifetime AVP defines the maximum number of seconds a user MAY make use of the resources before another authorization request is expected by the server. The Auth-Grace-Period AVP contains the number of seconds following the expiration of the Authorization-Lifetime, after which the server will release all state information related to the user's session. Note that if payment for services is expected by the serving realm from the user's home realm, the Authorization-Lifetime AVP, combined with the Auth-Grace-Period AVP, implies the maximum length of the session for which the home realm is willing to be fiscally responsible. Services provided past the expiration of the Authorization-Lifetime and Auth-Grace-Period AVPs are the responsibility of the access device. Of course, the actual cost of services rendered is clearly outside the scope of the protocol.
Diameterサーバーがユーザーに有限時間のネットワークリソースの実装を許可し、将来のリクエストを介して許可を拡張する場合、応答メッセージにAuthorization- Lifetime AVPを追加する必要があります。 Authorization-Lifetime AVPは、ユーザーがリソースを利用できる最大秒数を定義します。この秒数を超えると、サーバーは別の承認リクエストを予期します。 Auth-Grace-Period AVPには、Authorization-Lifetimeの有効期限が切れた後の秒数が含まれます。その後、サーバーはユーザーのセッションに関連するすべての状態情報を解放します。サービスの支払いがユーザーのホームレルムからサービス提供レルムによって期待される場合、Auth-Grace-Period AVPと組み合わされたAuthorization-Lifetime AVPは、ホームレルムが許容するセッションの最大長を意味します。財政的に責任があります。 Authorization-LifetimeおよびAuth-Grace-Period AVPの有効期限が切れた後に提供されるサービスは、アクセスデバイスの責任です。もちろん、提供されるサービスの実際のコストは明らかにプロトコルの範囲外です。
An access device that does not expect to send a re-authorization or a session termination request to the server MAY include the Auth-Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint to the server. If the server accepts the hint, it agrees that since no session termination message will be received once service to the user is terminated, it cannot maintain state for the session. If the answer message from the server contains a different value in the Auth-Session-State AVP (or the default value if the AVP is absent), the access device MUST follow the server's directives. Note that the value NO_STATE_MAINTAINED MUST NOT be set in subsequent re-authorization requests and answers.
再認証またはセッション終了要求をサーバーに送信することを期待しないアクセスデバイスは、サーバーへのヒントとしてNO_STATE_MAINTAINEDに値が設定されたAuth-Session-State AVPを含めることができます。サーバーがヒントを受け入れると、ユーザーへのサービスが終了するとセッション終了メッセージが受信されないため、セッションの状態を維持できないことに同意します。サーバーからの応答メッセージにAuth-Session-State AVPに異なる値（またはAVPがない場合のデフォルト値）が含まれている場合、アクセスデバイスはサーバーの指示に従う必要があります。値NO_STATE_MAINTAINEDは、後続の再認証要求と応答で設定してはならないことに注意してください。
The base protocol does not include any authorization request messages, since these are largely application-specific and are defined in a Diameter application document. However, the base protocol does define a set of messages that are used to terminate user sessions. These are used to allow servers that maintain state information to free resources.
これらは主にアプリケーション固有であり、Diameterアプリケーションドキュメントで定義されているため、ベースプロトコルには認証要求メッセージは含まれていません。ただし、基本プロトコルは、ユーザーセッションの終了に使用される一連のメッセージを定義します。これらは、状態情報を維持するサーバーがリソースを解放できるようにするために使用されます。
When a service only makes use of the accounting portion of the Diameter protocol, even in combination with an application, the Session-Id is still used to identify user sessions. However, the session termination messages are not used, since a session is signaled as being terminated by issuing an accounting stop message.
When a service only makes use of the accounting portion of the Diameter protocol, even in combination with an application, the Session-Id is still used to identify user sessions. However, the session termination messages are not used, since a session is signaled as being terminated by issuing an accounting stop message.
Diameter may also be used for services that cannot be easily categorized as authentication, authorization, or accounting (e.g., certain Third Generation Partnership Project Internet Multimedia System (3GPP IMS) interfaces). In such cases, the finite state machine defined in subsequent sections may not be applicable. Therefore, the application itself MAY need to define its own finite state machine. However, such application-specific state machines SHOULD follow the general state machine framework outlined in this document such as the use of Session-Id AVPs and the use of STR/STA, ASR/ASA messages for stateful sessions.
Diameter may also be used for services that cannot be easily categorized as authentication, authorization, or accounting (e.g., certain Third Generation Partnership Project Internet Multimedia System (3GPP IMS) interfaces). In such cases, the finite state machine defined in subsequent sections may not be applicable. Therefore, the application itself MAY need to define its own finite state machine. However, such application-specific state machines SHOULD follow the general state machine framework outlined in this document such as the use of Session-Id AVPs and the use of STR/STA, ASR/ASA messages for stateful sessions.
This section contains a set of finite state machines, which represent the life cycle of Diameter sessions and which MUST be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. The term "Service-Specific" below refers to a message defined in a Diameter application (e.g., Mobile IPv4, NASREQ).
このセクションには、Diameterセッションのライフサイクルを表す一連の有限状態マシンが含まれており、Diameterアプリケーションの認証および/または承認部分を利用するすべてのDiameter実装で監視する必要があります。以下の「サービス固有」という用語は、Diameterアプリケーションで定義されたメッセージ（モバイルIPv4、NASREQなど）を指します。
There are four different authorization session state machines supported in the Diameter base protocol. The first two describe a session in which the server is maintaining session state, indicated by the value of the Auth-Session-State AVP (or its absence). One describes the session from a client perspective, the other from a server perspective. The second two state machines are used when the server does not maintain session state. Here again, one describes the session from a client perspective, the other from a server perspective.
There are four different authorization session state machines supported in the Diameter base protocol. The first two describe a session in which the server is maintaining session state, indicated by the value of the Auth-Session-State AVP (or its absence). One describes the session from a client perspective, the other from a server perspective. The second two state machines are used when the server does not maintain session state. Here again, one describes the session from a client perspective, the other from a server perspective.
When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered an error condition, and an answer, if applicable, MUST be returned to the originator of the message.
セッションがアイドル状態に移行すると、特定のセッションに割り当てられていたすべてのリソースを解放する必要があります。状態マシンにリストされていないイベントは、エラー状態と見なされなければならず、該当する場合は、メッセージの発信者に応答が返されなければなりません（MUST）。
In the case that an application does not support re-auth, the state transitions related to server-initiated re-auth, when both client and server sessions maintain state (e.g., Send RAR, Pending, Receive RAA), MAY be ignored.
アプリケーションが再認証をサポートしていない場合、クライアントとサーバーの両方のセッションが状態を維持するとき（たとえば、RARの送信、保留、RAAの受信）、サーバーが開始した再認証に関連する状態遷移は無視されます（MAY）。
In the state table, the event "Failure to send X" means that the Diameter agent is unable to send command X to the desired destination. This could be due to the peer being down or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the corresponding Answer command. The event 'X successfully sent' is the complement of 'Failure to send X'.
状態テーブルで、「Xの送信に失敗しました」というイベントは、DiameterエージェントがコマンドXを目的の宛先に送信できないことを意味します。これは、ピアがダウンしているか、ピアが一時的な障害または対応するAnswerコマンドのResult-Code AVPの一時的なプロトコルエラー通知DIAMETER_TOO_BUSYまたはDIAMETER_LOOP_DETECTEDを送り返していることが原因である可能性があります。イベント「Xの送信に成功しました」は、「Xの送信に失敗しました」の補足です。
The following state machine is observed by a client when state is maintained on the server:
次のステートマシンは、サーバー上で状態が維持されるときにクライアントによって監視されます。
CLIENT, STATEFUL
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send Pending
access service-
specific
auth req
Idle ASR Received Send ASA Idle for unknown session with Result-Code = UNKNOWN_ SESSION_ID
Idle ASR Received Send ASA Idle for unknown session with Result-Code = UNKNOWN_ SESSION_ID
Idle RAR Received Send RAA Idle for unknown session with Result-Code = UNKNOWN_ SESSION_ID
Idle RAR Received Send RAA Idle for unknown session with Result-Code = UNKNOWN_ SESSION_ID
Pending Successful service-specific Grant Open authorization answer Access received with default Auth-Session-State value
デフォルトのAuth-Session-State値で受信した保留中の成功したサービス固有のGrant Open承認応答アクセス
Pending Successful service-specific Sent STR Discon authorization answer received, but service not provided
保留中のサービス固有の送信済みSTR Discon承認応答を受信しましたが、サービスは提供されていません
Pending Error processing successful Sent STR Discon service-specific authorization answer
保留中のエラー処理が正常に送信されましたSTR Disconサービス固有の認証回答
Pending Failed service-specific Clean up Idle authorization answer received
保留中の失敗したサービス固有のクリーンアップアイドル認証応答を受信
Open User or client device Send Open requests access to service service-specific auth req
Openユーザーまたはクライアントデバイスは、サービスサービス固有の認証要求へのアクセスをOpen要求に送信
Open Successful service-specific Provide Open authorization answer received service
Open成功したサービス固有のOpen Open認証の回答を受け取った
Open Failed service-specific Discon. Idle authorization answer user/device received.
失敗したサービス固有のDisconを開きます。アイドル認証応答ユーザー/デバイスを受信しました。
Open RAR received and client will Send RAA Open perform subsequent re-auth with Result-Code = SUCCESS
Open RARを受信し、クライアントはRAA Openを送信して、Result-Code = SUCCESSで後続の再認証を実行します
Open RAR received and client will Send RAA Idle not perform subsequent with re-auth Result-Code != SUCCESS, Discon. user/device
オープンRARを受信すると、クライアントはRAAアイドルを送信しますが、その後は再認証を実行しませんResult-Code！= SUCCESS、Discon。ユーザー/デバイス
Open Session-Timeout expires on Send STR Discon access device
Send STR DisconアクセスデバイスでOpen Session-Timeoutが期限切れになる
Open ASR received, Send ASA Discon client will comply with with request to end the Result-Code = session = SUCCESS, Send STR.
Open ASRを受信し、ASA Disconクライアントを送信すると、Result-Code = session = SUCCESS、Send STRを終了する要求に準拠します。
Open ASR Received, Send ASA Open client will not comply with with request to end the Result-Code != session != SUCCESS
Open ASR Received、Send ASA Openクライアントは、Result-Codeを終了する要求に準拠しません！=セッション！= SUCCESS
Open Authorization-Lifetime + Send STR Discon Auth-Grace-Period expires on access device
Open Authorization-Lifetime + Send STR Discon Auth-Grace-Period expires on access device
Discon ASR received Send ASA Discon Discon STA received Discon. Idle user/device
Discon ASRが送信されましたASA Discon Discon STAがDisconを受信しました。アイドル状態のユーザー/デバイス
The following state machine is observed by a server when it is maintaining state for the session:
次の状態マシンは、サーバーがセッションの状態を維持しているときに監視されます。
SERVER, STATEFUL
State Event Action New State
---------------------------------------------------------------
Idle Service-specific authorization Send Open
request received, and successful
user is authorized service-
specific
answer
Idle Service-specific authorization Send Idle request received, and failed user is not authorized service-specific answer
Idleサービス固有の承認Send Idleリクエストを受信しましたが、失敗したユーザーはサービス固有の回答を承認していません
Open Service-specific authorization Send Open request received, and user successful is authorized service-specific answer
Open Service固有の認証Open Openリクエストを受信し、ユーザーが成功すると、サービス固有の認証が承認されます
Open Service-specific authorization Send Idle request received, and user failed is not authorized service-specific answer, Clean up
Open Service-specific authorization Send Idle request received、and user failed is not authorized service-specific answer、Clean up
Open Home server wants to confirm Send RAR Pending authentication and/or authorization of the user
Open Homeサーバーが、RAR送信の保留中の認証やユーザーの承認を確認したい
Pending Received RAA with a failed Clean up Idle Result-Code
クリーンアップアイドル結果コードが失敗した保留中の受信RAA
Pending Received RAA with Result-Code Update Open = SUCCESS session
結果コードの更新がオープンされた保留中の受信RAA = SUCCESSセッション
Open Home server wants to Send ASR Discon terminate the service
Open HomeサーバーがASR Disconを送信してサービスを終了したい
Open Authorization-Lifetime (and Clean up Idle Auth-Grace-Period) expires on home server
ホームサーバーでOpen Authorization-Lifetime（およびClean up Idle Auth-Grace-Period）が期限切れになる
Open Session-Timeout expires on Clean up Idle home server
クリーンアップアイドルホームサーバーでオープンセッションタイムアウトが期限切れになる
Discon Failure to send ASR Wait, Discon resend ASR
DisconはASR待機の送信に失敗し、DisconはASRを再送信します
Discon ASR successfully sent and Clean up Idle ASA Received with Result-Code
Discon ASRは正常に送信され、結果コードで受信されたアイドルASAをクリーンアップします
Not ASA Received None No Change Discon
ASAが受け取らなかったなし変更ディスコンなし
Any STR Received Send STA, Idle Clean up
STRを受信して送信STA、アイドルクリーンアップ
The following state machine is observed by a client when state is not maintained on the server:
次の状態マシンは、サーバー上で状態が維持されていないときにクライアントによって監視されます。
CLIENT, STATELESS
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send Pending
access service-
specific
auth req
Pending Successful service-specific Grant Open authorization answer access received with Auth-Session-State set to NO_STATE_MAINTAINED
Auth-Session-StateをNO_STATE_MAINTAINEDに設定して受信した保留中の成功したサービス固有のGrant Open承認応答アクセス
Pending Failed service-specific Clean up Idle authorization answer received
保留中の失敗したサービス固有のクリーンアップアイドル認証応答を受信
Open Session-Timeout expires on Discon. Idle access device user/device
Open Session-TimeoutはDisconで期限切れになります。アイドルアクセスデバイスユーザー/デバイス
Open Service to user is terminated Discon. Idle user/device
ユーザーへのオープンサービスはDisconで終了します。アイドル状態のユーザー/デバイス
The following state machine is observed by a server when it is not maintaining state for the session:
次の状態マシンは、セッションの状態を維持していないときにサーバーによって監視されます。
SERVER, STATELESS
State Event Action New State
---------------------------------------------------------------
Idle Service-specific authorization Send Idle
request received, and service-
successfully processed specific
answer
The following state machines MUST be supported for applications that have an accounting portion or that require only accounting services. The first state machine is to be observed by clients.
次のステートマシンは、アカウンティング部分があるアプリケーション、またはアカウンティングサービスのみを必要とするアプリケーションでサポートされている必要があります。最初のステートマシンはクライアントによって監視されます。
See Section 9.7 for Accounting Command Codes and Section 9.8 for Accounting AVPs.
アカウンティングコマンドコードについてはセクション9.7を、アカウンティングAVPについてはセクション9.8を参照してください。
The server side in the accounting state machine depends in some cases on the particular application. The Diameter base protocol defines a default state machine that MUST be followed by all applications that have not specified other state machines. This is the second state machine in this section described below.
The server side in the accounting state machine depends in some cases on the particular application. The Diameter base protocol defines a default state machine that MUST be followed by all applications that have not specified other state machines. This is the second state machine in this section described below.
The default server side state machine requires the reception of accounting records in any order and at any time, and it does not place any standards requirement on the processing of these records. Implementations of Diameter may perform checking, ordering, correlation, fraud detection, and other tasks based on these records. AVPs may need to be inspected as a part of these tasks. The tasks can happen either immediately after record reception or in a post-processing phase. However, as these tasks are typically application or even policy dependent, they are not standardized by the Diameter specifications. Applications MAY define requirements on when to accept accounting records based on the used value of Accounting-Realtime-Required AVP, credit-limit checks, and so on.
デフォルトのサーバー側のステートマシンでは、アカウンティングレコードを任意の順序でいつでも受信する必要があり、これらのレコードの処理に関する標準要件はありません。 Diameterの実装では、これらのレコードに基づいて、チェック、順序付け、相関、不正検出、およびその他のタスクを実行できます。 AVPは、これらのタスクの一部として検査する必要がある場合があります。タスクは、レコードの受信直後または後処理フェーズで発生する可能性があります。ただし、これらのタスクは通常アプリケーションまたはポリシーに依存するため、Diameter仕様によって標準化されていません。アプリケーションは、Accounting-Realtime-Required AVP、信用限度チェックなどの使用された値に基づいて、会計記録をいつ受け入れるかについての要件を定義できます（MAY）。
However, the Diameter base protocol defines one optional server side state machine that MAY be followed by applications that require keeping track of the session state at the accounting server. Note that such tracking is incompatible with the ability to sustain long duration connectivity problems. Therefore, the use of this state machine is recommended only in applications where the value of the Accounting-Realtime-Required AVP is DELIVER_AND_GRANT; hence, accounting connectivity problems are required to cause the serviced user to be disconnected. Otherwise, records produced by the client may be lost by the server, which no longer accepts them after the connectivity is re-established. This state machine is the third state machine in this section. The state machine is supervised by a supervision session timer Ts, whose value should be reasonably higher than the Acct_Interim_Interval value. Ts MAY be set to two times the value of the Acct_Interim_Interval so as to avoid the accounting session in the Diameter server to change to Idle state in case of short transient network failure.
ただし、Diameter基本プロトコルは、アカウンティングサーバーでセッション状態を追跡する必要のあるアプリケーションが後に続く可能性がある1つのオプションのサーバー側の状態マシンを定義します。このようなトラッキングは、長時間の接続の問題を維持する機能と互換性がないことに注意してください。したがって、このステートマシンの使用は、Accounting-Realtime-Required AVPの値がDELIVER_AND_GRANTであるアプリケーションでのみ推奨されます。したがって、サービス対象のユーザーを切断するには、アカウンティング接続の問題が必要です。そうしないと、クライアントによって生成されたレコードがサーバーによって失われる可能性があり、接続が再確立された後はサーバーはそれらを受け入れなくなります。このステートマシンは、このセクションの3番目のステートマシンです。状態マシンは、監視セッションタイマーTsによって監視されます。このタイマーの値は、Acct_Interim_Interval値よりもかなり高い必要があります。 TsをAcct_Interim_Intervalの値の2倍に設定して、短時間の一時的なネットワーク障害の場合にDiameterサーバーのアカウンティングセッションがアイドル状態に変更されるのを防ぐことができます。
Any event not listed in the state machines MUST be considered as an error condition, and a corresponding answer, if applicable, MUST be returned to the originator of the message.
状態マシンにリストされていないイベントはエラー状態と見なされなければならず、該当する場合は対応する応答がメッセージの発信者に返されなければなりません（MUST）。
In the state table, the event "Failure to send" means that the Diameter client is unable to communicate with the desired destination. This could be due to the peer being down, or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting Answer command.
状態テーブルでは、「送信に失敗しました」というイベントは、Diameterクライアントが目的の宛先と通信できないことを意味します。これは、ピアがダウンしているか、ピアが一時的な障害または一時的なプロトコルエラー通知を返しているためである可能性があります。
The event "Failed answer" means that the Diameter client received a non-transient failure notification in the Accounting Answer command.
イベント「失敗した回答」は、Diameterクライアントがアカウンティング回答コマンドで非一時的な失敗通知を受け取ったことを意味します。
Note that the action "Disconnect user/dev" MUST also have an effect on the authorization session state table, e.g., cause the STR message to be sent, if the given application has both authentication/ authorization and accounting portions.
特定のアプリケーションに認証/承認とアカウンティングの両方の部分がある場合、アクション「Disconnect user / dev」も承認セッションステートテーブルに影響を与える必要があることに注意してください。たとえば、STRメッセージが送信されます。
The states PendingS, PendingI, PendingL, PendingE, and PendingB stand for pending states to wait for an answer to an accounting request related to a Start, Interim, Stop, Event, or buffered record, respectively.
状態PendingS、PendingI、PendingL、PendingE、およびPendingBは、それぞれ、開始、暫定、停止、イベント、またはバッファリングされたレコードに関連するアカウンティング要求への応答を待つ保留状態を表します。
CLIENT, ACCOUNTING
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send PendingS
access accounting
start req.
Idle Client or device requests Send PendingE a one-time service accounting event req
アイドル状態のクライアントまたはデバイスは、PendingEに1回限りのサービスアカウンティングイベント要求を要求します。
Idle Records in storage Send PendingB record
Idle Records in storage PendingBレコードを送信
PendingS Successful accounting Open start answer received
PendingS成功したアカウンティングオープンスタートの回答を受け取りました
PendingS Failure to send and buffer Store Open space available and real time Start not equal to DELIVER_AND_GRANT Record
PendingS送信およびバッファのオープンに失敗しました。利用可能なリアルタイムの空き領域とリアルタイムの開始がDELIVER_AND_GRANTレコードと等しくありません
PendingS Failure to send and no buffer Open space available and real time equal to GRANT_AND_LOSE
PendingS送信に失敗し、バッファがありません。使用可能な空き領域があり、リアルタイムはGRANT_AND_LOSEと同じです
PendingS Failure to send and no Disconnect Idle buffer space available and user/dev real time not equal to GRANT_AND_LOSE
PendingS送信に失敗し、Disconnect Idleバッファースペースが利用できず、ユーザー/開発者のリアルタイムがGRANT_AND_LOSEと等しくない
PendingS Failed accounting start answer Open received and real time equal to GRANT_AND_LOSE
PendingS失敗したアカウンティング開始応答Openが受信され、リアルタイムはGRANT_AND_LOSEに等しい
PendingS Failed accounting start answer Disconnect Idle received and real time not user/dev equal to GRANT_AND_LOSE
PendingS失敗したアカウンティング開始応答切断アイドルを受信しましたが、リアルタイムではuser / devがGRANT_AND_LOSEに等しくありません
PendingS User service terminated Store PendingS stop record
PendingSユーザーサービスが終了しましたStore PendingS停止レコード
Open Interim interval elapses Send PendingI accounting interim record
Open Interimインターバルが経過し、Send PendingIアカウンティング中間レコード
Open User service terminated Send PendingL accounting stop req.
オープンユーザーサービスが終了しましたPendingLアカウンティング停止要求の送信。
PendingI Successful accounting interim Open answer received
PendingI成功した会計中間オープン回答を受け取りました
PendingI Failure to send and (buffer Store Open space available or old interim record can be overwritten) record and real time not equal to DELIVER_AND_GRANT
PendingI送信に失敗し、（バッファストアオープンスペースが利用可能であるか、古い暫定レコードが上書きされる可能性があります）レコードとリアルタイムがDELIVER_AND_GRANTと等しくない
PendingI Failure to send and no buffer Open space available and real time equal to GRANT_AND_LOSE
PendingI送信に失敗し、バッファオープンスペースがなく、リアルタイムでGRANT_AND_LOSEに等しい
PendingI Failure to send and no Disconnect Idle buffer space available and user/dev real time not equal to GRANT_AND_LOSE
PendingI送信に失敗し、Disconnect Idleバッファースペースが利用できず、ユーザー/開発者のリアルタイムがGRANT_AND_LOSEと等しくない
PendingI Failed accounting interim Open answer received and real time equal to GRANT_AND_LOSE
PendingI失敗したアカウンティング暫定オープン回答を受け取り、リアルタイムはGRANT_AND_LOSEに等しい
PendingI Failed accounting interim Disconnect Idle answer received and user/dev real time not equal to GRANT_AND_LOSE
PendingI失敗したアカウンティング暫定切断アイドル応答を受け取り、ユーザー/デバイスのリアルタイムがGRANT_AND_LOSEと等しくない
PendingI User service terminated Store PendingI stop record PendingE Successful accounting Idle event answer received
PendingIユーザーサービスが終了しましたStore PendingI停止レコードPendingE成功したアカウンティングアイドルイベントの回答を受信しました
PendingE Failure to send and buffer Store Idle space available event record
PendingE送信およびストアアイドルスペースの利用可能なイベントレコードのバッファリングの失敗
PendingE Failure to send and no buffer Idle space available
PendingE送信に失敗し、使用可能なバッファーアイドルスペースがない
PendingE Failed accounting event answer Idle received
PendingE失敗したアカウンティングイベント応答Idleを受信しました
PendingB Successful accounting answer Delete Idle received record
PendingB成功したアカウンティング応答削除アイドル受信レコード
PendingB Failure to send Idle
PendingB Failure to send Idle
PendingB Failed accounting answer Delete Idle received record
PendingB Failed Accounting Answer Delete Idle received record
PendingL Successful accounting Idle stop answer received
PendingL成功したアカウンティングアイドル停止応答を受信
PendingL Failure to send and buffer Store Idle space available stop record
PendingL送信およびストアアイドルスペースのバッファリングに失敗しました
PendingL Failure to send and no buffer Idle space available
PendingL送信に失敗し、使用可能なバッファーアイドルスペースがない
PendingL Failed accounting stop answer Idle received
PendingL失敗したアカウンティング停止応答アイドル受信
SERVER, STATELESS ACCOUNTING
State Event Action New State
---------------------------------------------------------------
Idle Accounting start request Send Idle received and successfully accounting processed. start answer
Idle Accounting start request Send Idleを受信し、正常にアカウンティングが処理されました。答えを始める
Idle Accounting event request Send Idle received and successfully accounting processed. event answer
Idle Accountingイベント要求Send Idleを受信し、正常にアカウンティングを処理しました。イベント回答
Idle Interim record received Send Idle and successfully processed. accounting interim answer
アイドル中間レコードが送信アイドルを受信し、正常に処理されました。会計中間回答
Idle Accounting stop request Send Idle received and successfully accounting processed stop answer
Idle Accounting stop request Send Idle received and successfully accounting processed stop answer
Idle Accounting request received; Send Idle no space left to store accounting records answer; Result-Code = OUT_OF_ SPACE
アイドル会計要求を受け取りました。アカウンティングレコードの回答を格納するためのスペースをアイドルに送信しない結果コード= OUT_OF_ SPACE
SERVER, STATEFUL ACCOUNTING
State Event Action New State
---------------------------------------------------------------
Idle Accounting start request Send Open received and successfully accounting processed. start answer; Start Ts
Idle Accounting start request Send Openが受信され、正常にアカウンティングが処理されました。答えを始める; Tsを開始
Idle Accounting event request Send Idle received and successfully accounting processed. event answer Idle Accounting request received; Send Idle no space left to store accounting records answer; Result-Code = OUT_OF_ SPACE
Idle Accountingイベント要求Send Idleを受信し、正常にアカウンティングを処理しました。イベント応答アイドルアカウンティング要求が受信されました。アカウンティングレコードの回答を格納するためのスペースをアイドルに送信しない結果コード= OUT_OF_ SPACE
Open Interim record received Send Open and successfully processed. accounting interim answer; Restart Ts
Open InterimレコードはSend Openを受け取り、正常に処理されました。会計暫定回答; Tsを再起動します
Open Accounting stop request Send Idle received and successfully accounting processed stop answer; Stop Ts
Open Accounting stop request Send Idleを受信し、正常に処理された停止応答を送信します。 Tsを停止
Open Accounting request received; Send Idle
no space left to store accounting
records answer;
Result-Code =
OUT_OF_
SPACE;
Stop Ts
Open Session supervision timer Ts Stop Ts Idle expired
Open Session supervision timer Ts Stop Ts Idle expired
A Diameter server may initiate a re-authentication and/or re-authorization service for a particular session by issuing a Re-Auth-Request (RAR).
Diameterサーバーは、再認証リクエスト（RAR）を発行することにより、特定のセッションの再認証サービスや再認証サービスを開始できます。
For example, for prepaid services, the Diameter server that originally authorized a session may need some confirmation that the user is still using the services.
たとえば、プリペイドサービスの場合、最初にセッションを承認したDiameterサーバーは、ユーザーがまだサービスを使用していることを確認する必要があります。
An access device that receives an RAR message with the Session-Id equal to a currently active session MUST initiate a re-auth towards the user, if the service supports this particular feature. Each Diameter application MUST state whether server-initiated re-auth is supported, since some applications do not allow access devices to prompt the user for re-auth.
サービスがこの特定の機能をサポートしている場合、現在アクティブなセッションと等しいセッションIDを持つRARメッセージを受信するアクセスデバイスは、ユーザーに対して再認証を開始する必要があります。一部のアプリケーションでは、アクセスデバイスがユーザーに再認証を要求することを許可しないため、各Diameterアプリケーションは、サーバーが開始した再認証がサポートされているかどうかを明示する必要があります。
The Re-Auth-Request (RAR), indicated by the Command Code set to 258 and the message flags' 'R' bit set, may be sent by any server to the access device that is providing session service, to request that the user be re-authenticated and/or re-authorized.
258に設定されたコマンドコードとメッセージフラグの「R」ビットセットで示される再認証要求（RAR）は、セッションサービスを提供しているアクセスデバイスにサーバーから送信され、ユーザーに再認証および/または再承認されます。
Message Format
メッセージフォーマット
<RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Re-Auth-Answer (RAA), indicated by the Command Code set to 258 and the message flags' 'R' bit clear, is sent in response to the RAR. The Result-Code AVP MUST be present, and it indicates the disposition of the request.
コマンドコードが258に設定され、メッセージフラグの「R」ビットがクリアされていることで示される再認証応答（RAA）は、RARに応答して送信されます。 Result-Code AVPが存在しなければならず（MUST）、リクエストの処理を示します。
A successful RAA message MUST be followed by an application-specific authentication and/or authorization message.
成功したRAAメッセージの後には、アプリケーション固有の認証および/または承認メッセージが続く必要があります。
Message Format
メッセージフォーマット
<RAA> ::= < Diameter Header: 258, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
It is necessary for a Diameter server that authorized a session, for which it is maintaining state, to be notified when that session is no longer active, both for tracking purposes as well as to allow stateful agents to release any resources that they may have provided for the user's session. For sessions whose state is not being maintained, this section is not used.
状態を維持しているセッションを承認したDiameterサーバーは、そのセッションがアクティブでなくなったときに通知される必要があります。これは、追跡の目的と、ステートフルエージェントが提供したリソースを解放できるようにするための両方です。ユーザーのセッション用。状態が維持されていないセッションの場合、このセクションは使用されません。
When a user session that required Diameter authorization terminates, the access device that provided the service MUST issue a Session-Termination-Request (STR) message to the Diameter server that authorized the service, to notify it that the session is no longer active. An STR MUST be issued when a user session terminates for any reason, including user logoff, expiration of Session-Timeout, administrative action, termination upon receipt of an Abort-Session-Request (see below), orderly shutdown of the access device, etc.
Diameter承認を必要とするユーザーセッションが終了すると、サービスを提供したアクセスデバイスは、サービスを承認したDiameterサーバーにSession-Termination-Request（STR）メッセージを発行して、セッションがアクティブでなくなったことを通知する必要があります。 STRは、ユーザーのログオフ、Session-Timeoutの期限切れ、管理アクション、Abort-Session-Request（以下を参照）の受信による終了、アクセスデバイスの正常なシャットダウンなど、何らかの理由でユーザーセッションが終了したときに発行する必要があります。 。
The access device also MUST issue an STR for a session that was authorized but never actually started. This could occur, for example, due to a sudden resource shortage in the access device, or because the access device is unwilling to provide the type of service requested in the authorization, or because the access device does not support a mandatory AVP returned in the authorization, etc.
アクセスデバイスは、承認されたが実際には開始されなかったセッションに対してもSTRを発行する必要があります。これは、たとえば、アクセスデバイスの突然のリソース不足、アクセスデバイスが承認で要求されたタイプのサービスを提供することを望まない、またはアクセスデバイスが必須のAVPをサポートしていないために発生する可能性があります。認可など
It is also possible that a session that was authorized is never actually started due to action of a proxy. For example, a proxy may modify an authorization answer, converting the result from success to failure, prior to forwarding the message to the access device. If the answer did not contain an Auth-Session-State AVP with the value NO_STATE_MAINTAINED, a proxy that causes an authorized session not to be started MUST issue an STR to the Diameter server that authorized the session, since the access device has no way of knowing that the session had been authorized.
また、プロキシーのアクションにより、許可されたセッションが実際に開始されない場合もあります。たとえば、プロキシは、メッセージをアクセスデバイスに転送する前に、認証の回答を変更し、結果を成功から失敗に変換する場合があります。回答にNO-STATE_MAINTAINEDという値のAuth-Session-State AVPが含まれていなかった場合、承認されたセッションが開始されないようにするプロキシは、セッションを承認したDiameterサーバーにSTRを発行する必要があります。これは、アクセスデバイスに方法がないためです。セッションが承認されたことを知る。
A Diameter server that receives an STR message MUST clean up resources (e.g., session state) associated with the Session-Id specified in the STR and return a Session-Termination-Answer.
STRメッセージを受信するDiameterサーバーは、STRで指定されたSession-Idに関連付けられているリソース（セッション状態など）をクリーンアップして、Session-Termination-Answerを返す必要があります。
A Diameter server also MUST clean up resources when the Session-Timeout expires, or when the Authorization-Lifetime and the Auth-Grace-Period AVPs expire without receipt of a re-authorization request, regardless of whether an STR for that session is received. The access device is not expected to provide service beyond the expiration of these timers; thus, expiration of either of these timers implies that the access device may have unexpectedly shut down.
また、Diameterサーバーは、Session-Timeoutが期限切れになったとき、またはAuthorization-LifetimeとAuth-Grace-Period AVPが期限切れになったときに、そのセッションのSTRを受信したかどうかに関係なく、再承認リクエストを受信せずにリソースをクリーンアップする必要があります。アクセスデバイスは、これらのタイマーの有効期限を超えてサービスを提供することは期待されていません。したがって、これらのタイマーのいずれかの満了は、アクセスデバイスが予期せずシャットダウンした可能性があることを意味します。
The Session-Termination-Request (STR), indicated by the Command Code set to 275 and the Command Flags' 'R' bit set, is sent by a Diameter client or by a Diameter proxy to inform the Diameter server that an authenticated and/or authorized session is being terminated.
コマンドコードが275に設定され、コマンドフラグの「R」ビットが設定されていることで示されるセッション終了要求（STR）は、DiameterクライアントまたはDiameterプロキシによって送信され、Diameterサーバーに認証済みおよび/またはまたは、許可されたセッションが終了しています。
Message Format
メッセージフォーマット
<STR> ::= < Diameter Header: 275, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Termination-Cause }
[ User-Name ]
[ Destination-Host ]
* [ Class ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Session-Termination-Answer (STA), indicated by the Command Code set to 275 and the message flags' 'R' bit clear, is sent by the Diameter server to acknowledge the notification that the session has been terminated. The Result-Code AVP MUST be present, and it MAY contain an indication that an error occurred while servicing the STR.
コマンドコードが275に設定され、メッセージフラグの「R」ビットがクリアされていることを示すSession-Termination-Answer（STA）は、Diameterサーバーによって送信され、セッションが終了したことの通知を確認します。 Result-Code AVPが存在する必要があり、STRのサービス中にエラーが発生したことを示す情報が含まれる場合があります。
Upon sending or receipt of the STA, the Diameter server MUST release all resources for the session indicated by the Session-Id AVP. Any intermediate server in the Proxy-Chain MAY also release any resources, if necessary.
STAを送信または受信すると、Diameterサーバーは、Session-Id AVPで示されたセッションのすべてのリソースを解放する必要があります。プロキシチェーンの中間サーバーも、必要に応じてリソースを解放できます（MAY）。
Message Format
メッセージフォーマット
<STA> ::= < Diameter Header: 275, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
* [ Class ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Origin-State-Id ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
A Diameter server may request that the access device stop providing service for a particular session by issuing an Abort-Session-Request (ASR).
Diameterサーバーは、Abort-Session-Request（ASR）を発行することにより、アクセスデバイスが特定のセッションに対するサービスの提供を停止することを要求できます。
For example, the Diameter server that originally authorized the session may be required to cause that session to be stopped for lack of credit or other reasons that were not anticipated when the session was first authorized.
たとえば、最初にセッションを承認したDiameterサーバーは、クレジットの不足や、セッションが最初に承認されたときに予期されなかったその他の理由により、そのセッションを停止する必要がある場合があります。
An access device that receives an ASR with Session-ID equal to a currently active session MAY stop the session. Whether the access device stops the session or not is implementation and/or configuration dependent. For example, an access device may honor ASRs from certain agents only. In any case, the access device MUST respond with an Abort-Session-Answer, including a Result-Code AVP to indicate what action it took.
現在アクティブなセッションと等しいセッションIDを持つASRを受信するアクセスデバイスは、セッションを停止する場合があります。アクセスデバイスがセッションを停止するかどうかは、実装や構成に依存します。たとえば、アクセスデバイスは特定のエージェントからのASRのみを受け入れる場合があります。いずれの場合でも、アクセスデバイスは、Result-Code AVPを含むAbort-Session-Answerで応答し、どのアクションを実行したかを示す必要があります。
The Abort-Session-Request (ASR), indicated by the Command Code set to 274 and the message flags' 'R' bit set, may be sent by any Diameter server or any Diameter proxy to the access device that is providing session service, to request that the session identified by the Session-Id be stopped.
274に設定されたコマンドコードとメッセージフラグの「R」ビットセットで示される中止セッション要求（ASR）は、任意のDiameterサーバーまたは任意のDiameterプロキシによって、セッションサービスを提供しているアクセスデバイスに送信できます。 Session-Idで識別されるセッションの停止を要求する。
Message Format
メッセージフォーマット
<ASR> ::= < Diameter Header: 274, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Abort-Session-Answer (ASA), indicated by the Command Code set to 274 and the message flags' 'R' bit clear, is sent in response to the ASR. The Result-Code AVP MUST be present and indicates the disposition of the request.
コマンドコードが274に設定され、メッセージフラグの「R」ビットがクリアされていることで示されるAbort-Session-Answer（ASA）は、ASRに応答して送信されます。 Result-Code AVPが存在しなければならず、リクエストの処理を示します。
If the session identified by Session-Id in the ASR was successfully terminated, the Result-Code is set to DIAMETER_SUCCESS. If the session is not currently active, the Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the session for any other reason, the Result-Code is set to DIAMETER_UNABLE_TO_COMPLY.
ASRのSession-Idで識別されるセッションが正常に終了した場合、Result-CodeはDIAMETER_SUCCESSに設定されます。セッションが現在アクティブでない場合、Result-CodeはDIAMETER_UNKNOWN_SESSION_IDに設定されます。アクセスデバイスが他の理由でセッションを停止しない場合、Result-CodeはDIAMETER_UNABLE_TO_COMPLYに設定されます。
Message Format
メッセージフォーマット
<ASA> ::= < Diameter Header: 274, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
The Origin-State-Id is used to allow detection of terminated sessions for which no STR would have been issued, due to unanticipated shutdown of an access device.
Origin-State-Idは、アクセスデバイスの予期しないシャットダウンが原因でSTRが発行されなかった終了したセッションの検出を可能にするために使用されます。
A Diameter client or access device increments the value of the Origin-State-Id every time it is started or powered up. The new Origin-State-Id is then sent in the CER/CEA message immediately upon connection to the server. The Diameter server receiving the new Origin-State-Id can determine whether the sending Diameter client had abruptly shut down by comparing the old value of the Origin-State-Id it has kept for that specific client is less than the new value and whether it has un-terminated sessions originating from that client.
A Diameter client or access device increments the value of the Origin-State-Id every time it is started or powered up. The new Origin-State-Id is then sent in the CER/CEA message immediately upon connection to the server. The Diameter server receiving the new Origin-State-Id can determine whether the sending Diameter client had abruptly shut down by comparing the old value of the Origin-State-Id it has kept for that specific client is less than the new value and whether it has un-terminated sessions originating from that client.
An access device can also include the Origin-State-Id in request messages other than the CER if there are relays or proxies in between the access device and the server. In this case, however, the server cannot discover that the access device has been restarted unless and until it receives a new request from it. Therefore, this mechanism is more opportunistic across proxies and relays.
アクセスデバイスとサーバーの間にリレーまたはプロキシがある場合、アクセスデバイスはCER以外の要求メッセージにOrigin-State-Idを含めることもできます。ただし、この場合、サーバーは、アクセスデバイスから新しいリクエストを受信しない限り、アクセスデバイスが再起動されたことを検出できません。したがって、このメカニズムはプロキシとリレー全体でより便宜的です。
The Diameter server may assume that all sessions that were active prior to detection of a client restart have been terminated. The Diameter server MAY clean up all session state associated with such lost sessions, and it MAY also issue STRs for all such lost sessions that were authorized on upstream servers, to allow session state to be cleaned up globally.
Diameterサーバーは、クライアントの再起動が検出される前にアクティブであったすべてのセッションが終了したと想定する場合があります。 Diameterサーバーは、このような失われたセッションに関連付けられたすべてのセッション状態をクリーンアップできます（MAY）。また、上流のサーバーで承認されたすべての失われたセッションに対してSTRを発行して、セッション状態をグローバルにクリーンアップできるようにすることもできます（MAY）。
The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is included in application-specific auth requests to inform the peers whether a user is to be authenticated only, authorized only, or both. Note any value other than both MAY cause RADIUS interoperability issues. The following values are defined:
Auth-Request-Type AVP（AVPコード274）はEnumeratedタイプであり、アプリケーション固有の認証リクエストに含まれており、ユーザーが認証のみか、承認のみか、またはその両方かをピアに通知します。両方以外の値はRADIUSの相互運用性の問題を引き起こす可能性があることに注意してください。以下の値が定義されています。
AUTHENTICATE_ONLY 1
AUTHENTICATE_ONLY 1
The request being sent is for authentication only, and it MUST contain the relevant application-specific authentication AVPs that are needed by the Diameter server to authenticate the user.
The request being sent is for authentication only, and it MUST contain the relevant application-specific authentication AVPs that are needed by the Diameter server to authenticate the user.
AUTHORIZE_ONLY 2
AUTHORIZE_ONLY 2
The request being sent is for authorization only, and it MUST contain the application-specific authorization AVPs that are necessary to identify the service being requested/offered.
送信される要求は許可のみを目的としており、要求/提供されるサービスを識別するために必要なアプリケーション固有の許可AVPを含んでいる必要があります。
AUTHORIZE_AUTHENTICATE 3
AUTHORIZE AUTHENTICATE 3
The request contains a request for both authentication and authorization. The request MUST include both the relevant application-specific authentication information and authorization information necessary to identify the service being requested/ offered.
要求には、認証と承認の両方の要求が含まれています。リクエストには、関連するアプリケーション固有の認証情報と、リクエスト/提供されるサービスを識別するために必要な承認情報の両方を含める必要があります。
The Session-Id AVP (AVP Code 263) is of type UTF8String and is used to identify a specific session (see Section 8). All messages pertaining to a specific session MUST include only one Session-Id AVP, and the same value MUST be used throughout the life of a session. When present, the Session-Id SHOULD appear immediately following the Diameter header (see Section 3).
Session-Id AVP（AVPコード263）はUTF8Stringタイプであり、特定のセッションを識別するために使用されます（セクション8を参照）。特定のセッションに関連するすべてのメッセージには、Session-Id AVPが1つだけ含まれている必要があり、セッションの存続期間を通じて同じ値を使用する必要があります。存在する場合、Session-IdはDiameterヘッダーの直後に表示する必要があります（セクション3を参照）。
The Session-Id MUST be globally and eternally unique, as it is meant to uniquely identify a user session without reference to any other information, and it may be needed to correlate historical authentication information with accounting information. The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below.
Session-Idは、他の情報を参照せずにユーザーセッションを一意に識別することを目的としているため、グローバルかつ永続的に一意である必要があり、履歴認証情報とアカウンティング情報を関連付ける必要がある場合があります。 Session-Idには、必須部分と実装定義部分が含まれています。実装定義部分の推奨フォーマットの概要を以下に示します。
The Session-Id MUST begin with the sender's identity encoded in the DiameterIdentity type (see Section 4.3.1). The remainder of the Session-Id is delimited by a ";" character, and it MAY be any sequence that the client can guarantee to be eternally unique; however, the following format is recommended, (square brackets [] indicate an optional element):
Session-Idは、DiameterIdentityタイプでエンコードされた送信者のIDで始まる必要があります（セクション4.3.1を参照）。 Session-Idの残りは「;」で区切られます。文字であり、クライアントが永久に一意であることを保証できる任意のシーケンスである場合があります。ただし、次の形式をお勧めします（角括弧[]はオプションの要素を示します）。
<DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]
<high 32 bits> and <low 32 bits> are decimal representations of the high and low 32 bits of a monotonically increasing 64-bit value. The 64-bit value is rendered in two part to simplify formatting by 32-bit processors. At startup, the high 32 bits of the 64-bit value MAY be initialized to the time in NTP format [RFC5905], and the low 32 bits MAY be initialized to zero. This will for practical purposes eliminate the possibility of overlapping Session-Ids after a reboot, assuming the reboot process takes longer than a second. Alternatively, an implementation MAY keep track of the increasing value in non-volatile memory.
<high 32 bits>および<low 32 bits>は、単調に増加する64ビット値の上位および下位32ビットの10進表記です。 64ビット値は、32ビットプロセッサによるフォーマットを簡略化するために2つの部分でレンダリングされます。起動時に、64ビット値の上位32ビットはNTP形式[RFC5905]の時刻に初期化される場合があり、下位32ビットはゼロに初期化される場合があります。これにより、再起動プロセスに1秒以上かかると仮定して、再起動後にSession-Idが重複する可能性がなくなります。あるいは、実装は不揮発性メモリの増加する値を追跡してもよい（MAY）。
<optional value> is implementation specific, but it may include a modem's device Id, a Layer 2 address, timestamp, etc.
<オプション値>は実装固有ですが、モデムのデバイスID、レイヤー2アドレス、タイムスタンプなどが含まれる場合があります。
Example, in which there is no optional value:
Example, in which there is no optional value:
accesspoint7.example.com;1876543210;523
accesspoint7.example.com; 1876543210; 523
Example, in which there is an optional value:
オプションの値がある例：
accesspoint7.example.com;1876543210;523;mobile@200.1.1.88
The Session-Id is created by the Diameter application initiating the session, which, in most cases, is done by the client. Note that a Session-Id MAY be used for both the authentication, authorization, and accounting commands of a given application.
セッションIDは、セッションを開始するDiameterアプリケーションによって作成されます。これは、ほとんどの場合、クライアントによって行われます。 Session-Idは、特定のアプリケーションの認証、承認、およびアカウンティングコマンドの両方に使用される場合があります。
The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32 and contains the maximum number of seconds of service to be provided to the user before the user is to be re-authenticated and/or re-authorized. Care should be taken when the Authorization-Lifetime value is determined, since a low, non-zero value could create significant Diameter traffic, which could congest both the network and the agents.
Authorization-Lifetime AVP（AVPコード291）のタイプはUnsigned32であり、ユーザーが再認証または再承認される前にユーザーに提供されるサービスの最大秒数が含まれています。 Authorization-Lifetime値を決定するときは注意が必要です。ゼロ以外の低い値を指定すると、Diameterトラフィックが大量に発生し、ネットワークとエージェントの両方が混雑する可能性があるためです。
A value of zero (0) means that immediate re-auth is necessary by the access device. The absence of this AVP, or a value of all ones (meaning all bits in the 32-bit field are set to one) means no re-auth is expected.
ゼロ（0）の値は、アクセスデバイスによる即時の再認証が必要であることを意味します。このAVPがない、またはすべて1の値（32ビットフィールドのすべてのビットが1に設定されていることを意味する）は、再認証が予期されないことを意味します。
If both this AVP and the Session-Timeout AVP are present in a message, the value of the latter MUST NOT be smaller than the Authorization-Lifetime AVP.
このAVPとSession-Timeout AVPの両方がメッセージに存在する場合、後者の値はAuthorization-Lifetime AVPより小さくてはなりません（MUST NOT）。
An Authorization-Lifetime AVP MAY be present in re-authorization messages, and it contains the number of seconds the user is authorized to receive service from the time the re-auth answer message is received by the access device.
Authorization-Lifetime AVPは再認証メッセージに存在する場合があり、再認証応答メッセージがアクセスデバイスによって受信されたときからユーザーがサービスを受信することを許可された秒数が含まれます。
This AVP MAY be provided by the client as a hint of the maximum lifetime that it is willing to accept. The server MUST return a value that is equal to, or smaller than, the one provided by the client.
このAVPは、クライアントが受け入れ可能な最大有効期間のヒントとしてクライアントから提供される場合があります。サーバーは、クライアントから提供された値以下の値を返さなければなりません（MUST）。
The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and contains the number of seconds the Diameter server will wait following the expiration of the Authorization-Lifetime AVP before cleaning up resources for the session.
Auth-Grace-Period AVP（AVPコード276）のタイプはUnsigned32であり、セッションのリソースをクリーンアップする前に、Authorization-Lifetime AVPの期限切れ後にDiameterサーバーが待機する秒数が含まれています。
The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and specifies whether state is maintained for a particular session. The client MAY include this AVP in requests as a hint to the server, but the value in the server's answer message is binding. The following values are supported:
Auth-Session-State AVP（AVPコード277）は列挙型であり、特定のセッションで状態が維持されるかどうかを指定します。クライアントはサーバーへのヒントとしてリクエストにこのAVPを含めることができますが、サーバーの応答メッセージの値はバインドされています。次の値がサポートされています。
STATE_MAINTAINED 0
STATE_MAINTAINED 0
This value is used to specify that session state is being maintained, and the access device MUST issue a session termination message when service to the user is terminated. This is the default value.
この値は、セッション状態が維持されていることを指定するために使用され、アクセスデバイスは、ユーザーへのサービスが終了したときにセッション終了メッセージを発行する必要があります。これがデフォルト値です。
NO_STATE_MAINTAINED 1
NO_STATE_MAINTAINED 1
This value is used to specify that no session termination messages will be sent by the access device upon expiration of the Authorization-Lifetime.
この値は、Authorization-Lifetimeの有効期限が切れたときにセッション終了メッセージがアクセスデバイスによって送信されないことを指定するために使用されます。
The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and is included in application-specific auth answers to inform the client of the action expected upon expiration of the Authorization-Lifetime.
Re-Auth-Request-Type AVP（AVPコード285）はEnumeratedタイプであり、アプリケーション固有の認証応答に含まれており、Authorization-Lifetimeの期限切れ時に予期されるアクションをクライアントに通知します。
If the answer message contains an Authorization-Lifetime AVP with a positive value, the Re-Auth-Request-Type AVP MUST be present in an answer message. The following values are defined:
応答メッセージに正の値のAuthorization-Lifetime AVPが含まれている場合、Re-Auth-Request-Type AVPが応答メッセージに存在する必要があります。以下の値が定義されています。
AUTHORIZE_ONLY 0
AUTHORIZE_ONLY 0
An authorization only re-auth is expected upon expiration of the Authorization-Lifetime. This is the default value if the AVP is not present in answer messages that include the Authorization-Lifetime.
Authorization-Lifetimeの期限が切れると、承認のみの再認証が期待されます。これは、Authorization-Lifetimeを含む応答メッセージにAVPが存在しない場合のデフォルト値です。
AUTHORIZE_AUTHENTICATE 1
AUTHORIZE AUTHENTICATE 1
An authentication and authorization re-auth is expected upon expiration of the Authorization-Lifetime.
Authorization-Lifetimeの有効期限が切れると、認証と承認の再認証が期待されます。
The Session-Timeout AVP (AVP Code 27) [RFC2865] is of type Unsigned32 and contains the maximum number of seconds of service to be provided to the user before termination of the session. When both the Session-Timeout and the Authorization-Lifetime AVPs are present in an answer message, the former MUST be equal to or greater than the value of the latter.
セッションタイムアウトAVP（AVPコード27）[RFC2865]はUnsigned32タイプであり、セッションが終了する前にユーザーに提供されるサービスの最大秒数が含まれています。 Session-TimeoutとAuthorization-Lifetime AVPの両方が応答メッセージに存在する場合、前者は後者の値以上でなければなりません（MUST）。
A session that terminates on an access device due to the expiration of the Session-Timeout MUST cause an STR to be issued, unless both the access device and the home server had previously agreed that no session termination messages would be sent (see Section 8).
アクセスデバイスとホームサーバーの両方が以前にセッション終了メッセージを送信しないことに同意していない限り、セッションタイムアウトの期限切れのためにアクセスデバイスで終了するセッションは、STRを発行する必要があります（セクション8を参照）。 。
A Session-Timeout AVP MAY be present in a re-authorization answer message, and it contains the remaining number of seconds from the beginning of the re-auth.
セッションタイムアウトAVPは再認証応答メッセージに存在する場合があり、再認証の開始からの残りの秒数が含まれている場合があります。
A value of zero, or the absence of this AVP, means that this session has an unlimited number of seconds before termination.
ゼロの値、またはこのAVPがないことは、このセッションの終了までの秒数が無制限であることを意味します。
This AVP MAY be provided by the client as a hint of the maximum timeout that it is willing to accept. However, the server MAY return a value that is equal to, or smaller than, the one provided by the client.
このAVPは、クライアントが許容できる最大タイムアウトのヒントとしてクライアントから提供される場合があります。ただし、サーバーは、クライアントから提供された値以下の値を返す場合があります。
The User-Name AVP (AVP Code 1) [RFC2865] is of type UTF8String, which contains the User-Name, in a format consistent with the NAI specification [RFC4282].
User-Name AVP（AVPコード1）[RFC2865]は、UTF8Stringタイプであり、NAI仕様[RFC4282]と一致する形式でUser-Nameを含みます。
The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and is used to indicate the reason why a session was terminated on the access device. The currently assigned values for this AVP can be found in the IANA registry for Termination-Cause AVP Values [IANATCV].
Termination-Cause AVP（AVPコード295）は列挙型であり、セッションがアクセスデバイスで終了した理由を示すために使用されます。このAVPに現在割り当てられている値は、終了原因AVP値[IANATCV]のIANAレジストリにあります。
The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a monotonically increasing value that is advanced whenever a Diameter entity restarts with loss of previous state, for example, upon reboot. Origin-State-Id MAY be included in any Diameter message, including CER.
Unsigned32タイプのOrigin-State-Id AVP（AVPコード278）は単調に増加する値であり、Diameterエンティティが再起動するなど、以前の状態が失われて再起動するたびに進みます。 Origin-State-Idは、CERを含むすべてのDiameterメッセージに含めることができます。
A Diameter entity issuing this AVP MUST create a higher value for this AVP each time its state is reset. A Diameter entity MAY set Origin-State-Id to the time of startup, or it MAY use an incrementing counter retained in non-volatile memory across restarts.
このAVPを発行するDiameterエンティティは、状態がリセットされるたびに、このAVPにより高い値を作成する必要があります。 Diameterエンティティは、Origin-State-Idを起動時の時間に設定する場合があります。または、再起動時に不揮発性メモリに保持されるインクリメントカウンターを使用する場合があります。
The Origin-State-Id, if present, MUST reflect the state of the entity indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST either remove Origin-State-Id or modify it appropriately as well. Typically, Origin-State-Id is used by an access device that always starts up with no active sessions; that is, any session active prior to restart will have been lost. By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0.
Origin-State-Idが存在する場合は、Origin-Hostによって示されるエンティティの状態を反映する必要があります。プロキシがOrigin-Hostを変更する場合、Origin-State-Idを削除するか、適切に変更する必要があります。通常、Origin-State-Idは、アクティブなセッションなしで常に起動するアクセスデバイスによって使用されます。つまり、再起動前にアクティブだったセッションはすべて失われます。メッセージにOrigin-State-Idを含めることで、他のDiameterエンティティは、より低いOrigin-State-Idに関連付けられたセッションがアクティブではなくなったと推測できます。アクセスデバイスがそのような推論が行われることを意図していない場合は、メッセージにOrigin-State-Idを含めないか、その値を0に設定する必要があります。
The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and it MAY be present in application-specific authorization answer messages. If present, this AVP MAY inform the Diameter client that all future application-specific re-auth and Session-Termination-Request messages for this session MUST be sent to the same authorization server.
セッションバインディングAVP（AVPコード270）はタイプUnsigned32であり、アプリケーション固有の承認応答メッセージに存在する場合があります。存在する場合、このAVPは、Diameterクライアントに、このセッションの将来のすべてのアプリケーション固有の再認証およびSession-Termination-Requestメッセージを同じ認証サーバーに送信する必要があることを通知できます（MAY）。
This field is a bit mask, and the following bits have been defined:
このフィールドはビットマスクであり、次のビットが定義されています。
RE_AUTH 1
RE_AUTH 1
When set, future re-auth messages for this session MUST NOT include the Destination-Host AVP. When cleared, the default value, the Destination-Host AVP MUST be present in all re-auth messages for this session.
設定すると、このセッションの今後の再認証メッセージに宛先ホストAVPを含めることはできません。オフにすると、デフォルト値のDestination-Host AVPが、このセッションのすべての再認証メッセージに存在する必要があります。
STR 2
STR 2
When set, the STR message for this session MUST NOT include the Destination-Host AVP. When cleared, the default value, the Destination-Host AVP MUST be present in the STR message for this session.
設定されている場合、このセッションのSTRメッセージに宛先ホストAVPを含めてはなりません（MUST NOT）。オフにすると、デフォルト値のDestination-Host AVPがこのセッションのSTRメッセージに存在する必要があります。
ACCOUNTING 4
会計4
When set, all accounting messages for this session MUST NOT include the Destination-Host AVP. When cleared, the default value, the Destination-Host AVP, if known, MUST be present in all accounting messages for this session.
設定すると、このセッションのすべてのアカウンティングメッセージに宛先ホストAVPを含めることはできません。クリアすると、デフォルト値のDestination-Host AVPがわかっている場合は、このセッションのすべてのアカウンティングメッセージに存在する必要があります。
The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated and MAY be present in application-specific authorization answer messages that either do not include the Session-Binding AVP or include the Session-Binding AVP with any of the bits set to a zero value. If present, this AVP MAY inform the Diameter client that if a re-auth or STR message fails due to a delivery problem, the Diameter client SHOULD issue a subsequent message without the Destination-Host AVP. When absent, the default value is REFUSE_SERVICE.
Session-Server-Failover AVP（AVPコード271）は列挙型であり、Session-Binding AVPを含まないか、ビットのいずれかが設定されたSession-Binding AVPを含むアプリケーション固有の認証応答メッセージに存在する場合があります。ゼロ値に。存在する場合、このAVPは、Diameterクライアントに、配信の問題が原因で再認証またはSTRメッセージが失敗した場合、Destination-Host AVPなしで後続のメッセージを発行する必要があることを通知できます（MAY）。存在しない場合、デフォルト値はREFUSE_SERVICEです。
The following values are supported:
次の値がサポートされています。
REFUSE_SERVICE 0
REFUSE_SERVICE 0
If either the re-auth or the STR message delivery fails, terminate service with the user and do not attempt any subsequent attempts.
再認証またはSTRメッセージの配信のいずれかが失敗した場合は、ユーザーとのサービスを終了し、その後の試行は行わないでください。
TRY_AGAIN 1
TRY_AGAIN 1
If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present.
再認証またはSTRメッセージの配信に失敗した場合は、Destination-Host AVPが存在しない状態で失敗したメッセージを再送信します。
ALLOW_SERVICE 2
ALLOW_SERVICE 2
If re-auth message delivery fails, assume that re-authorization succeeded. If STR message delivery fails, terminate the session.
再認証メッセージの配信が失敗した場合は、再認証が成功したと想定します。 STRメッセージの配信に失敗した場合は、セッションを終了します。
TRY_AGAIN_ALLOW_SERVICE 3
TRY_AGAIN_ALLOW_SERVICE 3
If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present. If the second delivery fails for re-auth, assume re-authorization succeeded. If the second delivery fails for STR, terminate the session.
再認証またはSTRメッセージの配信に失敗した場合は、Destination-Host AVPが存在しない状態で失敗したメッセージを再送信します。 2回目の配信が再認証に失敗した場合は、再認証が成功したと見なします。 STRの2回目の配信が失敗した場合は、セッションを終了します。
The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32 and SHOULD be present in application-specific authorization answer messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH. This AVP contains the maximum number of seconds that the access device MUST provide the user in responding to an authentication request.
Multi-Round-Time-Out AVP（AVPコード272）はタイプUnsigned32であり、Result-Code AVPがDIAMETER_MULTI_ROUND_AUTHに設定されているアプリケーション固有の認証応答メッセージに存在する必要があります（SHOULD）。このAVPには、アクセスデバイスが認証要求に応答してユーザーに提供する必要がある最大秒数が含まれています。
The Class AVP (AVP Code 25) is of type OctetString and is used by Diameter servers to return state information to the access device. When one or more Class AVPs are present in application-specific authorization answer messages, they MUST be present in subsequent re-authorization, session termination and accounting messages. Class AVPs found in a re-authorization answer message override the ones found in any previous authorization answer message. Diameter server implementations SHOULD NOT return Class AVPs that require more than 4096 bytes of storage on the Diameter client. A Diameter client that receives Class AVPs whose size exceeds local available storage MUST terminate the session.
クラスAVP（AVPコード25）はタイプOctetStringであり、アクセスデバイスに状態情報を返すためにDiameterサーバーによって使用されます。 1つ以上のクラスAVPがアプリケーション固有の許可応答メッセージに存在する場合、それらは後続の再許可、セッション終了、およびアカウンティングメッセージに存在する必要があります。再承認応答メッセージで見つかったクラスAVPは、以前の承認応答メッセージで見つかったクラスAVPを上書きします。 Diameterサーバーの実装は、Diameterクライアントに4096バイトを超えるストレージを必要とするクラスAVPを返すべきではありません（SHOULD NOT）。ローカルの使用可能なストレージを超えるサイズのクラスAVPを受信するDiameterクライアントは、セッションを終了する必要があります。
The Event-Timestamp (AVP Code 55) is of type Time and MAY be included in an Accounting-Request and Accounting-Answer messages to record the time that the reported event occurred, in seconds since January 1, 1900 00:00 UTC.
Event-Timestamp（AVPコード55）のタイプはTimeであり、1900年1月1日00:00 UTCからの秒数で報告されたイベントが発生した時間を記録するために、Accounting-RequestおよびAccounting-Answerメッセージに含めることができます。
This accounting protocol is based on a server directed model with capabilities for real-time delivery of accounting information. Several fault resilience methods [RFC2975] have been built into the protocol in order minimize loss of accounting data in various fault situations and under different assumptions about the capabilities of the used devices.
このアカウンティングプロトコルは、アカウンティング情報のリアルタイム配信機能を備えたサーバー向けモデルに基づいています。さまざまな障害状況で、使用されているデバイスの機能に関するさまざまな想定の下でのアカウンティングデータの損失を最小限に抑えるために、いくつかの障害回復方法[RFC2975]がプロトコルに組み込まれています。
The server directed model means that the device generating the accounting data gets information from either the authorization server (if contacted) or the accounting server regarding the way accounting data shall be forwarded. This information includes accounting record timeliness requirements.
サーバー向けモデルとは、アカウンティングデータを生成するデバイスが、アカウンティングデータの転送方法に関して、承認サーバー（接続されている場合）またはアカウンティングサーバーから情報を取得することを意味します。この情報には、会計記録の適時性要件が含まれます。
As discussed in [RFC2975], real-time transfer of accounting records is a requirement, such as the need to perform credit-limit checks and fraud detection. Note that batch accounting is not a requirement, and is therefore not supported by Diameter. Should batched accounting be required in the future, a new Diameter application will need to be created, or it could be handled using another protocol. Note, however, that even if at the Diameter layer, accounting requests are processed one by one; transport protocols used under Diameter typically batch several requests in the same packet under heavy traffic conditions. This may be sufficient for many applications.
[RFC2975]で説明されているように、アカウンティングレコードのリアルタイム転送は、信用限度チェックや不正検出の実行などの要件です。バッチアカウンティングは必須ではないため、Diameterではサポートされていません。将来的にバッチアカウンティングが必要になった場合は、新しいDiameterアプリケーションを作成する必要があります。または、別のプロトコルを使用して処理することもできます。ただし、Diameterレイヤーにある場合でも、アカウンティング要求は1つずつ処理されることに注意してください。 Diameterで使用されるトランスポートプロトコルは、通常、トラフィックの多い状況で同じパケットにいくつかの要求をバッチ処理します。これは、多くのアプリケーションで十分な場合があります。
The authorization server (chain) directs the selection of proper transfer strategy, based on its knowledge of the user and relationships of roaming partnerships. The server (or agents) uses the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to control the operation of the Diameter peer operating as a client. The Acct-Interim-Interval AVP, when present, instructs the Diameter node acting as a client to produce accounting records continuously even during a session. Accounting-Realtime-Required AVP is used to control the behavior of the client when the transfer of accounting records from the Diameter client is delayed or unsuccessful.
承認サーバー（チェーン）は、ユーザーの知識とローミングパートナーシップの関係に基づいて、適切な転送戦略の選択を指示します。サーバー（またはエージェント）は、Acct-Interim-IntervalおよびAccounting-Realtime-Required AVPを使用して、クライアントとして動作するDiameterピアの動作を制御します。 Acct-Interim-Interval AVP（存在する場合）は、クライアントとして機能するDiameterノードに、セッション中でも継続的にアカウンティングレコードを生成するように指示します。 Accounting-Realtime-Required AVPは、Diameterクライアントからのアカウンティングレコードの転送が遅延または失敗したときのクライアントの動作を制御するために使用されます。
The Diameter accounting server MAY override the interim interval or the real-time requirements by including the Acct-Interim-Interval or Accounting-Realtime-Required AVP in the Accounting-Answer message. When one of these AVPs is present, the latest value received SHOULD be used in further accounting activities for the same session.
Diameterアカウンティングサーバーは、Accounting-AnswerメッセージにAcct-Interim-IntervalまたはAccounting-Realtime-Required AVPを含めることにより、暫定間隔またはリアルタイム要件をオーバーライドできます（MAY）。これらのAVPのいずれかが存在する場合、受け取った最新の値を同じセッションの以降の会計アクティビティで使用する必要があります（SHOULD）。
A Diameter node that receives a successful authentication and/or authorization message from the Diameter server SHOULD collect accounting information for the session. The Accounting-Request message is used to transmit the accounting information to the Diameter server, which MUST reply with the Accounting-Answer message to confirm reception. The Accounting-Answer message includes the Result-Code AVP, which MAY indicate that an error was present in the accounting message. The value of the Accounting-Realtime-Required AVP received earlier for the session in question may indicate that the user's session has to be terminated when a rejected Accounting-Request message was received.
Diameterサーバーから正常な認証または承認メッセージを受信するDiameterノードは、セッションのアカウンティング情報を収集する必要があります（SHOULD）。 Accounting-Requestメッセージは、アカウンティング情報をDiameterサーバーに送信するために使用されます。Diameterサーバーは、受信を確認するためにAccounting-Answerメッセージで応答する必要があります。 Accounting-Answerメッセージには、Result-Code AVPが含まれています。これは、アカウンティングメッセージにエラーが存在したことを示す場合があります。問題のセッションについて以前に受信したAccounting-Realtime-Required AVPの値は、拒否されたAccounting-Requestメッセージを受信したときにユーザーのセッションを終了する必要があることを示している可能性があります。
Each Diameter application (e.g., NASREQ, Mobile IP) SHOULD define its service-specific AVPs that MUST be present in the Accounting-Request message in a section titled "Accounting AVPs". The application MUST assume that the AVPs described in this document will be present in all Accounting messages, so only their respective service-specific AVPs need to be defined in that section.
各Diameterアプリケーション（NASREQ、モバイルIPなど）は、「Accounting AVPs」というタイトルのセクションのAccounting-Requestメッセージに存在する必要があるサービス固有のAVPを定義する必要があります（SHOULD）。アプリケーションは、このドキュメントで説明されているAVPがすべてのアカウンティングメッセージに存在することを前提とする必要があるため、それぞれのサービス固有のAVPのみをそのセクションで定義する必要があります。
Applications have the option of using one or both of the following accounting application extension models:
アプリケーションには、次の会計アプリケーション拡張モデルのいずれかまたは両方を使用するオプションがあります。
Split Accounting Service
分割会計サービス
The accounting message will carry the Application Id of the Diameter base accounting application (see Section 2.4). Accounting messages may be routed to Diameter nodes other than the corresponding Diameter application. These nodes might be centralized accounting servers that provide accounting service for multiple different Diameter applications. These nodes MUST advertise the Diameter base accounting Application Id during capabilities exchange.
アカウンティングメッセージには、DiameterベースアカウンティングアプリケーションのアプリケーションIDが含まれます（セクション2.4を参照）。アカウンティングメッセージは、対応するDiameterアプリケーション以外のDiameterノードにルーティングされる場合があります。これらのノードは、複数の異なるDiameterアプリケーションにアカウンティングサービスを提供する集中アカウンティングサーバーである場合があります。これらのノードは、機能交換中にDiameterベースアカウンティングアプリケーションIDを通知する必要があります。
Coupled Accounting Service
連結会計サービス
The accounting message will carry the Application Id of the application that is using it. The application itself will process the received accounting records or forward them to an accounting server. There is no accounting application advertisement required during capabilities exchange, and the accounting messages will be routed the same way as any of the other application messages.
アカウンティングメッセージには、それを使用しているアプリケーションのアプリケーションIDが含まれます。アプリケーション自体は、受信したアカウンティングレコードを処理するか、アカウンティングサーバーに転送します。機能交換中に必要なアカウンティングアプリケーションアドバタイズメントはなく、アカウンティングメッセージは他のアプリケーションメッセージと同じ方法でルーティングされます。
In cases where an application does not define its own accounting service, it is preferred that the split accounting model be used.
アプリケーションが独自のアカウンティングサービスを定義していない場合は、分割アカウンティングモデルを使用することをお勧めします。
Diameter base protocol mechanisms are used to overcome small message loss and network faults of a temporary nature.
Diameterベースのプロトコルメカニズムは、一時的な性質の小さなメッセージ損失およびネットワーク障害を克服するために使用されます。
Diameter peers acting as clients MUST implement the use of failover to guard against server failures and certain network failures. Diameter peers acting as agents or related off-line processing systems MUST detect duplicate accounting records caused by the sending of the same record to several servers and duplication of messages in transit. This detection MUST be based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. Appendix C discusses duplicate detection needs and implementation issues.
クライアントとして機能するDiameterピアは、フェイルオーバーを使用してサーバーの障害や特定のネットワーク障害から保護する必要があります。エージェントとして機能するDiameterピアまたは関連するオフライン処理システムは、複数のサーバーへの同じレコードの送信と転送中のメッセージの重複によって引き起こされた重複するアカウンティングレコードを検出する必要があります。この検出は、Session-IdおよびAccounting-Record-Number AVPペアの検査に基づく必要があります。付録Cでは、重複検出のニーズと実装の問題について説明します。
Diameter clients MAY have non-volatile memory for the safe storage of accounting records over reboots or extended network failures, network partitions, and server failures. If such memory is available, the client SHOULD store new accounting records there as soon as the records are created and until a positive acknowledgement of their reception from the Diameter server has been received. Upon a reboot, the client MUST start sending the records in the non-volatile memory to the accounting server with the appropriate modifications in termination cause, session length, and other relevant information in the records.
Diameterクライアントには、再起動または拡張ネットワーク障害、ネットワークパーティション、およびサーバー障害が発生しても、アカウンティングレコードを安全に保存するための不揮発性メモリが備わっている場合があります。そのようなメモリが利用可能な場合、クライアントは、レコードが作成され次第、Diameterサーバーからの受信の肯定応答が受信されるまで、新しいアカウンティングレコードをそこに格納する必要があります（SHOULD）。再起動時に、クライアントは、不揮発性メモリ内のレコードを、終了原因、セッションの長さ、およびレコード内のその他の関連情報を適切に変更して、アカウンティングサーバーに送信し始めなければなりません（MUST）。
A further application of this protocol may include AVPs to control the maximum number of accounting records that may be stored in the Diameter client without committing them to the non-volatile memory or transferring them to the Diameter server.
このプロトコルのさらなるアプリケーションには、不揮発性メモリにコミットしたり、Diameterサーバーに転送したりせずに、Diameterクライアントに格納できるアカウンティングレコードの最大数を制御するAVPが含まれる場合があります。
The client SHOULD NOT remove the accounting data from any of its memory areas before the correct Accounting-Answer has been received. The client MAY remove the oldest, undelivered, or as yet unacknowledged accounting data if it runs out of resources such as memory. It is an implementation-dependent matter for the client to accept new sessions under this condition.
クライアントは、正しいAccounting-Answerを受信する前に、そのメモリ領域からアカウンティングデータを削除してはなりません（SHOULD NOT）。クライアントは、メモリなどのリソースが不足した場合、最も古い、配信されていない、またはまだ確認されていないアカウンティングデータを削除する場合があります。この状況でクライアントが新しいセッションを受け入れるのは、実装に依存する問題です。
In all accounting records, the Session-Id AVP MUST be present; the User-Name AVP MUST be present if it is available to the Diameter client.
すべてのアカウンティングレコードには、Session-Id AVPが存在する必要があります。ユーザー名AVPは、Diameterクライアントで使用できる場合に存在する必要があります。
Different types of accounting records are sent depending on the actual type of accounted service and the authorization server's directions for interim accounting. If the accounted service is a one-time event, meaning that the start and stop of the event are simultaneous, then the Accounting-Record-Type AVP MUST be present and set to the value EVENT_RECORD.
アカウンティングされたサービスの実際のタイプと中間アカウンティングに対する許可サーバーの指示に応じて、さまざまなタイプのアカウンティングレコードが送信されます。アカウンティングサービスが1回限りのイベントである場合、つまりイベントの開始と停止が同時に行われる場合、Accounting-Record-Type AVPが存在し、値EVENT_RECORDに設定されている必要があります。
If the accounted service is of a measurable length, then the AVP MUST use the values START_RECORD, STOP_RECORD, and possibly, INTERIM_RECORD. If the authorization server has not directed interim accounting to be enabled for the session, two accounting records MUST be generated for each service of type session. When the initial Accounting-Request for a given session is sent, the Accounting-Record-Type AVP MUST be set to the value START_RECORD. When the last Accounting-Request is sent, the value MUST be STOP_RECORD.
アカウンティングサービスが測定可能な長さの場合、AVPは値START_RECORD、STOP_RECORD、および場合によってはINTERIM_RECORDを使用する必要があります。承認サーバーがセッションで有効になっている中間アカウンティングを指示していない場合は、セッションタイプのサービスごとに2つのアカウンティングレコードを生成する必要があります。特定のセッションの最初のAccounting-Requestが送信されるとき、Accounting-Record-Type AVPは値START_RECORDに設定する必要があります。最後のAccounting-Requestが送信されるとき、値はSTOP_RECORDでなければなりません。
If the authorization server has directed interim accounting to be enabled, the Diameter client MUST produce additional records between the START_RECORD and STOP_RECORD, marked INTERIM_RECORD. The production of these records is directed by Acct-Interim-Interval as well as any re-authentication or re-authorization of the session. The Diameter client MUST overwrite any previous interim accounting records that are locally stored for delivery, if a new record is being generated for the same session. This ensures that only one pending interim record can exist on an access device for any given session.
承認サーバーが中間アカウンティングを有効にするように指示している場合、Diameterクライアントは、START_RECORDとSTOP_RECORDの間に、INTERIM_RECORDとマークされた追加のレコードを作成する必要があります。これらのレコードの生成は、Acct-Interim-Intervalおよびセッションの再認証または再承認によって指示されます。同じレコードの新しいレコードが生成されている場合、Diameterクライアントは、配信のためにローカルに保存されている以前の中間アカウンティングレコードを上書きする必要があります。これにより、特定のセッションのアクセスデバイス上に保留中の中間レコードが1つだけ存在できるようになります。
A particular value of Accounting-Sub-Session-Id MUST appear only in one sequence of accounting records from a Diameter client, except for the purposes of retransmission. The one sequence that is sent MUST be either one record with Accounting-Record-Type AVP set to the value EVENT_RECORD or several records starting with one having the value START_RECORD, followed by zero or more INTERIM_RECORDs and a single STOP_RECORD. A particular Diameter application specification MUST define the type of sequences that MUST be used.
Accounting-Sub-Session-Idの特定の値は、再送信の目的を除いて、Diameterクライアントからのアカウンティングレコードの1つのシーケンスにのみ出現する必要があります。送信される1つのシーケンスは、Accounting-Record-Type AVPが値EVENT_RECORDに設定された1つのレコードか、値がSTART_RECORDで始まり、その後に0個以上のINTERIM_RECORDと単一のSTOP_RECORDが続くレコードである必要があります。特定のDiameterアプリケーション仕様では、使用する必要があるシーケンスのタイプを定義する必要があります。
If an application uses accounting messages, it can correlate accounting records with a specific application session by using the Session-Id of the particular application session in the accounting messages. Accounting messages MAY also use a different Session-Id from that of the application sessions, in which case, other session-related information is needed to perform correlation.
アプリケーションがアカウンティングメッセージを使用する場合、アカウンティングメッセージで特定のアプリケーションセッションのSession-Idを使用することにより、アカウンティングレコードを特定のアプリケーションセッションと関連付けることができます。また、アカウンティングメッセージは、アプリケーションセッションのセッションIDとは異なるセッションIDを使用する場合があります。その場合、相関を実行するには他のセッション関連情報が必要です。
In cases where an application requires multiple accounting sub-sessions, an Accounting-Sub-Session-Id AVP is used to differentiate each sub-session. The Session-Id would remain constant for all sub-sessions and is used to correlate all the sub-sessions to a particular application session. Note that receiving a STOP_RECORD with no Accounting-Sub-Session-Id AVP when sub-sessions were originally used in the START_RECORD messages implies that all sub-sessions are terminated.
アプリケーションで複数のアカウンティングサブセッションが必要な場合は、Accounting-Sub-Session-Id AVPを使用して各サブセッションを区別します。 Session-Idはすべてのサブセッションで一定であり、すべてのサブセッションを特定のアプリケーションセッションに関連付けるために使用されます。 START_RECORDメッセージでサブセッションが最初に使用されたときに、Accounting-Sub-Session-Id AVPなしでSTOP_RECORDを受信すると、すべてのサブセッションが終了したことになります。
There are also cases where an application needs to correlate multiple application sessions into a single accounting record; the accounting record may span multiple different Diameter applications and sessions used by the same user at a given time. In such cases, the Acct-Multi-Session-Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD be signaled by the server to the access device (typically, during authorization) when it determines that a request belongs to an existing session. The access device MUST then include the Acct-Multi-Session-Id AVP in all subsequent accounting messages.
アプリケーションが複数のアプリケーションセッションを単一のアカウンティングレコードに関連付ける必要がある場合もあります。アカウンティングレコードは、特定の時間に同じユーザーが使用する複数の異なるDiameterアプリケーションおよびセッションにまたがることがあります。このような場合、Acct-Multi-Session-Id AVPが使用されます。 Acct-Multi-Session-Id AVPは、リクエストが既存のセッションに属していると判断したときに、サーバーからアクセスデバイスに（通常は認証中に）通知する必要があります（SHOULD）。次に、アクセスデバイスは、後続のすべてのアカウンティングメッセージにAcct-Multi-Session-Id AVPを含める必要があります。
The Acct-Multi-Session-Id AVP MAY include the value of the original Session-Id. Its contents are implementation specific, but the MUST be globally unique across other Acct-Multi-Session-Ids and MUST NOT change during the life of a session.
Acct-Multi-Session-Id AVPには、元のSession-Idの値が含まれる場合があります。その内容は実装固有ですが、MUSTは他のAcct-Multi-Session-Id全体でグローバルに一意である必要があり、セッションの存続期間中に変更してはなりません。
A Diameter application document MUST define the exact concept of a session that is being accounted, and it MAY define the concept of a multi-session. For instance, the NASREQ DIAMETER application treats a single PPP connection to a Network Access Server as one session and a set of Multilink PPP sessions as one multi-session.
Diameterアプリケーションドキュメントは、説明されるセッションの正確な概念を定義する必要があり、マルチセッションの概念を定義する場合があります。たとえば、NASREQ DIAMETERアプリケーションは、ネットワークアクセスサーバーへの単一のPPP接続を1つのセッションとして扱い、マルチリンクPPPセッションのセットを1つのマルチセッションとして扱います。
This section defines Command Code values that MUST be supported by all Diameter implementations that provide accounting services.
このセクションでは、アカウンティングサービスを提供するすべてのDiameter実装でサポートする必要があるコマンドコード値を定義します。
The Accounting-Request (ACR) command, indicated by the Command Code field set to 271 and the Command Flags' 'R' bit set, is sent by a Diameter node, acting as a client, in order to exchange accounting information with a peer.
271に設定されたコマンドコードフィールドとコマンドフラグの「R」ビットセットで示されるアカウンティング要求（ACR）コマンドは、ピアとアカウンティング情報を交換するために、クライアントとして機能するDiameterノードによって送信されます。 。
In addition to the AVPs listed below, Accounting-Request messages SHOULD include service-specific accounting AVPs.
下記のAVPに加えて、アカウンティング要求メッセージには、サービス固有のアカウンティングAVPを含める必要があります（SHOULD）。
Message Format
メッセージフォーマット
<ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Destination-Host ]
[ Accounting-Sub-Session-Id ]
[ Acct-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Acct-Interim-Interval ]
[ Accounting-Realtime-Required ]
[ Origin-State-Id ]
[ Event-Timestamp ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Accounting-Answer (ACA) command, indicated by the Command Code field set to 271 and the Command Flags' 'R' bit cleared, is used to acknowledge an Accounting-Request command. The Accounting-Answer command contains the same Session-Id as the corresponding request.
コマンドコードフィールドが271に設定され、コマンドフラグの「R」ビットがクリアされていることで示されるアカウンティング応答（ACA）コマンドは、アカウンティング要求コマンドを確認するために使用されます。 Accounting-Answerコマンドには、対応する要求と同じSession-Idが含まれています。
Only the target Diameter server, known as the home Diameter server, SHOULD respond with the Accounting-Answer command.
ホームDiameterサーバーと呼ばれるターゲットDiameterサーバーのみが、Accounting-Answerコマンドで応答する必要があります。
In addition to the AVPs listed below, Accounting-Answer messages SHOULD include service-specific accounting AVPs.
下記のAVPに加えて、Accounting-Answerメッセージには、サービス固有のアカウンティングAVPを含める必要があります（SHOULD）。
Message Format
メッセージフォーマット
<ACA> ::= < Diameter Header: 271, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Accounting-Sub-Session-Id ]
[ Acct-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Acct-Interim-Interval ]
[ Accounting-Realtime-Required ]
[ Origin-State-Id ]
[ Event-Timestamp ]
* [ Proxy-Info ]
* [ AVP ]
This section contains AVPs that describe accounting usage information related to a specific session.
このセクションには、特定のセッションに関連するアカウンティング使用状況情報を説明するAVPが含まれています。
The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated and contains the type of accounting record being sent. The following values are currently defined for the Accounting-Record-Type AVP:
Accounting-Record-Type AVP（AVPコード480）はEnumeratedタイプで、送信されるアカウンティングレコードのタイプが含まれています。現在、次の値がAccounting-Record-Type AVPに定義されています。
EVENT_RECORD 1
EVENT_RECORD 1
An Accounting Event Record is used to indicate that a one-time event has occurred (meaning that the start and end of the event are simultaneous). This record contains all information relevant to the service, and it is the only record of the service.
アカウンティングイベントレコードは、1回限りのイベントが発生したことを示すために使用されます（イベントの開始と終了が同時に行われることを意味します）。このレコードには、サービスに関連するすべての情報が含まれており、サービスの唯一のレコードです。
START_RECORD 2
START_RECORD 2
Accounting Start, Interim, and Stop Records are used to indicate that a service of a measurable length has been given. An Accounting Start Record is used to initiate an accounting session and contains accounting information that is relevant to the initiation of the session.
アカウンティングの開始、中間、および停止レコードは、測定可能な長さのサービスが提供されたことを示すために使用されます。アカウンティング開始レコードは、アカウンティングセッションを開始するために使用され、セッションの開始に関連するアカウンティング情報を含みます。
INTERIM_RECORD 3
INTERIM_RECORD 3
An Interim Accounting Record contains cumulative accounting information for an existing accounting session. Interim Accounting Records SHOULD be sent every time a re-authentication or re-authorization occurs. Further, additional interim record triggers MAY be defined by application-specific Diameter applications. The selection of whether to use INTERIM_RECORD records is done by the Acct-Interim-Interval AVP.
中間アカウンティングレコードには、既存のアカウンティングセッションの累積アカウンティング情報が含まれます。中間認証レコードは、再認証または再認証が発生するたびに送信する必要があります。さらに、追加の中間レコードトリガーは、アプリケーション固有のDiameterアプリケーションによって定義される場合があります。 INTERIM_RECORDレコードを使用するかどうかの選択は、Acct-Interim-Interval AVPによって行われます。
STOP_RECORD 4
STOP_RECORD 4
An Accounting Stop Record is sent to terminate an accounting session and contains cumulative accounting information relevant to the existing session.
アカウンティング停止レコードは、アカウンティングセッションを終了するために送信され、既存のセッションに関連する累積アカウンティング情報を含みます。
The Acct-Interim-Interval AVP (AVP Code 85) is of type Unsigned32 and is sent from the Diameter home authorization server to the Diameter client. The client uses information in this AVP to decide how and when to produce accounting records. With different values in this AVP, service sessions can result in one, two, or two+N accounting records, based on the needs of the home organization. The following accounting record production behavior is directed by the inclusion of this AVP:
Acct-Interim-Interval AVP（AVPコード85）のタイプはUnsigned32であり、Diameterホーム認証サーバーからDiameterクライアントに送信されます。クライアントは、このAVPの情報を使用して、アカウンティングレコードを作成する方法とタイミングを決定します。このAVPの値が異なる場合、サービスセッションは、ホーム組織のニーズに基づいて、1つ、2つ、または2 + Nのアカウンティングレコードになる可能性があります。次のアカウンティングレコード生成動作は、このAVPを含めることによって指示されます。
1. The omission of the Acct-Interim-Interval AVP or its inclusion with Value field set to 0 means that EVENT_RECORD, START_RECORD, and STOP_RECORD are produced, as appropriate for the service.
1. Acct-Interim-Interval AVPが省略されているか、Valueフィールドが0に設定されている場合、サービスに応じて、EVENT_RECORD、START_RECORD、およびSTOP_RECORDが生成されます。
2. The inclusion of the AVP with Value field set to a non-zero value means that INTERIM_RECORD records MUST be produced between the START_RECORD and STOP_RECORD records. The Value field of this AVP is the nominal interval between these records in seconds. The Diameter node that originates the accounting information, known as the client, MUST produce the first INTERIM_RECORD record roughly at the time when this nominal interval has elapsed from the START_RECORD, the next one again as the interval has elapsed once more, and so on until the session ends and a STOP_RECORD record is produced.
2.値フィールドがゼロ以外の値に設定されたAVPを含めることは、START_RECORDレコードとSTOP_RECORDレコードの間にINTERIM_RECORDレコードを作成する必要があることを意味します。このAVPの値フィールドは、これらのレコード間の公称間隔（秒単位）です。クライアントと呼ばれるアカウンティング情報を発信するDiameterノードは、おおよそこの公称間隔がSTART_RECORDから経過したときにおおよそ最初のINTERIM_RECORDレコードを生成し、間隔がもう一度経過すると次のレコードを生成する必要があります。セッションが終了し、STOP_RECORDレコードが生成されます。
The client MUST ensure that the interim record production times are randomized so that large accounting message storms are not created either among records or around a common service start time.
クライアントは、レコード間または共通のサービス開始時間の前後で大きなアカウンティングメッセージストームが作成されないように、中間レコード生成時間がランダム化されるようにする必要があります。
The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 and identifies this record within one session. As Session-Id AVPs are globally unique, the combination of Session-Id and Accounting-Record-Number AVPs is also globally unique and can be used in matching accounting records with confirmations. An easy way to produce unique numbers is to set the value to 0 for records of type EVENT_RECORD and START_RECORD and set the value to 1 for the first INTERIM_RECORD, 2 for the second, and so on until the value for STOP_RECORD is one more than for the last INTERIM_RECORD.
Accounting-Record-Number AVP（AVPコード485）はタイプUnsigned32であり、1つのセッション内でこのレコードを識別します。 Session-Id AVPはグローバルに一意であるため、Session-IdとAccounting-Record-Number AVPの組み合わせもグローバルに一意であり、アカウンティングレコードと確認の照合に使用できます。一意の数値を生成する簡単な方法は、EVENT_RECORDおよびSTART_RECORDタイプのレコードの値を0に設定し、最初のINTERIM_RECORDの値を1、2番目の値を2に設定し、STOP_RECORDの値が1になるまで続けます。最後のINTERIM_RECORD。
The Acct-Session-Id AVP (AVP Code 44) is of type OctetString is only used when RADIUS/Diameter translation occurs. This AVP contains the contents of the RADIUS Acct-Session-Id attribute.
Acct-Session-Id AVP（AVPコード44）のタイプはOctetStringで、RADIUS /直径変換が行われる場合にのみ使用されます。このAVPには、RADIUS Acct-Session-Id属性の内容が含まれています。
The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String, following the format specified in Section 8.8. The Acct-Multi-Session-Id AVP is used to link multiple related accounting sessions, where each session would have a unique Session-Id but the same Acct-Multi-Session-Id AVP. This AVP MAY be returned by the Diameter server in an authorization answer, and it MUST be used in all accounting messages for the given session.
Acct-Multi-Session-Id AVP（AVPコード50）は、セクション8.8で指定されている形式に従って、UTF8Stringタイプです。 Acct-Multi-Session-Id AVPは、複数の関連するアカウンティングセッションをリンクするために使用されます。各セッションには、一意のSession-Idがありますが、同じAcct-Multi-Session-Id AVPがあります。このAVPは、Diameterサーバーによって認証応答で返される場合があり、特定のセッションのすべてのアカウンティングメッセージで使用する必要があります。
The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type Unsigned64 and contains the accounting sub-session identifier. The combination of the Session-Id and this AVP MUST be unique per sub-session, and the value of this AVP MUST be monotonically increased by one for all new sub-sessions. The absence of this AVP implies no sub-sessions are in use, with the exception of an Accounting-Request whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD message with no Accounting-Sub-Session-Id AVP present will signal the termination of all sub-sessions for a given Session-Id.
Accounting-Sub-Session-Id AVP（AVPコード287）のタイプはUnsigned64で、アカウンティングサブセッション識別子が含まれています。 Session-IdとこのAVPの組み合わせはサブセッションごとに一意である必要があり、このAVPの値はすべての新しいサブセッションで1ずつ単調に増加する必要があります。このAVPがないことは、Accounting-Record-TypeがSTOP_RECORDに設定されているAccounting-Requestを除いて、サブセッションが使用されていないことを意味します。 Accounting-Sub-Session-Id AVPが存在しないSTOP_RECORDメッセージは、特定のSession-Idのすべてのサブセッションの終了を通知します。
The Accounting-Realtime-Required AVP (AVP Code 483) is of type Enumerated and is sent from the Diameter home authorization server to the Diameter client or in the Accounting-Answer from the accounting server. The client uses information in this AVP to decide what to do if the sending of accounting records to the accounting server has been temporarily prevented due to, for instance, a network problem.
Accounting-Realtime-Required AVP（AVPコード483）は列挙型であり、Diameterホーム認証サーバーからDiameterクライアントに送信されるか、またはアカウンティングサーバーからAccounting-Answerに送信されます。クライアントはこのAVPの情報を使用して、たとえばネットワークの問題が原因で、アカウンティングサーバーへのアカウンティングレコードの送信が一時的に阻止された場合の対処法を決定します。
DELIVER_AND_GRANT 1
DELIVER_AND_GRANT 1
The AVP with Value field set to DELIVER_AND_GRANT means that the service MUST only be granted as long as there is a connection to an accounting server. Note that the set of alternative accounting servers are treated as one server in this sense. Having to move the accounting record stream to a backup server is not a reason to discontinue the service to the user.
値フィールドがDELIVER_AND_GRANTに設定されたAVPは、アカウンティングサーバーへの接続がある限り、サービスが許可されなければならないことを意味します。この意味では、代替の会計サーバーのセットは1つのサーバーとして扱われることに注意してください。アカウンティングレコードストリームをバックアップサーバーに移動しなければならないのは、ユーザーへのサービスを中止する理由にはなりません。
GRANT_AND_STORE 2
GRANT_AND_STORE 2
The AVP with Value field set to GRANT_AND_STORE means that service SHOULD be granted if there is a connection, or as long as records can still be stored as described in Section 9.4.
値フィールドがGRANT_AND_STOREに設定されたAVPは、接続が存在する場合、またはセクション9.4で説明されているようにレコードを引き続き保存できる限り、サービスを許可する必要があることを意味します。
This is the default behavior if the AVP isn't included in the reply from the authorization server.
これは、承認サーバーからの応答にAVPが含まれていない場合のデフォルトの動作です。
GRANT_AND_LOSE 3
GRANT_AND_LOSE 3
The AVP with Value field set to GRANT_AND_LOSE means that service SHOULD be granted even if the records cannot be delivered or stored.
値フィールドがGRANT_AND_LOSEに設定されたAVPは、レコードを配信または保存できない場合でも、サービスを許可する必要があることを意味します。
The following tables present the AVPs defined in this document and specify in which Diameter messages they MAY or MAY NOT be present. AVPs that occur only inside a Grouped AVP are not shown in these tables.
次の表は、このドキュメントで定義されているAVPを示し、それらが存在する場合と存在しない場合のあるDiameterメッセージを示しています。グループ化されたAVP内でのみ発生するAVPは、これらの表には示されていません。
The tables use the following symbols:
表では次の記号を使用しています。
0 The AVP MUST NOT be present in the message.
0 AVPはメッセージに存在してはなりません。
0+ Zero or more instances of the AVP MAY be present in the message.
0+ AVPのゼロ個以上のインスタンスがメッセージに存在する場合があります。
0-1 Zero or one instance of the AVP MAY be present in the message. It is considered an error if there are more than one instance of the AVP.
0-1 AVPのゼロまたは1つのインスタンスがメッセージに存在する場合があります。 AVPのインスタンスが複数ある場合は、エラーと見なされます。
1 One instance of the AVP MUST be present in the message.
1 AVPの1つのインスタンスがメッセージに存在する必要があります。
1+ At least one instance of the AVP MUST be present in the message.
1+ AVPの少なくとも1つのインスタンスがメッセージに存在する必要があります。
The table in this section is limited to the non-Accounting Command Codes defined in this specification.
このセクションの表は、この仕様で定義されている非アカウンティングコマンドコードに限定されています。
+-----------------------------------------------+
| Command Code |
+---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------+---+---+---+---+---+---+---+---+---+---+---+---+
Acct-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
Interval | | | | | | | | | | | | |
Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
Required | | | | | | | | | | | | |
Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Lifetime | | | | | | | | | | | | |
Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ |
Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 |
Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
Failed-AVP |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Inband-Security-Id |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
Origin-State-Id |0-1|0-1|0 |0 |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ |
Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |
Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
Redirect-Max-Cache- |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
Time | | | | | | | | | | | | |
Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |
Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |
Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |0 |
Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 |
Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Failover | | | | | | | | | | | | |
Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Supported-Vendor-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 |
User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|0-1|0-1|0-1|0-1|
Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Application-Id | | | | | | | | | | | | |
--------------------+---+---+---+---+---+---+---+---+---+---+---+---+
The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages. These AVP occurrence requirements are guidelines, which may be expanded, and/or overridden by application-specific requirements in the Diameter applications documents.
このセクションの表は、このドキュメントで定義されているどのAVPがアカウンティングメッセージに存在するかを表すために使用されます。これらのAVPオカレンス要件はガイドラインであり、Diameterアプリケーションドキュメントのアプリケーション固有の要件によって拡張またはオーバーライドされる場合があります。
+-----------+
| Command |
| Code |
+-----+-----+
Attribute Name | ACR | ACA |
------------------------------+-----+-----+
Acct-Interim-Interval | 0-1 | 0-1 |
Acct-Multi-Session-Id | 0-1 | 0-1 |
Accounting-Record-Number | 1 | 1 |
Accounting-Record-Type | 1 | 1 |
Acct-Session-Id | 0-1 | 0-1 |
Accounting-Sub-Session-Id | 0-1 | 0-1 |
Accounting-Realtime-Required | 0-1 | 0-1 |
Acct-Application-Id | 0-1 | 0-1 |
Auth-Application-Id | 0 | 0 |
Class | 0+ | 0+ |
Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 |
Error-Reporting-Host | 0 | 0+ |
Event-Timestamp | 0-1 | 0-1 |
Failed-AVP | 0 | 0-1 |
Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 |
Proxy-Info | 0+ | 0+ |
Route-Record | 0+ | 0 |
Result-Code | 0 | 1 |
Session-Id | 1 | 1 |
Termination-Cause | 0 | 0 |
User-Name | 0-1 | 0-1 |
Vendor-Specific-Application-Id| 0-1 | 0-1 |
------------------------------+-----+-----+
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the Diameter protocol, in accordance with [RFC5226]. Existing IANA registries and assignments put in place by RFC 3588 remain the same unless explicitly updated or deprecated in this section.
このセクションは、[RFC5226]に従って、Diameterプロトコルに関連する値の登録に関するInternet Assigned Numbers Authority（IANA）へのガイダンスを提供します。このセクションで明示的に更新または廃止されない限り、RFC 3588によって設定された既存のIANAレジストリと割り当ては同じままです。
As defined in Section 4, the AVP header contains three fields that require IANA namespace management: the AVP Code, Vendor-ID, and Flags fields.
セクション4で定義されているように、AVPヘッダーには、IANA名前空間の管理が必要な3つのフィールド（AVPコード、ベンダーID、およびフラグフィールド）が含まれています。
There are multiple namespaces. Vendors can have their own AVP Codes namespace that will be identified by their Vendor-ID (also known as Enterprise-Number), and they control the assignments of their vendor-specific AVP Codes within their own namespace. The absence of a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF AVP Codes namespace, which is under IANA control. The AVP Codes and sometimes possible values in an AVP are controlled and maintained by IANA. AVP Code 0 is not used. AVP Codes 1-255 are managed separately as RADIUS Attribute Types. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs should be encouraged instead.
複数の名前空間があります。ベンダーは、ベンダーID（別名エンタープライズ番号）によって識別される独自のAVPコード名前空間を持つことができ、独自の名前空間内のベンダー固有のAVPコードの割り当てを制御します。 Vendor-IDまたはゼロ（0）のVendor-ID値がないことは、IANAの制御下にあるIETF AVPコード名前空間を識別します。 AVPコードおよびAVPで可能な値は、IANAによって制御および維持されます。 AVPコード0は使用されません。 AVPコード1〜255は、RADIUS属性タイプとして個別に管理されます。ベンダー固有のAVPが複数のベンダーによって実装されている場合は、代わりにグローバルAVPの割り当てを推奨する必要があります。
AVPs may be allocated following Expert Review (by a Designated Expert) with Specification Required [RFC5226]. A block allocation (release of more than three AVPs at a time for a given purpose) requires IETF Review [RFC5226].
AVPは、指定された専門家による（指定された専門家による）エキスパートレビューに続いて割り当てられます[RFC5226]。ブロック割り当て（特定の目的で一度に4つ以上のAVPをリリースする）には、IETFレビュー[RFC5226]が必要です。
Section 4.1 describes the existing AVP Flags. The remaining bits can only be assigned via a Standards Action [RFC5226].
セクション4.1では、既存のAVPフラグについて説明します。残りのビットは、標準アクション[RFC5226]を介してのみ割り当てることができます。
For the Diameter header, the Command Code namespace allocation has changed. The new allocation rules are as follows:
Diameterヘッダーの場合、コマンドコードの名前空間の割り当てが変更されました。新しい割り当てルールは次のとおりです。
The Command Code values 256 - 8,388,607 (0x100 to 0x7fffff) are for permanent, standard commands, allocated by IETF Review [RFC5226].
コマンドコード値256〜8,388,607（0x100〜0x7fffff）は、IETFレビュー[RFC5226]によって割り当てられた永続的な標準コマンド用です。
The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved for vendor-specific Command Codes, to be allocated on a First Come, First Served basis by IANA [RFC5226]. The request to IANA for a Vendor-Specific Command Code SHOULD include a reference to a publicly available specification that documents the command in sufficient detail to aid in interoperability between independent implementations. If the specification cannot be made publicly available, the request for a vendor-specific Command Code MUST include the contact information of persons and/or entities responsible for authoring and maintaining the command.
値8,388,608-16,777,213（0x800000-0xfffffd）は、ベンダー固有のコマンドコード用に予約されており、IANA [RFC5226]によって先着順で割り当てられます。ベンダー固有のコマンドコードのIANAへのリクエストには、独立した実装間の相互運用性を支援するために十分詳細にコマンドを文書化した公開仕様への参照を含める必要があります。仕様を公開できない場合は、ベンダー固有のコマンドコードのリクエストに、コマンドの作成と保守を担当する人物やエンティティの連絡先情報を含める必要があります。
The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 0xffffff) are reserved for experimental commands. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between Diameter peers using experimental commands.
値16,777,214および16,777,215（16進値0xfffffe-0xffffff）は、実験的なコマンド用に予約されています。これらのコードは実験とテストのみを目的としているため、実験的なコマンドを使用したDiameterピア間の相互運用性は保証されません。
Section 3 describes the existing Command Flags field. The remaining bits can only be assigned via a Standards Action [RFC5226].
セクション3では、既存のコマンドフラグフィールドについて説明します。残りのビットは、標準アクション[RFC5226]を介してのみ割り当てることができます。
For AVP values, the Experimental-Result-Code AVP value allocation has been added; see Section 11.3.1. The old AVP value allocation rule, IETF Consensus, has been updated to IETF Review as per [RFC5226], and affected AVPs are listed as reminders.
AVP値の場合、Experimental-Result-Code AVP値の割り当てが追加されました。セクション11.3.1を参照してください。古いAVP値割り当てルールであるIETFコンセンサスは、[RFC5226]に従ってIETFレビューに更新され、影響を受けるAVPがリマインダーとしてリストされています。
Values for this AVP are purely local to the indicated vendor, and no IANA registry is maintained for them.
このAVPの値は、示されたベンダーに対して純粋にローカルであり、それらのIANAレジストリは維持されません。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
The use of this AVP has been deprecated.
このAVPの使用は廃止されました。
IANA has registered the "_diameters" service name and assigned port numbers for TLS/TCP and DTLS/SCTP according to the guidelines given in [RFC6335].
IANAは[_diameters]サービス名を登録し、[RFC6335]に記載されているガイドラインに従ってTLS / TCPおよびDTLS / SCTPのポート番号を割り当てました。
Service Name: _diameters
サービス名：_diameters
Transport Protocols: TCP, SCTP
トランスポートプロトコル：TCP、SCTP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Diameter over TLS/TCP and DTLS/SCTP
Reference: RFC 6733
リファレンス：RFC 6733
Port Number: 5868, from the User Range
ポート番号：5868、ユーザー範囲から
Two SCTP payload protocol identifiers have been registered in the SCTP Payload Protocol Identifiers registry:
2つのSCTPペイロードプロトコル識別子がSCTP Payload Protocol Identifiersレジストリに登録されています。
Value | SCTP Payload Protocol Identifier
-------|-----------------------------------
46 | Diameter in a SCTP DATA chunk
47 | Diameter in a DTLS/SCTP DATA chunk
The following tag has been registered in the S-NAPTR Application Protocol Tags registry:
次のタグがS-NAPTR Application Protocol Tagsレジストリに登録されています。
Tag | Protocol
-------------------|---------
diameter.dtls.sctp | DTLS/SCTP
This section contains the configurable parameters that are found throughout this document:
このセクションには、このドキュメント全体で見つかる構成可能なパラメーターが含まれています。
Diameter Peer
直径ピア
A Diameter entity MAY communicate with peers that are statically configured. A statically configured Diameter peer would require that either the IP address or the fully qualified domain name (FQDN) be supplied, which would then be used to resolve through DNS.
Diameterエンティティは、静的に構成されたピアと通信できます（MAY）。静的に構成されたDiameterピアでは、IPアドレスまたは完全修飾ドメイン名（FQDN）のいずれかを指定する必要があり、これを使用してDNS経由で解決します。
Routing Table
ルーティングテーブル
A Diameter proxy server routes messages based on the realm portion of a Network Access Identifier (NAI). The server MUST have a table of Realm Names, and the address of the peer to which the message must be forwarded. The routing table MAY also include a "default route", which is typically used for all messages that cannot be locally processed.
Diameterプロキシサーバーは、ネットワークアクセス識別子（NAI）のレルム部分に基づいてメッセージをルーティングします。サーバーには、レルム名のテーブルと、メッセージの転送先となるピアのアドレスが必要です。ルーティングテーブルには、「デフォルトルート」も含まれる場合があります。これは通常、ローカルで処理できないすべてのメッセージに使用されます。
Tc timer
Tcタイマー
The Tc timer controls the frequency that transport connection attempts are done to a peer with whom no active transport connection exists. The recommended value is 30 seconds.
Tcタイマーは、アクティブなトランスポート接続が存在しないピアに対してトランスポート接続の試行が行われる頻度を制御します。推奨値は30秒です。
The Diameter base protocol messages SHOULD be secured by using TLS [RFC5246] or DTLS/SCTP [RFC6083]. Additional security mechanisms such as IPsec [RFC4301] MAY also be deployed to secure connections between peers. However, all Diameter base protocol implementations MUST support the use of TLS/TCP and DTLS/SCTP, and the Diameter protocol MUST NOT be used without one of TLS, DTLS, or IPsec.
Diameter基本プロトコルメッセージは、TLS [RFC5246]またはDTLS / SCTP [RFC6083]を使用して保護する必要があります。ピア間の接続を保護するために、IPsec [RFC4301]などの追加のセキュリティメカニズムも展開できます。ただし、すべてのDiameter基本プロトコル実装はTLS / TCPおよびDTLS / SCTPの使用をサポートする必要があり、DiameterプロトコルはTLS、DTLS、またはIPsecのいずれかなしで使用してはなりません（MUST NOT）。
If a Diameter connection is to be protected via TLS/TCP and DTLS/SCTP or IPsec, then TLS/TCP and DTLS/SCTP or IPsec/IKE SHOULD begin prior to any Diameter message exchange. All security parameters for TLS/ TCP and DTLS/SCTP or IPsec are configured independent of the Diameter protocol. All Diameter messages will be sent through the TLS/TCP and DTLS/SCTP or IPsec connection after a successful setup.
Diameter接続をTLS / TCPおよびDTLS / SCTPまたはIPsecで保護する場合、Diameterメッセージ交換の前にTLS / TCPおよびDTLS / SCTPまたはIPsec / IKEを開始する必要があります（SHOULD）。 TLS / TCPおよびDTLS / SCTPまたはIPsecのすべてのセキュリティパラメータは、Diameterプロトコルとは無関係に設定されます。すべてのDiameterメッセージは、セットアップが成功した後、TLS / TCPおよびDTLS / SCTPまたはIPsec接続を介して送信されます。
For TLS/TCP and DTLS/SCTP connections to be established in the open state, the CER/CEA exchange MUST include an Inband-Security-ID AVP with a value of TLS/TCP and DTLS/SCTP. The TLS/TCP and DTLS/SCTP handshake will begin when both ends successfully reach the open state, after completion of the CER/CEA exchange. If the TLS/TCP and DTLS/SCTP handshake is successful, all further messages will be sent via TLS/TCP and DTLS/SCTP. If the handshake fails, both ends MUST move to the closed state. See Section 13.1 for more details.
TLS / TCPおよびDTLS / SCTP接続をオープン状態で確立するには、CER / CEA交換に、TLS / TCPおよびDTLS / SCTPの値を持つInband-Security-ID AVPを含める必要があります。 TLS / TCPおよびDTLS / SCTPハンドシェイクは、CER / CEA交換の完了後、両端がオープン状態に正常に到達したときに開始されます。 TLS / TCPおよびDTLS / SCTPハンドシェイクが成功した場合、以降のすべてのメッセージはTLS / TCPおよびDTLS / SCTPを介して送信されます。ハンドシェイクが失敗した場合、両端は閉じた状態に移行する必要があります。詳細については、セクション13.1を参照してください。
Diameter nodes using TLS/TCP and DTLS/SCTP for security MUST mutually authenticate as part of TLS/TCP and DTLS/SCTP session establishment. In order to ensure mutual authentication, the Diameter node acting as the TLS/TCP and DTLS/SCTP server MUST request a certificate from the Diameter node acting as TLS/TCP and DTLS/SCTP client, and the Diameter node acting as the TLS/TCP and DTLS/SCTP client MUST be prepared to supply a certificate on request.
セキュリティのためにTLS / TCPおよびDTLS / SCTPを使用するDiameterノードは、TLS / TCPおよびDTLS / SCTPセッション確立の一部として相互認証する必要があります。相互認証を確実にするために、TLS / TCPおよびDTLS / SCTPサーバーとして機能するDiameterノードは、TLS / TCPおよびDTLS / SCTPクライアントとして機能するDiameterノード、およびTLS / TCPとして機能するDiameterノードに証明書を要求する必要があります。また、DTLS / SCTPクライアントは、要求に応じて証明書を提供する準備ができていなければなりません。
Diameter nodes MUST be able to negotiate the following TLS/TCP and DTLS/SCTP cipher suites:
Diameterノードは、次のTLS / TCPおよびDTLS / SCTP暗号スイートをネゴシエートできる必要があります。
TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
Diameter nodes SHOULD be able to negotiate the following TLS/TCP and DTLS/SCTP cipher suite:
Diameterノードは、次のTLS / TCPおよびDTLS / SCTP暗号スイートをネゴシエートできる必要があります（SHOULD）。
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
Note that it is quite possible that support for the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite will be REQUIRED at some future date. Diameter nodes MAY negotiate other TLS/TCP and DTLS/ SCTP cipher suites.
TLS_RSA_WITH_AES_128_CBC_SHA暗号スイートのサポートは、将来的に必要になる可能性があることに注意してください。 Diameterノードは、他のTLS / TCPおよびDTLS / SCTP暗号スイートをネゴシエートしてもよい（MAY）。
If public key certificates are used for Diameter security (for example, with TLS), the value of the expiration times in the routing and peer tables MUST NOT be greater than the expiry time in the relevant certificates.
公開鍵証明書がDiameterのセキュリティ（TLSなど）に使用される場合、ルーティングテーブルとピアテーブルの有効期限の値は、関連する証明書の有効期限を超えてはなりません（MUST NOT）。
As with any peer-to-peer protocol, proper configuration of the trust model within a Diameter peer is essential to security. When certificates are used, it is necessary to configure the root certificate authorities trusted by the Diameter peer. These root CAs are likely to be unique to Diameter usage and distinct from the root CAs that might be trusted for other purposes such as Web browsing. In general, it is expected that those root CAs will be configured so as to reflect the business relationships between the organization hosting the Diameter peer and other organizations. As a result, a Diameter peer will typically not be configured to allow connectivity with any arbitrary peer. With certificate authentication, Diameter peers may not be known beforehand and therefore peer discovery may be required.
他のピアツーピアプロトコルと同様に、Diameterピア内の信頼モデルを適切に構成することは、セキュリティにとって不可欠です。証明書を使用する場合は、Diameterピアが信頼するルート認証局を設定する必要があります。これらのルートCAは、Diameterの使用に固有である可能性が高く、Webブラウジングなどの他の目的で信頼されている可能性があるルートCAとは異なります。一般に、これらのルートCAは、Diameterピアをホストしている組織と他の組織との間のビジネス関係を反映するように構成されます。その結果、Diameterピアは通常、任意のピアとの接続を許可するように構成されません。証明書認証では、Diameterピアが事前に認識されていない場合があるため、ピアの検出が必要になる場合があります。
Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The following AVPs defined in this document are considered to be security-sensitive:
Diameter AVPには、セキュリティ上重要なデータが含まれていることがよくあります。たとえば、ユーザーのパスワードと場所のデータ、ネットワークアドレス、暗号化キーなどです。このドキュメントで定義されている次のAVPは、セキュリティ上重要であると見なされています。
o Acct-Interim-Interval
o Acct-Interim-Interval
o Accounting-Realtime-Required
o アカウンティング-リアルタイムが必要
o Acct-Multi-Session-Id
o Acct-Multi-Session-Id
o Accounting-Record-Number
o 会計レコード番号
o Accounting-Record-Type
o 会計レコードタイプ
o Accounting-Session-Id
o Accounting-Session-Id
o Accounting-Sub-Session-Id
o Accounting-Sub-Session-Id
o Class o Session-Id
oクラスoセッションID
o Session-Binding
o セッションバインディング
o Session-Server-Failover
o セッションサーバーフェイルオーバー
o User-Name
o ユーザー名
Diameter messages containing these or any other AVPs considered to be security-sensitive MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages MUST NOT be sent via intermediate nodes unless there is end-to-end security between the originator and recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed. For example, end-to-end security may not be required in the case where an intermediary node is known to be operated as part of the same administrative domain as the endpoints so that an ability to successfully compromise the intermediary would imply a high probability of being able to compromise the endpoints as well. Note that no end-to-end security mechanism is specified in this document.
これらまたは他のセキュリティ上重要であると見なされるAVPを含むDiameterメッセージは、相互認証されたTLSまたはIPsecを介してのみ保護されて送信される必要があります。さらに、発信者と受信者の間にエンドツーエンドのセキュリティがあるか、発信者がエンドツーエンドのセキュリティが不要であることを示すローカルで信頼された構成がない限り、これらのメッセージは中間ノードを介して送信してはなりません。たとえば、中間ノードがエンドポイントと同じ管理ドメインの一部として運用されていることがわかっている場合は、エンドツーエンドのセキュリティは必要ない可能性があります。エンドポイントを危険にさらすこともできます。このドキュメントでは、エンドツーエンドのセキュリティメカニズムは指定されていないことに注意してください。
[FLOATPOINT] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985", August 1985.
[FLOATPOINT] Institute of Electrical and Electronics Engineers、「IEEE Standard for Binary Floating-Point Arithmetic、ANSI / IEEE Standard 754-1985」、1985年8月。
[IANAADFAM] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[IANAADFAM] IANA、「アドレスファミリー番号」、<http://www.iana.org/assignments/address-family-numbers>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[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月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、2003年3月。
[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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958] Daigle、L。およびA. Newton、「SRV RRおよび動的委任検出サービス（DDDS）を使用したドメインベースのアプリケーションサービスロケーション」、RFC 3958、2005年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004] Calhoun、P.、Johansson、T.、Perkins、C.、Hiller、T。、およびP. McCann、「Diameter Mobile IPv4 Application」、RFC 4004、2005年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005.
[RFC4006] Hakala、H.、Mattila、L.、Koskinen、J-P。、Stura、M。、およびJ. Loughney、「Diameter Credit-Control Application」、RFC 4006、2005年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「The Network Access Identifier」、RFC 4282、2005年12月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009.
[RFC5729] Korhonen、J.、Jones、M.、Morand、L。、およびT. Tsou、「ユーザー名とレルムに基づくDiameterリクエストのルーティングに関する説明」、RFC 5729、2009年12月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、2010年8月。
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.
[RFC6083] Tuexen、M.、Seggelmann、R。、およびE. Rescorla、「Data Control Transport Layer Security（DTLS）for Stream Control Transmission Protocol（SCTP）」、RFC 6083、2011年1月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
[RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage", RFC 6408, November 2011.
[RFC6408] Jones、M.、Korhonen、J。、およびL. Morand、「Diameter Straightforward-Naming Authority Pointer（S-NAPTR）Usage」、RFC 6408、2011年11月。
[ENTERPRISE] IANA, "SMI Network Management Private Enterprise Codes", <http://www.iana.org/assignments/enterprise-numbers>.
[エンタープライズ] IANA、「SMIネットワーク管理プライベートエンタープライズコード」、<http://www.iana.org/assignments/enterprise-numbers>。
[IANATCV] IANA, "Termination-Cause AVP Values (code 295)", <http://www.iana.org/assignments/aaa-parameters/ aaa-parameters.xml#aaa-parameters-16>.
[IANATCV] IANA、「Termination-Cause AVP Values（code 295）」、<http://www.iana.org/assignments/aaa-parameters/ aaa-parameters.xml＃aaa-parameters-16>。
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993.
[RFC1492] Finseth、C。、「アクセスコントロールプロトコル、TACACSと呼ばれることもある」、RFC 1492、1993年7月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]リグニー、C。、「RADIUSアカウンティング」、RFC 2866、2000年6月。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W。、およびP. Calhoun、「RADIUS Extensions」、RFC 2869、2000年6月。
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[RFC2881] Mitton、D。およびM. Beadles、「ネットワークアクセスサーバー要件次世代（NASREQNG）NASモデル」、RFC 2881、2000年7月。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2975] Aboba、B.、Arkko、J。、およびD. Harrington、「Introduction to Accounting Management」、RFC 2975、2000年10月。
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S., and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000.
[RFC2989] Aboba、B.、Calhoun、P.、Glass、S.、Hiller、T.、McCann、P.、Shiino、H.、Walsh、P.、Zorn、G.、Dommety、G.、Perkins、 C.、Patil、B.、Mitton、D.、Manning、S.、Beadles、M.、Chen、X.、Sivalingham、S.、Hameed、A.、Munson、M.、Jacobs、S.、Lim、 B.、Hirschman、B.、Hsu、R.、Koo、H.、Lipford、M.、Campbell、E.、Xu、Y.、Baba、S。、およびE. Jaques、「AAAプロトコルの評価基準ネットワークアクセス」、RFC 2989、2000年11月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「RADIUS and IPv6」、RFC 3162、2001年8月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690] Klensin、J.、Faltstrom、P.、Karp、C。、およびIAB、「Review and Recommendations for Internationalized Domain Names（IDNs）」、RFC 4690、2006年9月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 5176、January 2008。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC5461] Gont、F。、「ソフトエラーに対するTCPの反応」、RFC 5461、2009年2月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills、D.、Martin、J.、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927] Gont、F。、「TCPに対するICMP攻撃」、RFC 5927、2010年7月。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスタールンド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、2011年8月。
[RFC6737] Kang, J. and G. Zorn, "The Diameter Capabilities Update Application", RFC 6737, October 2012.
[RFC6737] Kang、J。およびG. Zorn、「Diameter Capabilities Update Application」、RFC 6737、2012年10月。
The authors would like to thank the following people that have provided proposals and contributions to this document:
著者は、このドキュメントへの提案と貢献を提供してくれた以下の人々に感謝します。
To Vishnu Ram and Satendra Gera for their contributions on capabilities updates, predictive loop avoidance, as well as many other technical proposals. To Tolga Asveren for his insights and contributions on almost all of the proposed solutions incorporated into this document. To Timothy Smith for helping on the capabilities Update and other topics. To Tony Zhang for providing fixes to loopholes on composing Failed-AVPs as well as many other issues and topics. To Jan Nordqvist for clearly stating the usage of Application Ids. To Anders Kristensen for providing needed technical opinions. To David Frascone for providing invaluable review of the document. To Mark Jones for providing clarifying text on vendor command codes and other vendor-specific indicators. To Victor Pascual and Sebastien Decugis for new text and recommendations on SCTP/DTLS. To Jouni Korhonen for taking over the editing task and resolving last bits from versions 27 through 29.
Vishnu RamとSatendra Geraが、機能の更新、予測ループの回避、およびその他の多くの技術提案に貢献してくれたことに感謝します。このドキュメントに組み込まれている提案されたソリューションのほとんどすべてに対する洞察と貢献についてTolga Asverenに。機能アップデートおよびその他のトピックについて支援してくださったTimothy Smithに。 Failed-AVPの作成に関する抜け穴やその他の多くの問題やトピックを修正してくれたTony Zhangに。アプリケーションIDの使用を明確に述べてくれたJan Nordqvistに。必要な技術的意見を提供してくれたAnders Kristensenに。ドキュメントの非常に貴重なレビューを提供してくれたDavid Frasconeに。ベンダのコマンドコードおよびその他のベンダ固有のインジケータに関する明確なテキストを提供するためにマークジョーンズに。 SCTP / DTLSに関する新しいテキストと推奨事項については、Victor PascualおよびSebastien Decugisに。編集作業を引き継ぎ、バージョン27〜29の最後の部分を解決してくれたJouni Korhonenに。
Special thanks to the Diameter extensibility design team, which helped resolve the tricky question of mandatory AVPs and ABNF semantics. The members of this team are as follows:
Diameter拡張性設計チームに特に感謝します。これは、必須のAVPとABNFセマンティクスの難しい問題を解決するのに役立ちました。このチームのメンバーは次のとおりです。
Avi Lior, Jari Arkko, Glen Zorn, Lionel Morand, Mark Jones, Tolga Asveren, Jouni Korhonen, and Glenn McGregor.
Avi Lior、Jari Arkko、Glen Zorn、Lionel Morand、Mark Jones、Tolga Asveren、Jouni Korhonen、およびGlenn McGregor。
Special thanks also to people who have provided invaluable comments and inputs especially in resolving controversial issues:
特に論争の的となる問題を解決する上で貴重なコメントと情報を提供してくれた人々にも特に感謝します。
Glen Zorn, Yoshihiro Ohba, Marco Stura, Stephen Farrel, Pete Resnick, Peter Saint-Andre, Robert Sparks, Krishna Prasad, Sean Turner, Barry Leiba, and Pasi Eronen.
Glen Zorn、Ohba Hirohiro、Marco Stura、Stephen Farrel、Pete Resnick、Peter Saint-Andre、Robert Sparks、Krishna Prasad、Sean Turner、Barry Leiba、Pasi Eronen。
Finally, we would like to thank the original authors of this document:
最後に、このドキュメントの原作者に感謝します。
Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman, and Glen Zorn.
Pat Calhoun、John Loughney、Jari Arkko、Erik Guttman、Glen Zorn。
Their invaluable knowledge and experience has given us a robust and flexible AAA protocol that many people have seen great value in adopting. We greatly appreciate their support and stewardship for the continued improvements of Diameter as a protocol. We would also like to extend our gratitude to folks aside from the authors who have assisted and contributed to the original version of this document. Their efforts significantly contributed to the success of Diameter.
彼らの非常に貴重な知識と経験により、多くの人々が採用に大きな価値を見出している堅牢で柔軟なAAAプロトコルを提供しています。プロトコルとしてのDiameterの継続的な改善に対する彼らのサポートとスチュワードシップに深く感謝します。また、このドキュメントの元のバージョンを手伝い、貢献してくれた著者以外の方々にも感謝の意を表したいと思います。彼らの努力はDiameterの成功に大きく貢献しました。
The authors would like to thank Nenad Trifunovic, Tony Johansson and Pankaj Patel for their participation in the pre-IETF Document Reading Party. Allison Mankin, Jonathan Wood, and Bernard Aboba provided invaluable assistance in working out transport issues and this was also the case with Steven Bellovin in the security area.
著者は、IETF以前の文書閲覧会に参加してくれたNenad Trifunovic、Tony Johansson、およびPankaj Patelに感謝します。アリソンマンキン、ジョナサンウッド、バーナードアボバは、輸送問題の解決に非常に貴重な支援を提供しました。これは、セキュリティエリアのスティーブンベロビンにも当てはまります。
Paul Funk and David Mitton were instrumental in getting the Peer State Machine correct, and our deep thanks go to them for their time.
Paul FunkとDavid Mittonは、ピアステートマシンを正しくするために尽力してくれました。
Text in this document was also provided by Paul Funk, Mark Eklund, Mark Jones, and Dave Spence. Jacques Caron provided many great comments as a result of a thorough review of the spec.
このドキュメントのテキストは、Paul Funk、Mark Eklund、Mark Jones、およびDave Spenceも提供しています。 Jacques Caronは、仕様を徹底的に見直した結果、多くのすばらしいコメントを提供しました。
The authors would also like to acknowledge the following people for their contribution in the development of the Diameter protocol:
著者はまた、Diameterプロトコルの開発に貢献した以下の人々に感謝します。
Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell, David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien, Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht, and Jeff Weisberg.
アランC.ルーベンス、ハシーブアクタール、ウィリアムブリー、スティーブンファレル、デビッドフラスコーネ、ダニエルC.フォックス、ロルグラント、イグナシオゴイレット、ナンシーグリーン、ピーターヘイトマン、フレドリックヨハンソン、マークジョーンズ、マーティンジュリアン、ボブコパッチ、ポールクルムビデ、ファーガルラドリー、ライアン・モーツ、ビクター・モスリン、ケネス・パース、ジョン・シュニズライン、スミット・ヴァキル、ジョン・R・ボルブレヒト、ジェフ・ワイスバーグ。
Finally, Pat Calhoun would like to thank Sun Microsystems since most of the effort put into this document was done while he was in their employ.
最後に、Pat Calhounは、Sun Microsystemsに感謝したいと思います。この文書に加えられた努力のほとんどは、彼が彼らの雇用中に行われたからです。
As an example, consider a client that wishes to resolve aaa: ex1.example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
例として、aaaを解決したいクライアントを考えてみましょう：ex1.example.com。クライアントはそのドメインに対してNAPTRクエリを実行し、次のNAPTRレコードが返されます。
;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" "" _diameter._tls.ex1.example.com IN NAPTR 100 50 "s" "aaa:diameter.tcp" "" _aaa._tcp.ex1.example.com IN NAPTR 150 50 "s" "aaa:diameter.sctp" "" _diameter._sctp.ex1.example.com
;;注文設定フラグサービスregexp置換IN NAPTR 50 50 "s" "aaa：diameter.tls.tcp" "" _diameter._tls.ex1.example.com IN NAPTR 100 50 "s" "aaa：diameter.tcp" "" _aaa ._tcp.ex1.example.com IN NAPTR 150 50 "s" "aaa：diameter.sctp" "" _diameter._sctp.ex1.example.com
This indicates that the server supports TLS, TCP, and SCTP in that order. If the client supports TLS, TLS will be used, targeted to a host determined by an SRV lookup of _diameter._tls.ex1.example.com. That lookup would return:
これは、サーバーがTLS、TCP、SCTPの順にサポートしていることを示しています。クライアントがTLSをサポートしている場合、TLSが使用され、_diameter._tls.ex1.example.comのSRVルックアップによって決定されたホストをターゲットにします。そのルックアップは以下を返します：
;; Priority Weight Port Target IN SRV 0 1 5060 server1.ex1.example.com IN SRV 0 2 5060 server2.ex1.example.com
;;優先度ウェイトポートターゲットIN SRV 0 1 5060 server1.ex1.example.com IN SRV 0 2 5060 server2.ex1.example.com
As an alternative example, a client that wishes to resolve aaa: ex2.example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
別の例として、aaaを解決したいクライアント：ex2.example.com。クライアントはそのドメインに対してNAPTRクエリを実行し、次のNAPTRレコードが返されます。
;; order pref flags service regexp replacement IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" server1.ex2.example.com IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" server2.ex2.example.com
;;注文設定フラグサービスregexp置換IN NAPTR 150 50 "a" "aaa：diameter.tls.tcp" "" server1.ex2.example.com IN NAPTR 150 50 "a" "aaa：diameter.tls.tcp" "" server2 .ex2.example.com
This indicates that the server supports TCP available at the returned host names.
これは、サーバーが、返されたホスト名で利用可能なTCPをサポートしていることを示しています。
As described in Section 9.4, accounting record duplicate detection is based on session identifiers. Duplicates can appear for various reasons:
セクション9.4で説明されているように、アカウンティングレコードの重複検出はセッション識別子に基づいています。重複はさまざまな理由で発生する可能性があります。
o Failover to an alternate server. Where close to real-time performance is required, failover thresholds need to be kept low. This may lead to an increased likelihood of duplicates. Failover can occur at the client or within Diameter agents.
o 代替サーバーへのフェイルオーバー。ほぼリアルタイムのパフォーマンスが必要な場合は、フェイルオーバーのしきい値を低く保つ必要があります。これにより、重複する可能性が高くなります。フェイルオーバーは、クライアントまたはDiameterエージェント内で発生する可能性があります。
o Failure of a client or agent after sending a record from non-volatile memory, but prior to receipt of an application-layer ACK and deletion of the record to be sent. This will result in retransmission of the record soon after the client or agent has rebooted.
o 不揮発性メモリからレコードを送信した後、アプリケーション層のACKを受信して送信するレコードを削除する前の、クライアントまたはエージェントの障害。これにより、クライアントまたはエージェントが再起動した直後にレコードが再送信されます。
o Duplicates received from RADIUS gateways. Since the retransmission behavior of RADIUS is not defined within [RFC2865], the likelihood of duplication will vary according to the implementation.
o RADIUSゲートウェイから受信した重複。 RADIUSの再送信動作は[RFC2865]で定義されていないため、重複の可能性は実装によって異なります。
o Implementation problems and misconfiguration.
o 実装の問題と設定ミス。
The T flag is used as an indication of an application-layer retransmission event, e.g., due to failover to an alternate server. It is defined only for request messages sent by Diameter clients or agents. For instance, after a reboot, a client may not know whether it has already tried to send the accounting records in its non-volatile memory before the reboot occurred. Diameter servers MAY use the T flag as an aid when processing requests and detecting duplicate messages. However, servers that do this MUST ensure that duplicates are found even when the first transmitted request arrives at the server after the retransmitted request. It can be used only in cases where no answer has been received from the server for a request and the request is sent again, (e.g., due to a failover to an alternate peer, due to a recovered primary peer or due to a client re-sending a stored record from non-volatile memory such as after reboot of a client or agent).
Tフラグは、たとえば、代替サーバーへのフェイルオーバーが原因のアプリケーション層再送信イベントを示すものとして使用されます。これは、Diameterクライアントまたはエージェントによって送信された要求メッセージに対してのみ定義されます。たとえば、再起動後、クライアントは、再起動が発生する前に、アカウンティングレコードを不揮発性メモリに送信しようとしたかどうかを知らない場合があります。 Diameterサーバーは、リクエストを処理して重複メッセージを検出する際の補助としてTフラグを使用する場合があります。ただし、これを行うサーバーは、再送信された要求の後に最初に送信された要求がサーバーに到着した場合でも、重複が検出されるようにする必要があります。これは、リクエストに対してサーバーから応答が受信されず、リクエストが再送信された場合にのみ使用できます（たとえば、代替ピアへのフェイルオーバー、回復されたプライマリピア、またはクライアントの再インストールが原因で）。 -クライアントまたはエージェントの再起動後など、不揮発性メモリから保存されたレコードを送信する）。
In some cases, the Diameter accounting server can delay the duplicate detection and accounting record processing until a post-processing phase takes place. At that time records are likely to be sorted according to the included User-Name and duplicate elimination is easy in this case. In other situations, it may be necessary to perform real-time duplicate detection, such as when credit limits are imposed or real-time fraud detection is desired.
場合によっては、Diameterアカウンティングサーバーは、後処理フェーズが行われるまで、重複の検出とアカウンティングレコードの処理を遅らせることができます。当時、レコードは含まれているユーザー名に従ってソートされる可能性が高く、この場合、重複の排除は簡単です。その他の状況では、クレジット制限が課されている場合やリアルタイムの不正検出が必要な場合など、リアルタイムの重複検出を実行する必要がある場合があります。
In general, only generation of duplicates due to failover or re-sending of records in non-volatile storage can be reliably detected by Diameter clients or agents. In such cases, the Diameter client or agents can mark the message as a possible duplicate by setting the T flag. Since the Diameter server is responsible for duplicate detection, it can choose whether or not to make use of the T flag, in order to optimize duplicate detection. Since the T flag does not affect interoperability, and it may not be needed by some servers, generation of the T flag is REQUIRED for Diameter clients and agents, but it MAY be implemented by Diameter servers.
一般に、Diameterクライアントまたはエージェントが確実に検出できるのは、不揮発性ストレージ内のレコードのフェイルオーバーまたは再送信による重複の生成のみです。このような場合、Diameterクライアントまたはエージェントは、Tフラグを設定することにより、メッセージを重複の可能性があるものとしてマークできます。 Diameterサーバーは重複検出を担当するため、重複検出を最適化するために、Tフラグを使用するかどうかを選択できます。 Tフラグは相互運用性に影響せず、一部のサーバーでは必要ない場合があるため、Tフラグの生成はDiameterクライアントおよびエージェントで必須ですが、Diameterサーバーで実装される場合があります。
As an example, it can be usually be assumed that duplicates appear within a time window of longest recorded network partition or device fault, perhaps a day. So only records within this time window need to be looked at in the backward direction. Secondly, hashing techniques or other schemes, such as the use of the T flag in the received messages, may be used to eliminate the need to do a full search even in this set except for rare cases.
例として、重複が、最も長く記録されたネットワークパーティションまたはデバイスの障害、おそらく1日のタイムウィンドウ内に表示されると通常想定できます。そのため、この時間枠内のレコードのみを逆方向に見る必要があります。第2に、ハッシュメッセージまたは受信したメッセージでのTフラグの使用などの他のスキームを使用して、まれなケースを除いて、このセットでも完全検索を実行する必要をなくすことができます。
The following is an example of how the T flag may be used by the server to detect duplicate requests.
次の例は、サーバーがTフラグを使用して、重複する要求を検出する方法を示しています。
A Diameter server MAY check the T flag of the received message to determine if the record is a possible duplicate. If the T flag is set in the request message, the server searches for a duplicate within a configurable duplication time window backward and forward. This limits database searching to those records where the T flag is set. In a well-run network, network partitions and device faults will presumably be rare events, so this approach represents a substantial optimization of the duplicate detection process. During failover, it is possible for the original record to be received after the T-flag-marked record, due to differences in network delays experienced along the path by the original and duplicate transmissions. The likelihood of this occurring increases as the failover interval is decreased. In order to be able to detect duplicates that are out of order, the Diameter server should use backward and forward time windows when performing duplicate checking for the T-flag-marked request. For example, in order to allow time for the original record to exit the network and be recorded by the accounting server, the Diameter server can delay processing records with the T flag set until a time period TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after the closing of the original transport connection. After this time period, it may check the T-flag-marked records against the database with relative assurance that the original records, if sent, have been received and recorded.
Diameterサーバーは、受信したメッセージのTフラグをチェックして、レコードが重複している可能性があるかどうかを判断できます（MAY）。要求メッセージでTフラグが設定されている場合、サーバーは構成可能な複製時間ウィンドウ内で重複を逆方向および順方向に検索します。これにより、データベース検索がTフラグが設定されているレコードに制限されます。正常に実行されているネットワークでは、ネットワークパーティションとデバイスの障害はおそらくまれなイベントであるため、このアプローチは重複検出プロセスの大幅な最適化を表しています。フェイルオーバー中に、元の送信と重複した送信によってパスに沿って発生するネットワーク遅延の違いにより、Tフラグでマークされたレコードの後に元のレコードが受信される可能性があります。これが発生する可能性は、フェイルオーバー間隔が短くなるにつれて増加します。順不同の重複を検出できるようにするために、Diameterサーバーは、Tフラグのマークが付いたリクエストの重複チェックを実行するときに、後方および前方の時間枠を使用する必要があります。たとえば、元のレコードがネットワークから出て、アカウンティングサーバーによって記録されるまでの時間を確保するために、Diameterサーバーは、Tフラグが設定されたレコードの処理を、を閉じてからTIME_WAIT + RECORD_PROCESSING_TIME時間が経過するまで遅らせることができます。元のトランスポート接続。この期間が経過すると、Tフラグのマークが付いたレコードをデータベースと照合して、元のレコードが送信された場合は受信および記録されたことを相対的に保証します。
To be compatible with the existing DNS infrastructure and simplify host and domain name comparison, Diameter identities (FQDNs) are represented in ASCII form. This allows the Diameter protocol to fall in-line with the DNS strategy of being transparent from the effects of Internationalized Domain Names (IDNs) by following the recommendations in [RFC4690] and [RFC5890]. Applications that provide support for IDNs outside of the Diameter protocol but interacting with it SHOULD use the representation and conversion framework described in [RFC5890], [RFC5891], and [RFC3492].
既存のDNSインフラストラクチャとの互換性を維持し、ホストとドメイン名の比較を簡素化するために、Diameter ID（FQDN）はASCII形式で表されます。これにより、[RFC4690]と[RFC5890]の推奨事項に従うことで、Diameterプロトコルを国際化ドメイン名（IDN）の影響から透過的にするDNS戦略に合わせることができます。 Diameterプロトコルの外部でIDNのサポートを提供するが、それと対話するアプリケーションは、[RFC5890]、[RFC5891]、および[RFC3492]で説明されている表現および変換フレームワークを使用する必要があります（SHOULD）。
Authors' Addresses
著者のアドレス
Victor Fajardo (editor) Telcordia Technologies One Telcordia Drive, 1S-222 Piscataway, NJ 08854 USA
ビクターファハルド（編集者）Telcordia Technologies One Telcordia Drive、1S-222 Piscataway、NJ 08854 USA
Phone: +1-908-421-1845
EMail: vf0213@gmail.com
Jari Arkko Ericsson Research 02420 Jorvas Finland
Jari Arkko Ericsson Research 02420 Jorvasフィンランド
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
John Loughney Nokia Research Center 955 Page Mill Road Palo Alto, CA 94304 US
John Loughney Nokia Research Center 955 Page Mill Road Palo Alto、CA 94304 US
Phone: +1-650-283-8068
EMail: john.loughney@nokia.com
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Geron Joron（編集者）Network Zen 228/356 Thanong Sunfight Bang Na、Bangkok 10260 Thailand
Phone: +66 (0) 87-0404617
EMail: glenzorn@gmail.com