[要約] RFC 3588は、Diameterベースプロトコルの仕様を定義しており、Diameterプロトコルの基本的な動作とメッセージ交換を提供します。このRFCの目的は、ネットワークノード間での認証、認可、アカウンティング（AAA）情報の交換を可能にするための標準化を行うことです。
Network Working Group P. Calhoun
Request for Comments: 3588 Airespace, Inc.
Category: Standards Track J. Loughney
Nokia
E. Guttman
Sun Microsystems, Inc.
G. Zorn
Cisco Systems, Inc.
J. Arkko
Ericsson
September 2003
Diameter Base Protocol
Diameterベースプロトコル
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
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. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations.
Diameter基本プロトコルは、ネットワークアクセスやIPモビリティなどのアプリケーションに認証、承認、アカウンティング（AAA）フレームワークを提供することを目的としています。 Diameterは、ローカルの認証、承認、アカウンティング、ローミングの両方の状況で機能することも目的としています。このドキュメントでは、すべてのDiameterアプリケーションで使用されるメッセージフォーマット、トランスポート、エラーレポート、アカウンティング、およびセキュリティサービスを指定します。 Diameter基本アプリケーションは、すべてのDiameter実装でサポートされる必要があります。
Conventions Used In This Document
このドキュメントで使用される規則
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 BCP 14, RFC 2119 [KEYWORD].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [KEYWORD]の説明に従って解釈されます。
Table of Contents
目次
1. Introduction................................................. 6
1.1. Diameter Protocol..................................... 9
1.1.1. Description of the Document Set.............. 10
1.2. Approach to Extensibility............................. 11
1.2.1. Defining New AVP Values...................... 11
1.2.2. Creating New AVPs............................ 11
1.2.3. Creating New Authentication Applications..... 11
1.2.4. Creating New Accounting Applications......... 12
1.2.5. Application Authentication Procedures........ 14
1.3. Terminology........................................... 14
2. Protocol Overview............................................ 18
2.1. Transport............................................. 20
2.1.1. SCTP Guidelines.............................. 21
2.2. Securing Diameter Messages............................ 21
2.3. Diameter Application Compliance....................... 21
2.4. Application Identifiers............................... 22
2.5. Connections vs. Sessions.............................. 22
2.6. Peer Table............................................ 23
2.7. Realm-Based Routing Table............................. 24
2.8. Role of Diameter Agents............................... 25
2.8.1. Relay Agents................................. 26
2.8.2. Proxy Agents................................. 27
2.8.3. Redirect Agents.............................. 28
2.8.4. Translation Agents........................... 29
2.9. End-to-End Security Framework......................... 30
2.10. Diameter Path Authorization........................... 30
3. Diameter Header.............................................. 32
3.1. Command Codes......................................... 35
3.2. Command Code ABNF specification....................... 36
3.3. Diameter Command Naming Conventions................... 38
4. Diameter AVPs................................................ 38
4.1. AVP Header............................................ 39
4.1.1. Optional Header Elements..................... 41
4.2. Basic AVP Data Formats................................ 41
4.3. Derived AVP Data Formats.............................. 42
4.4. Grouped AVP Values.................................... 49
4.4.1. Example AVP with a Grouped Data Type......... 50
4.5. Diameter Base Protocol AVPs........................... 53
5. Diameter Peers............................................... 56
5.1. Peer Connections...................................... 56
5.2. Diameter Peer Discovery............................... 56
5.3. Capabilities Exchange................................. 59
5.3.1. Capabilities-Exchange-Request................ 60
5.3.2. Capabilities-Exchange-Answer................. 60
5.3.3. Vendor-Id AVP................................ 61
5.3.4. Firmware-Revision AVP........................ 61
5.3.5. Host-IP-Address AVP.......................... 62
5.3.6. Supported-Vendor-Id AVP...................... 62
5.3.7. Product-Name AVP............................. 62
5.4. Disconnecting Peer Connections........................ 62
5.4.1. Disconnect-Peer-Request...................... 63
5.4.2. Disconnect-Peer-Answer....................... 63
5.4.3. Disconnect-Cause AVP......................... 63
5.5. Transport Failure Detection........................... 64
5.5.1. Device-Watchdog-Request...................... 64
5.5.2. Device-Watchdog-Answer....................... 64
5.5.3. Transport Failure Algorithm.................. 65
5.5.4. Failover and Failback Procedures............. 65
5.6. Peer State Machine.................................... 66
5.6.1. Incoming connections......................... 68
5.6.2. Events....................................... 69
5.6.3. Actions...................................... 70
5.6.4. The Election Process......................... 71
6. Diameter Message Processing.................................. 71
6.1. Diameter Request Routing Overview..................... 71
6.1.1. Originating a Request........................ 73
6.1.2. Sending a Request............................ 73
6.1.3. Receiving Requests........................... 73
6.1.4. Processing Local Requests.................... 73
6.1.5. Request Forwarding........................... 74
6.1.6. Request Routing.............................. 74
6.1.7. Redirecting Requests......................... 74
6.1.8. Relaying and Proxying Requests............... 75
6.2. Diameter Answer Processing............................ 76
6.2.1. Processing Received Answers.................. 77
6.2.2. Relaying and Proxying Answers................ 77
6.3. Origin-Host AVP....................................... 77
6.4. Origin-Realm AVP...................................... 78
6.5. Destination-Host AVP.................................. 78
6.6. Destination-Realm AVP................................. 78
6.7. Routing AVPs.......................................... 78
6.7.1. Route-Record AVP............................. 79
6.7.2. Proxy-Info AVP............................... 79
6.7.3. Proxy-Host AVP............................... 79
6.7.4. Proxy-State AVP.............................. 79
6.8. Auth-Application-Id AVP............................... 79
6.9. Acct-Application-Id AVP............................... 79
6.10. Inband-Security-Id AVP................................ 79
6.11. Vendor-Specific-Application-Id AVP.................... 80
6.12. Redirect-Host AVP..................................... 80
6.13. Redirect-Host-Usage AVP............................... 80
6.14. Redirect-Max-Cache-Time AVP........................... 81
6.15. E2E-Sequence AVP...................................... 82
7. Error Handling............................................... 82
7.1. Result-Code AVP....................................... 84
7.1.1. Informational................................ 84
7.1.2. Success...................................... 84
7.1.3. Protocol Errors.............................. 85
7.1.4. Transient Failures........................... 86
7.1.5. Permanent Failures........................... 86
7.2. Error Bit............................................. 88
7.3. Error-Message AVP..................................... 89
7.4. Error-Reporting-Host AVP.............................. 89
7.5. Failed-AVP AVP........................................ 89
7.6. Experimental-Result AVP............................... 90
7.7. Experimental-Result-Code AVP.......................... 90
8. Diameter User Sessions....................................... 90
8.1. Authorization Session State Machine................... 92
8.2. Accounting Session State Machine...................... 96
8.3. Server-Initiated Re-Auth.............................. 101
8.3.1. Re-Auth-Request.............................. 102
8.3.2. Re-Auth-Answer............................... 102
8.4. Session Termination................................... 103
8.4.1. Session-Termination-Request.................. 104
8.4.2. Session-Termination-Answer................... 105
8.5. Aborting a Session.................................... 105
8.5.1. Abort-Session-Request........................ 106
8.5.2. Abort-Session-Answer......................... 106
8.6. Inferring Session Termination from Origin-State-Id.... 107
8.7. Auth-Request-Type AVP................................. 108
8.8. Session-Id AVP........................................ 108
8.9. Authorization-Lifetime AVP............................ 109
8.10. Auth-Grace-Period AVP................................. 110
8.11. Auth-Session-State AVP................................ 110
8.12. Re-Auth-Request-Type AVP.............................. 110
8.13. Session-Timeout AVP................................... 111
8.14. User-Name AVP......................................... 111
8.15. Termination-Cause AVP................................. 111
8.16. Origin-State-Id AVP................................... 112
8.17. Session-Binding AVP................................... 113
8.18. Session-Server-Failover AVP........................... 113
8.19. Multi-Round-Time-Out AVP.............................. 114
8.20. Class AVP............................................. 114
8.21. Event-Timestamp AVP................................... 115
9. Accounting................................................... 115
9.1. Server Directed Model................................. 115
9.2. Protocol Messages..................................... 116
9.3. Application Document Requirements..................... 116
9.4. Fault Resilience...................................... 116
9.5. Accounting Records.................................... 117
9.6. Correlation of Accounting Records..................... 118
9.7. Accounting Command-Codes.............................. 119
9.7.1. Accounting-Request........................... 119
9.7.2. Accounting-Answer............................ 120
9.8. Accounting AVPs....................................... 121
9.8.1. Accounting-Record-Type AVP................... 121
9.8.2. Acct-Interim-Interval AVP.................... 122
9.8.3. Accounting-Record-Number AVP................. 123
9.8.4. Acct-Session-Id AVP.......................... 123
9.8.5. Acct-Multi-Session-Id AVP.................... 123
9.8.6. Accounting-Sub-Session-Id AVP................ 123
9.8.7. Accounting-Realtime-Required AVP............. 123
10. AVP Occurrence Table......................................... 124
10.1. Base Protocol Command AVP Table....................... 124
10.2. Accounting AVP Table.................................. 126
11. IANA Considerations.......................................... 127
11.1. AVP Header............................................ 127
11.1.1. AVP Code..................................... 127
11.1.2. AVP Flags.................................... 128
11.2. Diameter Header....................................... 128
11.2.1. Command Codes................................ 128
11.2.2. Command Flags................................ 129
11.3. Application Identifiers............................... 129
11.4. AVP Values............................................ 129
11.4.1. Result-Code AVP Values....................... 129
11.4.2. Accounting-Record-Type AVP Values............ 130
11.4.3. Termination-Cause AVP Values................. 130
11.4.4. Redirect-Host-Usage AVP Values............... 130
11.4.5. Session-Server-Failover AVP Values........... 130
11.4.6. Session-Binding AVP Values................... 130
11.4.7. Disconnect-Cause AVP Values.................. 130
11.4.8. Auth-Request-Type AVP Values................. 130
11.4.9. Auth-Session-State AVP Values................ 130
11.4.10. Re-Auth-Request-Type AVP Values.............. 131
11.4.11. Accounting-Realtime-Required AVP Values...... 131
11.5. Diameter TCP/SCTP Port Numbers........................ 131
11.6. NAPTR Service Fields.................................. 131
12. Diameter Protocol Related Configurable Parameters............ 131
13. Security Considerations...................................... 132
13.1. IPsec Usage........................................... 133
13.2. TLS Usage............................................. 134
13.3. Peer-to-Peer Considerations........................... 134
14. References................................................... 136
14.1. Normative References.................................. 136
14.2. Informative References................................ 138
15. Acknowledgements............................................. 140
Appendix A. Diameter Service Template........................... 141
Appendix B. NAPTR Example....................................... 142
Appendix C. Duplicate Detection................................. 143
Appendix D. Intellectual Property Statement..................... 145
Authors' Addresses............................................... 146
Full Copyright Statement......................................... 147
Authentication, Authorization and Accounting (AAA) protocols such as TACACS [TACACS] and RADIUS [RADIUS] were initially deployed to provide dial-up PPP [PPP] and terminal server access. Over time, with the growth of the Internet and the introduction of new access technologies, including wireless, DSL, Mobile IP and Ethernet, routers and network access servers (NAS) have increased in complexity and density, putting new demands on AAA protocols.
TACACS [TACACS]やRADIUS [RADIUS]などの認証、承認、アカウンティング（AAA）プロトコルは、ダイヤルアップPPP [PPP]およびターミナルサーバーアクセスを提供するために最初に導入されました。インターネットの成長と、ワイヤレス、DSL、モバイルIPおよびイーサネットなどの新しいアクセステクノロジーの導入に伴い、ルーターとネットワークアクセスサーバー（NAS）の複雑さと密度が高まり、AAAプロトコルに新たな要求が課されています。
Network access requirements for AAA protocols are summarized in [AAAREQ]. These include:
AAAプロトコルのネットワークアクセス要件は、[AAAREQ]にまとめられています。これらには以下が含まれます：
Failover [RADIUS] 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. This is described in Section 5.5 and [AAATRANS].
フェイルオーバー[RADIUS]はフェイルオーバーメカニズムを定義していないため、フェイルオーバーの動作は実装によって異なります。明確に定義されたフェイルオーバー動作を提供するために、Diameterはアプリケーション層の確認応答をサポートし、フェイルオーバーアルゴリズムと関連するステートマシンを定義します。これについては、セクション5.5と[AAATRANS]で説明しています。
Transmission-level security
[RADIUS] defines an application-layer authentication and integrity
scheme that is required only for use with Response packets. While
[RADEXT] defines an additional authentication and integrity
mechanism, use is only required during Extensible Authentication
Protocol (EAP) sessions. While attribute-hiding is supported,
[RADIUS] does not provide support for per-packet confidentiality.
In accounting, [RADACCT] assumes that replay protection is
provided by the backend billing server, rather than within the
protocol itself.
While [RFC3162] defines the use of IPsec with RADIUS, support for IPsec is not required. Since within [IKE] authentication occurs only within Phase 1 prior to the establishment of IPsec SAs in Phase 2, it is typically not possible to define separate trust or authorization schemes for each application. This limits the usefulness of IPsec in inter-domain AAA applications (such as roaming) where it may be desirable to define a distinct certificate hierarchy for use in a AAA deployment. In order to provide universal support for transmission-level security, and enable both intra- and inter-domain AAA deployments, IPsec support is mandatory in Diameter, and TLS support is optional. Security is discussed in Section 13.
[RFC3162]はRADIUSでのIPsecの使用を定義していますが、IPsecのサポートは必要ありません。 [IKE]内の認証は、フェーズ2でIPsec SAが確立される前のフェーズ1内でのみ発生するため、通常、アプリケーションごとに個別の信頼または承認スキームを定義することはできません。これにより、ドメイン間AAAアプリケーション（ローミングなど）でのIPsecの有用性が制限され、AAA展開で使用するために個別の証明書階層を定義することが望ましい場合があります。伝送レベルのセキュリティに対するユニバーサルサポートを提供し、ドメイン内およびドメイン間のAAA展開を有効にするために、DiameterではIPsecサポートが必須であり、TLSサポートはオプションです。セキュリティについては、セクション13で説明します。
Reliable transport RADIUS runs over UDP, and does not define retransmission behavior; as a result, reliability varies between implementations. As described in [ACCMGMT], 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, SCTP) as defined in [AAATRANS].
信頼性の高いトランスポートRADIUSはUDPで実行され、再送信動作を定義していません。その結果、信頼性は実装によって異なります。 [ACCMGMT]で説明されているように、これはアカウンティングの主要な問題であり、パケット損失は直接収益損失につながる可能性があります。 Diameterは、明確に定義されたトランスポート動作を提供するために、[AAATRANS]で定義されている信頼性の高いトランスポートメカニズム（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 RADIUS server-initiated messages are defined in [DYNAUTH], support is optional. This makes it difficult to implement features such as unsolicited disconnect or reauthentication/reauthorization on demand across a heterogeneous deployment. Support for server-initiated messages is mandatory in Diameter, and is described in Section 8.
サーバー開始メッセージRADIUSサーバー開始メッセージは[DYNAUTH]で定義されていますが、サポートはオプションです。これにより、異種混合デプロイメント全体で、要求されていない切断や再認証/再認証などの機能をオンデマンドで実装することが困難になります。サーバー起動メッセージのサポートはDiameterで必須であり、セクション8で説明されています。
Auditability RADIUS does not define data-object security mechanisms, and as a result, untrusted proxies may modify attributes or even packet headers without being detected. Combined with lack of support for capabilities negotiation, this makes it very difficult to determine what occurred in the event of a dispute. While implementation of data object security is not mandatory within Diameter, these capabilities are supported, and are described in [AAACMS].
監査性RADIUSはデータオブジェクトのセキュリティメカニズムを定義していないため、信頼できないプロキシが検出されずに属性またはパケットヘッダーを変更する可能性があります。能力交渉のサポートの欠如と相まって、これは紛争の際に何が起こったかを決定することを非常に困難にします。データオブジェクトセキュリティの実装はDiameter内で必須ではありませんが、これらの機能はサポートされており、[AAACMS]で説明されています。
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, described in [NASREQ], 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エージェント間の通信を可能にするゲートウェイ内に配備されることが期待されています。 [NASREQ]で説明されているこの機能により、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 [RADIUS]. Through DNS, Diameter enables dynamic discovery of peers. Derivation of dynamic session keys is enabled via transmission-level security.
ピアの検出と設定RADIUS実装では、通常、サーバーまたはクライアントの名前またはアドレスを、対応する共有シークレットとともに手動で設定する必要があります。これにより、管理上の負担が大きくなり、RADIUS共有シークレットを再利用しようとする誘惑が生まれます。[Authenticator]が[RADIUS]で要求されているようにグローバルおよび一時的に一意でない場合、セキュリティ上の重大な脆弱性が生じる可能性があります。 DiameterはDNSを通じて、ピアの動的な検出を可能にします。動的セッションキーの派生は、伝送レベルのセキュリティによって有効になります。
Roaming support The ROAMOPS WG provided a survey of roaming implementations [ROAMREV], detailed roaming requirements [ROAMCRIT], defined the Network Access Identifier (NAI) [NAI], and documented existing implementations (and imitations) of RADIUS-based roaming [PROXYCHAIN]. In order to improve scalability, [PROXYCHAIN] introduced the concept of proxy chaining via an intermediate server, facilitating roaming between providers. However, since RADIUS does not provide explicit support for proxies, and lacks auditability and transmission-level security features, RADIUS-based roaming is vulnerable to attack from external parties as well as susceptible to fraud perpetrated by the roaming partners themselves. As a result, it is not suitable for wide-scale deployment on the Internet [PROXYCHAIN]. By providing explicit support for inter-domain roaming and message routing (Sections 2.7 and 6), auditability [AAACMS], and transmission-layer security (Section 13) features, Diameter addresses these limitations and provides for secure and scalable roaming.
ローミングのサポートROAMOPS WGは、ローミング実装の調査[ROAMREV]、詳細なローミング要件[ROAMCRIT]、ネットワークアクセス識別子（NAI）[NAI]の定義、およびRADIUSベースのローミング[PROXYCHAIN]の既存の実装（および模倣）の文書化を提供しました。スケーラビリティを向上させるために、[PROXYCHAIN]は、中間サーバーを介したプロキシチェーンの概念を導入し、プロバイダー間のローミングを容易にしました。ただし、RADIUSはプロキシに対する明示的なサポートを提供せず、監査性と伝送レベルのセキュリティ機能がないため、RADIUSベースのローミングは、外部のパーティからの攻撃に対して脆弱であるだけでなく、ローミングパートナー自身が行う詐欺の影響を受けやすくなっています。その結果、インターネット[PROXYCHAIN]での大規模な展開には適していません。 Diameterは、ドメイン間のローミングとメッセージルーティング（セクション2.7および6）、監査機能[AAACMS]、および伝送層セキュリティ（セクション13）機能を明示的にサポートすることにより、これらの制限に対処し、安全でスケーラブルなローミングを実現します。
In the decade since AAA protocols were first introduced, 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 within embedded devices, given improvements in processor speeds and the widespread availability of embedded IPsec and TLS implementations.
AAAプロトコルが最初に導入されてから10年で、ネットワークアクセスサーバー（NAS）デバイスの機能は大幅に増加しました。その結果、DiameterはRADIUSよりもはるかに洗練されたプロトコルですが、プロセッサ速度の向上と組み込みIPsecおよびTLS実装の広範な可用性を考慮すれば、組み込みデバイス内での実装は引き続き可能です。
The Diameter base protocol provides the following facilities:
Diameter基本プロトコルは、次の機能を提供します。
- Delivery of AVPs (attribute value pairs) - Capabilities negotiation - Error notification - Extensibility, through addition of new commands and AVPs (required in [AAAREQ]). - Basic services necessary for applications, such as handling of user sessions or accounting
- AVP（属性値ペア）の配信-機能のネゴシエーション-エラー通知-新しいコマンドとAVPの追加による拡張性（[AAAREQ]で必要）。 -ユーザーセッションの処理やアカウンティングなど、アプリケーションに必要な基本サービス
All data delivered by the protocol is in the form of an AVP. 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 added arbitrarily to Diameter messages, so long as the required AVPs are included and AVPs that are explicitly excluded are not included. AVPs are used by the base Diameter protocol to support the following required features:
プロトコルによって配信されるすべてのデータは、AVPの形式です。これらのAVP値には、Diameterプロトコル自体で使用されるものと、Diameterを使用する特定のアプリケーションに関連するデータを提供するものがあります。必要なAVPが含まれ、明示的に除外されているAVPが含まれていない限り、AVPは任意にDiameterメッセージに追加できます。 AVPは、以下の必須機能をサポートするために基本Diameterプロトコルによって使用されます。
- Transporting of user authentication information, for the purposes of enabling the Diameter server to authenticate the user.
- Diameterサーバーがユーザーを認証できるようにするためのユーザー認証情報の転送。
- Transporting of service specific authorization information, between client and servers, allowing the peers to decide whether a user's access request should be granted.
- クライアントとサーバー間でのサービス固有の承認情報の転送。ピアがユーザーのアクセス要求を許可するかどうかを決定できるようにします。
- Exchanging resource usage information, which MAY be used for accounting purposes, capacity planning, etc.
- 会計目的、容量計画などに使用される可能性があるリソース使用情報の交換。
- Relaying, proxying and redirecting of Diameter messages through a server hierarchy.
- サーバー階層を介したDiameterメッセージのリレー、プロキシ、リダイレクト。
The Diameter base protocol provides the minimum requirements needed for a AAA protocol, as required by [AAAREQ]. 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 [DIAMMIP], or network access [NASREQ]. It is also possible for the base protocol to be extended for use in new applications, via the addition of new commands or AVPs. At this time the focus of Diameter is 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.
Diameter基本プロトコルは、[AAAREQ]で要求される、AAAプロトコルに必要な最小要件を提供します。基本プロトコルは、会計目的でのみ単独で使用することも、モバイルIPv4 [DIAMMIP]やネットワークアクセス[NASREQ]などのDiameterアプリケーションで使用することもできます。新しいコマンドまたはAVPを追加することにより、基本プロトコルを拡張して新しいアプリケーションで使用することもできます。現時点では、Diameterの焦点はネットワークアクセスおよびアカウンティングアプリケーションです。多くのアプリケーションで使用されている真に一般的なAAAプロトコルは、Diameterで提供されていない機能を提供する場合があります。したがって、Diameterを使用する前に、新しいアプリケーションの設計者が要件を理解することが不可欠です。
See Section 2.4 for more information on Diameter applications.
Diameterアプリケーションの詳細については、セクション2.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 authenticate and/or authorize messages locally; 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プロトコルは、特定のユーザーへのサービスを中止する要求など、サーバーが開始するメッセージもサポートします。
Currently, the Diameter specification consists of a base specification (this document), Transport Profile [AAATRANS] and applications: Mobile IPv4 [DIAMMIP], and NASREQ [NASREQ].
現在、Diameter仕様は、基本仕様（このドキュメント）、トランスポートプロファイル[AAATRANS]、およびアプリケーション：モバイルIPv4 [DIAMMIP]、およびNASREQ [NASREQ]で構成されています。
The Transport Profile document [AAATRANS] 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.
トランスポートプロファイルドキュメント[AAATRANS]では、AAAプロトコルで発生するトランスポート層の問題と、これらの問題を克服する方法についての推奨事項について説明しています。このドキュメントでは、Diameterフェイルオーバーアルゴリズムとステートマシンも定義しています。
The Mobile IPv4 [DIAMMIP] application defines a Diameter application that allows a Diameter server to perform AAA functions for Mobile IPv4 services to a mobile node.
モバイルIPv4 [DIAMMIP]アプリケーションは、DiameterサーバーがモバイルノードへのモバイルIPv4サービスのAAA機能を実行できるようにするDiameterアプリケーションを定義します。
The NASREQ [NASREQ] application defines a Diameter Application that allows a Diameter server to be used in a PPP/SLIP Dial-Up and Terminal Server Access environment. Consideration was given for servers that need to perform protocol conversion between Diameter and RADIUS.
NASREQ [NASREQ]アプリケーションは、PPP / SLIPダイヤルアップおよびターミナルサーバーアクセス環境でDiameterサーバーを使用できるようにするDiameterアプリケーションを定義します。 DiameterとRADIUSの間でプロトコル変換を実行する必要があるサーバーについて検討されました。
In summary, this document defines the base protocol specification for AAA, which includes support for accounting. The Mobile IPv4 and the NASREQ documents describe applications that use this base specification for Authentication, Authorization and Accounting.
要約すると、このドキュメントでは、アカウンティングのサポートを含む、AAAの基本プロトコル仕様を定義しています。モバイルIPv4およびNASREQドキュメントは、認証、承認、アカウンティングにこの基本仕様を使用するアプリケーションについて説明しています。
The Diameter protocol is designed to be extensible, using several mechanisms, including:
Diameterプロトコルは、以下を含むいくつかのメカニズムを使用して、拡張できるように設計されています。
- Defining new AVP values - Creating new AVPs - Creating new authentication/authorization applications - Creating new accounting applications - Application authentication procedures
- 新しいAVP値の定義-新しいAVPの作成-新しい認証/承認アプリケーションの作成-新しい会計アプリケーションの作成-アプリケーション認証手順
Reuse of existing AVP values, AVPs and Diameter applications are strongly recommended. Reuse simplifies standardization and implementation and avoids potential interoperability issues. It is expected that command codes are reused; new command codes can only be created by IETF Consensus (see Section 11.2.1).
既存のAVP値、AVP、およびDiameterアプリケーションの再利用を強くお勧めします。再利用により、標準化と実装が簡素化され、潜在的な相互運用性の問題が回避されます。コマンドコードが再利用されることが期待されています。新しいコマンドコードは、IETFコンセンサスによってのみ作成できます（セクション11.2.1を参照）。
New applications should attempt to reuse AVPs defined in existing applications when possible, as opposed to creating new AVPs. For AVPs of type Enumerated, an application may require a new value to communicate some service-specific information.
新しいアプリケーションは、新しいAVPを作成するのではなく、可能な場合、既存のアプリケーションで定義されたAVPを再利用しようとします。 EnumeratedタイプのAVPの場合、アプリケーションは、サービス固有の情報を伝達するために新しい値を必要とする場合があります。
In order to allocate a new AVP value, a request MUST be sent to IANA [IANA], along with an explanation of the new AVP value. IANA considerations for Diameter are discussed in Section 11.
新しいAVP値を割り当てるには、新しいAVP値の説明とともに、リクエストをIANA [IANA]に送信する必要があります。 Diameterに関するIANAの考慮事項については、セクション11で説明します。
When no existing AVP can be used, a new AVP should be created. The new AVP being defined MUST use one of the data types listed in Section 4.2.
既存のAVPを使用できない場合は、新しいAVPを作成する必要があります。定義される新しいAVPは、セクション4.2にリストされているデータ型の1つを使用する必要があります。
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を参照）。
In order to create a new AVP, a request MUST be sent to IANA, with a specification for the AVP. The request MUST include the commands that would make use of the AVP.
新しいAVPを作成するには、AVPの仕様とともにリクエストをIANAに送信する必要があります。リクエストには、AVPを使用するコマンドを含める必要があります。
Every Diameter application specification MUST have an IANA assigned Application Identifier (see Section 2.4) or a vendor specific Application Identifier.
すべてのDiameterアプリケーション仕様には、IANAで割り当てられたアプリケーション識別子（セクション2.4を参照）またはベンダー固有のアプリケーション識別子が必要です。
Should a new Diameter usage scenario find itself unable to fit within an existing application without requiring major changes to the specification, it may be desirable to create a new Diameter application. Major changes to an application include:
新しいDiameterの使用シナリオで、仕様を大幅に変更することなく既存のアプリケーションに適合できない場合は、新しいDiameterアプリケーションを作成することが望ましい場合があります。アプリケーションの主な変更点は次のとおりです。
- Adding new AVPs to the command, which have the "M" bit set.
- 「M」ビットが設定された新しいAVPをコマンドに追加する。
- Requiring a command that has a different number of round trips to satisfy a request (e.g., application foo has a command that requires one round trip, but new application bar has a command that requires two round trips to complete).
- リクエストを満たすために、往復数の異なるコマンドが必要です（たとえば、アプリケーションfooには1回の往復が必要なコマンドがありますが、新しいアプリケーションバーには、完了するまでに2回の往復が必要なコマンドがあります）。
- Adding support for an authentication method requiring definition of new AVPs for use with the application. Since a new EAP authentication method can be supported within Diameter without requiring new AVPs, addition of EAP methods does not require the creation of a new authentication application.
- アプリケーションで使用するための新しいAVPの定義を必要とする認証方法のサポートを追加します。新しいAVPを必要とせずに、Diameter内で新しいEAP認証方法をサポートできるため、EAPメソッドを追加しても、新しい認証アプリケーションを作成する必要はありません。
Creation of a new application should be viewed as a last resort. An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs without needing to define a new application. Please refer to Section 11.1.1 for details.
新しいアプリケーションの作成は、最後の手段と見なす必要があります。実装は、新しいアプリケーションを定義する必要なしに、ベンダー固有のAVPを含む、アプリケーションで定義された任意のコマンドに任意の必須ではないAVPを追加できます。詳細については、セクション11.1.1を参照してください。
In order to justify allocation of a new application identifier, Diameter applications MUST define one Command Code, or add new mandatory AVPs to the ABNF.
新しいアプリケーション識別子の割り当てを正当化するために、Diameterアプリケーションは1つのコマンドコードを定義するか、新しい必須のAVPをABNFに追加する必要があります。
The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see Section 3.2). If the Diameter application has accounting requirements, it MUST also specify the AVPs that are to be present in the Diameter Accounting messages (see Section 9.3). However, just because a new authentication application id is required, does not imply that a new accounting application id is required.
予想されるAVPは、ABNF [ABNF]文法で定義する必要があります（セクション3.2を参照）。 Diameterアプリケーションにアカウンティング要件がある場合、Diameterアカウンティングメッセージに存在するAVPも指定する必要があります（セクション9.3を参照）。ただし、新しい認証アプリケーションIDが必要であるという理由だけで、新しいアカウンティングアプリケーションIDが必要であるとは限りません。
When possible, a new Diameter application SHOULD reuse existing Diameter AVPs, in order to avoid defining multiple AVPs that carry similar information.
同様の情報を持つ複数のAVPの定義を回避するために、可能な場合、新しいDiameterアプリケーションは既存のDiameter AVPを再利用する必要があります（SHOULD）。
There are services that only require Diameter accounting. Such services need to define the AVPs carried in the Accounting-Request (ACR)/ Accounting-Answer (ACA) messages, but do not need to define new command codes. An implementation MAY add arbitrary non-mandatory AVPs (AVPs with the "M" bit not set) to any command defined in an application, including vendor-specific AVPs, without needing to define a new accounting application. Please refer to Section 11.1.1 for details.
Diameterアカウンティングのみを必要とするサービスがあります。このようなサービスは、Accounting-Request（ACR）/ Accounting-Answer（ACA）メッセージで伝達されるAVPを定義する必要がありますが、新しいコマンドコードを定義する必要はありません。実装は、新しい会計アプリケーションを定義する必要なしに、ベンダー固有のAVPを含む、アプリケーションで定義されたコマンドに任意の非必須AVP（「M」ビットが設定されていないAVP）を追加してもよい（MAY）。詳細については、セクション11.1.1を参照してください。
Application Identifiers are still required for Diameter capability exchange. Every Diameter accounting application specification MUST have an IANA assigned Application Identifier (see Section 2.4) or a vendor specific Application Identifier.
Diameter機能の交換には、引き続きアプリケーション識別子が必要です。すべてのDiameterアカウンティングアプリケーション仕様には、IANAで割り当てられたアプリケーション識別子（セクション2.4を参照）またはベンダー固有のアプリケーション識別子が必要です。
Every Diameter implementation MUST support accounting. Basic accounting support is sufficient to handle any application that uses the ACR/ACA commands defined in this document, as long as no new mandatory AVPs are added. A mandatory AVP is defined as one which has the "M" bit set when sent within an accounting command, regardless of whether it is required or optional within the ABNF for the accounting application.
すべてのDiameter実装は、アカウンティングをサポートする必要があります。新しい必須AVPが追加されない限り、このドキュメントで定義されているACR / ACAコマンドを使用するアプリケーションを処理するには、基本的なアカウンティングサポートで十分です。必須AVPは、アカウンティングアプリケーションのABNF内で必須かオプションかに関係なく、アカウンティングコマンド内で送信されるときに「M」ビットが設定されたものとして定義されます。
The creation of a new accounting application should be viewed as a last resort and MUST NOT be used unless a new command or additional mechanisms (e.g., application defined state machine) is defined within the application, or new mandatory AVPs are added to the ABNF.
新しいアカウンティングアプリケーションの作成は最後の手段と見なす必要があり、新しいコマンドまたは追加のメカニズム（たとえば、アプリケーション定義のステートマシン）がアプリケーション内で定義されていないか、または新しい必須のAVPがABNFに追加されていない限り、使用してはなりません。
Within an accounting command, setting the "M" bit implies that a backend server (e.g., billing server) or the accounting server itself MUST understand the AVP in order to compute a correct bill. If the AVP is not relevant to the billing process, when the AVP is included within an accounting command, it MUST NOT have the "M" bit set, even if the "M" bit is set when the same AVP is used within other Diameter commands (i.e., authentication/authorization commands).
アカウンティングコマンド内で「M」ビットを設定すると、バックエンドサーバー（請求サーバーなど）またはアカウンティングサーバー自体が正しい請求書を計算するためにAVPを理解する必要があります。 AVPが課金プロセスに関連していない場合、AVPがアカウンティングコマンドに含まれているとき、他のDiameter内で同じAVPが使用されているときに「M」ビットが設定されていても、「M」ビットが設定されていてはなりません。コマンド（つまり、認証/承認コマンド）。
A DIAMETER base accounting implementation MUST be configurable to advertise supported accounting applications in order to prevent the accounting server from accepting accounting requests for unbillable services. The combination of the home domain and the accounting application Id can be used in order to route the request to the appropriate accounting server.
DIAMETERベースのアカウンティング実装は、サポートされているアカウンティングアプリケーションをアドバタイズして、アカウンティングサーバーが課金されないサービスに対するアカウンティング要求を受け入れないように構成可能でなければなりません（MUST）。ホームドメインとアカウンティングアプリケーションIDの組み合わせを使用して、要求を適切なアカウンティングサーバーにルーティングできます。
When possible, a new Diameter accounting application SHOULD attempt to reuse existing AVPs, in order to avoid defining multiple AVPs that carry similar information.
可能な場合、新しいDiameterアカウンティングアプリケーションは、同様の情報を持つ複数のAVPの定義を回避するために、既存のAVPの再利用を試みる必要があります（SHOULD）。
If the base accounting is used without any mandatory AVPs, new commands or additional mechanisms (e.g., application defined state machine), then the base protocol defined standard accounting application Id (Section 2.4) MUST be used in ACR/ACA commands.
必須のAVP、新しいコマンド、または追加のメカニズム（アプリケーション定義のステートマシンなど）なしで基本アカウンティングを使用する場合、ACR / ACAコマンドで基本プロトコル定義の標準アカウンティングアプリケーションID（セクション2.4）を使用する必要があります。
When possible, applications SHOULD be designed such that new authentication methods MAY be added without requiring changes to the application. This MAY require that new AVP values be assigned to represent the new authentication transform, or any other scheme that produces similar results. When possible, authentication frameworks, such as Extensible Authentication Protocol [EAP], SHOULD be used.
可能な場合は、アプリケーションを変更することなく新しい認証方法を追加できるようにアプリケーションを設計する必要があります（SHOULD）。これは、新しい認証トランスフォーム、または同様の結果を生成する他のスキームを表すために、新しいAVP値を割り当てる必要がある場合があります。可能な場合、拡張認証プロトコル[EAP]などの認証フレームワークを使用する必要があります（SHOULD）。
AAA Authentication, Authorization and Accounting.
AAA認証、承認、アカウンティング。
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).
認証エンティティ（サブジェクト）のIDを検証する行為。
Authorization The act of determining whether a requesting entity (subject) will be allowed access to a resource (object).
認可要求エンティティ（サブジェクト）がリソース（オブジェクト）へのアクセスを許可されるかどうかを決定する行為。
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.
AVP Diameterプロトコルは、ヘッダーとそれに続く1つ以上の属性値ペア（AVP）で構成されます。 AVPにはヘッダーが含まれており、プロトコル固有のデータ（ルーティング情報など）だけでなく、認証、承認、またはアカウンティング情報をカプセル化するために使用されます。
Broker A broker is a business term commonly used in AAA infrastructures. A broker is either a relay, proxy or redirect agent, and MAY be operated by roaming consortiums. Depending on the business model, a broker may either choose to deploy relay agents or proxy agents.
ブローカーブローカーは、AAAインフラストラクチャで一般的に使用されるビジネス用語です。ブローカーはリレー、プロキシ、またはリダイレクトエージェントのいずれかであり、ローミングコンソーシアムによって運営される場合があります。ビジネスモデルに応じて、ブローカーはリレーエージェントまたはプロキシエージェントのどちらを展開するかを選択できます。
Diameter Agent A Diameter Agent is a Diameter node that provides either relay, proxy, redirect or translation services.
DiameterエージェントDiameterエージェントは、リレー、プロキシ、リダイレクト、または変換サービスのいずれかを提供するDiameterノードです。
Diameter Client A Diameter Client is a device at the edge of the network that performs access control. An example of a Diameter client is a Network Access Server (NAS) or a Foreign Agent (FA).
DiameterクライアントDiameterクライアントは、アクセス制御を実行するネットワークのエッジにあるデバイスです。 Diameterクライアントの例は、ネットワークアクセスサーバー（NAS）または外部エージェント（FA）です。
Diameter Node A Diameter node is a host process that implements the Diameter protocol, and acts either as a Client, Agent or Server.
DiameterノードDiameterノードは、Diameterプロトコルを実装するホストプロセスであり、クライアント、エージェント、またはサーバーとして機能します。
Diameter Peer A Diameter Peer is a Diameter Node to which a given Diameter Node has a direct transport connection.
DiameterピアDiameterピアは、特定のDiameterノードが直接転送接続するDiameterノードです。
Diameter Security Exchange A Diameter Security Exchange is a process through which two Diameter nodes establish end-to-end security.
Diameterセキュリティ交換Diameterセキュリティ交換は、2つのDiameterノードがエンドツーエンドのセキュリティを確立するプロセスです。
Diameter Server A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. By its very nature, a Diameter Server MUST support Diameter 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 access device.
ダウンストリームダウンストリームは、ホームサーバーからアクセスデバイスに向かう特定のDiameterメッセージの方向を識別するために使用されます。
End-to-End Security TLS and IPsec provide hop-by-hop security, or security across a transport connection. When relays or proxy are involved, this hop-by-hop security does not protect the entire Diameter user session. End-to-end security is security between two Diameter nodes, possibly communicating through Diameter Agents. This security protects the entire Diameter communications path from the originating Diameter node to the terminating Diameter node.
エンドツーエンドのセキュリティTLSおよびIPsecは、ホップバイホップのセキュリティ、またはトランスポート接続全体のセキュリティを提供します。リレーまたはプロキシが関係する場合、このホップバイホップのセキュリティは、Diameterユーザーセッション全体を保護しません。エンドツーエンドセキュリティは、2つのDiameterノード間のセキュリティであり、Diameterエージェントを介して通信する可能性があります。このセキュリティは、元のDiameterノードから終了するDiameterノードへのDiameter通信パス全体を保護します。
Home Realm A Home Realm is the administrative domain with which the user maintains an account relationship.
ホームレルムホームレルムは、ユーザーがアカウント関係を維持するための管理ドメインです。
Home Server See Diameter Server.
ホームサーバー「Diameterサーバー」を参照してください。
Interim accounting An interim accounting message provides a snapshot of usage during a user's session. It is typically implemented in order to provide for partial accounting of a user's session in the case of a device reboot or other network problem prevents the reception 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 [NAI], 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 [NAI]）は、DiameterプロトコルでユーザーのIDと領域を抽出するために使用されます。 IDは、認証や承認の際にユーザーを識別するために使用され、レルムはメッセージルーティングの目的で使用されます。
Proxy Agent or Proxy In addition to forwarding requests and responses, proxies make policy decisions relating to resource usage and provisioning. This is typically accomplished by tracking the state of NAS devices. While proxies typically 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 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. Time constraints are typically imposed in order to limit financial risk.
リアルタイムアカウンティングリアルタイムアカウンティングには、定義された時間枠内のリソース使用状況に関する情報の処理が含まれます。財務リスクを制限するために、時間的な制約が通常課されます。
Relay Agent or Relay Relays forward requests and responses based on routing-related AVPs and realm 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 proxy agents, redirect agents do not keep state with respect to sessions or NAS resources.
リダイレクトエージェントクライアントとサーバー間で要求と応答を転送するのではなく、リダイレクトエージェントはクライアントをサーバーに参照させ、直接通信できるようにします。リダイレクトエージェントは転送パスに存在しないため、クライアントとサーバー間を通過するAVPは変更されません。リダイレクトエージェントはメッセージを生成せず、任意のメッセージタイプを処理できますが、他のタイプのリレーエージェントまたはプロキシエージェントとして機能する一方で、特定のタイプのメッセージをリダイレクトするようにのみ設定できます。プロキシエージェントと同様に、リダイレクトエージェントはセッションやNASリソースに関して状態を保持しません。
Roaming Relationships Roaming relationships include relationships between companies and ISPs, relationships among peer ISPs within a roaming consortium, and relationships between an ISP and a roaming consortium.
ローミング関係ローミング関係には、企業とISP間の関係、ローミングコンソーシアム内のピアISP間の関係、およびISPとローミングコンソーシアム間の関係が含まれます。
Security Association A security association is an association between two endpoints in a Diameter session which allows the endpoints to communicate with integrity and confidentially, even in the presence of relays and/or proxies.
セキュリティアソシエーションセキュリティアソシエーションは、Diameterセッション内の2つのエンドポイント間のアソシエーションであり、リレーやプロキシが存在する場合でも、エンドポイントは完全性と機密性を保って通信できます。
Session A session is a related progression of events devoted to a particular activity. Each application SHOULD provide guidelines as to when a session begins and ends. All Diameter packets with the same Session-Identifier are considered to be part of the same session.
セッションセッションは、特定のアクティビティに特化したイベントの関連する進行です。各アプリケーションは、セッションの開始と終了に関するガイドラインを提供する必要があります（SHOULD）。同じセッションIDを持つすべてのDiameterパケットは、同じセッションの一部と見なされます。
Session state 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 by 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 is a stateful Diameter node that performs protocol translation between Diameter and another AAA protocol, such as RADIUS.
変換エージェント変換エージェントは、DiameterとRADIUSなどの別のAAAプロトコルとの間のプロトコル変換を実行するステートフルDiameterノードです。
Transport Connection A transport connection is a TCP or SCTP connection existing directly between two Diameter peers, otherwise known as a Peer-to-Peer Connection.
トランスポート接続トランスポート接続は、2つのDiameterピア間に直接存在するTCPまたはSCTP接続であり、ピアツーピア接続とも呼ばれます。
Upstream Upstream is used to identify the direction of a particular Diameter message from the access device towards the home server.
アップストリームアップストリームは、アクセスデバイスからホームサーバーへの特定のDiameterメッセージの方向を識別するために使用されます。
User The entity requesting or using some resource, in support of which a Diameter client has generated a request.
ユーザーDiameterクライアントがリクエストを生成したことをサポートするリソースを要求または使用しているエンティティ。
The base Diameter protocol may be used by itself for accounting applications, but for use in authentication and authorization it is always extended for a particular application. Two Diameter applications are defined by companion documents: NASREQ [NASREQ],
基本Diameterプロトコルは、それ自体がアカウンティングアプリケーションに使用できますが、認証と承認に使用する場合は、常に特定のアプリケーションに拡張されます。 2つのDiameterアプリケーションは、関連ドキュメントで定義されています。NASREQ[NASREQ]、
Mobile IPv4 [DIAMMIP]. These applications are introduced in this document but specified elsewhere. Additional Diameter applications MAY be defined in the future (see Section 11.3).
モバイルIPv4 [DIAMMIP]。これらのアプリケーションはこのドキュメントで紹介されていますが、他の場所で指定されています。追加のDiameterアプリケーションが将来定義される可能性があります（セクション11.3を参照）。
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., NASREQ and/or Mobile IPv4. A Diameter Client that does not support both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X Client" where X is the application which it supports, and not a "Diameter Client".
Diameterクライアントは、アカウンティングを含む基本プロトコルをサポートする必要があります。さらに、クライアントのサービスを実装するために必要な各Diameterアプリケーション（NASREQやモバイルIPv4など）を完全にサポートする必要があります。 NASREQとモバイルIPv4の両方をサポートしない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 that does not support both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X Server" where X is the application which it supports, and not a "Diameter Server".
Diameterサーバーは、アカウンティングを含む基本プロトコルをサポートする必要があります。さらに、NASREQやモバイルIPv4などの目的のサービスを実装するために必要な各Diameterアプリケーションを完全にサポートする必要があります。 NASREQとモバイルIPv4の両方をサポートしないDiameterサーバーは、「Diameter Xサーバー」と呼ばなければなりません。Xは、サポートするアプリケーションであり、「Diameterサーバー」ではありません。
Diameter Relays and redirect agents are, by definition, protocol transparent, and MUST transparently support the Diameter base protocol, which includes accounting, and all Diameter applications.
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 which does not support also both NASREQ and Mobile IPv4, 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アプリケーションを完全にサポートする必要があります。 NASREQとモバイルIPv4の両方をサポートしていないDiameterプロキシは、「Diameter Xプロキシ」と呼ばれなければなりません。Xは、「Diameterプロキシ」ではなく、サポートするアプリケーションです。
The base Diameter protocol concerns itself with capabilities negotiation, how messages are sent and how peers may eventually be abandoned. The base protocol also defines certain rules that apply to all exchanges of messages 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. The Session-Id is then used in all subsequent messages to identify the user's session (see Section 8 for 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 an error occurred. The specific behavior of the Diameter server or client receiving a request depends on the Diameter application employed.
ユーザーの認証または承認、あるいはその両方の最初の要求には、Session-Idが含まれます。その後、Session-Idは、後続のすべてのメッセージでユーザーのセッションを識別するために使用されます（詳細については、セクション8を参照してください）。通信する側は要求を受け入れるか、エラーが発生したことを示すために結果コード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で確立されたルールに従って解放する必要があります応用。
Transport profile is defined in [AAATRANS].
トランスポートプロファイルは[AAATRANS]で定義されています。
The base Diameter protocol is run on port 3868 of both TCP [TCP] and SCTP [SCTP] transport protocols.
基本Diameterプロトコルは、TCP [TCP]およびSCTP [SCTP]トランスポートプロトコルの両方のポート3868で実行されます。
Diameter clients MUST support either TCP or SCTP, while agents and servers MUST support both. Future versions of this specification MAY mandate that clients support SCTP.
DiameterクライアントはTCPまたはSCTPのいずれかをサポートする必要がありますが、エージェントとサーバーは両方をサポートする必要があります。この仕様の将来のバージョンでは、クライアントがSCTPをサポートすることが義務付けられる場合があります。
A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and MUST be prepared to receive connections on port 3868. 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ノードは、着信接続の受け入れを宣言したソースポート以外のソースポートから接続を開始する場合があり、ポート3868で接続を受信できるように準備する必要があります。ピアステートマシンの特定のDiameterインスタンスは、複数のトランスポートを使用してはなりません（MUST NOT）ピアに複数のインスタンスが存在しない限り、特定のピアと通信するための接続。この場合、プロセスごとに個別の接続が許可されます。
When no transport connection exists with a peer, an attempt to connect SHOULD be periodically made. This behavior is handled via the Tc timer, 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タイマーを介して処理されます。このルールには特定の例外があります。たとえば、通信したくないとピアがトランスポート接続を終了した場合などです。
When connecting to a peer and either zero or more transports are specified, SCTP SHOULD be tried first, followed by TCP. See Section 5.2 for more information on peer discovery.
ピアに接続していて、0個以上のトランスポートが指定されている場合、最初にSCTP SHOULDを試行し、次にTCPを試行する必要があります。ピア検出の詳細については、セクション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. Diameter implementations SHOULD also be able to interpret a reset from the transport and timed-out connection attempts.
Diameter実装は、ICMPプロトコルポート到達不能メッセージを、そのようなメッセージを信頼することに関するセキュリティポリシーに従って、サーバーに到達できないことを明示的に示すものとして解釈できる必要があります（SHOULD）。 Diameter実装は、トランスポートからのリセットおよびタイムアウトした接続試行を解釈できる必要もあります（SHOULD）。
If Diameter receives data up from TCP 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がTCPからupを受信し、ピアによって作成されたDiameterエラーとして解析または識別できない場合、ストリームは危険にさらされており、回復できません。トランスポート接続は、RESET呼び出し（TCP RSTビットを送信）またはSCTP ABORTメッセージ（正常なクローズが損なわれる）を使用してクローズする必要があります。
The following are guidelines for Diameter implementations that support SCTP:
SCTPをサポートするDiameter実装のガイドラインは次のとおりです。
1. For interoperability: All Diameter nodes MUST be prepared to receive Diameter messages on any SCTP stream in the association.
1. 相互運用性のために：すべてのDiameterノードは、関連付けのSCTPストリームでDiameterメッセージを受信できるように準備する必要があります。
2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP streams available to the association to prevent head-of-the-line blocking.
2. ブロッキングを防止するには：すべてのDiameterノードは、アソシエーションで使用可能なすべてのSCTPストリームを利用して、先頭のブロッキングを防止する必要があります（SHOULD）。
Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS]. Diameter servers MUST support TLS and IPsec. The Diameter protocol MUST NOT be used without any security mechanism (TLS or IPsec).
ネットワークアクセスサーバー（NAS）やモビリティエージェントなどのDiameterクライアントは、IPセキュリティ[SECARCH]をサポートする必要があり、TLS [TLS]をサポートする場合があります。 DiameterサーバーはTLSおよびIPsecをサポートする必要があります。 Diameterプロトコルは、セキュリティメカニズム（TLSまたはIPsec）なしで使用してはなりません（MUST NOT）。
It is suggested that IPsec can be used primarily at the edges and in intra-domain traffic, such as using pre-shared keys between a NAS a local AAA proxy. This also eases the requirements on the NAS to support certificates. It is also suggested that inter-domain traffic would primarily use TLS. See Sections 13.1 and 13.2 for more details on IPsec and TLS usage.
NASとローカルAAAプロキシ間の事前共有キーの使用など、IPsecは主にエッジとドメイン内トラフィックで使用できることが推奨されます。これにより、NASが証明書をサポートするための要件も緩和されます。また、ドメイン間トラフィックは主にTLSを使用することもお勧めします。 IPsecおよびTLSの使用の詳細については、セクション13.1および13.2を参照してください。
Application Identifiers are advertised during the capabilities exchange phase (see Section 5.3). For a given application, advertising support of an application implies that the sender supports all command codes, and the AVPs specified in the associated ABNFs, described in the specification.
アプリケーションIDは、機能交換フェーズ中に通知されます（セクション5.3を参照）。特定のアプリケーションの場合、アプリケーションのアドバタイズサポートは、送信者がすべてのコマンドコード、および仕様に記載されている関連するABNFで指定されたAVPをサポートすることを意味します。
An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs. Please refer to Section 11.1.1 for details.
実装は、ベンダー固有のAVPを含む、アプリケーションで定義されたコマンドに任意の非必須AVPを追加してもよい（MAY）。詳細については、セクション11.1.1を参照してください。
Each Diameter application MUST have an IANA assigned Application Identifier (see Section 11.3). The base protocol does not require an Application Identifier 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 Identifier, which is used in the message forwarding process.
各Diameterアプリケーションには、IANAで割り当てられたアプリケーション識別子が必要です（セクション11.3を参照）。基本プロトコルはサポートが必須であるため、アプリケーション識別子は必要ありません。機能の交換中に、Diameterノードはローカルでサポートされているアプリケーションをピアに通知します。さらに、すべてのDiameterメッセージには、メッセージ転送プロセスで使用されるアプリケーション識別子が含まれています。
The following Application Identifier values are defined:
次のアプリケーション識別子の値が定義されています。
Diameter Common Messages 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameter Base Accounting 3 Relay 0xffffffff
Diameter共通メッセージ0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameterベースアカウンティング3リレー0xffffffff
Relay and redirect agents MUST advertise the Relay Application Identifier, 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.
リレーおよびリダイレクトエージェントは、リレーアプリケーション識別子をアドバタイズする必要がありますが、他のすべての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 is a transport level connection between two peers, used to send and receive Diameter messages. A session is a logical concept at the application layer, and is shared between an access device and a server, and is identified via the Session-Id AVP
接続は、2つのピア間のトランスポートレベルの接続であり、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 its local 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. 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.
図1の例では、クライアントとそのローカルリレーの間にピア接続Aが確立されています。リレーとサーバーの間にピア接続Bが確立されます。ユーザーセッションXは、クライアントからリレーを経由してサーバーに及びます。サービスの「ユーザー」ごとに、一意のセッション識別子を使用して認証リクエストが送信されます。サーバーに受け入れられると、クライアントとサーバーの両方がセッションを認識します。接続とセッションの間に関係はなく、複数のセッションのDiameterメッセージはすべて単一の接続を介して多重化されることに注意することが重要です。
The Diameter Peer Table is used in message forwarding, and referenced by the Realm Routing Table. A Peer Table entry contains the following fields:
Diameterピアテーブルはメッセージ転送で使用され、レルムルーティングテーブルによって参照されます。ピアテーブルエントリには、次のフィールドが含まれます。
Host identity Following the conventions described for the DiameterIdentity derived AVP data format in Section 4.4. This field contains the contents of the Origin-Host (Section 6.3) AVP found in the CER or CEA message.
ホストIDセクション4.4のDiameterIdentity派生AVPデータ形式について説明した規則に従います。このフィールドには、CERまたはCEAメッセージにあるOrigin-Host（セクション6.3）AVPの内容が含まれます。
StatusT This is the state of the peer entry, and MUST match one of the values listed in Section 5.6.
StatusTこれはピアエントリの状態であり、セクション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.
有効期限時刻動的に検出されたピアテーブルエントリが更新されるか、期限切れになる時刻を指定します。
TLS Enabled Specifies whether TLS is to be used when communicating with the peer.
TLS有効ピアとの通信時にTLSを使用するかどうかを指定します。
Additional security information, when needed (e.g., keys, certificates)
必要に応じて、追加のセキュリティ情報（キー、証明書など）
All Realm-Based routing lookups are performed against what is commonly known as the Realm Routing Table (see Section 12). A Realm Routing Table Entry contains the following fields:
すべてのレルムベースのルーティングルックアップは、レルムルーティングテーブルとして一般的に知られているものに対して実行されます（セクション12を参照）。レルムルーティングテーブルエントリには、次のフィールドが含まれます。
Realm Name This is the field that is typically 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 a vendor id and an application id. For all IETF standards track Diameter applications, the vendor id is zero. A route entry can have a different destination based on the application identification AVP of the message. This field MUST be used as a secondary key field in routing table lookups.
アプリケーション識別子アプリケーションは、ベンダーIDとアプリケーションIDによって識別されます。すべてのIETF標準トラックDiameterアプリケーションでは、ベンダーIDはゼロです。ルートエントリは、メッセージのアプリケーション識別AVPに基づいて異なる宛先を持つことができます。このフィールドは、ルーティングテーブルルックアップのセカンダリキーフィールドとして使用する必要があります。
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 resolve to a route entry with the Local Action set to Local can be satisfied locally, and do not need to be routed to another server.
1. LOCAL-ローカルアクションがローカルに設定されているルートエントリに解決されるDiameterメッセージはローカルで満たすことができ、別のサーバーにルーティングする必要はありません。
2. RELAY - All Diameter messages that fall within this category MUST be routed to a next hop server, without modifying any non-routing AVPs. See Section 6.1.8 for relaying guidelines
2. RELAY-このカテゴリに該当するすべてのDiameterメッセージは、非ルーティングAVPを変更せずに、ネクストホップサーバーにルーティングする必要があります。リレーのガイドラインについては、セクション6.1.8を参照してください
3. PROXY - All Diameter messages that fall within this category MUST be routed to a next hop server. 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.8 for proxying guidelines.
3. プロキシ-このカテゴリに該当するすべてのDiameterメッセージは、ネクストホップサーバーにルーティングする必要があります。ローカルサーバーは、ルーティングの前にメッセージに新しいAVPを含めることにより、メッセージにローカルポリシーを適用できます（MAY）。プロキシのガイドラインについては、セクション6.1.8を参照してください。
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.7 for redirect guidelines.
4. REDIRECT-このカテゴリに該当するDiameterメッセージには、ホームDiameterサーバーのIDが追加され、メッセージの送信者に返される必要があります。リダイレクトのガイドラインについては、セクション6.1.7を参照してください。
Server Identifier One or more servers the message is to be routed to. These servers MUST also be present in the Peer table. When the Local Action is set to RELAY or PROXY, this field contains the identity of the server(s) the message must be routed to. When the Local Action field is set to REDIRECT, this field contains the identity of one or more servers the message should be redirected to.
サーバー識別子メッセージがルーティングされる1つ以上のサーバー。これらのサーバーは、ピアテーブルにも存在する必要があります。ローカルアクションがRELAYまたはPROXYに設定されている場合、このフィールドには、メッセージのルーティング先となるサーバーのIDが含まれます。 [ローカルアクション]フィールドが[リダイレクト]に設定されている場合、このフィールドには、メッセージのリダイレクト先となる1つ以上のサーバーのIDが含まれます。
Static or Dynamic Specifies whether a route entry was statically configured, or dynamically discovered.
静的または動的ルートエントリが静的に構成されたか、動的に検出されたかを指定します。
Expiration time Specifies the time which a dynamically discovered route table entry expires.
有効期限動的に検出されたルートテーブルエントリが期限切れになる時間を指定します。
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 MUST follow the protocol compliance guidelines in Section 2. Relay agents MUST NOT reorder AVPs, and proxies MUST NOT reorder AVPs.
Diameterエージェントは、LOCAL、RELAY、PROXY、またはREDIRECTモードの操作の少なくとも1つをサポートする必要があることに注意することが重要です。エージェントはプロトコル仕様に準拠するためにすべての動作モードをサポートする必要はありませんが、セクション2のプロトコルコンプライアンスガイドラインに従う必要があります。リレーエージェントはAVPを並べ替えてはならず、プロキシは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 Identifier (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.
リクエストがルーティングされるとき、ターゲットサーバーは、指定されたメッセージのアプリケーション識別子（セクション2.4を参照）をアドバタイズするか、それ自体をリレーまたはプロキシエージェントとしてアドバタイズしている必要があります。そうでない場合、Result-Code AVPがDIAMETER_UNABLE_TO_DELIVERに設定された状態でエラーが返されます。
In addition to client and servers, the Diameter protocol introduces relay, proxy, redirect, and translation agents, each of which is defined in Section 1.3. These Diameter agents are useful for several reasons:
クライアントとサーバーに加えて、Diameterプロトコルはリレー、プロキシ、リダイレクト、および変換エージェントを導入します。それぞれのエージェントはセクション1.3で定義されています。これらのDiameterエージェントは、いくつかの理由で役立ちます。
- They can distribute administration of systems to a configurable grouping, including the maintenance of security associations.
- 彼らは、セキュリティアソシエーションのメンテナンスなど、システムの管理を構成可能なグループに分散できます。
- They can be used for concentration of requests from an number of co-located or distributed NAS equipment sets to a set of like user groups.
- それらは、多数の同じ場所に配置または分散されたNAS機器セットから、同様のユーザーグループのセットへのリクエストの集中に使用できます。
- They can do value-added processing to the requests or responses.
- 要求または応答に付加価値処理を実行できます。
- They can be used for load balancing.
- ロードバランシングに使用できます。
- A complex network will have multiple authentication sources, they can sort requests and forward towards the correct target.
- 複雑なネットワークには複数の認証ソースがあり、リクエストを並べ替えて正しいターゲットに転送できます。
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 either until it is notified otherwise, or by expiration. 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:
セッション状態の維持は、次のような特定のアプリケーションで役立つ場合があります。
- Protocol translation (e.g., RADIUS <-> Diameter)
- プロトコル変換（例：RADIUS <-> Diameter）
- Limiting resources authorized to a particular user
- 特定のユーザーに許可されたリソースを制限する
- Per user or transaction auditing
- ユーザーまたはトランザクションごとの監査
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., Destination-Realm). This routing decision is performed using a list of supported realms, and known peers. This is known as the Realm Routing Table, as is defined further in Section 2.7.
リレーエージェントは、要求を受け入れ、メッセージ内の情報（宛先レルムなど）に基づいて他のDiameterノードにメッセージをルーティングするDiameterエージェントです。このルーティングの決定は、サポートされているレルムと既知のピアのリストを使用して実行されます。これは、セクション2.7でさらに定義されるように、レルムルーティングテーブルと呼ばれます。
Relays MAY be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (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.
リレーは、共通の地理的領域（POP）内の複数のネットワークアクセスサーバー（NAS）からの要求を集約するために使用できます（MAY）。リレーを使用すると、他のレルムのDiameterサーバーと通信するために必要な必要なセキュリティ情報をNASに構成する必要がなくなるため、利点があります。同様に、これにより、NASが追加、変更、または削除されたときに必要となる、Diameterサーバーの構成負荷が軽減されます。
Relays modify Diameter messages by inserting and removing routing information, but 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 NAS, which is an access device, for the user bob@example.com. Prior to issuing the request, NAS performs a Diameter route lookup, using "example.com" as the key, and determines that the message is to be relayed to DRL, which is a Diameter Relay. DRL performs the same route lookup as NAS, and relays the message to HMS, which is example.com's Home Diameter Server. 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 NAS using saved transaction state.
図2の例は、アクセスデバイスであるNASからユーザーbob@example.comに対して発行されたリクエストを示しています。リクエストを発行する前に、NASは「example.com」をキーとして使用してDiameterルートルックアップを実行し、メッセージがDiameterリレーであるDRLにリレーされることを決定します。 DRLはNASと同じルートルックアップを実行し、example.comのHome DiameterサーバーであるHMSにメッセージをリレーします。 HMSは、要求がローカルで（レルムを介して）サポートできることを識別し、認証および/または許可要求を処理し、保存されたトランザクション状態を使用してNASにルーティングされる応答を返します。
Since Relays do not perform any application level processing, they provide relaying services for all Diameter applications, and therefore MUST advertise the Relay Application Identifier.
リレーはアプリケーションレベルの処理を実行しないため、すべてのDiameterアプリケーションにリレーサービスを提供するため、リレーアプリケーション識別子を通知する必要があります。
Similarly 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 provisioning.
リレーと同様に、プロキシエージェントはDiameterルーティングテーブルを使用してDiameterメッセージをルーティングします。ただし、ポリシー適用を実装するためにメッセージを変更するため、両者は異なります。これには、リソースの使用を強制し、アドミッションコントロールとプロビジョニングを提供するために、プロキシがダウンストリームピア（アクセスデバイスなど）の状態を維持する必要があります。
It is important to note that although proxies MAY provide a value-add function for NASes, they do not allow access devices to use end-to-end security, since modifying messages breaks authentication.
プロキシはNASに付加価値機能を提供する場合がありますが、メッセージを変更すると認証が失敗するため、アクセスデバイスでエンドツーエンドのセキュリティを使用できないことに注意することが重要です。
Proxies MAY be used in call control centers or access ISPs that provide outsourced connections, they can monitor the number and types of ports in use, and make allocation and admission decisions according to their configuration.
プロキシは、アウトソース接続を提供するコールコントロールセンターまたはアクセスISPで使用される場合があり、使用中のポートの数とタイプを監視し、構成に応じて割り当てとアドミッションの決定を行うことができます。
Proxies that wish to limit resources MUST maintain session state. All proxies MUST maintain transaction state.
リソースを制限するプロキシは、セッション状態を維持する必要があります。すべてのプロキシはトランザクションの状態を維持する必要があります。
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. Further, since redirect agents never relay requests, they are not required to maintain transaction 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. DRL has a default route configured to DRD, which is a redirect agent that returns a redirect notification to DRL, as well as HMS' contact information. Upon receipt of the redirect notification, DRL establishes a transport connection with 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にリダイレクト通知を返すリダイレクトエージェントであるDRDに設定されたデフォルトルートと、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, and therefore MUST advertise the Relay Application Identifier.
リダイレクトエージェントはアプリケーションレベルの処理を実行しないため、すべてのDiameterアプリケーションにリレーサービスを提供するため、リレーアプリケーション識別子を通知する必要があります。
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, and therefore translation agents MUST only advertise their locally supported applications.
メッセージの翻訳は、エージェントが特定のリクエストのアプリケーションを認識する場合にのみ発生する可能性があるため、翻訳エージェントはローカルでサポートされているアプリケーションのみをアドバタイズしなければなりません（MUST）。
+------+ ---------> +------+ ---------> +------+
| | 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への変換
End-to-end security services include confidentiality and message origin authentication. These services are provided by supporting AVP integrity and confidentiality between two peers, communicating through agents.
エンドツーエンドのセキュリティサービスには、機密性とメッセージ発信元認証が含まれます。これらのサービスは、エージェントを介して通信する2つのピア間のAVPの整合性と機密性をサポートすることで提供されます。
End-to-end security is provided via the End-to-End security extension, described in [AAACMS]. The circumstances requiring the use of end-to-end security are determined by policy on each of the peers. Security policies, which are not the subject of standardization, may be applied by next hop Diameter peer or by destination realm. For example, where TLS or IPsec transmission-level security is sufficient, there may be no need for end-to-end security.
エンドツーエンドのセキュリティは、[AAACMS]で説明されているエンドツーエンドのセキュリティ拡張機能を介して提供されます。エンドツーエンドのセキュリティを使用する必要がある状況は、各ピアのポリシーによって決定されます。標準化の対象ではないセキュリティポリシーは、ネクストホップのDiameterピアまたは宛先レルムによって適用できます。たとえば、TLSまたはIPsecの伝送レベルのセキュリティで十分な場合、エンドツーエンドのセキュリティは不要です。
End-to-end security policies include:
エンドツーエンドのセキュリティポリシーは次のとおりです。
- Never use end-to-end security.
- エンドツーエンドのセキュリティを使用しないでください。
- Use end-to-end security on messages containing sensitive AVPs. Which AVPs are sensitive is determined by service provider policy. AVPs containing keys and passwords should be considered sensitive. Accounting AVPs may be considered sensitive. Any AVP for which the P bit may be set or which may be encrypted may be considered sensitive.
- 機密性の高いAVPを含むメッセージにエンドツーエンドのセキュリティを使用します。機密性の高いAVPは、サービスプロバイダーのポリシーによって決定されます。キーとパスワードを含むAVPは機密情報と見なされます。会計AVPは機密と見なされる場合があります。 Pビットが設定されている、または暗号化されているAVPは、機密情報と見なされます。
- Always use end-to-end security.
- 常にエンドツーエンドのセキュリティを使用します。
It is strongly RECOMMENDED that all Diameter implementations support end-to-end security.
すべてのDiameter実装がエンドツーエンドのセキュリティをサポートすることを強くお勧めします。
As noted in Section 2.2, Diameter requires transmission level security to be used on each connection (TLS or IPsec). Therefore, each connection is authenticated, replay and integrity protected and confidential on a per-packet basis.
セクション2.2で述べたように、Diameterは各接続（TLSまたはIPsec）で使用される伝送レベルのセキュリティを必要とします。したがって、各接続は認証され、再生および整合性が保護され、パケットごとに機密性が保たれます。
In addition to authenticating each connection, each connection as well as 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.8, a relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer the request was received from.
セクション6.1.8で述べたように、リレーまたはプロキシエージェントは、転送されるすべてのリクエストにルートレコード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 the 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応答に対応することを確認することもできます。対応する承認応答のないアカウンティング要求は、要求されたサービスと提供されたサービスの違いを示すアカウンティング要求と同様に、さらに精査される必要があります。
Similarly, the local Diameter agent, on receiving a Diameter response authorizing a session, MUST check the Route-Record AVPs to make sure that the route traversed by the response is acceptable. At each step, 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 which 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エージェントは、セッションを承認するDiameter応答を受信すると、ルートレコードAVPをチェックして、応答が通過するルートが受け入れ可能であることを確認する必要があります。各ステップで、承認応答の転送は、セッションに関連して財務リスクを引き受ける意欲の証拠と見なされます。ローカルレルムは、たとえば、中間レルムのクレジット制限を確立し、それらの制限に違反する応答を受け入れることを拒否することによって、このエクスポージャーを制限することを望む場合があります。許可応答に対応するアカウンティング要求を発行することにより、ローカルレルムは、許可応答で示されたサービスを提供することへの同意を暗黙的に示します。ローカルレルムでサービスを提供できない場合は、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.
メッセージ長メッセージ長フィールドは3オクテットで、ヘッダーフィールドを含むDiameterメッセージの長さを示します。
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) - 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 ABNF 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. T(Potentially re-transmitted message) - 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 is sent again. This flag MUST NOT be set in answer messages.
R（equest）-設定されている場合、メッセージは要求です。クリアされている場合、メッセージは回答です。 P（roxiable）-設定されている場合、メッセージはプロキシ、リレー、またはリダイレクトされる場合があります。クリアした場合、メッセージはローカルで処理する必要があります。 E（rror）-設定されている場合、メッセージにはプロトコルエラーが含まれ、メッセージはこのコマンドで説明されているABNFに準拠しません。 「E」ビットが設定されたメッセージは、一般にエラーメッセージと呼ばれます。このビットは要求メッセージで設定してはいけません。セクション7.2を参照してください。 T（潜在的に再送信されたメッセージ）-このフラグは、リンクフェイルオーバー手順の後に設定され、重複する要求の削除を支援します。これは、まだ確認されていない要求を再送信するときに設定されます。これは、リンク障害による重複の可能性を示しています。このビットは、リクエストを初めて送信するときにクリアする必要があります。それ以外の場合、送信者はこのフラグを設定する必要があります。 Diameterエージェントは、受信した単一の要求に基づいて送信する要求の数を考慮するだけで済みます。他のエンティティによる再送信を追跡する必要はありません。 Tフラグが設定されたリクエストを受信するDiameterエージェントは、転送されたリクエストでTフラグが設定された状態を維持する必要があります。以前のメッセージに対してエラー応答メッセージ（プロトコルエラーなど）が受信された場合、このフラグを設定してはなりません（MUST NOT）。これは、サーバーから要求に対する応答を受信しておらず、要求が再送信された場合にのみ設定できます。このフラグは、応答メッセージで設定してはなりません（MUST NOT）。
r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver.
r（eserved）-これらのフラグビットは将来の使用のために予約されており、ゼロに設定する必要があり、受信側によって無視される必要があります。
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 11.2.1).
Command-Code Command-Codeフィールドは3オクテットであり、メッセージに関連付けられたコマンドを伝達するために使用されます。 24ビットのアドレス空間はIANAによって管理されます（セクション11.2.1を参照）。
Command-Code values 16,777,214 and 16,777,215 (hexadecimal values FFFFFE -FFFFFF) are reserved for experimental use (See Section 11.3).
コマンドコード値16,777,214および16,777,215（16進値FFFFFE -FFFFFF）は実験用に予約されています（セクション11.3を参照）。
Application-ID Application-ID is four octets and is used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application. See Section 11.3 for the possible values that the application-id may use.
Application-ID Application-IDは4オクテットであり、メッセージが適用されるアプリケーションを識別するために使用されます。アプリケーションは、認証アプリケーション、会計アプリケーション、またはベンダー固有のアプリケーションです。 application-idが使用する可能性のある値については、セクション11.3を参照してください。
The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message.
ヘッダーのapplication-idは、メッセージに含まれる関連するAVPに含まれているものと同じである必要があります。
Hop-by-Hop Identifier The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) and 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 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ビット整数フィールドであり、要求と応答の照合に役立ちます。送信者は、リクエスト内のホップバイホップ識別子が特定の接続で常に一意であることを確認する必要があり、再起動全体で番号が一意であることを確認しようとする場合があります。 Answerメッセージの送信者は、Hop-by-Hop Identifierフィールドに、対応するリクエストで見つかったのと同じ値が含まれていることを確認する必要があります。ホップバイホップ識別子は通常、単調に増加する数値であり、その開始値はランダムに生成されました。不明なホップバイホップ識別子を使用して受信した応答メッセージは破棄する必要があります。
End-to-End Identifier The End-to-End Identifier is an unsigned 32-bit integer field (in network byte order) and 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 (see 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 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分間はローカルで一意である必要があります。 Answerメッセージの発信者は、End-to-End Identifierフィールドに、対応するリクエストで見つかったのと同じ値が含まれていることを確認する必要があります。エンドツーエンド識別子は、いかなる種類のDiameterエージェントによっても変更してはなりません。 Origin-Host（セクション6.3を参照）とこのフィールドの組み合わせは、重複を検出するために使用されます。重複したリクエストは同じ応答を送信する必要があり（SHOULD）、ホップバイホップの識別子フィールドと存在するルーティングAVPを法として）、元のリクエストが処理されたときに設定された状態に影響を与えてはなりません（MUST NOT）。ローカルで消費される重複した応答メッセージ（セクション6.2を参照）は、通知なく破棄されるべきです（SHOULD）。
AVPs AVPs are a method of encapsulating information relevant to the Diameter message. See Section 4 for more information on AVPs.
AVP 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メッセージには、ヘッダーのCommand-Codeフィールドにコマンドコードが含まれている必要があります。これは、特定のメッセージに対して実行するアクションを決定するために使用されます。次のコマンドコードは、Diameter基本プロトコルで定義されています。
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 ABNF specification, which is used to define the AVPs that MUST or MAY be present. The following format is used in the definition:
定義されているすべてのコマンドコードには、対応するABNF仕様を含める必要があります。これは、存在する必要があるまたは存在する可能性のあるAVPを定義するために使用されます。定義では次の形式が使用されます。
command-def = command-name "::=" diameter-message
command-name = diameter-name
diameter-name = ALPHA *(ALPHA / DIGIT / "-")
diameter-message = header [ *fixed] [ *required] [ *optional]
[ *fixed]
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 which is included
; in a fixed or required rule. The AVP can
; appear anywhere in the message.
qual = [min] "*" [max]
; See ABNF conventions, RFC 2234 Section 6.6.
; The absence of any qualifiers 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.
;
; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above).
; 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'.
min = 1*DIGIT
; The minimum number of times the element may
; be present. The default value is zero.
max = 1*DIGIT
; The maximum number of times the element may
; be present. The default value is infinity. A
; value of zero 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, which does not conflict with the
; required or fixed position AVPs defined in
; the command code definition.
The following is a definition of a fictitious command code:
以下は、架空のコマンドコードの定義です。
Example-Request ::= < "Diameter-Header: 9999999, REQ, PXY >
{ User-Name }
* { 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に設定されていることで識別され、ユーザーの承認やセッションの終了など、特定のアクションの実行を要求します。受信側が要求を完了すると、対応する応答が発行されます。これには、次のいずれかを伝える結果コードが含まれます。
- The request was successful
- リクエストは成功しました
- The request failed
- リクエストは失敗しました
- An additional request must be sent to provide information the peer requires prior to returning a successful or failed answer.
- 成功または失敗した回答を返す前に、ピアが必要とする情報を提供するために、追加のリクエストを送信する必要があります。
- The receiver could not process the request, but provides information about a Diameter peer that is able to satisfy the request, known as redirect.
- 受信側は要求を処理できませんでしたが、リダイレクトと呼ばれる、要求を満たすことができるDiameterピアに関する情報を提供します。
Additional information, encoded within AVPs, MAY also be included in answer messages.
AVP内でエンコードされた追加情報も、応答メッセージに含めることができます。
Diameter AVPs carry specific authentication, accounting, authorization, routing and security information as well as configuration details for the request and reply.
Diameter AVPは、特定の認証、アカウンティング、許可、ルーティング、セキュリティ情報、および要求と応答の構成の詳細を伝達します。
Some AVPs MAY be listed more than once. The effect of such an AVP is specific, and is specified in each case by the AVP description.
一部のAVPは複数回リストされる場合があります。このようなAVPの効果は固有であり、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 till 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 The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA (see Section 11.1).
AVPコードAVPコードは、Vendor-Idフィールドと組み合わせて、属性を一意に識別します。 AVP番号1〜255は、Vendor-Idフィールドを設定せずに、RADIUSとの下位互換性のために予約されています。 Diameterには、AANAによって割り当てられたAVP番号256以上が使用されます（セクション11.1を参照）。
AVP Flags The AVP Flags field informs the receiver how each attribute must be handled. The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. The 'P' bit indicates the need for encryption for end-to-end security.
AVPフラグAVPフラグフィールドは、各属性の処理方法を受信者に通知します。 'r'（予約済み）ビットは未使用であり、0に設定する必要があります。後続のDiameterアプリケーションは、AVPヘッダー内で追加のビットを定義できます（MAY）。認識されないビットはエラーと見なされるべきです（SHOULD）。 「P」ビットは、エンドツーエンドのセキュリティのための暗号化の必要性を示します。
The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized AVPs.
必須ビットと呼ばれる「M」ビットは、AVPのサポートが必要かどうかを示します。 「M」ビットが設定されたAVPがDiameterクライアント、サーバー、プロキシ、または変換エージェントによって受信され、AVPまたはその値のいずれかが認識されない場合、メッセージは拒否される必要があります。 Diameterリレーおよびリダイレクトエージェントは、認識されないAVPを含むメッセージを拒否してはなりません（MUST NOT）。
The 'M' bit MUST be set according to the rules defined for the AVP containing it. In order to preserve interoperability, a Diameter implementation MUST be able to exclude from a Diameter message any Mandatory AVP which is neither defined in the base Diameter protocol nor in any of the Diameter Application specifications governing the message in which it appears. It MAY do this in one of the following ways:
「M」ビットは、それを含むAVPに定義された規則に従って設定する必要があります。相互運用性を維持するために、Diameter実装は、Diameterメッセージから、基本Diameterプロトコルでも、それが表示されるメッセージを管理するDiameterアプリケーション仕様でも定義されていない必須AVPを除外できる必要があります。次のいずれかの方法でこれを行う場合があります。
1) If a message is rejected because it contains a Mandatory AVP which is neither defined in the base Diameter standard nor in any of the Diameter Application specifications governing the message in which it appears, the implementation may resend the message without the AVP, possibly inserting additional standard AVPs instead.
1）メッセージが、ベースのDiameter標準にも、メッセージが表示されるメッセージを管理するDiameterアプリケーション仕様にも定義されていない必須のAVPが含まれているために拒否された場合、実装はAVPなしでメッセージを再送信し、場合によっては挿入します。代わりに追加の標準AVP。
2) A configuration option may be provided on a system wide, per peer, or per realm basis that would allow/prevent particular Mandatory AVPs to be sent. Thus an administrator could change the configuration to avoid interoperability problems.
2）構成オプションは、特定の必須AVPの送信を許可/防止するシステム全体、ピアごと、またはレルムごとに提供できます。したがって、管理者は相互運用性の問題を回避するために構成を変更できます。
Diameter implementations are required to support all Mandatory AVPs which are allowed by the message's formal syntax and defined either in the base Diameter standard or in one of the Diameter Application specifications governing the message.
Diameterの実装は、メッセージの正式な構文で許可され、基本のDiameter標準またはメッセージを管理するDiameterアプリケーション仕様のいずれかで定義されているすべての必須AVPをサポートするために必要です。
AVPs with the 'M' bit cleared are informational only and 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コードは特定のベンダーコードアドレス空間に属します。
Unless otherwise noted, AVPs will have the following default AVP Flags field settings:
特に明記しない限り、AVPには次のデフォルトのAVPフラグフィールド設定があります。
The 'M' bit MUST be set. The 'V' bit MUST NOT be set.
「M」ビットを設定する必要があります。 「V」ビットを設定してはなりません。
AVP Length The AVP Length field is three octets, and indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if present) and the AVP data. If a message is received with an invalid attribute length, the message SHOULD be rejected.
AVP長さAVP長さフィールドは3オクテットであり、AVPコード、AVP長さ、AVPフラグ、ベンダーIDフィールド（存在する場合）、およびAVPデータを含む、このAVPのオクテット数を示します。無効な属性長でメッセージを受信した場合、メッセージは拒否されるべきです（SHOULD）。
The AVP Header contains one optional field. This field is only present if the respective bit-flag is enabled.
AVPヘッダーには、オプションのフィールドが1つ含まれています。このフィールドは、それぞれのビットフラグが有効な場合にのみ存在します。
Vendor-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" [ASSIGNNO] value, encoded in network byte order. Any vendor 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), nor with future IETF applications.
ベンダーIDベンダーIDフィールドは、「V」ビットがAVPフラグフィールドに設定されている場合に存在します。オプションの4オクテットのベンダーIDフィールドには、IANAが割り当てた「SMIネットワーク管理プライベートエンタープライズコード」[ASSIGNNO]値が含まれ、ネットワークバイトオーダーでエンコードされます。ベンダー固有のDiameter AVPの実装を希望するベンダーは、プライベートに管理されたAVPアドレススペースとともに独自のベンダーIDを使用し、他のベンダーのベンダー固有のAVPや将来のIETFアプリケーションと衝突しないことを保証する必要があります。 。
A vendor ID value of zero (0) corresponds to the IETF adopted AVP values, as managed by the IANA. Since the absence of the vendor ID field implies that the AVP in question is not vendor specific, implementations MUST NOT use the zero (0) vendor ID.
ゼロ（0）のベンダーID値は、IANAによって管理されるIETF採用AVP値に対応します。ベンダーIDフィールドがないことは、問題のAVPがベンダー固有ではないことを意味するため、実装はゼロ（0）ベンダーIDを使用してはなりません（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 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 four-octets in length is followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary.
OctetStringデータには、可変長の任意のデータが含まれます。特に明記しない限り、AVP長さフィールドは少なくとも8（「V」ビットが有効な場合は12）に設定する必要があります。長さが4オクテットの倍数ではないこのタイプのAVP値の後に、次のAVP（存在する場合）が32ビット境界で開始するように、必要なパディングが続きます。
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).
Integer32 32ビットの符号付き値、ネットワークバイト順。 AVP長さフィールドは12に設定する必要があります（ 'V'ビットが有効な場合は16）。
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).
Integer64 64ビット符号付き値、ネットワークバイト順。 AVP長さフィールドは16に設定する必要があります（「V」ビットが有効な場合は20）。
Unsigned32 32 bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled).
Unsigned32 32ビットの符号なし値、ネットワークバイト順。 AVP長さフィールドは12に設定する必要があります（ 'V'ビットが有効な場合は16）。
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).
Unsigned64 64ビットの符号なし値、ネットワークバイト順。 AVP長さフィールドは16に設定する必要があります（「V」ビットが有効な場合は20）。
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).
Float32これは、[FLOATPOINT]で記述されている単精度の浮動小数点値を表します。 32ビット値は、ネットワークバイトオーダーで送信されます。 AVP長さフィールドは12に設定する必要があります（ 'V'ビットが有効な場合は16）。
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).
Float64 [FLOATPOINT]で説明されているように、これは倍精度の浮動小数点値を表します。 64ビット値は、ネットワークバイトオーダーで送信されます。 AVP長さフィールドは16に設定する必要があります（「V」ビットが有効な場合は20）。
Grouped The Data field is specified as a sequence of AVPs. Each of these AVPs follows - in the order in which they are specified - including their headers and padding. 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長フィールドは常に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 AVP Derived Data Formats MUST include them in a section entitled "AVP Derived 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 below AVP Derived Data Formats are commonly used by applications.
以下のAVP派生データ形式は、アプリケーションで一般的に使用されます。
Address The Address format is derived from the OctetString AVP Base Format. It is a discriminated union, representing, for example a 32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most significant octet first. The first two octets of the Address AVP represents 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 AVP基本形式から派生しています。これは、たとえば32ビット（IPv4）[IPV4]または128ビット（IPv6）[IPV6]アドレスを表す、最も重要なオクテットを最初に表す、区別されたユニオンです。アドレスAVPの最初の2つのオクテットは、[IANAADFAM]で定義されたアドレスファミリを含むAddressTypeを表します。 AddressTypeは、残りのオクテットの内容と形式を区別するために使用されます。
Time The Time format is derived from the OctetString AVP Base 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 chapter 3 of [SNTP].
Time Time形式はOctetString AVP Base Formatから派生しています。文字列には、最初の4バイトがNTPタイムスタンプ形式であるのと同じ形式で、4つのオクテットを含める必要があります。 NTPタイムスタンプ形式は、[SNTP]の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. SNTP [SNTP] 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では、時間値がオーバーフローします。 SNTP [SNTP]は、時間を2104に延長する手順を示しています。この手順は、すべてのDIAMETERノードでサポートされている必要があります。
UTF8String The UTF8String format is derived from the OctetString AVP Base 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 [UFT8] transformation format described in RFC 2279.
UTF8String UTF8String形式は、OctetString AVP Base Formatから派生しています。これは、ISO / IEC IS 10646-1文字セットを使用して表され、RFC 2279で説明されているUTF-8 [UFT8]変換形式を使用して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 an 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 The DiameterIdentity format is derived from the OctetString AVP Base Format.
DiameterIdentity DiameterIdentity形式は、OctetString AVP基本形式から派生しています。
DiameterIdentity = FQDN
DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection and routing loop detection.
DiameterIdentity値は、重複した接続とルーティングループの検出のために、Diameterノードを一意に識別するために使用されます。
The contents of the string MUST be the 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 it is sent on.
文字列の内容は、DiameterノードのFQDNである必要があります。同じホスト上で複数のDiameterノードが実行されている場合、各Diameterノードには一意のDiameterIdentityを割り当てる必要があります。 Diameterノードを複数のFQDNで識別できる場合は、起動時に単一のFQDNを選択し、送信先の接続が何であれ、そのノードの唯一のDiameterIdentityとして使用する必要があります。
DiameterURI
ぢ編めてるり
The DiameterURI MUST follow the Uniform Resource Identifiers (URI) syntax [URI] rules specified below:
DiameterURIは、以下に指定するURI（Uniform Resource Identifiers）構文[URI]の規則に従う必要があります。
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
; No transport security
;輸送セキュリティなし
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transport security used
;使用されるトランスポートセキュリティ
FQDN = Fully Qualified Host Name
port = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections.
; If absent,
; the default Diameter port (3868) is
; assumed.
transport = ";transport=" transport-protocol
; One of the transports used to listen
; for incoming connections. If absent,
; the default SCTP [SCTP] protocol is
; assumed. 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 Enumerated is derived from the Integer32 AVP Base Format. The definition contains a list of valid values and their interpretation and is described in the Diameter application introducing the AVP.
Enumerated Enumeratedは、Integer32 AVP Base Formatから派生しています。定義には有効な値とその解釈のリストが含まれ、AVPを導入するDiameterアプリケーションで説明されています。
IPFilterRule The IPFilterRule format is derived from the OctetString AVP Base Format. It uses the ASCII charset. Packets may be filtered based on the following information that is associated with it:
IPFilterRule IPFilterRule形式は、OctetString AVP基本形式から派生しています。 ASCII文字セットを使用します。パケットは、それに関連付けられている次の情報に基づいてフィルタリングできます。
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. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.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"
<address / mask>は次のように指定できます。ipnoドット付きクワッド形式または正規のIPv6形式のIPv4またはIPv6番号。この正確なIP番号のみがルールに一致します。 ipno / bitsマスク幅が1.2.3.4/24の上記のIP番号。この場合、1.2.3.0から1.2.3.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:
icmptypesは、ICMPパケットのみをタイプします。 ICMPタイプがリストタイプにある場合に一致します。リストは、範囲の任意の組み合わせ、またはコンマで区切られた個々のタイプとして指定できます。以下の数値と記号値の両方を使用できます。サポートされるICMPタイプは次のとおりです。
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).
エコー応答（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 rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations.
ルールの構文はFreeBSDのipfw（8）の修正サブセットであり、ipfw.cコードは実装に役立つベースを提供するかもしれません。
QoSFilterRule The QosFilterRule format is derived from the OctetString AVP Base Format. It uses the ASCII charset. Packets may be marked or metered based on the following information that is associated with it:
QoSFilterRule QosFilterRule形式は、OctetString AVP基本形式から派生しています。 ASCII文字セットを使用します。パケットは、それに関連付けられている次の情報に基づいてマークまたは測定される場合があります。
Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) DSCP values (no mask or range)
方向（インまたはアウト）送信元および宛先IPアドレス（マスクされる可能性があります）プロトコル送信元および宛先ポート（リストまたは範囲）DSCP値（マスクまたは範囲なし）
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 treated as best effort. An access device that is unable to interpret or apply a QoS rule SHOULD NOT terminate the session.
適切な方向のルールが順番に評価され、最初に一致したルールが評価を終了します。各パケットは一度評価されます。一致するルールがない場合、パケットはベストエフォートとして扱われます。 QoSルールを解釈または適用できないアクセスデバイスは、セッションを終了しないでください。
QoSFilterRule filters MUST follow the format:
QoSFilterRuleフィルターは次の形式に従う必要があります。
action dir proto from src to dst [options]
action dir proto srcからdst [オプション]
tag - Mark packet with a specific DSCP [DIFFSERV]. The DSCP option MUST be included. meter - Meter traffic. The metering options MUST be included.
tag-特定のDSCP [DIFFSERV]でパケットをマークします。 DSCPオプションを含める必要があります。 meter-メーターのトラフィック。計測オプションを含める必要があります。
dir The format is as described under IPFilterRule.
形式は、IPFilterルールで説明したとおりです。
proto The format is as described under IPFilterRule.
proto形式はIPFilterRuleで説明したとおりです。
src and dst The format is as described under IPFilterRule.
srcおよびdst形式はIPFilterRuleで説明したとおりです。
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.
Diameterプロトコルでは、「グループ化」タイプのAVP値を使用できます。これは、データフィールドが実際にはAVPのシーケンスであることを意味します。 Groupedタイプの中にAVPをGroupedタイプに含めることができます。つまり、それらをネストすることができます。セクション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. Further, if any of the AVPs encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, the Grouped AVP itself MUST also include the 'M' bit set.
グループ化されたAVPに含まれるすべてのAVPのAVPコード番号付けスペースは、グループ化されていないAVPの場合と同じです。さらに、グループ化されたAVP内にカプセル化されたAVPのいずれかに「M」（必須）ビットセットがある場合、グループ化されたAVP自体にも「M」ビットセットが含まれている必要があります。
Every Grouped AVP defined MUST include a corresponding grammar, using ABNF [ABNF] (with modifications), as defined below.
定義されたすべてのグループ化されたAVPには、以下に定義されているように、ABNF [ABNF]（変更あり）を使用して、対応する文法を含める必要があります。
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]
[ *fixed]
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 ABNF grammar:
Example-AVP（AVPコード999999）はGroupedタイプであり、Grouped AVP値の機能を明確にするために使用されます。 Grouped Dataフィールドには、次のABNF文法があります。
Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ]
An Example-AVP with Grouped Data follows.
グループ化されたデータを使用したAVPの例を次に示します。
The Origin-Host AVP is required (Section 6.3). 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 hex since the format of these AVPs is neither 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 which 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 which the receiver cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record AVPs).
オプションのAVPのデータは16進数で表されます。これらのAVPの形式は、例AVPグループの定義時には不明であり、このAVPの例のインスタンスが解釈される時点でも（おそらく）不明であるためです。同じAVPセットをサポートするDiameter実装。エンコードの例は、パディングの使用方法と長さフィールドの計算方法を示しています。また、AVPが受信者が解釈できないグループ化されたAVP値に存在する可能性があることにも注意してください（ここでは、Recover-PolicyおよびFuturistic-Acct-Record 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 = 468 |
+-------+-------+-------+-------+-------+-------+-------+-------+
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 = 50 | 'g' | 'r' | 'u' | 'm' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
72 | Session-Id AVP Header (AVP Code = 263), Length = 51 |
+-------+-------+-------+-------+-------+-------+-------+-------+
80 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
112 | Recovery-Policy Header (AVP Code = 8341), Length = 223 |
+-------+-------+-------+-------+-------+-------+-------+-------+
120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137|
+-------+-------+-------+-------+-------+-------+-------+-------+
336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
464 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+
The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. For the originator of a Diameter message, "Encr" (Encryption) means that if a message containing that AVP is to be sent via a Diameter agent (proxy, redirect or relay) then the message MUST NOT be sent unless there is end-to-end security between the originator and the recipient and integrity / confidentiality protection is offered for this AVP OR the originator has locally trusted configuration that indicates that end-to-end security is not needed. Similarly, for the originator of a Diameter message, a "P" in the "MAY" column means that if a message containing that AVP is to be sent via a Diameter agent (proxy, redirect or relay) then the message MUST NOT be sent unless there is end-to-end security between the originator and the recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed.
次の表は、基本プロトコルで定義されているDiameter AVP、それらのAVPコード値、タイプ、可能なフラグ値、およびAVPを暗号化できるかどうかを示しています。 Diameterメッセージの発信者の場合、 "Encr"（暗号化）は、そのAVPを含むメッセージがDiameterエージェント（プロキシ、リダイレクト、またはリレー）を介して送信される場合、エンドツーエンドがない限り、メッセージを送信してはならないことを意味します。 -発信者と受信者の間のエンドセキュリティと整合性/機密性保護がこのAVPに提供されている、または発信者がローカルで信頼された構成であり、エンドツーエンドのセキュリティが不要であることを示している同様に、Diameterメッセージの発信者の場合、「MAY」列の「P」は、そのAVPを含むメッセージがDiameterエージェント（プロキシ、リダイレクト、またはリレー）経由で送信される場合、メッセージを送信してはならないことを意味します発信者と受信者の間にエンドツーエンドのセキュリティがない場合、または発信者がエンドツーエンドのセキュリティが不要であることを示すローカルで信頼された構成がない限り。
Due to space constraints, the short form DiamIdent is used to represent DiameterIdentity.
スペースの制約により、DiamIdentityを表すために短い形式のDiamIdentが使用されています。
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST| |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Acct- 85 9.8.2 Unsigned32 | M | P | | V | Y |
Interim-Interval | | | | | |
Accounting- 483 9.8.7 Enumerated | M | P | | V | Y |
Realtime-Required | | | | | |
Acct- 50 9.8.5 UTF8String | M | P | | V | Y |
Multi-Session-Id | | | | | |
Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y |
Record-Number | | | | | |
Accounting- 480 9.8.1 Enumerated | M | P | | V | Y |
Record-Type | | | | | |
Accounting- 44 9.8.4 OctetString| M | P | | V | Y |
Session-Id | | | | | |
Accounting- 287 9.8.6 Unsigned64 | M | P | | V | Y |
Sub-Session-Id | | | | | |
Acct- 259 6.9 Unsigned32 | M | P | | V | N |
Application-Id | | | | | |
Auth- 258 6.8 Unsigned32 | M | P | | V | N |
Application-Id | | | | | |
Auth-Request- 274 8.7 Enumerated | M | P | | V | N |
Type | | | | | |
Authorization- 291 8.9 Unsigned32 | M | P | | V | N |
Lifetime | | | | | |
Auth-Grace- 276 8.10 Unsigned32 | M | P | | V | N |
Period | | | | | |
Auth-Session- 277 8.11 Enumerated | M | P | | V | N |
State | | | | | |
Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N |
Type | | | | | |
Class 25 8.20 OctetString| M | P | | V | Y |
Destination-Host 293 6.5 DiamIdent | M | P | | V | N |
Destination- 283 6.6 DiamIdent | M | P | | V | N |
Realm | | | | | |
Disconnect-Cause 273 5.4.3 Enumerated | M | P | | V | N |
E2E-Sequence AVP 300 6.15 Grouped | M | P | | V | Y |
Error-Message 281 7.3 UTF8String | | P | | V,M | N |
Error-Reporting- 294 7.4 DiamIdent | | P | | V,M | N |
Host | | | | | |
Event-Timestamp 55 8.21 Time | M | P | | V | N |
Experimental- 297 7.6 Grouped | M | P | | V | N |
Result | | | | | |
-----------------------------------------|----+-----+----+-----|----|
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Experimental- 298 7.7 Unsigned32 | M | P | | V | N |
Result-Code | | | | | |
Failed-AVP 279 7.5 Grouped | M | P | | V | N |
Firmware- 267 5.3.4 Unsigned32 | | | |P,V,M| N |
Revision | | | | | |
Host-IP-Address 257 5.3.5 Address | M | P | | V | N |
Inband-Security | M | P | | V | N |
-Id 299 6.10 Unsigned32 | | | | | |
Multi-Round- 272 8.19 Unsigned32 | M | P | | V | Y |
Time-Out | | | | | |
Origin-Host 264 6.3 DiamIdent | M | P | | V | N |
Origin-Realm 296 6.4 DiamIdent | M | P | | V | N |
Origin-State-Id 278 8.16 Unsigned32 | M | P | | V | N |
Product-Name 269 5.3.7 UTF8String | | | |P,V,M| N |
Proxy-Host 280 6.7.3 DiamIdent | M | | | P,V | N |
Proxy-Info 284 6.7.2 Grouped | M | | | P,V | N |
Proxy-State 33 6.7.4 OctetString| M | | | P,V | N |
Redirect-Host 292 6.12 DiamURI | M | P | | V | N |
Redirect-Host- 261 6.13 Enumerated | M | P | | V | N |
Usage | | | | | |
Redirect-Max- 262 6.14 Unsigned32 | M | P | | V | N |
Cache-Time | | | | | |
Result-Code 268 7.1 Unsigned32 | M | P | | V | N |
Route-Record 282 6.7.1 DiamIdent | M | | | P,V | N |
Session-Id 263 8.8 UTF8String | M | P | | V | Y |
Session-Timeout 27 8.13 Unsigned32 | M | P | | V | N |
Session-Binding 270 8.17 Unsigned32 | M | P | | V | Y |
Session-Server- 271 8.18 Enumerated | M | P | | V | Y |
Failover | | | | | |
Supported- 265 5.3.6 Unsigned32 | M | P | | V | N |
Vendor-Id | | | | | |
Termination- 295 8.15 Enumerated | M | P | | V | N |
Cause | | | | | |
User-Name 1 8.14 UTF8String | M | P | | V | Y |
Vendor-Id 266 5.3.3 Unsigned32 | M | P | | V | N |
Vendor-Specific- 260 6.11 Grouped | M | P | | V | N |
Application-Id | | | | | |
-----------------------------------------|----+-----+----+-----|----|
This section describes how Diameter nodes establish connections and communicate with peers.
このセクションでは、Diameterノードがどのように接続を確立し、ピアと通信するかについて説明します。
Although a Diameter node may have many possible peers that it is able to communicate with, 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 timeframe, 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 shutdown. 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 will make it possible for simpler and more robust deployment of Diameter services. In order to promote interoperable implementations of Diameter peer discovery, the following mechanisms are described. These are based on existing IETF standards. The first option (manual configuration) MUST be supported by all DIAMETER nodes, while the latter two options (SRVLOC and DNS) MAY be supported.
動的なDiameterエージェントの検出を可能にすることで、Diameterサービスのよりシンプルで堅牢な展開が可能になります。 Diameterピアディスカバリの相互運用可能な実装を促進するために、次のメカニズムについて説明します。これらは、既存のIETF標準に基づいています。最初のオプション（手動構成）はすべてのDIAMETERノードでサポートされなければなりません（MUST）が、後者の2つのオプション（SRVLOCとDNS）はサポートされるかもしれません。
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 static (manually) configured Diameter agent locations. These will be used if they exist and respond.
1. Diameter実装は、静的な（手動で）構成されたDiameterエージェントの場所のリストを調べます。これらは、存在して応答する場合に使用されます。
2. The Diameter implementation uses SLPv2 [SLP] to discover Diameter services. The Diameter service template [TEMPLATE] is included in Appendix A.
2. Diameterの実装では、SLPv2 [SLP]を使用してDiameterサービスを検出します。 Diameterサービステンプレート[TEMPLATE]は付録Aに含まれています。
It is recommended that SLPv2 security be deployed (this requires distributing keys to SLPv2 agents). This is discussed further in Appendix A. SLPv2 security SHOULD be used (requiring distribution of keys to SLPv2 agents) in order to ensure that discovered peers are authorized for their roles. SLPv2 is discussed further in Appendix A.
SLPv2セキュリティを展開することをお勧めします（これには、SLPv2エージェントにキーを配布する必要があります）。これについては、付録Aでさらに説明します。検出されたピアがその役割に対して承認されるようにするには、SLPv2セキュリティを使用する必要があります（SLPv2エージェントへの鍵の配布が必要）。 SLPv2については、付録Aで詳しく説明します。
3. The Diameter implementation performs a NAPTR query for a server in a particular realm. The Diameter implementation has to know in advance which realm to look for a Diameter agent in. This could be deduced, for example, from the 'realm' in a NAI that a Diameter implementation needed to perform a Diameter operation on.
3. Diameter実装は、特定のレルムのサーバーに対してNAPTRクエリを実行します。 Diameter実装は、Diameterエージェントを探すレルムを事前に知っておく必要があります。これは、たとえば、Diameter実装がDiameter操作を実行するために必要なNAIの「レルム」から推定できます。
3.1 The services relevant for the task of transport protocol selection are those with NAPTR service fields with values "AAA+D2x", where x is a letter that corresponds to a transport protocol supported by the domain. This specification defines D2T for TCP and D2S for SCTP. We also establish an IANA registry for NAPTR service name to transport protocol mappings.
3.1 トランスポートプロトコル選択のタスクに関連するサービスは、NAPAAサービスフィールドの値が「AAA + D2x」のサービスです。xは、ドメインでサポートされているトランスポートプロトコルに対応する文字です。この仕様では、TCPにはD2T、SCTPにはD2Sを定義しています。また、NAPTRサービス名のIANAレジストリを確立して、プロトコルマッピングを転送します。
These NAPTR records provide a mapping from a domain, to the SRV record for contacting a server with the specific transport protocol in the NAPTR services field. The resource record will contain an empty regular expression and a replacement value, which is the SRV record for that particular transport protocol. If the server supports multiple transport protocols, there will be multiple NAPTR records, each with a different service value. As per RFC 2915 [NAPTR], the client
これらのNAPTRレコードは、ドメインからSRVレコードへのマッピングを提供し、NAPTRサービスフィールドで特定のトランスポートプロトコルを使用してサーバーに接続します。リソースレコードには、空の正規表現と置換値が含まれます。これは、特定のトランスポートプロトコルのSRVレコードです。サーバーが複数のトランスポートプロトコルをサポートしている場合は、それぞれが異なるサービス値を持つ複数のNAPTRレコードが存在します。 RFC 2915 [NAPTR]に従って、クライアント
discards any records whose services fields are not applicable. For the purposes of this specification, several rules are defined.
サービスフィールドが適用されないレコードを破棄します。この仕様の目的のために、いくつかのルールが定義されています。
3.2 A client MUST discard any service fields that identify a resolution service whose value is not "D2X", for values of X that indicate transport protocols supported by the client. The NAPTR processing as described in RFC 2915 will result in discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server.
3.2 クライアントは、クライアントがサポートするトランスポートプロトコルを示すXの値について、値が「D2X」ではない解決サービスを識別するサービスフィールドを破棄する必要があります。 RFC 2915で説明されているNAPTR処理により、クライアントがサポートするサーバーの最も好ましいトランスポートプロトコルと、サーバーのSRVレコードが検出されます。
The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query.
NAPTR置換フィールドのドメインサフィックスは、元のクエリのドメインと一致する必要があります（SHOULD）。
4. If no NAPTR records are found, the requester queries for those address records for the destination address, '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address records include A RR's, AAAA RR's or other similar records, chosen according to the requestor's network protocol capabilities. If the DNS server returns no address records, the requestor gives up.
4. NAPTRレコードが見つからない場合、リクエスターは宛先アドレス '_diameter._sctp'.realmまたは' _diameter._tcp'.realmのアドレスレコードを照会します。アドレスレコードには、要求者のネットワークプロトコル機能に応じて選択されたA RR、AAAA RR、またはその他の同様のレコードが含まれます。 DNSサーバーがアドレスレコードを返さない場合、リクエスタはあきらめます。
If the server is using a site certificate, the domain name in the 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 or 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 that this was the desired behavior, or the result of an attack
サーバーがサイト証明書を使用している場合、クエリのドメイン名と置換フィールドのドメイン名の両方が、TLSまたは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, or validation of DNS RRs via DNSSEC is not sufficient to conclude this. For example, a web server may have obtained a valid TLS 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による認証、またはDNSSECによるDNS RRの検証では不十分です。たとえば、Webサーバーが有効なTLS証明書を取得し、セキュリティで保護されたRRがDNSに含まれている可能性がありますが、これは、Diameterサーバーとして機能することが承認されていることを意味しません。
Authorization can be achieved for example, by configuration of a Diameter Server CA. Alternatively this can be achieved by definition of OIDs within TLS or IKE certificates so as to signify Diameter Server authorization.
承認は、たとえば、DiameterサーバーCAの構成によって実現できます。あるいは、これは、Diameterサーバーの承認を示すために、TLSまたはIKE証明書内のOIDの定義によって実現できます。
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 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, 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 applications in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer.
レシーバーは、コマンドを定義するDiameterアプリケーションのサポートをアドバタイズしたピアにのみコマンドを発行します。 Diameterノードは、認識されていないコマンドやAVPが不必要にピアに送信されないようにするために、サポートされているアプリケーションをキャッシュする必要があります。
A receiver of a Capabilities-Exchange-Req (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-Req（CER）メッセージの受信者は、Result-Code AVPがDIAMETER_NO_COMMON_APPLICATIONに設定されたCapabilities-Exchange-Answer（CEA）を返さなければならず、トランスポートを切断する必要があります（SHOULD）レイヤー接続。自身をリレーとしてアドバタイズするピアからCERまたはCEAを受信すること（セクション2.4を参照）は、ピアとの共通のアプリケーションを持つものとして解釈されなければならないことに注意してください。
Similarly, a receiver of a Capabilities-Exchange-Req (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.
同様に、送信者と共通のセキュリティメカニズムを持たないCapabilities-Exchange-Req（CER）メッセージの受信者は、Result-Code AVPがDIAMETER_NO_COMMON_SECURITYに設定されたCapabilities-Exchange-Answer（CEA）を返さなければならず、SHOULDトランスポート層の接続を切断します。
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 receives 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 (see Section 7.) with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER to inform the downstream to take action (e.g., re-routing request to an alternate peer).
CER / CEAメッセージはプロキシできないため、コマンドコードに対応するアプリケーションを処理するために使用可能なピアがないアップストリームエージェントがメッセージを受信する可能性があります。そのような場合、「E」ビットが応答メッセージで設定され（セクション7を参照）、Result-Code AVPがDIAMETER_UNABLE_TO_DELIVERに設定されて、ダウンストリームにアクション（たとえば、要求を代替ピアに再ルーティングする）を通知するように通知します。
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 Identifier).
Capabilities-Exchange-Requestメッセージ、Auth-Application-IdまたはAcct-Application-Id AVPを含むリクエストタイプのメッセージ、またはアプリケーション固有のコマンドコードを含むメッセージを除いて、アプリケーションのサポートを明示的にアドバタイズした（またはリレーアプリケーション識別子をアドバタイズした）ホスト。
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.
Command-Codeが257に設定され、コマンドフラグの「R」ビットが設定されていることで示されるCapabilities-Exchange-Request（CER）は、ローカル機能を交換するために送信されます。トランスポート障害の検出時に、このメッセージを代替ピアに送信してはならない（MUST NOT）。
When Diameter is run over SCTP [SCTP], which allows 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 [SCTP]で実行されている場合、接続が複数のインターフェースと複数のIPアドレスにまたがることができるため、Capabilities-Exchange-Requestメッセージには、ローカルで使用される可能性があるIPアドレスごとに1つのHost-IP-Address 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.
Command-Codeが257に設定され、コマンドフラグの「R」ビットがクリアされることで示されるCapabilities-Exchange-Answer（CEA）は、CERメッセージに応答して送信されます。
When Diameter is run over SCTP [SCTP], which allows 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 [SCTP]を介して実行されると、接続が複数のインターフェース、つまり複数のIPアドレスにまたがることができるため、Capabilities-Exchange-Answerメッセージには、ローカルで使用される可能性のあるIPアドレスごとに1つのHost-IP-Address AVPを含める必要がありますDiameterメッセージを送信するとき。
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" [ASSIGNNO] value assigned to the vendor of the Diameter application. In combination with the Supported-Vendor-Id AVP (Section 5.3.6), this MAY be used in order to know which vendor specific attributes may be sent to the peer. It is also envisioned that the combination of the Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs MAY provide very useful debugging information.
Vendor-Id AVP（AVPコード266）はUnsigned32タイプで、Diameterアプリケーションのベンダーに割り当てられたIANA "SMIネットワーク管理プライベートエンタープライズコード" [ASSIGNNO]値が含まれています。 Supported-Vendor-Id AVP（セクション5.3.6）と組み合わせて、これは、どのベンダー固有の属性がピアに送信されるかを知るために使用できます（MAY）。 Vendor-Id、Product-Name（セクション5.3.7）およびFirmware-Revision（セクション5.3.4）AVPの組み合わせが非常に有用なデバッグ情報を提供する場合があることも想定されています。
A Vendor-Id value of zero in the CER or CEA messages 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 [SCTP] MUST be advertised in the CER and CEA messages by including a Host-IP-Address AVP for each address. This AVP MUST ONLY be used in the CER and CEA messages.
Host-IP-Address AVP（AVPコード257）はアドレスタイプで、Diameterピアに送信者のIPアドレスを通知するために使用されます。 DiameterノードがSCTP [SCTP]で使用することを期待しているすべてのソースアドレスは、各アドレスのHost-IP-Address AVPを含めることにより、CERおよびCEAメッセージでアドバタイズされなければなりません（MUST）。この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" [ASSIGNNO] value assigned to a vendor other than the device 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.
Supported-Vendor-Id AVP（AVPコード265）はUnsigned32タイプであり、デバイスベンダー以外のベンダーに割り当てられたIANA "SMIネットワーク管理プライベートエンタープライズコード" [ASSIGNNO]値が含まれています。これは、送信者がこのAVPで識別されたベンダーによって定義されたベンダー固有のAVP（のサブセット）をサポートすることをピアに通知するために、CERおよびCEAメッセージで使用されます。
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 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 initiates the transport disconnect.
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 its intentions to shutdown the transport connection. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.
Disconnect-Peer-Request（DPR）は、コマンドコードが282に設定され、コマンドフラグの「R」ビットが設定されていることで示され、トランスポート接続をシャットダウンする意図をピアに送信します。トランスポート障害の検出時に、このメッセージを代替ピアに送信してはならない（MUST NOT）。
Message Format
メッセージフォーマット
<DPR> ::= < Diameter Header: 282, REQ >
{ Origin-Host }
{ Origin-Realm }
{ Disconnect-Cause }
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 shutdown.
Disconnect-Peer-Request（DPA）は、コマンドコードが282に設定され、コマンドフラグの「R」ビットがクリアされていることで示され、Disconnect-Peer-Requestメッセージへの応答として送信されます。このメッセージを受信すると、トランスポート接続がシャットダウンされます。
Message Format
メッセージフォーマット
<DPA> ::= < Diameter Header: 282 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-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 shutdown the transport connection. The following values are supported: REBOOTING 0 A scheduled reboot is imminent.
Disconnect-Cause AVP（AVPコード273）は列挙型です。 Diameterノードは、トランスポート接続をシャットダウンする意図の理由をピアに通知するために、Disconnect-Peer-RequestメッセージにこのAVPを含める必要があります。次の値がサポートされています。REBOOTING 0スケジュールされた再起動が間近に迫っています。
BUSY 1 The peer's internal resources are constrained, and it has determined that the transport connection needs to be closed.
BUSY 1ピアの内部リソースに制約があり、トランスポート接続を閉じる必要があると判断しました。
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.
DO_NOT_WANT_TO_TALK_TO_YOU 2ピアは、近い将来メッセージが交換されることを予期していないため、トランスポート接続が存在する必要がないと判断しました。
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.
Command-Codeが280に設定され、コマンドフラグの「R」ビットが設定されていることで示されるDevice-Watchdog-Request（DWR）は、2つのピア間でトラフィックが交換されていない場合にピアに送信されます（セクション5.5.3を参照）。 ）。トランスポート障害の検出時に、このメッセージを代替ピアに送信してはならない（MUST NOT）。
Message Format
メッセージフォーマット
<DWR> ::= < Diameter Header: 280, REQ >
{ Origin-Host }
{ Origin-Realm }
[ Origin-State-Id ]
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.
Command-Codeが280に設定され、コマンドフラグの「R」ビットがクリアされることで示されるDevice-Watchdog-Answer（DWA）は、Device-Watchdog-Requestメッセージへの応答として送信されます。
Message Format
メッセージフォーマット
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
* [ Failed-AVP ]
[ Original-State-Id ]
The transport failure algorithm is defined in [AAATRANS]. All Diameter implementations MUST support the algorithm defined in the specification in order to be compliant to the Diameter base protocol.
トランスポート障害アルゴリズムは[AAATRANS]で定義されています。すべての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 records still remaining to be transmitted in non-volatile storage. 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 [AAATRANS], which is used to open, close, failover, probe, and reopen transport connections. Note in particular that [AAATRANS] requires the use of watchdog messages to probe connections. For Diameter, DWR and DWA messages are to be used.
このステートマシンは、[AAATRANS]で説明されているステートマシンと密接に結合しており、トランスポート接続のオープン、クローズ、フェイルオーバー、プローブ、および再オープンに使用されます。特に、[AAATRANS]は、ウォッチドッグメッセージを使用して接続をプローブする必要があることに注意してください。 Diameterの場合、DWRおよびDWAメッセージが使用されます。
I- is used to represent the initiator (connecting) connection, while the R- 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 usage, a TLS handshake will begin when both ends are in the open state. If the TLS handshake is successful, all further messages will be sent via TLS. If the handshake fails, both ends move to the closed state.
TLSを使用する場合、両端がオープン状態になると、TLSハンドシェイクが開始されます。 TLSハンドシェイクが成功した場合、以降のすべてのメッセージはTLS経由で送信されます。ハンドシェイクが失敗すると、両端がクローズ状態に移行します。
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, Closed R-Disc
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-ディスク
R-Peer-Disc R-Disc Closed R-Rcv-CER R-Snd-CEA R-Open R-Rcv-CEA Process-CEA R-Open
R-ピア-ディスクR-ディスククローズR-Rcv-CER R-Snd-CEA R-オープンR-Rcv-CEAプロセス-CEA R-オープン
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, Closed I-Disc I-Peer-Disc I-Disc Closed I-Rcv-CER I-Snd-CEA I-Open I-Rcv-CEA Process-CEA I-Open
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-Disc I-Peer-Disc I-DiscクローズI-Rcv-CER I- Snd-CEA I-Open I-Rcv-CEAプロセス-CEA I-Open
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; and the source port of an incoming connection is arbitrary. Upon receipt of CER, the identity of the connecting peer can be uniquely determined from 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 CER. Once 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 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 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 prefix, since the actual event would be identical, but would occur on one of two possible connections.
オートマトンの遷移とアクションは、イベントによって引き起こされます。このセクションでは、実際のイベントは同じですが、2つの可能な接続のいずれかで発生するため、-Iおよび-Rプレフィックスは無視します。
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 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-prefix, since the actual action would be identical, but would occur on one of two possible connections.
オートマトンのアクションはイベントによって引き起こされ、通常はパケットの送信や接続で行われるアクションを示します。このセクションでは、実際のアクションは同じですが、2つの可能な接続のいずれかで発生するため、IプレフィックスとRプレフィックスは無視します。
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 CEAメッセージがピアに送信されます。
Cleanup If necessary, the connection is shutdown, 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 DWAメッセージが送信されます。
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 sent by its peer with its own Origin-Host. If the local Diameter entity's Origin-Host is higher than the peer's, a Win-Election event is issued locally.
選挙はレスポンダーで行われます。レスポンダは、ピアによって送信されたCERで受信されたOrigin-Hostを、自身のOrigin-Hostと比較します。ローカルDiameterエンティティのOrigin-Hostがピアのものよりも高い場合、Win-Electionイベントがローカルに発行されます。
The comparison proceeds by considering the shorter OctetString to be padded with zeros so that it length is the same as the length of the longer, then performing an octet-by-octet unsigned comparison with the first octet being most significant. Any remaining octets are assumed to have value 0x80.
比較は、短いOctetStringにゼロが埋め込まれるように考慮され、長さが長いものと同じになるように考慮されます。次に、最初のオクテットが最も重要なオクテットごとの符号なし比較を実行します。残りのオクテットは値0x80であると想定されます。
This section describes how Diameter requests and answers are created and processed.
このセクションでは、Diameter要求と応答がどのように作成および処理されるかについて説明します。
A request is sent towards its final destination using a combination of the Destination-Realm and Destination-Host AVPs, in one of these three combinations:
Destination-RealmとDestination-Host AVPの組み合わせを使用して、次の3つの組み合わせのいずれかでリクエストが最終的な宛先に送信されます。
- a request that is not able to be proxied (such as CER) MUST NOT contain either Destination-Realm or Destination-Host AVPs.
- プロキシできないリクエスト（CERなど）には、Destination-RealmまたはDestination-Host AVPを含めることはできません。
- 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.
- 特定のレルムを提供するホームサーバーに送信する必要があるが、特定のサーバーには送信しない要求（一連の往復の最初の要求など）には、宛先レルムAVPを含める必要がありますが、宛先ホストAVP。
- 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.
- それ以外の場合、特定のレルムにサービスを提供しているサーバーの中で特定のホームサーバーに送信する必要がある要求には、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は、リクエストの宛先が次のように固定されている場合に、上記のように使用されます。
- Authentication requests that span multiple round trips
- 複数のラウンドトリップにまたがる認証リクエスト
- 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.
- メッセージの送信元と最終的な送信先の間で共有される事前に確立されたセッションキーを利用するセキュリティメカニズムを使用するDiameterメッセージ。
- 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.
- 特定のユーザーのセッションの終了を要求するために使用されるAbort-Session-Requestメッセージなど、特定のDiameterクライアント（アクセスデバイスなど）が受信する必要のあるサーバー開始メッセージ。
Note that an agent can forward a request to a host described in the Destination-Host AVP only if the host in question is included in its peer table (see Section 2.7). Otherwise, the request is routed based on the Destination-Realm only (see Sections 6.1.6).
問題のホストがピアテーブルに含まれている場合にのみ、エージェントがDestination-Host AVPに記述されているホストにリクエストを転送できることに注意してください（セクション2.7を参照）。それ以外の場合、要求は宛先レルムのみに基づいてルーティングされます（セクション6.1.6を参照）。
The Destination-Realm AVP MUST be present if the message is proxiable. Request messages that may be forwarded by Diameter agents (proxies, redirects or relays) MUST also contain an Acct-Application-Id AVP, an Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP. A message that MUST NOT be forwarded by Diameter agents (proxies, redirects or relays) MUST not include the Destination-Realm in its ABNF. The value of the Destination-Realm AVP MAY be extracted from the User-Name AVP, or other application-specific methods.
メッセージがプロキシ可能な場合、宛先レルムAVPが存在する必要があります。 Diameterエージェント（プロキシ、リダイレクト、またはリレー）によって転送される可能性のある要求メッセージには、Acct-Application-Id AVP、Auth-Application-Id AVP、またはVendor-Specific-Application-Id AVPも含まれている必要があります。 Diameterエージェント（プロキシ、リダイレクト、またはリレー）によって転送してはならない（MUST）メッセージは、そのABNFにDestination-Realmを含めてはならない（MUST NOT）。 Destination-Realm AVPの値は、User-Name AVPまたは他のアプリケーション固有のメソッドから抽出される場合があります。
When a message is received, the message is processed in the following order:
メッセージを受信すると、メッセージは次の順序で処理されます。
1. If the message is destined for the local host, the procedures listed in Section 6.1.4 are followed.
1. メッセージの宛先がローカルホストの場合は、セクション6.1.4に記載されている手順に従います。
2. 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.
2. メッセージが、ローカルホストが直接通信できるDiameterピアを対象としている場合は、セクション6.1.5に記載されている手順に従います。これはリクエスト転送と呼ばれます。
3. The procedures listed in Section 6.1.6 are followed, which is known as Request Routing.
3. セクション6.1.6に記載されている手順に従います。これはリクエストルーティングと呼ばれます。
4. If none of the above is successful, an answer is returned with the Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the E-bit set.
4. 上記のいずれも成功しなかった場合、Result-Codeを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ノードがピアである必要があります。
Note the processing rules contained in this section are intended to be used as general guidelines to Diameter developers. Certain implementations MAY use different methods than the ones described here, and still comply with the protocol specification. See Section 7 for more detail on error handling.
このセクションに含まれる処理ルールは、Diameter開発者向けの一般的なガイドラインとして使用することを目的としています。特定の実装は、ここで説明されている方法とは異なる方法を使用しても、プロトコル仕様に準拠する場合があります。エラー処理の詳細については、セクション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:
リクエストを作成するときは、その特定のリクエストのアプリケーション定義で説明されている他の手順に加えて、次の手順に従う必要があります。
- the Command-Code is set to the appropriate value
- コマンドコードが適切な値に設定されている
- the 'R' bit is set
- 「R」ビットが設定されている
- the End-to-End Identifier is set to a locally unique value
- エンドツーエンド識別子がローカルで一意の値に設定されている
- the Origin-Host and Origin-Realm AVPs MUST be set to the appropriate values, used to identify the source of the message
- Origin-HostおよびOrigin-Realm AVPは、メッセージのソースを識別するために使用される適切な値に設定する必要があります。
- the Destination-Host and Destination-Realm AVPs MUST be set to the appropriate values as described in Section 6.1.
- セクション6.1で説明されているように、Destination-HostおよびDestination-Realm AVPは適切な値に設定する必要があります。
- an Acct-Application-Id AVP, an Auth-Application-Id or a Vendor-Specific-Application-Id AVP must be included if the request is proxiable.
- リクエストがプロキシ可能である場合、Acct-Application-Id AVP、Auth-Application-IdまたはVendor-Specific-Application-Id AVPを含める必要があります。
When sending a request, originated either locally, or as the result of a forwarding or routing operation, the following procedures MUST be followed:
ローカルで、または転送またはルーティング操作の結果として要求を送信する場合、次の手順に従う必要があります。
- the Hop-by-Hop Identifier should be set to a locally unique value
- ホップバイホップ識別子は、ローカルで一意の値に設定する必要があります
- The message should be saved in the list of pending requests.
- メッセージは保留中のリクエストのリストに保存する必要があります。
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 occur:
次のいずれかの条件が発生した場合、リクエストはローカルでの消費であることがわかっています。
- The Destination-Host AVP contains the local host's identity,
- Destination-Host AVPには、ローカルホストのIDが含まれています。
- 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
- Destination-Host AVPが存在せず、Destination-Realm AVPに、サーバーがローカルで処理するように構成されているレルムが含まれ、Diameterアプリケーションがローカルでサポートされている、または
- Both the Destination-Host and the Destination-Realm are not present.
- 宛先ホストと宛先レルムの両方が存在しません。
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 that the local node is able to directly communicate with.
要求の転送は、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 applications. A Diameter message that may be forwarded by Diameter agents (proxies, redirects or relays) MUST include the target realm in the Destination-Realm AVP and one of the application identification AVPs Auth-Application-Id, Acct-Application-Id or Vendor-Specific-Application-Id. 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リクエストメッセージのルーティングは、レルムとアプリケーションを介して行われます。 Diameterエージェント（プロキシ、リダイレクト、またはリレー）によって転送されるDiameterメッセージには、Destination-Realm AVPのターゲットレルムと、アプリケーション識別AVPのAuth-Application-Id、Acct-Application-IdまたはVendor-Specificのいずれかを含める必要があります。 -アプリケーションID。レルムは、ネットワークアクセス識別子（NAI）の形式のユーザー名AVPから取得できます（MAY）。 NAIのレルム部分は、宛先レルムAVPに挿入されます。
Diameter agents MAY have a list of locally supported realms and applications, and 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 Realm Routing Table (see Section 2.7).
Diameterエージェントには、ローカルでサポートされているレルムとアプリケーションのリストがあり、外部でサポートされているレルムとアプリケーションのリストがあります（MAY）。ローカルでサポートされていないレルムやアプリケーションを含むリクエストを受信すると、メッセージはレルムルーティングテーブルで構成されたピアにルーティングされます（セクション2.7を参照）。
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 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
図5：Diameterリダイレクトエージェント
The receiver of the answer message with the 'E' bit set, and the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by-hop field in the Diameter header to identify the request in the pending message queue (see Section 5.3) that is to be redirected. If no transport connection exists with the new agent, one is created, and the request is sent directly to it.
「E」ビットが設定され、Result-Code AVPがDIAMETER_REDIRECT_INDICATIONに設定された応答メッセージの受信者は、Diameterヘッダーのホップバイホップフィールドを使用して、保留中のメッセージキュー（5.3を参照）内のリクエストを識別します。リダイレクトされます。新しいエージェントとのトランスポート接続が存在しない場合は、トランスポート接続が作成され、要求がエージェントに直接送信されます。
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つだけを選択します。
A relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer the request was received from.
リレーまたはプロキシエージェントは、転送されるすべてのリクエストに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. Proxy-Info AVP has certain security implications and SHOULD contain an embedded HMAC with a node-local key. Alternatively, it MAY simply use local storage to store state information.
リレーまたはプロキシエージェントは、対応する応答を受信したときにローカル状態情報にアクセスする必要がある場合、リクエストにProxy-Info AVPを含めることができます。 Proxy-Info AVPには特定のセキュリティ上の影響があり、ノードローカルキーを持つ埋め込みHMACを含む必要があります（SHOULD）。あるいは、単にローカルストレージを使用して状態情報を格納する場合があります。
The message is then forwarded to the next hop, as identified in the Realm Routing Table.
次に、メッセージは、レルムルーティングテーブルで識別されている次のホップに転送されます。
Figure 6 provides an example of message routing using the procedures listed in these sections.
図6は、これらのセクションにリストされている手順を使用したメッセージルーティングの例を示しています。
(Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net)
(Origin-Realm=mno.net) (Origin-Realm=mno.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メッセージのルーティング
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アプリケーションで説明される可能性がある追加の手順に加えて、関連する回答を作成するために次の手順を適用する必要があります。
- The same Hop-by-Hop identifier in the request is used in the answer.
- リクエストでは同じホップバイホップ識別子が回答で使用されます。
- The local host's identity is encoded in the Origin-Host AVP.
- ローカルホストのIDは、Origin-Host AVPでエンコードされます。
- The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message.
- Destination-HostおよびDestination-Realm AVPは、応答メッセージに存在してはなりません。
- The Result-Code AVP is added with its value indicating success or failure.
- Result-Code AVPに、成功または失敗を示す値が追加されます。
- If the Session-Id is present in the request, it MUST be included in the answer.
- リクエストにSession-Idが存在する場合は、それを回答に含める必要があります。
- Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request.
- 要求内のすべてのProxy-Info AVPは、要求内に存在したのと同じ順序で、応答メッセージに追加する必要があります。
- The 'P' bit is set to the same value as the one in the request.
- 「P」ビットは、要求のビットと同じ値に設定されます。
- The same End-to-End identifier in the request is used in the answer.
- 要求では、同じエンドツーエンド識別子が応答で使用されます。
Note that the error messages (see Section 7.3) are also subjected to the above processing rules.
エラーメッセージ（7.3項を参照）も上記の処理規則に従うことに注意してください。
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 which 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 and it MUST issue an STR on behalf of the access device.
リレーまたはプロキシエージェントが、失敗を示す結果コードAVPを含む応答を受信した場合、AVPの内容を変更してはなりません。追加のローカルエラーが検出された場合はログに記録する必要がありますが、結果コードAVPには反映されません。エージェントが成功を示すResult-Code AVPを含む応答メッセージを受信し、エラーを示すようにAVPを変更したい場合、アクセスデバイス宛てのメッセージに適切なエラーが含まれるようにResult-Code AVPを変更する必要があります。また、Error-Reporting-Host AVPを含め、アクセスデバイスに代わって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 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. 6.10
このAVPは、Diameterヘッダーのできるだけ近くに配置する必要があります（SHOULD）。 6.10
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.
Origin-Realm AVP（AVPコード296）は、DiameterIdentityタイプです。このAVPには、Diameterメッセージの発信元のレルムが含まれており、すべてのメッセージに存在する必要があります。
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 the message is to be routed to. 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はAnswerメッセージに存在してはなりません。 Diameterクライアントは、User-Name AVPの領域部分を挿入します。要求メッセージを開始するDiameterサーバーは、（事前にわかっている場合を除いて）対象のターゲットホストから受信した前のメッセージのOrigin-Realm AVPの値を使用します。存在する場合、宛先レルムAVPはメッセージルーティングの決定を実行するために使用されます。
Request messages whose ABNF does not list the Destination-Realm AVP as a mandatory AVP are inherently non-routable messages.
ABNFがDestination-Realm AVPを必須AVPとしてリストしていない要求メッセージは、本質的にルーティング不可能なメッセージです。
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, and therefore MUST NOT be protected by end-to-end security.
このセクションで定義されているAVPは、ルーティングの目的で使用されるDiameter AVPです。これらのAVPは、Diameterメッセージがエージェントによって処理されるときに変更されるため、エンドツーエンドのセキュリティによって保護してはなりません（MUST NOT）。
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.
Route-Record AVP（AVPコード282）は、DiameterIdentityタイプです。このAVPに追加されたIDは、Capabilities ExchangeメッセージのOrigin-Hostで受信されたものと同じである必要があります。
The Proxy-Info AVP (AVP Code 284) is of type Grouped. The Grouped Data field has the following ABNF grammar:
Proxy-Info AVP（AVPコード284）のタイプはGroupedです。 Grouped Dataフィールドには、次のABNF文法があります。
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, and contains state local information, and MUST be treated as opaque data.
Proxy-State AVP（AVPコード33）はOctetStringタイプであり、状態ローカル情報を含み、不透明なデータとして扱われなければなりません（MUST）。
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). The Auth-Application-Id MUST also be present in all Authentication and/or Authorization messages that are defined in a separate Diameter specification and have an Application ID assigned.
Auth-Application-Id AVP（AVPコード258）はタイプUnsigned32であり、アプリケーションの認証および承認部分のサポートをアドバタイズするために使用されます（セクション2.4を参照）。 Auth-Application-Idは、別の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). The Acct-Application-Id MUST also be present in all Accounting messages. Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present.
Acct-Application-Id AVP（AVPコード259）はタイプUnsigned32であり、アプリケーションのアカウンティング部分のサポートをアドバタイズするために使用されます（セクション2.4を参照）。 Acct-Application-Idは、すべてのアカウンティングメッセージにも存在する必要があります。 Auth-Application-IdおよびAcct-Application-Id AVPの1つだけが存在する場合があります。
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.
Inband-Security-Id AVP（AVPコード299）はタイプUnsigned32であり、アプリケーションのセキュリティ部分のサポートをアドバタイズするために使用されます。
Currently, the following values are supported, but there is ample room to add new security Ids.
現在、次の値がサポートされていますが、新しいセキュリティIDを追加するための十分な余地があります。
NO_INBAND_SECURITY 0 This peer does not support TLS. This is the default value, if the AVP is omitted.
NO_INBAND_SECURITY 0このピアはTLSをサポートしていません。これは、AVPが省略されている場合のデフォルト値です。
TLS 1 This node supports TLS security, as defined by [TLS].
TLS 1このノードは、[TLS]で定義されているTLSセキュリティをサポートします。
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 of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present.
Vendor-Specific-Application-Id AVP（AVPコード260）はGroupedタイプであり、ベンダー固有のDiameterアプリケーションのサポートをアドバタイズするために使用されます。 Auth-Application-IdおよびAcct-Application-Id AVPの1つだけが存在する場合があります。
This AVP MUST also be present as the first AVP in all experimental commands defined in the vendor-specific application.
このAVPは、ベンダー固有のアプリケーションで定義されているすべての実験的コマンドの最初のAVPとしても存在する必要があります。
This AVP SHOULD be placed as close to the Diameter header as possible.
このAVPは、Diameterヘッダーのできるだけ近くに配置する必要があります（SHOULD）。
AVP Format
AVPフォーマット
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
1* [ Vendor-Id ]
0*1{ Auth-Application-Id }
0*1{ Acct-Application-Id }
One or more of 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.
応答メッセージの「E」ビットが設定され、結果コードAVPがDIAMETER_REDIRECT_INDICATIONに設定されている場合、このAVPの1つ以上のインスタンスが存在する必要があります。
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 pertaining to this session.
上記を受信すると、受信側のDiameterノードは、これらのAVPで識別されたホストの1つに直接要求を転送する必要があります（SHOULD）。選択されたリダイレクトホスト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 dictates how the routing entry resulting from the Redirect-Host is to be used. The following values are supported:
存在する場合、このAVPは、Redirect-Hostからのルーティングエントリの使用方法を決定します。次の値がサポートされています。
DONT_CACHE 0 The host specified in the Redirect-Host AVP should not be cached. This is the default value.
DONT_CACHE 0 Redirect-Host AVPで指定されたホストはキャッシュされません。これがデフォルト値です。
ALL_SESSION 1 All messages within the same session, as defined by the same value of the Session-ID AVP MAY be sent to the host specified in the Redirect-Host AVP.
ALL_SESSION 1 Session-ID AVPの同じ値で定義されている同じセッション内のすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信される場合があります。
ALL_REALM 2 All messages destined for the realm requested MAY be sent to the host specified in the Redirect-Host AVP.
ALL_REALM 2要求されたレルム宛てのすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信される場合があります。
REALM_AND_APPLICATION 3 All messages for the application requested to the realm specified MAY be sent to the host specified in the Redirect-Host AVP.
REALM_AND_APPLICATION 3指定されたレルムに要求されたアプリケーションのすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信される場合があります。
ALL_APPLICATION 4 All messages for the application requested MAY be sent to the host specified in the Redirect-Host AVP.
ALL_APPLICATION 4要求されたアプリケーションのすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信される場合があります。
ALL_HOST 5 All messages that would be sent to the host that generated the Redirect-Host MAY be sent to the host specified in the Redirect-Host AVP.
ALL_HOST 5 Redirect-Hostを生成したホストに送信されるすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信される場合があります。
ALL_USER 6 All messages for the user requested MAY be sent to the host specified in the Redirect-Host AVP.
ALL_USER 6要求されたユーザーのすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信される場合があります。
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, the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the 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, will be cached. Note that once a host created due to a redirect indication is no longer reachable, any associated peer and routing table entries MUST be deleted.
このAVPには、リダイレクトホストの結果として作成されたピアおよびルートテーブルエントリがキャッシュされる最大秒数が含まれます。リダイレクトの指示により作成されたホストに到達できなくなった場合は、関連するピアとルーティングテーブルのエントリを削除する必要があることに注意してください。
The E2E-Sequence AVP (AVP Code 300) provides anti-replay protection for end to end messages and is of type grouped. It contains a random value (an OctetString with a nonce) and counter (an Integer). For each end-to-end peer with which a node communicates (or remembers communicating) a different nonce value MUST be used and the counter is initiated at zero and increases by one each time this AVP is emitted to that peer. This AVP MUST be included in all messages which use end-to-end protection (e.g., CMS signing or encryption).
E2E-Sequence AVP（AVPコード300）は、エンドツーエンドのメッセージにアンチリプレイ保護を提供し、グループ化されたタイプです。ランダムな値（ノンスを含むOctetString）とカウンター（整数）が含まれます。ノードが通信する（または通信を覚えている）エンドツーエンドピアごとに、異なるナンス値を使用する必要があり（MUST）、カウンターはゼロで開始され、このAVPがそのピアに送信されるたびに1ずつ増加します。このAVPは、エンドツーエンドの保護（CMS署名や暗号化など）を使用するすべてのメッセージに含める必要があります。
There are two different types of errors in Diameter; protocol and application errors. A protocol error is one that occurs at the base protocol level, and MAY require per hop attention (e.g., 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, and therefore the message would be forwarded back to the originator of the request.
図8に、アプリケーションエラーの原因となったDiameterメッセージの例を示します。アプリケーションエラーが発生すると、エラーを報告するDiameterエンティティがコマンドフラグの「R」ビットをクリアし、適切な値を使用して結果コードAVPを追加します。アプリケーションエラーはプロキシまたはリレーエージェントの関与を必要としないため、メッセージは要求の発信者に転送されます。
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:
回答に追加のAVPが存在する必要がある特定の結果コードAVPアプリケーションエラーがあります。これらの場合、結果コードAVPを設定してエラーを示すDiameterノードは、AVPを追加する必要があります。次に例を示します。
- 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.
- 「M」ビット（必須ビット）が設定された認識されないAVPを受信すると、結果コードAVPがDIAMETER_AVP_UNSUPPORTEDに設定された応答が送信され、問題のAVPを含むFailed-AVP AVPが送信されます。
- 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.
- 認識されない値で受信されたAVPは、結果コードAVPがDIAMETER_INVALID_AVP_VALUEに設定された応答を返し、Failed-AVP AVPはエラーの原因となったAVPを含みます。
- A command is received with an AVP that is omitted, yet is mandatory according to the command's ABNF. 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.
- コマンドは、省略されたAVPで受信されますが、コマンドのABNFに従って必須です。受信者は、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 whether an error occurred. All Diameter answer messages defined in IETF applications 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.
Result-Code AVP（AVPコード268）はUnsigned32タイプで、特定のリクエストが正常に完了したかどうか、またはエラーが発生したかどうかを示します。 IETFアプリケーションで定義されているすべてのDiameter応答メッセージには、1つのResult-Code 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.4). Diameter provides the following classes of errors, all identified by the thousands digit in the decimal notation:
Result-Codeデータフィールドには、エラーを表すIANA管理の32ビットアドレス空間が含まれます（セクション11.4を参照）。 Diameterは、次のクラスのエラーを提供します。これらはすべて、10進表記の数千桁で識別されます。
- 1xxx (Informational) - 2xxx (Success) - 3xxx (Protocol Errors) - 4xxx (Transient Failures) - 5xxx (Permanent Failure)
- 1xxx（情報）-2xxx（成功）-3xxx（プロトコルエラー）-4xxx（一時的な障害）-5xxx（永続的な障害）
A non-recognized 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.
このカテゴリに該当するエラーは、要求が満たされなかったことを要求者に通知するために使用され、アクセスが許可される前に、その側で追加のアクションが必要です。
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_MULTI_ROUND_AUTH 1001この情報エラーは、使用されている認証メカニズムに複数のラウンドトリップが必要であること、およびアクセスを許可するために後続の要求を発行する必要があることをアクセスデバイスに通知するために、Diameterサーバーから返されます。
Errors that fall within the Success category are used to inform a peer that a request has been successfully completed.
成功カテゴリに含まれるエラーは、リクエストが正常に完了したことをピアに通知するために使用されます。
DIAMETER_SUCCESS 2001 The Request was successfully completed.
DIAMETER_SUCCESS 2001リクエストは正常に完了しました。
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.
DIAMETER_LIMITED_SUCCESS 2002返されると、要求は正常に完了しましたが、ユーザーにサービスを提供するために、アプリケーションによる追加の処理が必要です。
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 and only these errors MUST only be used in answer messages whose 'E' bit is set.
プロトコルエラーカテゴリに該当するエラーは、ホップごとに処理する必要があります（SHOULD）。Diameterプロキシは、可能であれば、エラーを修正しようとします（MAY）。これらのエラーとこれらのエラーのみは、「E」ビットが設定されている応答メッセージでのみ使用する必要があることに注意してください。
DIAMETER_COMMAND_UNSUPPORTED 3001 The Request contained a Command-Code that the receiver did not recognize or support. This MUST be used when a Diameter node receives an experimental command that it does not understand.
DIAMETER_COMMAND_UNSUPPORTED 3001リクエストには、受信者が認識またはサポートしていないコマンドコードが含まれていました。これは、Diameterノードが理解できない実験的なコマンドを受け取ったときに使用する必要があります。
DIAMETER_UNABLE_TO_DELIVER 3002 This error is given when Diameter can not 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 Destination-Host AVP was given without the associated Destination-Realm AVP.
DIAMETER_UNABLE_TO_DELIVER 3002このエラーは、要求を処理するために必要なアプリケーションをサポートするレルム内のホストが利用できなかったか、関連付けられた宛先レルムAVPなしで宛先ホストAVPが与えられたために、Diameterが宛先にメッセージを配信できない場合に発生します。 。
DIAMETER_REALM_NOT_SERVED 3003 The intended realm of the request is not recognized.
DIAMETER_REALM_NOT_SERVED 3003要求の意図されたレルムが認識されません。
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_TOO_BUSY 3004返されたとき、Diameterノードは、代替ピアへのメッセージの送信を試行する必要があります（SHOULD）。このエラーは、特定のサーバーが要求された場合にのみ使用する必要があり、要求されたサービスを提供できません。
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_LOOP_DETECTED 3005意図した受信者にメッセージを送信しようとしたときに、エージェントがループを検出しました。メッセージは、使用可能な場合、代替ピアに送信される場合がありますが、エラーを報告しているピアが構成の問題を識別しています。
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.
DIAMETER_REDIRECT_INDICATION 3006リダイレクトエージェントは、要求をローカルで満たすことができなかったと判断しました。要求の開始者は、要求をサーバーに直接送信する必要があります。サーバーには、連絡先情報が応答に追加されています。設定されている場合、Redirect-Host AVPが存在する必要があります。
DIAMETER_APPLICATION_UNSUPPORTED 3007 A request was sent for an application that is not supported.
DIAMETER_APPLICATION_UNSUPPORTED 3007サポートされていないアプリケーションのリクエストが送信されました。
DIAMETER_INVALID_HDR_BITS 3008 A request was received whose bits in the Diameter header were either set to an invalid combination, or to a value that is inconsistent with the command code's definition.
DIAMETER_INVALID_HDR_BITS 3008 Diameterヘッダーのビットが無効な組み合わせに設定されているか、コマンドコードの定義と矛盾する値に設定されている要求を受信しました。
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.
DIAMETER_INVALID_AVP_BITS 3009フラグビットが認識されない値に設定されているAVPを含む要求、またはAVPの定義と矛盾する要求が受信されました。
DIAMETER_UNKNOWN_PEER 3010 A CER was received from an unknown peer.
DIAMETER_UNKNOWN_PEER 3010 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.
一時的な障害のカテゴリに含まれるエラーは、要求が受信されたときに要求が満たされなかったことをピアに通知するために使用されますが、将来は要求を満たすことができる場合があります。
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_AUTHENTICATION_REJECTED 4001ユーザーの認証プロセスが失敗しました。おそらくユーザーが無効なパスワードを使用したことが原因です。ユーザーに新しいパスワードを要求した後にのみ、それ以上の試行を試行する必要があります。
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.
DIAMETER_OUT_OF_SPACE 4002 Diameterノードはアカウンティング要求を受信しましたが、一時的なスペース不足のため、それを安定したストレージにコミットできませんでした。
ELECTION_LOST 4003 The peer has determined that it has lost the election process and has therefore disconnected the transport connection.
ELECTION_LOST 4003ピアは、選択プロセスを失ったと判断したため、トランスポート接続を切断しました。
Errors that fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again.
永続的な失敗のカテゴリに該当するエラーは、要求が失敗したことをピアに通知するために使用され、再試行しないでください。
DIAMETER_AVP_UNSUPPORTED 5001 The peer received a message that contained an AVP that is not recognized or supported and was marked with the Mandatory bit. A Diameter message with this error MUST contain one or more Failed-AVP AVP containing the AVPs that caused the failure.
DIAMETER_AVP_UNSUPPORTED 5001ピアは、認識またはサポートされておらず、必須ビットでマークされたAVPを含むメッセージを受信しました。このエラーのあるDiameterメッセージには、失敗の原因となったAVPを含む1つ以上のFailed-AVP AVPが含まれている必要があります。
DIAMETER_UNKNOWN_SESSION_ID 5002 The request contained an unknown Session-Id.
DIAMETER_UNKNOWN_SESSION_ID 5002リクエストに不明なセッションIDが含まれていました。
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_AUTHORIZATION_REJECTED 5003ユーザーを承認できないリクエストを受け取りました。このエラーは、要求されたサービスがユーザーに許可されていない場合に発生する可能性があります。
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.
DIAMETER_INVALID_AVP_VALUE 5004リクエストのデータ部分に無効な値を持つAVPが含まれていました。このエラーを示すDiameterメッセージには、Failed-AVP AVP内の問題のAVPが含まれている必要があります。
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.
DIAMETER_MISSING_AVP 5005要求には、コマンドコード定義で必要なAVPが含まれていませんでした。この値がResult-Code AVPで送信される場合、Failed-AVP AVPがメッセージに含まれる必要があります。 Failed-AVP AVPには、該当する場合、Vendor-Idを備えた欠落AVPの例を含める必要があります。欠落しているAVPの値フィールドは、正しい最小長で、ゼロが含まれている必要があります。
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 a user that is restricted to one dial-up PPP port, attempts to establish a second PPP connection.
DIAMETER_RESOURCES_EXCEEDED 5006ユーザーが既に許可されたリソースを消費しているため、承認できない要求を受け取りました。このエラー状態の例は、1つのダイヤルアップPPPポートに制限され、2番目のPPP接続を確立しようとするユーザーです。
DIAMETER_CONTRADICTING_AVPS 5007 The Home Diameter server has detected AVPs in the request that contradicted each other, and is not willing to provide service to the user. One or more Failed-AVP AVPs MUST be present, containing the AVPs that contradicted each other.
DIAMETER_CONTRADICTING_AVPS 5007 Home Diameterサーバーは、互いに矛盾する要求でAVPを検出し、ユーザーにサービスを提供する用意がありません。 1つ以上のFailed-AVP AVPが存在しなければならず、互いに矛盾したAVPが含まれています。
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.
DIAMETER_AVP_NOT_ALLOWED 5008存在してはならないAVPを含むメッセージが受信されました。 Failed-AVP AVPが含まれていて、問題のAVPのコピーを含んでいる必要があります。
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
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009メッセージ定義で許可されているよりも頻繁に出現するAVPを含むメッセージが受信されました。 Failed-AVP AVPが含まれている必要があり、最大発生回数を超えた問題のAVPの最初のインスタンスのコピーが含まれている必要があります。
DIAMETER_NO_COMMON_APPLICATION 5010 This error is returned when a CER message is received, and there are no common applications supported between the peers.
DIAMETER_NO_COMMON_APPLICATION 5010このエラーは、CERメッセージを受信したときに返され、ピア間でサポートされる共通のアプリケーションはありません。
DIAMETER_UNSUPPORTED_VERSION 5011 This error is returned when a request was received, whose version number is unsupported.
DIAMETER_UNSUPPORTED_VERSION 5011このエラーは、要求が受信されたときに返されます。バージョン番号はサポートされていません。
DIAMETER_UNABLE_TO_COMPLY 5012 This error is returned when a request is rejected for unspecified reasons.
DIAMETER_UNABLE_TO_COMPLY 5012このエラーは、不特定の理由でリクエストが拒否された場合に返されます。
DIAMETER_INVALID_BIT_IN_HEADER 5013 This error is returned when an unrecognized bit in the Diameter header is set to one (1).
DIAMETER_INVALID_BIT_IN_HEADER 5013このエラーは、Diameterヘッダーの認識されないビットが1に設定されている場合に返されます。
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.
DIAMETER_INVALID_AVP_LENGTH 5014リクエストに無効な長さのAVPが含まれていました。このエラーを示すDiameterメッセージには、Failed-AVP AVP内の問題のAVPが含まれている必要があります。
DIAMETER_INVALID_MESSAGE_LENGTH 5015 This error is returned when a request is received with an invalid message length.
DIAMETER_INVALID_MESSAGE_LENGTH 5015このエラーは、無効なメッセージ長でリクエストを受信した場合に返されます。
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.
DIAMETER_INVALID_AVP_BIT_COMBO 5016リクエストには、AVPフラグフィールドに指定された値を持つことを許可されていないAVPが含まれていました。このエラーを示すDiameterメッセージには、Failed-AVP AVP内の問題のAVPが含まれている必要があります。
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) MUST be returned with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY.
DIAMETER_NO_COMMON_SECURITY 5017このエラーは、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 ABNF specification for the command, and will instead conform to the following ABNF: Message Format
Diameterヘッダーの「E」（エラービット）は、リクエストがプロトコル関連のエラーを引き起こしたときに設定されます（セクション7.1.3を参照）。 「E」ビットを含むメッセージは、応答メッセージへの応答として送信してはなりません。 「E」ビットが設定されたメッセージは、セクション6.2で定義された処理ルールに従うことに注意してください。設定すると、応答メッセージはコマンドのABNF仕様に準拠せず、代わりに次のABNFに準拠します。メッセージフォーマット
<answer-message> ::= < Diameter Header: code, ERR [PXY] >
0*1< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ Origin-State-Id ]
[ Error-Reporting-Host ]
[ 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 real-time, and SHOULD NOT be expected to be parsed by network entities.
エラーメッセージAVP（AVPコード281）のタイプはUTF8Stringです。人間が読めるエラーメッセージとしてResult-Code AVPを伴う場合があります。 Error-Message AVPは、リアルタイムでの使用を意図したものではなく、ネットワークエンティティによって解析されることは想定されていません（SHOULD NOT）。
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 MUST be set when the Result-Code AVP indicates a failure.
Error-Reporting-Host AVP（AVPコード294）のタイプはDiameterIdentityです。このAVPには、Result-Code AVPを送信したDiameterホストのIDが2001（成功）以外の値に含まれます。これは、Result-Codeを設定するホストがOrigin-Host AVPでエンコードされたものと異なる場合のみです。この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.
Failed-AVP AVP（AVPコード279）はグループ化されたタイプであり、特定のAVPの誤った情報が原因でリクエストが拒否された場合や完全に処理されなかった場合のデバッグ情報を提供します。 Result-Code AVPの値は、Failed-AVP 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 which 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 MAY 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.
Diameterメッセージには、正常に処理できなかったAVP全体を含む1つのFailed-AVP AVPが含まれる場合があります。失敗の理由が必要なAVPの省略、AVPコードが欠落しているAVP、欠落しているベンダーID、および省略された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. Its Data field has the following ABNF grammar:
実験結果AVP（AVPコード297）はグループ化されたタイプであり、特定のベンダー固有の要求が正常に完了したかどうか、またはエラーが発生したかどうかを示します。そのデータフィールドには、次のABNF文法があります。
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 which 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に指定された同じ規則に従うことをお勧めします。
Diameter can provide two different types of services to applications. The first involves authentication and authorization, and 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 use 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 the home realm is willing to be fiscally responsible for. 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 is 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.
サービスがDiameterプロトコルのアカウンティング部分のみを使用する場合、アプリケーションと組み合わせても、Session-Idはユーザーセッションの識別に使用されます。ただし、アカウンティング停止メッセージを発行することでセッションが終了したことを通知するため、セッション終了メッセージは使用されません。
This section contains a set of finite state machines, representing 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.
Diameter基本プロトコルでサポートされている4つの異なる承認セッションステートマシンがあります。最初の2つは、サーバーがセッション状態を維持しているセッションを示し、Auth-Session-State AVP（またはその不在）の値によって示されます。 1つはクライアントの観点からセッションを説明し、もう1つはサーバーの観点から説明します。 2番目の2つの状態マシンは、サーバーがセッション状態を維持しない場合に使用されます。ここでも、1つはクライアントの観点からセッションを説明し、もう1つはサーバーの観点から説明します。
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 as an error condition, and an answer, if applicable, MUST be returned to the originator of the message.
セッションがアイドル状態に移行すると、特定のセッションに割り当てられていたすべてのリソースを解放する必要があります。状態マシンにリストされていないイベントはエラー状態と見なされなければならず、該当する場合は、メッセージの発信者に応答が返されなければなりません（MUST）。
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
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 Cleanup Idle authorization answer received
保留中の失敗したサービス固有のCleanup Idle承認応答を受け取りました
Open User or client device Send Open requests access to service service specific auth req
ユーザーまたはクライアントデバイスを開くサービスサービス固有の認証要求へのアクセスを開く要求の送信
Open Successful Service-specific Provide Open authorization answer received Service
Open成功したサービス固有のOpen承認の回答を受け取ったサービス
Open Failed Service-specific Discon. Idle authorization answer user/device received.
失敗したサービス固有のDisconを開きます。アイドル認証応答ユーザー/デバイスを受信しました。
Open Session-Timeout Expires on Send STR Discon Access Device
送信STR Disconアクセスデバイスでのオープンセッションタイムアウトの期限切れ
Open ASR Received, Send ASA Discon client will comply with with request to end the session Result-Code = SUCCESS, Send STR.
開いたASRを受信し、ASA Disconクライアントを送信すると、セッションを終了する要求に準拠します。結果コード= SUCCESS、送信STR。
Open ASR Received, Send ASA Open client will not comply with with request to end the session Result-Code != 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 ASR受信Send ASA Discon
Discon STA Received Discon. Idle user/device
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 serv.
specific answer
Idle Service-specific authorization Send Idle request received, and failed serv. user is not authorized specific answer
Idleサービス固有の承認Send Idleリクエストを受信し、servに失敗しました。ユーザーは特定の回答を許可されていません
Open Service-specific authorization Send Open request received, and user successful is authorized serv. specific answer
Open Service固有の認証Open Openリクエストを受信し、成功したユーザーは認証されたservです。具体的な答え
Open Service-specific authorization Send Idle request received, and user failed serv. is not authorized specific answer, Cleanup
Open Service固有の認証Send Idleリクエストを受信し、ユーザーがservに失敗しました。承認された特定の回答ではありません、クリーンアップ
Open Home server wants to Send ASR Discon terminate the service
Open HomeサーバーがASR Disconを送信してサービスを終了したい
Open Authorization-Lifetime (and Cleanup Idle Auth-Grace-Period) expires on home server.
Open Authorization-Lifetime（およびCleanup Idle Auth-Grace-Period）がホームサーバーで期限切れになります。
Open Session-Timeout expires on Cleanup Idle home server
クリーンアップアイドルホームサーバーでオープンセッションタイムアウトが期限切れになる
Discon Failure to send ASR Wait, Discon resend ASR
DisconはASR待機の送信に失敗し、DisconはASRを再送信します
Discon ASR successfully sent and Cleanup Idle ASA Received with Result-Code
Discon ASRが正常に送信され、結果コードでアイドルASAがクリーンアップされました
Not ASA Received None No Change. Discon
ASAが受信しませんなし変化なし。 Discon
Any STR Received Send STA, Idle Cleanup.
任意の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 Cleanup Idle authorization answer received
保留中の失敗したサービス固有のCleanup Idle承認応答を受け取りました
Open Session-Timeout Expires on Discon. Idle Access Device user/device
DisconでOpen Session-Timeout Expires。アイドルアクセスデバイスユーザー/デバイス
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 serv. Idle
request received, and specific
successfully processed 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.
アカウンティングステートマシンのサーバー側は、特定のアプリケーションに依存する場合があります。 Diameter基本プロトコルは、他の状態マシンを指定していないすべてのアプリケーションが従わなければならないデフォルトの状態マシンを定義します。これは、以下で説明するこのセクションの2番目のステートマシンです。
The default server side state machine requires the reception of accounting records in any order and at any time, and 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. Both base Diameter AVPs as well as application specific AVPs MAY 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 limits checks, and so on.
デフォルトのサーバー側のステートマシンでは、アカウンティングレコードを任意の順序でいつでも受信する必要があり、これらのレコードの処理に関する標準要件はありません。 Diameterの実装は、これらのレコードに基づいて、チェック、順序付け、相関、不正検出、およびその他のタスクを実行する場合があります。これらのタスクの一部として、基本Diameter AVPとアプリケーション固有のAVPの両方を検査できます（MAY）。タスクは、レコードの受信直後または後処理フェーズで発生する可能性があります。ただし、これらのタスクは通常アプリケーションまたはポリシーに依存するため、Diameter仕様によって標準化されていません。アプリケーションは、Accounting-Realtime-Required AVP、信用限度チェックなどの使用された値に基づいて、いつ会計記録を受け入れるかについての要件を定義する場合があります。
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, and 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, which the 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クライアントが目的の宛先と通信できないことを意味します。これは、ピアがダウンしているか、ピアが一時的な障害または一時的なプロトコルエラー通知DIAMETER_OUT_OF_SPACE、DIAMETER_TOO_BUSY、またはDIAMETER_LOOP_DETECTEDをAccounting AnswerコマンドのResult-Code AVPに送信したことが原因である可能性があります。
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 have an effect also to 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 realtime Start not equal to DELIVER_AND_GRANT Record
PendingS送信およびストアオープンスペースのバッファリングに失敗し、使用可能なリアルタイムスペースがDELIVER_AND_GRANTレコードと等しくありません
PendingS Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE
PendingS送信に失敗し、バッファがありません。使用可能な空き領域があり、リアルタイムはGRANT_AND_LOSEと同じです
PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE
PendingS送信に失敗し、バッファーが切断されないアイドルスペースが利用可能であり、リアルタイムのユーザー/デバイスがGRANT_AND_LOSEと等しくない
PendingS Failed accounting start answer Open received and realtime equal to GRANT_AND_LOSE
PendingS失敗したアカウンティング開始応答Openが受信され、リアルタイムはGRANT_AND_LOSEに等しい
PendingS Failed accounting start answer Disconnect Idle received and realtime not user/dev equal to GRANT_AND_LOSE
PendingS失敗したアカウンティング開始応答切断アイドルを受信し、リアルタイムではないユーザー/デバイスがGRANT_AND_LOSEに等しい
PendingS User service terminated Store PendingS stop record
PendingSユーザーサービスが終了しましたStore PendingS停止レコード
Open Interim interval elapses Send PendingI accounting interim record Open User service terminated Send PendingL accounting stop req.
オープン暫定間隔が経過しましたPendingIアカウンティング中間レコードを送信しますOpen Userサービスが終了しましたPendingLアカウンティング停止要求を送信しました。
PendingI Successful accounting interim Open answer received
PendingI成功した会計中間オープン回答を受け取りました
PendingI Failure to send and (buffer Store Open space available or old record interim can be overwritten) and record realtime not equal to DELIVER_AND_GRANT
PendingI送信に失敗し、（バッファストアオープンスペースが利用可能であるか、古いレコードの中間が上書きされる可能性があります）、リアルタイムの記録がDELIVER_AND_GRANTと等しくない
PendingI Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE
PendingI送信に失敗し、バッファオープンスペースがなく、リアルタイムはGRANT_AND_LOSEに等しい
PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE
PendingI送信に失敗し、バッファーが切断されず、アイドルスペースが利用可能であり、リアルタイムのユーザー/デバイスがGRANT_AND_LOSEと等しくない
PendingI Failed accounting interim Open answer received and realtime equal to GRANT_AND_LOSE
PendingI失敗したアカウンティング暫定オープン回答を受け取り、リアルタイムはGRANT_AND_LOSEに等しい
PendingI Failed accounting interim Disconnect Idle answer received and realtime user/dev 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がアイドル送信に失敗
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 Interimレコードを受信し、Idleを送信して正常に処理されました。会計中間回答
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
アイドルアカウンティング開始要求Send Openを受信し、アカウンティングが正常に処理されました。回答を開始、TSを開始
Idle Accounting event request Send Idle received, and successfully accounting processed. event answer
Idle Accountingイベント要求Send Idleを受信し、正常にアカウンティングが処理されました。イベント回答
Idle Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE
アイドルアカウンティング要求を受信しました。アカウンティングレコードを格納するためのスペースが残っていません。結果コード= 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
オープンアカウンティング停止要求送信アイドルを受信し、アカウンティングが正常に処理された停止応答、ストップTs
Open Accounting request received, Send Idle no space left to store accounting records answer, Result-Code = OUT_OF_ SPACE, Stop Ts
オープンアカウンティング要求を受信しました、アカウンティングレコードを格納するための空きスペースをアイドルに送信しません回答、結果コード= OUT_OF_ SPACE、ストップTs
Open Session supervision timer Ts Stop Ts Idle expired
オープンセッション監視タイマーTs Stop Ts Idleの期限切れ
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 pre-paid 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 a RAR message with 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 service-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.
Command-Codeが258に設定され、メッセージフラグの「R」ビットが設定されていることで示されるRe-Auth-Request（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 indicates the disposition of the request.
Command-Codeが258に設定され、メッセージフラグの「R」ビットがクリアされていることで示されるRe-Auth-Answer（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-Host-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 expires 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 the access device to inform the Diameter Server that an authenticated and/or authorized session is being terminated.
コマンドコードが275に設定され、コマンドフラグの「R」ビットが設定されていることで示されるセッション終了要求（STR）は、認証済みまたは承認済みのセッションが存在することを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 MAY contain an indication that an error occurred while servicing the STR.
セッションコードが275に設定され、メッセージフラグの「R」ビットがクリアされていることで示されるセッション終了応答（STA）は、セッションが終了したという通知を確認するためにDiameterサーバーによって送信されます。 Result-Code AVPが存在しなければならず（MUST）、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 credit or other reasons that were not anticipated when the session was first authorized. On the other hand, an operator may maintain a management server for the purpose of issuing ASRs to administratively remove users from the network.
たとえば、最初にセッションを承認したDiameterサーバーは、クレジットまたはセッションが最初に承認されたときに予期されなかったその他の理由により、そのセッションを停止させる必要がある場合があります。一方、オペレーターは、ASRを発行してユーザーをネットワークから管理上削除する目的で、管理サーバーを維持する場合があります。
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で応答し、どのアクションを実行したかを示す必要があります。
Note that if the access device does stop the session upon receipt of an ASR, it issues an STR to the authorizing server (which may or may not be the agent issuing the ASR) just as it would if the session were terminated for any other reason.
アクセスデバイスがASRの受信時にセッションを停止する場合、他の理由でセッションが終了した場合と同様に、認証サーバー（ASRを発行するエージェントである場合とそうでない場合がある）にSTRを発行することに注意してください。 。
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 server to the access device that is providing session service, to request that the session identified by the Session-Id be stopped.
274に設定されたCommand-Codeとメッセージフラグの「R」ビットセットによって示されるAbort-Session-Request（ASR）は、任意のサーバーからセッションサービスを提供しているアクセスデバイスに送信され、 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.
Abort-Session-Answer（ASA）は、コマンドコードが274に設定され、メッセージフラグの「R」ビットがクリアされていることで、ASRに応答して送信されます。 Result-Code AVPが存在しなければならず（MUST）、要求の処理を示します。
If the session identified by Session-Id in the ASR was successfully terminated, Result-Code is set to DIAMETER_SUCCESS. If the session is not currently active, Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the session for any other reason, 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 ]
Origin-State-Id is used to allow rapid detection of terminated sessions for which no STR would have been issued, due to unanticipated shutdown of an access device.
Origin-State-Idを使用すると、アクセスデバイスの予期しないシャットダウンが原因で、STRが発行されなかった終了したセッションを迅速に検出できます。
By including Origin-State-Id in CER/CEA messages, an access device allows a next-hop server to determine immediately upon connection whether the device has lost its sessions since the last connection.
CER / CEAメッセージにOrigin-State-Idを含めることにより、アクセスデバイスは、ネクストホップサーバーが最後の接続以降にデバイスがセッションを失ったかどうかを接続直後に判断できます。
By including Origin-State-Id in request messages, an access device also allows a server with which it communicates via proxy to make such a determination. However, a server that is not directly connected with the access device will not discover that the access device has been restarted unless and until it receives a new request from the access device. Thus, use of this mechanism across proxies is opportunistic rather than reliable, but useful nonetheless.
要求メッセージにOrigin-State-Idを含めることにより、アクセスデバイスは、プロキシを介して通信するサーバーがそのような決定を行うこともできます。ただし、アクセスデバイスに直接接続されていないサーバーは、アクセスデバイスから新しい要求を受信しない限り、アクセスデバイスが再起動されたことを検出しません。したがって、プロキシ間でのこのメカニズムの使用は、信頼できるというよりは日和見的ですが、それでも有用です。
When a Diameter server receives an Origin-State-Id that is greater than the Origin-State-Id previously received from the same issuer, it may assume that the issuer has lost state since the previous message and that all sessions that were active under the lower Origin-State-Id have been terminated. The Diameter server MAY clean up all session state associated with such lost sessions, and MAY also issues STRs for all such lost sessions that were authorized on upstream servers, to allow session state to be cleaned up globally.
Diameterサーバーが同じ発行者から以前に受け取ったOrigin-State-Idよりも大きいOrigin-State-Idを受け取った場合、前のメッセージ以降に発行者が状態を失ったと想定し、すべてのセッションがより低いOrigin-State-Idは終了しました。 Diameterサーバーは、失われたセッションに関連するすべてのセッション状態をクリーンアップできます。また、上流のサーバーで承認された失われたすべてのセッションに対してSTRを発行して、セッション状態をグローバルにクリーンアップできるようにする場合があります。
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 The request being sent is for authentication only, and MUST contain the relevant application specific authentication AVPs that are needed by the Diameter server to authenticate the user.
AUTHENTICATE_ONLY 1送信される要求は認証専用であり、Diameterサーバーがユーザーを認証するために必要な、関連するアプリケーション固有の認証AVPを含んでいる必要があります。
AUTHORIZE_ONLY 2 The request being sent is for authorization only, and MUST contain the application specific authorization AVPs that are necessary to identify the service being requested/offered.
AUTHORIZE_ONLY 2送信される要求は承認のみを目的としており、要求/提供されるサービスを識別するために必要なアプリケーション固有の承認AVPを含める必要があります。
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.
AUTHORIZE_AUTHENTICATE 3要求には、認証と承認の両方の要求が含まれています。リクエストには、関連するアプリケーション固有の認証情報と、リクエスト/提供されるサービスを識別するために必要な承認情報の両方を含める必要があります。
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 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.4). The remainder of the Session-Id is delimited by a ";" character, and 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.4を参照）。 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, 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ビットは時間に初期化されてもよく（MAY）、下位32ビットはゼロに初期化されてもよい（MAY）。これにより、再起動プロセスに1秒以上かかると仮定して、再起動後にSession-Idが重複する可能性がなくなります。あるいは、実装は不揮発性メモリの増加する値を追跡してもよい（MAY）。
<optional value> is implementation specific but may include a modem's device Id, a layer 2 address, timestamp, etc.
<オプション値>は実装固有ですが、モデムのデバイスID、レイヤー2アドレス、タイムスタンプなどを含めることができます。
Example, in which there is no optional value: accesspoint7.acme.com;1876543210;523
オプションの値がない例：accesspoint7.acme.com; 1876543210; 523
Example, in which there is an optional value:
accesspoint7.acme.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 authorization and accounting commands of a given application.
セッションIDは、セッションを開始するDiameterアプリケーションによって作成されます。これは、ほとんどの場合、クライアントによって行われます。セッション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. Great 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. This is typically used in cases where multiple authentication methods are used, and a successful auth response with this AVP set to zero is used to signal that the next authentication method is to be immediately initiated. 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がゼロに設定された成功した認証応答を使用して、次の認証方法がすぐに開始されることを通知します。この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 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. However, the server MAY return a value that is equal to, or smaller, than the one provided by the client.
このAVPは、クライアントが受け入れ可能な最大有効期間のヒントとしてクライアントから提供される場合があります。ただし、サーバーは、クライアントによって提供された値以下の値を返す場合があります。
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 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.
STATE_MAINTAINED 0この値は、セッション状態が維持されていることを指定するために使用され、アクセスデバイスは、ユーザーへのサービスが終了したときにセッション終了メッセージを発行する必要があります。これがデフォルト値です。
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.
NO_STATE_MAINTAINED 1この値は、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. 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: 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.
Re-Auth-Request-Type AVP（AVPコード285）は列挙型であり、アプリケーション固有の認証応答に含まれており、Authorization-Lifetimeの期限切れ時に予期されるアクションをクライアントに通知します。応答メッセージに正の値のAuthorization-Lifetime AVPが含まれている場合、Re-Auth-Request-Type AVPが応答メッセージに存在する必要があります。次の値が定義されています。AUTHORIZE_ONLY 0 Authorization-Lifetimeの期限が切れると、認証のみの再認証が期待されます。これは、Authorization-Lifetimeを含む応答メッセージにAVPが存在しない場合のデフォルト値です。
AUTHORIZE_AUTHENTICATE 1 An authentication and authorization re-auth is expected upon expiration of the Authorization-Lifetime.
AUTHORIZE_AUTHENTICATE 1 Authorization-Lifetimeの期限が切れると、認証と承認の再認証が期待されます。
The Session-Timeout AVP (AVP Code 27) [RADIUS] 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）[RADIUS]は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.9).
アクセスデバイスとホームサーバーの両方が以前にセッション終了メッセージを送信しないことに同意していない限り、セッションタイムアウトの期限切れのためにアクセスデバイスで終了するセッションは、STRを発行する必要があります（セクション8.9を参照）。 。
A Session-Timeout AVP MAY be present in a re-authorization answer message, and 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) [RADIUS] is of type UTF8String, which contains the User-Name, in a format consistent with the NAI specification [NAI].
ユーザー名AVP（AVPコード1）[RADIUS]は、UTF8Stringタイプであり、NAI仕様[NAI]と一致する形式でユーザー名を含みます。
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 following values are defined: DIAMETER_LOGOUT 1 The user initiated a disconnect
Termination-Cause AVP（AVPコード295）は列挙型であり、セッションがアクセスデバイスで終了した理由を示すために使用されます。次の値が定義されています。DIAMETER_LOGOUT 1ユーザーが切断を開始しました
DIAMETER_SERVICE_NOT_PROVIDED 2 This value is used when the user disconnected prior to the receipt of the authorization answer message.
DIAMETER_SERVICE_NOT_PROVIDED 2この値は、ユーザーが認証応答メッセージを受信する前に切断したときに使用されます。
DIAMETER_BAD_ANSWER 3 This value indicates that the authorization answer received by the access device was not processed successfully.
DIAMETER_BAD_ANSWER 3この値は、アクセスデバイスが受信した認証応答が正常に処理されなかったことを示します。
DIAMETER_ADMINISTRATIVE 4 The user was not granted access, or was disconnected, due to administrative reasons, such as the receipt of a Abort-Session-Request message.
DIAMETER_ADMINISTRATIVE 4 Abort-Session-Requestメッセージの受信などの管理上の理由により、ユーザーはアクセスを許可されなかったか、接続が切断されました。
DIAMETER_LINK_BROKEN 5 The communication to the user was abruptly disconnected.
DIAMETER_LINK_BROKEN 5ユーザーへの通信が突然切断されました。
DIAMETER_AUTH_EXPIRED 6 The user's access was terminated since its authorized session time has expired.
DIAMETER_AUTH_EXPIRED 6承認されたセッション時間が経過したため、ユーザーのアクセスが終了しました。
DIAMETER_USER_MOVED 7 The user is receiving services from another access device.
DIAMETER_USER_MOVED 7ユーザーは別のアクセスデバイスからサービスを受信しています。
DIAMETER_SESSION_TIMEOUT 8 The user's session has timed out, and service has been terminated.
DIAMETER_SESSION_TIMEOUT 8ユーザーのセッションがタイムアウトし、サービスが終了しました。
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.
Origin-State-Idが存在する場合は、Origin-Hostによって示されるエンティティの状態を反映する必要があります。プロキシがOrigin-Hostを変更する場合、Origin-State-Idを削除するか、適切に変更する必要があります。
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-State-Idをメッセージに含めることで、他のDiameterエンティティは、より低いOrigin-State-Idに関連付けられたセッションがアクティブではなくなったと推測できます。アクセスデバイスがそのような推論が行われることを意図していない場合は、メッセージにOrigin-State-Idを含めないか、その値を0に設定する必要があります。
The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and 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 messages for this session MUST be sent to the same authorization server. This AVP MAY also specify that a Session-Termination-Request message for this session MUST be sent to the same authorizing server.
セッションバインディングAVP（AVPコード270）はタイプUnsigned32であり、アプリケーション固有の承認応答メッセージに存在する場合があります。存在する場合、このAVPは、Diameterクライアントに、このセッションのすべての将来のアプリケーション固有の再認証メッセージを同じ認証サーバーに送信する必要があることを通知できます（MAY）。このAVPは、このセッションのSession-Termination-Requestメッセージを同じ認証サーバーに送信する必要があることも指定できます（MAY）。
This field is a bit mask, and the following bits have been defined:
このフィールドはビットマスクであり、次のビットが定義されています。
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.
RE_AUTH 1設定されている場合、このセッションの今後の再認証メッセージには、Destination-Host AVPを含めることはできません。オフにすると、デフォルト値のDestination-Host AVPが、このセッションのすべての再認証メッセージに存在する必要があります。
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 2設定されている場合、このセッションのSTRメッセージに宛先ホストAVPを含めてはなりません（MUST NOT）。オフにすると、デフォルト値のDestination-Host AVPがこのセッションのSTRメッセージに存在する必要があります。
ACCOUNTING 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.
ACCOUNTING 4設定されている場合、このセッションのすべてのアカウンティングメッセージには、Destination-Host 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 If either the re-auth or the STR message delivery fails, terminate service with the user, and do not attempt any subsequent attempts.
REFUSE_SERVICE 0再認証またはSTRメッセージの配信に失敗した場合は、ユーザーとのサービスを終了し、その後の試行は行わないでください。
TRY_AGAIN 1 If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present.
TRY_AGAIN 1再認証またはSTRメッセージ配信のいずれかが失敗した場合、Destination-Host AVPが存在しない状態で失敗したメッセージを再送信します。
ALLOW_SERVICE 2 If re-auth message delivery fails, assume that re-authorization succeeded. If STR message delivery fails, terminate the session.
ALLOW_SERVICE 2再認証メッセージの配信に失敗した場合は、再認証が成功したと見なします。 STRメッセージの配信に失敗した場合は、セッションを終了します。
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.
TRY_AGAIN_ALLOW_SERVICE 3再認証または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 to 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 [ACCMGMT] have been built in to the protocol in order minimize loss of accounting data in various fault situations and under different assumptions about the capabilities of the used devices.
このアカウンティングプロトコルは、アカウンティング情報のリアルタイム配信機能を備えたサーバー向けモデルに基づいています。さまざまな障害状況で、使用するデバイスの機能に関するさまざまな想定の下でのアカウンティングデータの損失を最小限に抑えるために、プロトコルにはいくつかの障害回復方法[ACCMGMT]が組み込まれています。
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 [ACCMGMT], 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.
[ACCMGMT]で説明されているように、与信限度チェックや不正検出の実行など、会計記録のリアルタイム転送が必要です。バッチアカウンティングは必須ではないため、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 realtime 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の1つが存在する場合、受け取った最新の値を、同じセッションの以降のアカウンティングアクティビティで使用する必要があります（SHOULD）。
A Diameter node that receives a successful authentication and/or authorization messages from the Home AAA server MUST collect accounting information for the session. The Accounting-Request message is used to transmit the accounting information to the Home AAA 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. A rejected Accounting-Request message MAY cause the user's session to be terminated, depending on the value of the Accounting-Realtime-Required AVP received earlier for the session in question.
ホームAAAサーバーから正常な認証および/または承認メッセージを受信するDiameterノードは、セッションのアカウンティング情報を収集する必要があります。 Accounting-Requestメッセージは、アカウンティング情報をホームAAAサーバーに送信するために使用されます。ホームAAAサーバーは、受信を確認するためにAccounting-Answerメッセージで応答する必要があります。 Accounting-Answerメッセージには、Result-Code AVPが含まれています。これは、アカウンティングメッセージにエラーが存在したことを示す場合があります。拒否されたAccounting-Requestメッセージは、問題のセッションについて以前に受信したAccounting-Realtime-Required AVPの値に応じて、ユーザーのセッションを終了させる場合があります。
Each Diameter Accounting protocol message MAY be compressed, in order to reduce network bandwidth usage. If IPsec and IKE are used to secure the Diameter session, then IP compression [IPComp] MAY be used and IKE [IKE] MAY be used to negotiate the compression parameters. If TLS is used to secure the Diameter session, then TLS compression [TLS] MAY be used.
ネットワーク帯域幅の使用量を削減するために、各Diameter Accountingプロトコルメッセージは圧縮される場合があります。 IPsecとIKEを使用してDiameterセッションを保護する場合、IP圧縮[IPComp]を使用してもよいし、IKE [IKE]を使用して圧縮パラメータをネゴシエートしてもよい（MAY）。 TLSを使用してDiameterセッションを保護する場合は、TLS圧縮[TLS]を使用できます。
Each Diameter application (e.g., NASREQ, MobileIP), MUST define their Service-Specific AVPs that MUST be present in the Accounting-Request message in a section entitled "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 this section.
各Diameterアプリケーション（NASREQ、MobileIPなど）は、「Accounting AVPs」というタイトルのセクションのAccounting-Requestメッセージに存在する必要があるサービス固有のAVPを定義する必要があります。アプリケーションは、このドキュメントで説明されているAVPがすべてのアカウンティングメッセージに存在すると想定する必要があるため、このセクションでは、それぞれのサービス固有のAVPのみを定義する必要があります。
Diameter Base protocol mechanisms are used to overcome small message loss and network faults of temporary nature.
Diameter Baseプロトコルメカニズムは、一時的な性質の小さなメッセージ損失とネットワーク障害を克服するために使用されます。
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 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 starting sending the records in the non-volatile memory to the accounting server with 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 how many accounting records may at most 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 oldest, undelivered or 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. If strong authentication across agents is required, end-to-end security may be used for authentication purposes.
すべてのアカウンティングレコードには、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_RECORD 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アプリケーション仕様では、使用する必要があるシーケンスのタイプを定義する必要があります。
The Diameter protocol's Session-Id AVP, which is globally unique (see Section 8.8), is used during the authorization phase to identify a particular session. Services that do not require any authorization still use the Session-Id AVP to identify sessions. Accounting messages MAY use a different Session-Id from that sent in authorization messages. Specific applications MAY require different a Session-ID for accounting messages.
DiameterプロトコルのセッションID AVPは、グローバルに一意であり（セクション8.8を参照）、認証フェーズ中に特定のセッションを識別するために使用されます。承認を必要としないサービスでも、Session-Id AVPを使用してセッションを識別します。アカウンティングメッセージは、許可メッセージで送信されたものとは異なるSession-Idを使用する場合があります。特定のアプリケーションでは、アカウンティングメッセージに異なるセッションIDが必要になる場合があります。
However, there are certain applications that require multiple accounting sub-sessions. Such applications would send messages with a constant Session-Id AVP, but a different Accounting-Sub-Session-Id AVP. In these cases, correlation is performed using the Session-Id. It is important to 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.
ただし、複数の会計サブセッションを必要とする特定のアプリケーションがあります。このようなアプリケーションは、一定のセッションID AVPを使用してメッセージを送信しますが、アカウンティングサブセッションID AVPは異なります。これらの場合、相関はSession-Idを使用して実行されます。最初にサブセッションがSTART_RECORDメッセージで使用されたときに、Accounting-Sub-Session-Id AVPなしでSTOP_RECORDを受信すると、すべてのサブセッションが終了することに注意してください。
Furthermore, there are certain applications where a user receives service from different access devices (e.g., Mobile IPv4), each with their own unique Session-Id. In such cases, the Acct-Multi-Session-Id AVP is used for correlation. During authorization, a server that determines that a request is for an existing session SHOULD include the Acct-Multi-Session-Id AVP, which the access device MUST include in all subsequent accounting messages.
さらに、ユーザーがさまざまなアクセスデバイス（モバイルIPv4など）からサービスを受け取る特定のアプリケーションがあり、それぞれが独自のセッションIDを持っています。このような場合、相関にはAcct-Multi-Session-Id AVPが使用されます。認可の間、要求が既存のセッションに対するものであることを決定するサーバーは、アクセスデバイスが後続のすべてのアカウンティングメッセージに含める必要があるAcct-Multi-Session-Id AVPを含める必要があります。
The Acct-Multi-Session-Id AVP MAY include the value of the original Session-Id. It's contents are implementation specific, but MUST be globally unique across other Acct-Multi-Session-Id, and MUST NOT change during the life of a session.
Acct-Multi-Session-Id AVPには、元のSession-Idの値が含まれる場合があります。その内容は実装固有ですが、他のAcct-Multi-Session-Id全体でグローバルに一意である必要があり、セッションの存続期間中に変更してはなりません。
A Diameter application document MUST define the exact concept of a session that is being accounted, and 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アプリケーションドキュメントは、説明されているセッションの正確な概念を定義しなければならず（MUST）、マルチセッションの概念を定義してもよい（MAY）。たとえば、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実装でサポートする必要があるCommand-Code値を定義します。
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ノードによって送信され、アカウンティング情報をピア。
One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present, it must have an Acct-Application-Id inside.
Acct-Application-IdおよびVendor-Specific-Application-Id AVPのいずれかが存在する必要があります。 Vendor-Specific-Application-Idグループ化されたAVPが存在する場合、内部にAcct-Application-Idが必要です。
The AVP listed below SHOULD include service specific accounting AVPs, as described in Section 9.3.
以下にリストされているAVPには、セクション9.3で説明されているように、サービス固有の会計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 ]
[ 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 and includes the usage AVPs only if CMS is in use when sending this command. Note that the inclusion of the usage AVPs when CMS is not being used leads to unnecessarily large answer messages, and can not be used as a server's proof of the receipt of these AVPs in an end-to-end fashion. If the Accounting-Request was protected by end-to-end security, then the corresponding ACA message MUST be protected by end-to-end security.
コマンドコードフィールドが271に設定され、コマンドフラグの「R」ビットがクリアされていることで示されるアカウンティング応答（ACA）コマンドは、アカウンティング要求コマンドを確認するために使用されます。 Accounting-Answerコマンドには同じSession-Idが含まれ、このコマンドを送信するときにCMSが使用されている場合にのみ使用法AVPが含まれます。 CMSが使用されていないときに使用AVPを含めると、応答メッセージが不必要に大きくなり、これらのAVPをエンドツーエンドで受信したことのサーバーの証拠として使用できないことに注意してください。 Accounting-Requestがエンドツーエンドのセキュリティによって保護されている場合、対応するACAメッセージはエンドツーエンドのセキュリティによって保護される必要があります。
Only the target Diameter Server, known as the home Diameter Server, SHOULD respond with the Accounting-Answer command.
ホームDiameterサーバーと呼ばれるターゲットDiameterサーバーのみが、Accounting-Answerコマンドで応答する必要があります。
One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present, it must have an Acct-Application-Id inside.
Acct-Application-IdおよびVendor-Specific-Application-Id AVPのいずれかが存在する必要があります。 Vendor-Specific-Application-Idグループ化されたAVPが存在する場合、内部にAcct-Application-Idが必要です。
The AVP listed below SHOULD include service specific accounting AVPs, as described in Section 9.3.
以下にリストされているAVPには、セクション9.3で説明されているように、サービス固有の会計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-Reporting-Host ]
[ 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 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 is the only record of the service.
EVENT_RECORD 1アカウンティングイベントレコードは、1回限りのイベントが発生したことを示すために使用されます（つまり、イベントの開始と終了が同時に発生します）。このレコードには、サービスに関連するすべての情報が含まれており、サービスの唯一のレコードです。
START_RECORD 2 An 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.
START_RECORD 2アカウンティングの開始、中間、および停止レコードは、測定可能な長さのサービスが提供されたことを示すために使用されます。アカウンティング開始レコードは、アカウンティングセッションを開始するために使用され、セッションの開始に関連するアカウンティング情報を含みます。
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.
INTERIM_RECORD 3中間アカウンティングレコードには、既存のアカウンティングセッションの累積アカウンティング情報が含まれます。中間認証レコードは、再認証または再認証が発生するたびに送信する必要があります。さらに、追加の中間レコードトリガーは、アプリケーション固有のDiameterアプリケーションによって定義される場合があります。 INTERIM_RECORDレコードを使用するかどうかの選択は、Acct-Interim-Interval AVPによって行われます。
STOP_RECORD 4 An Accounting Stop Record is sent to terminate an accounting session and contains cumulative accounting information relevant to the existing session.
STOP_RECORD 4アカウンティング停止レコードは、アカウンティングセッションを終了するために送信され、既存のセッションに関連する累積アカウンティング情報を含みます。
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 together 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 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 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 1値フィールドがDELIVER_AND_GRANTに設定されたAVPは、アカウンティングサーバーへの接続がある限り、サービスを許可する必要があることを意味します。この意味では、代替の会計サーバーのセットは1つのサーバーとして扱われることに注意してください。アカウンティングレコードストリームをバックアップサーバーに移動しなければならないのは、ユーザーへのサービスを中止する理由にはなりません。
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 2値フィールドが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 The AVP with Value field set to GRANT_AND_LOSE means that service SHOULD be granted even if the records can not be delivered or stored.
GRANT_AND_LOSE 3値フィールドがGRANT_AND_LOSEに設定されたAVPは、レコードを配信または保存できない場合でもサービスを許可する必要があることを意味します。
The following tables presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table.
次の表は、このドキュメントで定義されているAVPを示し、それらが存在する場合と存在しない場合のあるDiameterメッセージを示しています。グループ化されたAVP内にのみ存在できるAVPは、このテーブルには表示されないことに注意してください。
The table uses the following symbols:
この表では次の記号を使用しています。
0 The AVP MUST NOT be present in the message. 0+ Zero or more instances of the AVP MAY be present in the message. 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. 1 One instance of the AVP MUST be present in the message. 1+ At least one instance of the AVP MUST be present in the message.
0 AVPはメッセージに存在してはなりません。 0+ AVPのゼロ個以上のインスタンスがメッセージに存在する場合があります。 0-1 AVPのゼロまたは1つのインスタンスがメッセージに存在する場合があります。 AVPのインスタンスが複数ある場合は、エラーと見なされます。 1 AVPの1つのインスタンスがメッセージに存在する必要があります。 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+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |0 |0+ |
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 |0 |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 |
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-1 | 0-1 |
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 BCP 26 [IANA]. The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action".
このセクションでは、BCP 26 [IANA]に従って、Diameterプロトコルに関連する値の登録に関するInternet Assigned Numbers Authority（IANA）へのガイダンスを提供します。次のポリシーは、BCP 26で定義された意味でここで使用されます：「私的使用」、「先着順」、「専門家によるレビュー」、「必要な仕様」、「IETFコンセンサス」、「標準アクション」。
This section explains the criteria to be used by the IANA for assignment of numbers within namespaces defined within this document.
このセクションでは、このドキュメントで定義されている名前空間内の番号の割り当てにIANAが使用する基準について説明します。
Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting.
Diameterは、汎用プロトコルとして意図されたものではなく、認証、承認、またはアカウンティングとは無関係の目的で割り当てを行うことはできません。
For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. For Designated Expert with Specification Required, the request is posted to the AAA WG mailing list (or, if it has been disbanded, a successor designated by the Area Director) for comment and review, and MUST include a pointer to a public specification. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the AAA WG mailing list or its successor. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.
指定専門家に相談する必要がある登録要求については、担当IESGエリアディレクターが指定専門家を指名する必要があります。仕様が必要な指定エキスパートの場合、リクエストはコメントとレビューのためにAAA WGメーリングリスト（または解散された場合はエリアディレクターが指定した後継者）に投稿され、公開仕様へのポインターを含める必要があります。 30日が経過する前に、Designated Expertは登録要求を承認または拒否し、決定の通知をAAA WGメーリングリストまたはその後継者に公開します。拒否の通知は説明によって正当化する必要があり、可能な場合は、要求が受け入れられるように変更する方法に関する具体的な提案が必要です。
As defined in Section 4, the AVP header contains three fields that requires IANA namespace management; the AVP Code, Vendor-ID and Flags field.
セクション4で定義されているように、AVPヘッダーにはIANA名前空間の管理を必要とする3つのフィールドが含まれています。 AVPコード、ベンダーID、およびフラグフィールド。
The AVP Code namespace is used to identify attributes. There are multiple namespaces. Vendors can have their own AVP Codes namespace which 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 IANA controlled AVP Codes namespace. The AVP Codes and sometimes also possible values in an AVP are controlled and maintained by IANA.
AVPコード名前空間は、属性を識別するために使用されます。複数の名前空間があります。ベンダーは、ベンダーID（別名エンタープライズ番号）によって識別される独自のAVPコード名前空間を持つことができ、独自の名前空間内でベンダー固有のAVPコードの割り当てを制御します。 Vendor-IDまたはゼロ（0）のVendor-ID値がないことは、IETF IANA制御のAVPコード名前空間を識別します。 AVPコード、およびAVPで可能な値もIANAによって制御および維持されます。
AVP Code 0 is not used. AVP Codes 1-255 are managed separately as RADIUS Attribute Types [RADTYPE]. This document defines the AVP Codes 257-274, 276-285, 287, 291-300, 480, 483 and 485-486. See Section 4.5 for the assignment of the namespace in this specification.
AVPコード0は使用されません。 AVPコード1〜255は、RADIUS属性タイプ[RADTYPE]として個別に管理されます。このドキュメントでは、AVPコード257-274、276-285、287、291-300、480、483および485-486を定義しています。この仕様での名前空間の割り当てについては、セクション4.5を参照してください。
AVPs may be allocated following Designated Expert with Specification Required [IANA]. Release of blocks of AVPs (more than 3 at a time for a given purpose) should require IETF Consensus.
AVPは、仕様が必要な指定エキスパート[IANA]に従って割り当てることができます。 AVPのブロックのリリース（特定の目的で一度に3つ以上）を行うには、IETFの合意が必要です。
Note that Diameter defines a mechanism for Vendor-Specific AVPs, where the Vendor-Id field in the AVP header is set to a non-zero value. Vendor-Specific AVPs codes are for Private Use and should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of Diameter, where no interoperability is deemed useful. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs should be encouraged instead.
Diameterはベンダー固有のAVPのメカニズムを定義することに注意してください。AVPヘッダーのVendor-Idフィールドはゼロ以外の値に設定されます。ベンダー固有のAVPコードは私的使用のためのものであり、相互運用性が役に立たないと見なされるDiameterの1つのベンダーの実装にのみ固有の機能では、グローバル属性タイプの割り当ての代わりに推奨されます。ベンダー固有のAVPが複数のベンダーによって実装されている場合は、代わりにグローバルAVPの割り当てを推奨する必要があります。
There are 8 bits in the AVP Flags field of the AVP header, defined in Section 4. This document assigns bit 0 ('V'endor Specific), bit 1 ('M'andatory) and bit 2 ('P'rotected). The remaining bits should only be assigned via a Standards Action [IANA].
セクション4で定義されている、AVPヘッダーのAVPフラグフィールドには8ビットがあります。このドキュメントでは、ビット0（ 'V'エンダー固有）、ビット1（ 'M'andatory）、およびビット2（' P'rotected）を割り当てます。残りのビットは、標準アクション[IANA]を介してのみ割り当てる必要があります。
As defined in Section 3, the Diameter header contains two fields that require IANA namespace management; Command Code and Command Flags.
セクション3で定義されているように、Diameterヘッダーには、IANA名前空間の管理を必要とする2つのフィールドが含まれています。コマンドコードとコマンドフラグ。
The Command Code namespace is used to identify Diameter commands. The values 0-255 are reserved for RADIUS backward compatibility, and are defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values 256- 16,777,213 are for permanent, standard commands, allocated by IETF Consensus [IANA]. This document defines the Command Codes 257, 258, 271, 274-275, 280 and 282. See Section 3.1 for the assignment of the namespace in this specification.
コマンドコード名前空間は、Diameterコマンドを識別するために使用されます。値0〜255は、RADIUS下位互換性のために予約されており、[RADTYPE]で「RADIUSパケットタイプコード」として定義されています。値256〜16,777,213は、IETFコンセンサス[IANA]によって割り当てられた永続的な標準コマンド用です。このドキュメントでは、コマンドコード257、258、271、274-275、280、および282を定義しています。この仕様での名前空間の割り当てについては、セクション3.1を参照してください。
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, as outlined in [IANA-EXP].
値16,777,214および16,777,215（16進値0xfffffe-0xffffff）は、実験的なコマンド用に予約されています。これらのコードは実験とテストのみを目的としているため、[IANA-EXP]で概説されているように、実験コマンドを使用したDiameterピア間の相互運用性は保証されません。
There are eight bits in the Command Flags field of the Diameter header. This document assigns bit 0 ('R'equest), bit 1 ('P'roxy), bit 2 ('E'rror) and bit 3 ('T'). Bits 4 through 7 MUST only be assigned via a Standards Action [IANA].
Diameterヘッダーのコマンドフラグフィールドには8ビットがあります。このドキュメントは、ビット0（ 'R'equest）、ビット1（' P'roxy）、ビット2（ 'E'rror）、およびビット3（' T '）を割り当てます。ビット4〜7は、標準アクション[IANA]を介してのみ割り当てる必要があります。
As defined in Section 2.4, the Application Identifier is used to identify a specific Diameter Application. There are standards-track application ids and vendor specific application ids.
セクション2.4で定義されているように、アプリケーションIDは特定のDiameterアプリケーションを識別するために使用されます。標準化されたアプリケーションIDとベンダー固有のアプリケーションIDがあります。
IANA [IANA] has assigned the range 0x00000001 to 0x00ffffff for standards-track applications; and 0x01000000 - 0xfffffffe for vendor specific applications, on a first-come, first-served basis. The following values are allocated.
IANA [IANA]は、標準トラックアプリケーションに0x00000001から0x00ffffffの範囲を割り当てました。および0x01000000-ベンダー固有のアプリケーションの場合は0xfffffffe、先着順。以下の値が割り当てられます。
Diameter Common Messages 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameter Base Accounting 3 Relay 0xffffffff
Diameter共通メッセージ0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameterベースアカウンティング3リレー0xffffffff
Assignment of standards-track application IDs are by Designated Expert with Specification Required [IANA].
標準化過程のアプリケーションIDの割り当ては、指定された専門家による指定が必要です[IANA]。
Both Application-Id and Acct-Application-Id AVPs use the same Application Identifier space.
Application-IdとAcct-Application-Idの両方のAVPは、同じアプリケーション識別子スペースを使用します。
Vendor-Specific Application Identifiers, are for Private Use. Vendor-Specific Application Identifiers are assigned on a First Come, First Served basis by IANA.
ベンダー固有のアプリケーション識別子は、私的使用のためのものです。ベンダー固有のアプリケーション識別子は、IANAによって先着順で割り当てられます。
Certain AVPs in Diameter define a list of values with various meanings. For attributes other than those specified in this section, adding additional values to the list can be done on a First Come, First Served basis by IANA.
Diameterの特定のAVPは、さまざまな意味を持つ値のリストを定義します。このセクションで指定されている以外の属性の場合、リストに値を追加することは、IANAが先着順で行うことができます。
As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines the values 1001, 2001-2002, 3001-3010, 4001-4002 and 5001-5017.
セクション7.1で定義されているように、結果コードAVP（AVPコード268）は、値1001、2001-2002、3001-3010、4001-4002および5001-5017を定義します。
All remaining values are available for assignment via IETF Consensus [IANA].
残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 9.8.1, the Accounting-Record-Type AVP (AVP Code 480) defines the values 1-4. All remaining values are available for assignment via IETF Consensus [IANA].
セクション9.8.1で定義されているように、Accounting-Record-Type AVP（AVPコード480）は値1〜4を定義します。残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 8.15, the Termination-Cause AVP (AVP Code 295) defines the values 1-8. All remaining values are available for assignment via IETF Consensus [IANA].
セクション8.15で定義されているように、Termination-Cause AVP（AVPコード295）は値1〜8を定義します。残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 6.13, the Redirect-Host-Usage AVP (AVP Code 261) defines the values 0-5. All remaining values are available for assignment via IETF Consensus [IANA].
セクション6.13で定義されているように、Redirect-Host-Usage AVP（AVPコード261）は値0〜5を定義します。残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 8.18, the Session-Server-Failover AVP (AVP Code 271) defines the values 0-3. All remaining values are available for assignment via IETF Consensus [IANA].
セクション8.18で定義されているように、Session-Server-Failover AVP（AVPコード271）は値0〜3を定義します。残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 8.17, the Session-Binding AVP (AVP Code 270) defines the bits 1-4. All remaining bits are available for assignment via IETF Consensus [IANA].
セクション8.17で定義されているように、セッションバインディングAVP（AVPコード270）はビット1〜4を定義します。残りのすべてのビットは、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 5.4.3, the Disconnect-Cause AVP (AVP Code 273) defines the values 0-2. All remaining values are available for assignment via IETF Consensus [IANA].
セクション5.4.3で定義されているように、Disconnect-Cause AVP（AVPコード273）は値0〜2を定義します。残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 8.7, the Auth-Request-Type AVP (AVP Code 274) defines the values 1-3. All remaining values are available for assignment via IETF Consensus [IANA].
セクション8.7で定義されているように、Auth-Request-Type AVP（AVPコード274）は1〜3の値を定義します。残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 8.11, the Auth-Session-State AVP (AVP Code 277) defines the values 0-1. All remaining values are available for assignment via IETF Consensus [IANA].
セクション8.11で定義されているように、Auth-Session-State AVP（AVPコード277）は値0-1を定義します。残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 8.12, the Re-Auth-Request-Type AVP (AVP Code 285) defines the values 0-1. All remaining values are available for assignment via IETF Consensus [IANA].
セクション8.12で定義されているように、Re-Auth-Request-Type AVP（AVPコード285）は値0-1を定義します。残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 9.8.7, the Accounting-Realtime-Required AVP (AVP Code 483) defines the values 1-3. All remaining values are available for assignment via IETF Consensus [IANA].
セクション9.8.7で定義されているように、Accounting-Realtime-Required AVP（AVPコード483）は、値1〜3を定義します。残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
As defined in Section 6.10, the Inband-Security-Id AVP (AVP Code 299) defines the values 0-1. All remaining values are available for assignment via IETF Consensus [IANA].
セクション6.10で定義されているように、Inband-Security-Id AVP（AVPコード299）は値0-1を定義します。残りのすべての値は、IETFコンセンサス[IANA]による割り当てに使用できます。
The IANA has assigned TCP and SCTP port number 3868 to Diameter.
IANAは、DiameterにTCPおよびSCTPポート番号3868を割り当てています。
The registration in the RFC MUST include the following information:
RFCへの登録には、次の情報を含める必要があります。
Service Field: The service field being registered. An example for a new fictitious transport protocol called NCTP might be "AAA+D2N".
サービスフィールド：登録されているサービスフィールド。 NCTPと呼ばれる新しい架空のトランスポートプロトコルの例は、「AAA + D2N」です。
Protocol: The specific transport protocol associated with that service field. This MUST include the name and acronym for the protocol, along with reference to a document that describes the transport protocol. For example - "New Connectionless Transport Protocol (NCTP), RFC 5766".
プロトコル：そのサービスフィールドに関連付けられた特定のトランスポートプロトコル。これには、プロトコルの名前と頭字語、およびトランスポートプロトコルを説明するドキュメントへの参照を含める必要があります。例-「新しいコネクションレス型トランスポートプロトコル（NCTP）、RFC 5766」。
Name and Contact Information: The name, address, email address and telephone number for the person performing the registration.
名前と連絡先情報：登録を行う人の名前、住所、電子メールアドレス、および電話番号。
The following values have been placed into the registry:
次の値がレジストリに配置されています。
Services Field Protocol AAA+D2T TCP AAA+D2S SCTP
サービスフィールドプロトコルAAA + D2T TCP AAA + D2S 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ピアDiameterエンティティは、静的に構成されたピアと通信できます（MAY）。静的に構成されたDiameterピアでは、IPアドレスまたは完全修飾ドメイン名（FQDN）のいずれかを指定する必要があります。これは、DNSを介した解決に使用されます。
Realm 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 to. 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 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タイマーTcタイマーは、アクティブなトランスポート接続が存在しないピアに対してトランスポート接続の試行が行われる頻度を制御します。推奨値は30秒です。
The Diameter base protocol assumes that messages are secured by using either IPSec or TLS. This security mechanism is acceptable in environments where there is no untrusted third party agent. In other situations, end-to-end security is needed.
Diameter基本プロトコルは、メッセージがIPSecまたはTLSのいずれかを使用して保護されていることを前提としています。このセキュリティメカニズムは、信頼できないサードパーティのエージェントが存在しない環境では受け入れられます。他の状況では、エンドツーエンドのセキュリティが必要です。
Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SECARCH] and MAY support TLS [TLS]. Diameter servers MUST support TLS and IPsec. Diameter implementations MUST use transmission-level security of some kind (IPsec or TLS) on each connection.
ネットワークアクセスサーバー（NAS）やモビリティエージェントなどのDiameterクライアントは、IPセキュリティ[SECARCH]をサポートする必要があり、TLS [TLS]をサポートする場合があります。 DiameterサーバーはTLSおよびIPsecをサポートする必要があります。 Diameterの実装では、各接続で何らかの送信レベルのセキュリティ（IPsecまたはTLS）を使用する必要があります。
If a Diameter connection is not protected by IPsec, then the CER/CEA exchange MUST include an Inband-Security-ID AVP with a value of TLS. For TLS usage, a TLS handshake will begin when both ends are in the open state, after completion of the CER/CEA exchange. If the TLS handshake is successful, all further messages will be sent via TLS. If the handshake fails, both ends move to the closed state.
Diameter接続がIPsecで保護されていない場合、CER / CEA交換には、TLSの値を持つInband-Security-ID AVPを含める必要があります。 TLSを使用する場合、CER / CEA交換が完了した後、両端がオープン状態になると、TLSハンドシェイクが開始されます。 TLSハンドシェイクが成功した場合、以降のすべてのメッセージはTLS経由で送信されます。ハンドシェイクが失敗すると、両端がクローズ状態に移行します。
It is suggested that IPsec be used primarily at the edges for intra-domain exchanges. For NAS devices without certificate support, pre-shared keys can be used between the NAS and a local AAA proxy.
IPsecは主にドメイン内交換のエッジで使用することをお勧めします。証明書をサポートしていないNASデバイスの場合、事前共有キーをNASとローカルAAAプロキシの間で使用できます。
For protection of inter-domain exchanges, TLS is recommended. See Sections 13.1 and 13.2 for more details on IPsec and TLS usage.
ドメイン間交換の保護のために、TLSが推奨されます。 IPsecおよびTLSの使用の詳細については、セクション13.1および13.2を参照してください。
All Diameter implementations MUST support IPsec ESP [IPsec] in transport mode with non-null encryption and authentication algorithms to provide per-packet authentication, integrity protection and confidentiality, and MUST support the replay protection mechanisms of IPsec.
すべてのDiameter実装は、非ヌルの暗号化および認証アルゴリズムを使用するトランスポートモードでIPsec ESP [IPsec]をサポートし、パケットごとの認証、完全性保護、および機密性を提供する必要があり、IPsecのリプレイ保護メカニズムをサポートする必要があります。
Diameter implementations MUST support IKE for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [IPSECDOI]. Diameter implementations MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKE's Sections 5.2 and 5.3 [IKE] SHOULD NOT be used.
Diameter実装は、IPsec DOI [IPSECDOI]を使用して、ピア認証、セキュリティアソシエーションのネゴシエーション、およびキー管理のためにIKEをサポートする必要があります。 Diameter実装は、事前共有キーを使用したピア認証をサポートする必要があり、デジタル署名を使用した証明書ベースのピア認証をサポートする場合があります（MAY）。 IKEのセクション5.2および5.3で概説されている公開鍵暗号化方式を使用したピア認証[IKE]は使用しないでください。
Conformant implementations MUST support both IKE Main Mode and Aggressive Mode. When pre-shared keys are used for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used. When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used.
準拠する実装は、IKEメインモードとアグレッシブモードの両方をサポートする必要があります。認証に事前共有キーを使用する場合は、IKEアグレッシブモードを使用する必要があり（SHOULD）、IKEメインモードを使用しないでください（SHOULD NOT）。認証にデジタル署名が使用される場合、IKEメインモードまたはIKEアグレッシブモードのいずれかが使用される場合があります。
When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD use pertinent certificate revocation checks before accepting a PKI certificate for use in IKE's authentication procedures.
認証を達成するためにデジタル署名が使用される場合、IKEネゴシエーターはIKE証明書要求ペイロードを使用して、そのローカルポリシーに従って信頼される認証局を指定する必要があります（SHOULD）。 IKEネゴシエーターは、IKEの認証手順で使用するPKI証明書を受け入れる前に、関連する証明書失効チェックを使用する必要があります（SHOULD）。
The Phase 2 Quick Mode exchanges used to negotiate protection for Diameter connections MUST explicitly carry the Identity Payload fields (IDci and IDcr). The DOI provides for several types of identification data. However, when used in conformant implementations, each ID Payload MUST carry a single IP address and a single non-zero port number, and MUST NOT use the IP Subnet or IP Address Range formats. This allows the Phase 2 security association to correspond to specific TCP and SCTP connections.
Diameter接続の保護をネゴシエートするために使用されるフェーズ2クイックモード交換は、IDペイロードフィールド（IDciおよびIDcr）を明示的に運ぶ必要があります。 DOIは、いくつかのタイプの識別データを提供します。ただし、準拠する実装で使用する場合、各IDペイロードは単一のIPアドレスとゼロ以外の単一のポート番号を運ばなければならず（MUST）、IPサブネットまたはIPアドレス範囲の形式を使用してはなりません（MUST NOT）。これにより、フェーズ2セキュリティアソシエーションを特定のTCPおよびSCTP接続に対応させることができます。
Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down a Diameter connection. Rather, it is preferable to leave the connection up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing connections up and down.
IPsecアクセラレーションハードウェアは限られた数のアクティブなIKEフェーズ2 SAしか処理できないため、アクティブなフェーズ2 SAの数を最小限に抑える手段として、フェーズ2削除メッセージをアイドルSAに送信できます。 IKEフェーズ2削除メッセージの受信は、Diameter接続を切断する理由として解釈されるべきではありません（SHOULD NOT）。むしろ、接続を維持したままにし、追加のトラフィックが送信される場合は、別のIKEフェーズ2 SAを起動して接続を保護することをお勧めします。これにより、接続が継続的にアップおよびダウンする可能性が回避されます。
A Diameter node that initiates a connection to another Diameter node acts as a TLS client according to [TLS], and a Diameter node that accepts a connection acts as a TLS server. Diameter nodes implementing TLS for security MUST mutually authenticate as part of TLS session establishment. In order to ensure mutual authentication, the Diameter node acting as TLS server must request a certificate from the Diameter node acting as TLS client, and the Diameter node acting as TLS client MUST be prepared to supply a certificate on request.
別のDiameterノードへの接続を開始するDiameterノードは、[TLS]に従ってTLSクライアントとして機能し、接続を受け入れるDiameterノードはTLSサーバーとして機能します。セキュリティのためにTLSを実装するDiameterノードは、TLSセッション確立の一部として相互認証する必要があります。相互認証を確実にするために、TLSサーバーとして機能するDiameterノードは、TLSクライアントとして機能するDiameterノードに証明書を要求する必要があり、TLSクライアントとして機能するDiameterノードは、要求に応じて証明書を提供できるように準備する必要があります。
Diameter nodes MUST be able to negotiate the following TLS cipher suites:
Diameterノードは、次のTLS暗号スイートをネゴシエートできる必要があります。
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 cipher suite:
Diameterノードは、次のTLS暗号スイートをネゴシエートできる必要があります（SHOULD）。
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
Diameter nodes MAY negotiate other TLS cipher suites.
Diameterノードは、他のTLS暗号スイートをネゴシエートしてもよい（MAY）。
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. When 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ピアが事前に認識されていない可能性があるため、ピアの検出が必要になる場合があります。
Note that IPsec is considerably less flexible than TLS when it comes to configuring root CAs. Since use of Port identifiers is prohibited within IKE Phase 1, within IPsec it is not possible to uniquely configure trusted root CAs for each application individually; the same policy must be used for all applications. This implies, for example, that a root CA trusted for use with Diameter must also be trusted to protect SNMP. These restrictions can be awkward at best. Since TLS supports application-level granularity in certificate policy, TLS SHOULD be used to protect Diameter connections between administrative domains. IPsec is most appropriate for intra-domain usage when pre-shared keys are used as a security mechanism.
ルートCAの構成に関しては、IPsecはTLSよりも柔軟性がかなり低いことに注意してください。 IKEフェーズ1内ではポート識別子の使用が禁止されているため、IPsec内では、アプリケーションごとに信頼されたルートCAを個別に個別に構成することはできません。すべてのアプリケーションに同じポリシーを使用する必要があります。これは、たとえば、Diameterでの使用が信頼されているルートCAも、SNMPを保護するために信頼されている必要があることを意味します。これらの制限は、せいぜい扱いにくい場合があります。 TLSは証明書ポリシーでアプリケーションレベルの細分性をサポートするため、管理ドメイン間のDiameter接続を保護するためにTLSを使用する必要があります（SHOULD）。 IPsecは、事前共有キーがセキュリティメカニズムとして使用される場合、ドメイン内での使用に最適です。
When pre-shared key authentication is used with IPsec to protect Diameter, unique pre-shared keys are configured with Diameter peers, who are identified by their IP address (Main Mode), or possibly their FQDN (Aggressive Mode). As a result, it is necessary for the set of Diameter peers to be known beforehand. Therefore, peer discovery is typically not necessary.
Diameterを保護するためにIPsecで事前共有キー認証を使用する場合、固有の事前共有キーは、IPアドレス（メインモード）またはFQDN（アグレッシブモード）で識別されるDiameterピアで構成されます。その結果、Diameterピアのセットを事前に知っておく必要があります。したがって、ピアの検出は通常必要ありません。
The following is intended to provide some guidance on the issue.
以下は、この問題に関するいくつかのガイダンスを提供することを目的としています。
It is recommended that a Diameter peer implement the same security mechanism (IPsec or TLS) across all its peer-to-peer connections. Inconsistent use of security mechanisms can result in redundant security mechanisms being used (e.g., TLS over IPsec) or worse, potential security vulnerabilities. When IPsec is used with Diameter, a typical security policy for outbound traffic is "Initiate IPsec, from me to any, destination port Diameter"; for inbound traffic, the policy would be "Require IPsec, from any to me, destination port Diameter".
Diameterピアは、すべてのピアツーピア接続にわたって同じセキュリティメカニズム（IPsecまたはTLS）を実装することをお勧めします。セキュリティメカニズムの一貫性のない使用は、冗長なセキュリティメカニズムが使用される（例：TLS over IPsec）か、またはより悪い、潜在的なセキュリティの脆弱性をもたらす可能性があります。 DiameterでIPsecを使用する場合、発信トラフィックの一般的なセキュリティポリシーは「IPsecを自分から任意の宛先ポートDiameterに開始する」です。インバウンドトラフィックの場合、ポリシーは「IPsecを必要とします。私から宛先まで、宛先ポートDiameter」です。
This policy causes IPsec to be used whenever a Diameter peer initiates a connection to another Diameter peer, and to be required whenever an inbound Diameter connection occurs. This policy is attractive, since it does not require policy to be set for each peer or dynamically modified each time a new Diameter connection is created; an IPsec SA is automatically created based on a simple static policy. Since IPsec extensions are typically not available to the sockets API on most platforms, and IPsec policy functionality is implementation dependent, use of a simple static policy is the often the simplest route to IPsec-enabling a Diameter implementation.
このポリシーにより、Diameterピアが別のDiameterピアへの接続を開始するたびにIPsecが使用され、着信Diameter接続が発生するたびにIPsecが必要になります。このポリシーは魅力的です。ピアごとにポリシーを設定したり、新しいDiameter接続が作成されるたびに動的に変更したりする必要がないためです。 IPsec SAは、単純な静的ポリシーに基づいて自動的に作成されます。 IPsec拡張機能は通常、ほとんどのプラットフォームのソケットAPIで利用できず、IPsecポリシー機能は実装に依存しているため、単純な静的ポリシーの使用が、Diameter実装をIPsec対応にするための最も単純なルートであることがよくあります。
One implication of the recommended policy is that if a node is using both TLS and IPsec, there is not a convenient way in which to use either TLS or IPsec, but not both, without reserving an additional port for TLS usage. Since Diameter uses the same port for TLS and non-TLS usage, where the recommended IPsec policy is put in place, a TLS-protected connection will match the IPsec policy, and both IPsec and TLS will be used to protect the Diameter connection. To avoid this, it would be necessary to plumb peer-specific policies either statically or dynamically.
推奨ポリシーの1つの意味は、ノードがTLSとIPsecの両方を使用している場合、TLSの使用のために追加のポートを予約せずに、TLSまたはIPsecのいずれかを使用する便利な方法がないことです。 Diameterは、推奨されるIPsecポリシーが配置されているTLSと非TLSの使用に同じポートを使用するため、TLSで保護された接続はIPsecポリシーと一致し、Diameter接続を保護するためにIPsecとTLSの両方が使用されます。これを回避するには、ピア固有のポリシーを静的または動的に組み込む必要があります。
If IPsec is used to secure Diameter peer-to-peer connections, IPsec policy SHOULD be set so as to require IPsec protection for inbound connections, and to initiate IPsec protection for outbound connections. This can be accomplished via use of inbound and outbound filter policy.
IPsecを使用してDiameterピアツーピア接続を保護する場合は、IPsecポリシーを設定して、インバウンド接続にIPsec保護を要求し、アウトバウンド接続にIPsec保護を開始する必要があります。これは、インバウンドおよびアウトバウンドのフィルターポリシーを使用して実現できます。
[AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[AAATRANS] Aboba、B.およびJ. Wood、「Authentication、Authorization and Accounting（AAA）Transport Profile」、RFC 3539、2003年6月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年11月。
[ASSIGNNO] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[ASSIGNNO] Reynolds、J。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられました」、RFC 3232、2002年1月。
[DIFFSERV] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[DIFFSERV] Nichols、K.、Blake、S.、Baker、F。およびD. Black、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、RFC 2474、1998年12月。
[DIFFSERVAF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[DIFFSERVAF] Heinanen、J.、Baker、F.、Weiss、W。およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[DIFFSERVEF] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB", RFC 3246, March 2002.
[DIFFSERVEF]デイビーB.、チャーニーA.、ベネットJ.、ベンソンK.、ルブーデックJ.、コートニーW.、ダヴァリS.、フィロイ、V.、D。スティリアディス、「An Expedited Forwarding PHB」、RFC 3246、2002年3月。
[DNSSRV] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[DNSSRV] Gulbrandsen、A.、Vixie、P。およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[EAP] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[EAP] Blunk、L.およびJ. Vollbrecht、「PPP Extensible Authentication Protocol（EAP）」、RFC 2284、1998年3月。
[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月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[IANAADFAM] IANA; "Address Family Numbers",
http://www.iana.org/assignments/address-family-numbers
[IANAWEB] IANA, "Number assignment", http://www.iana.org
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[IPComp] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[IPComp] Shacham、A.、Monsour、R.、Pereira、R。およびM. Thomas、「IP Payload Compression Protocol（IPComp）」、RFC 3173、2001年9月。
[IPSECDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[IPSECDOI] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPV4] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[IPV6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[IPV6] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 2373、1998年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[NAI] Aboba、B。およびM. Beadles、「The Network Access Identifier」、RFC 2486、1999年1月。
[NAPTR] Mealling, M. and R. Daniel, "The naming authority pointer (NAPTR) DNS resource record," RFC 2915, September 2000.
[NAPTR] Mealling、M。およびR. Daniel、「命名機関ポインタ（NAPTR）DNSリソースレコード」、RFC 2915、2000年9月。
[RADTYPE] IANA, "RADIUS Types",
http://www.iana.org/assignments/radius-types
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[SCTP] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。およびV. Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[SLP] Veizades, J., Guttman, E., Perkins, C. and M. Day, "Service Location Protocol, Version 2", RFC 2165, June 1999.
[SLP] Veizades、J.、Guttman、E.、Perkins、C。およびM. Day、「Service Location Protocol、バージョン2」、RFC 2165、1999年6月。
[SNTP] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[SNTP] Mills、D。、「Simple Network Time Protocol（SNTP）Version 4 for IPv4、IPv6 and OSI」、RFC 2030、1996年10月。
[TCP] Postel, J. "Transmission Control Protocol", STD 7, RFC 793, January 1981.
[TCP]ポステル、J。「伝送制御プロトコル」、STD 7、RFC 793、1981年1月。
[TEMPLATE] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999.
[テンプレート] Guttman、E.、Perkins、C。およびJ. Kempf、「Service Templates and Service：Schemes」、RFC 2609、1999年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[TLSSCTP] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[TLSSCTP] Jungmaier、A.、Rescorla、E。、およびM. Tuexen、「トランスポート層セキュリティover Stream Control Transmission Protocol」、RFC 3436、2002年12月。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI] Berners-Lee、T.、Fielding、R。およびL. Masinter、「Uniform Resource Identifiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF8] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、RFC 2279、1998年1月。
[AAACMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security Application", Work in Progress.
[AAACMS] P.カルホーン、W。ブリー、S。ファレル、「Diameter CMSセキュリティアプリケーション」、作業中。
[AAAREQ] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Walsh, P., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Xu, Y., Campbell, E., Baba, S. and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000.
[AAAREQ] Aboba、B.、Calhoun、P.、Glass、S.、Hiller、T.、McCann、P.、Shiino、H.、Zorn、G.、Dommety、G.、Perkins、C.、Patil、 B.、ミトン、D。、マニング、S。、ビードル、M。、ウォルシュ、P。、チェン、X。、シバリンガム、S。、ハメッド、A。、マンソン、M。、ジェイコブス、S。、リム、 B.、Hirschman、B.、Hsu、R.、Xu、Y.、Campbell、E.、Baba、S。、およびE. Jaques、「Criteria for Evaluating AAA Protocols for Network Access」、RFC 2989、2000年11月。
[ACCMGMT] Aboba, B., Arkko, J. and D. Harrington. "Introduction to Accounting Management", RFC 2975, October 2000.
[ACCMGMT] Aboba、B.、Arkko、J。およびD. Harrington。 「Introduction to Accounting Management」、RFC 2975、2000年10月。
[CDMA2000] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety, G., Sivalingham, S., Lim, B., McCann, P., Shiino, H., Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford, M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu, Y., Baba, S., Ayaki, T., Seki, T. and A. Hameed, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001.
[CDMA2000] Hiller、T.、Walsh、P.、Chen、X.、Munson、M.、Dommety、G.、Sivalingham、S.、Lim、B.、McCann、P.、Shiino、H.、Hirschman、 B.、マニング、S.、Hsu、R.、Koo、H.、Lipford、M.、Calhoun、P.、Lo、C.、Jaques、E。、キャンベル、E.、Xu、Y.、Baba、 S.、Ayaki、T.、Seki、T. and A. Hameed、 "CDMA2000 Wireless Data Requirements for AAA"、RFC 3141、2001年6月。
[DIAMMIP] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", Work in Progress.
[DIAMMIP] P.カルホーン、C。パーキンス、「DiameterモバイルIPアプリケーション」、作業中。
[DYNAUTH] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[DYNAUTH] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D. and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 3576、July 2003。
[IANA-EXP] T. Narten, "Assigning Experimental and Testing Numbers Considered Useful", Work in Progress.
[IANA-EXP] T.ナーテン、「有用と見なされる実験およびテスト番号の割り当て」、進行中の作業。
[MIPV4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[MIPV4] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[MIPREQ] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[MIPREQ] Glass、S.、Hiller、T.、Jacobs、S。およびC. Perkins、「Mobile IP Authentication、Authorization、and Accounting Requirements」、RFC 2977、2000年10月。
[NASNG] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[NASNG]ミトンD.およびM.ビードル、「ネットワークアクセスサーバー要件次世代（NASREQNG）NASモデル」、RFC 2881、2000年7月。
[NASREQ] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ Application", Work in Progress.
[NASREQ] P. Calhoun、W。Bulley、A。Rubens、J。Haag、「Diameter NASREQ Application」、作業中。
[NASCRIT] Beadles, M. and D. Mitton, "Criteria for Evaluating Network Access Server Protocols", RFC 3169, September 2001.
[NASCRIT] Beadles、M。およびD. Mitton、「Criteria for Evaluating Network Access Server Protocols」、RFC 3169、2001年9月。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[PPP]シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[PROXYCHAIN] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[PROXYCHAIN] Aboba、B。およびJ. Vollbrecht、「Proxy Chaining and Policy Implementation in Roaming」、RFC 2607、1999年6月。
[RADACCT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RADACCT]リグニー、C。、「RADIUSアカウンティング」、RFC 2866、2000年6月。
[RADEXT] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RADEXT] Rigney、C.、Willats、W。およびP. Calhoun、「RADIUS Extensions」、RFC 2869、2000年6月。
[RADIUS] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RADIUS] Rigney、C.、Willens、S.、Rubens、A。およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[ROAMREV] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[ROAMREV] Aboba、B.、Lu、J.、Alsop、J.、Ding、J。およびW. Wang、「ローミング実装のレビュー」、RFC 2194、1997年9月。
[ROAMCRIT] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[ROAMCRIT] Aboba、B。およびG. Zorn、「ローミングプロトコルの評価基準」、RFC 2477、1999年1月。
[SECARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[SECARCH]ケントS.およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[TACACS] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993.
[TACACS] Finseth、C。、「アクセス制御プロトコル、TACACSと呼ばれることもある」、RFC 1492、1993年7月。
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 similarly 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に感謝したいと思います。この文書に加えられた努力のほとんどは、彼が彼らの雇用中に行われたからです。
The following service template describes the attributes used by Diameter servers to advertise themselves. This simplifies the process of selecting an appropriate server to communicate with. A Diameter client can request specific Diameter servers based on characteristics of the Diameter service desired (for example, an AAA server to use for accounting.)
次のサービステンプレートは、Diameterサーバーが自身をアドバタイズするために使用する属性を示しています。これにより、通信する適切なサーバーを選択するプロセスが簡略化されます。 Diameterクライアントは、必要なDiameterサービスの特性に基づいて特定のDiameterサーバーを要求できます（たとえば、アカウンティングに使用するAAAサーバー）。
Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> Language of
service template: en
Security Considerations: Diameter clients and servers use various cryptographic mechanisms to protect communication integrity, confidentiality as well as perform end-point authentication. It would thus be difficult if not impossible for an attacker to advertise itself using SLPv2 and pose as a legitimate Diameter peer without proper preconfigured secrets or cryptographic keys. Still, as Diameter services are vital for network operation it is important to use SLPv2 authentication to prevent an attacker from modifying or eliminating service advertisements for legitimate Diameter servers.
セキュリティに関する考慮事項：Diameterクライアントとサーバーは、さまざまな暗号化メカニズムを使用して、通信の整合性と機密性を保護し、エンドポイント認証を実行します。したがって、攻撃者がSLPv2を使用して自身をアドバタイズし、適切に事前設定されたシークレットまたは暗号化キーなしに正当なDiameterピアを装うことは不可能ではないにしても困難です。それでも、Diameterサービスはネットワーク操作に不可欠であるため、SLPv2認証を使用して、攻撃者が正規のDiameterサーバーのサービスアドバタイズを変更または削除しないようにすることが重要です。
Template text:
-------------------------template begins here-----------------------
template-type=service:diameter
template-version=0.0
template-version = 0.0
template-description= The Diameter protocol is defined by RFC 3588.
template-description = DiameterプロトコルはRFC 3588で定義されています。
template-url-syntax=
url-path= ; The Diameter URL format is described in Section 2.9.
; Example: 'aaa://aaa.example.com:1812;transport=tcp
supported-auth-applications= string L M
# This attribute lists the Diameter applications supported by the
# AAA implementation. The applications currently defined are:
# Application Name Defined by
# ---------------- -----------------------------------
# NASREQ Diameter Network Access Server Application
# MobileIP Diameter Mobile IP Application
#
# Notes:
# . Diameter implementations support one or more applications.
# . Additional applications may be defined in the future.
# An updated service template will be created at that time.
# NASREQ,MobileIP
＃NASREQ、MobileIP
supported-acct-applications= string L M
# This attribute lists the Diameter applications supported by the
# AAA implementation. The applications currently defined are:
# Application Name Defined by
# ---------------- -----------------------------------
# NASREQ Diameter Network Access Server Application
# MobileIP Diameter Mobile IP Application
#
# Notes:
# . Diameter implementations support one or more applications.
# . Additional applications may be defined in the future.
# An updated service template will be created at that time.
#
NASREQ,MobileIP
supported-transports= string L M SCTP # This attribute lists the supported transports that the Diameter # implementation accepts. Note that a compliant Diameter # implementation MUST support SCTP, though it MAY support other # transports, too. SCTP,TCP
supported-transports = string L M SCTP＃この属性は、Diameter実装が受け入れる＃サポートされるトランスポートをリストします。 ＃準拠のDiameter実装はSCTPをサポートする必要がありますが、他のトランスポートもサポートする場合があります。 SCTP、TCP
-------------------------template ends here-----------------------
As an example, consider a client that wishes to resolve aaa:ex.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
例として、aaa：ex.comを解決したいクライアントを考えてみましょう。クライアントはそのドメインに対してNAPTRクエリを実行し、次のNAPTRレコードが返されます。
;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "AAA+D2S" "" _diameter._sctp.example.com IN NAPTR 100 50 "s" "AAA+D2T" "" _aaa._tcp.example.com
;;注文設定フラグサービスregexp置換IN NAPTR 50 50 "s" "AAA + D2S" "" _diameter._sctp.example.com IN NAPTR 100 50 "s" "AAA + D2T" "" _aaa._tcp.example.com
This indicates that the server supports SCTP, and TCP, in that order. If the client supports over SCTP, SCTP will be used, targeted to a host determined by an SRV lookup of _diameter._sctp.ex.com. That lookup would return:
これは、サーバーがSCTP、TCPをこの順序でサポートしていることを示しています。クライアントがSCTPをサポートしている場合、SCTPが使用され、_diameter._sctp.ex.comのSRVルックアップによって決定されたホストをターゲットにします。そのルックアップは以下を返します：
;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com
;;優先度の重みポートターゲットIN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com
As described in Section 9.4, accounting record duplicate detection is based on session identifiers. Duplicates can appear for various reasons:
セクション9.4で説明されているように、アカウンティングレコードの重複検出はセッション識別子に基づいています。重複はさまざまな理由で発生する可能性があります。
- Failover to an alternate server. Where close to real-time performance is required, failover thresholds need to be kept low and this may lead to an increased likelihood of duplicates. Failover can occur at the client or within Diameter agents.
- 代替サーバーへのフェイルオーバー。ほぼリアルタイムのパフォーマンスが必要な場合は、フェイルオーバーのしきい値を低く保つ必要があり、これにより重複の可能性が高まる可能性があります。フェイルオーバーは、クライアントまたはDiameterエージェント内で発生する可能性があります。
- Failure of a client or agent after sending of a record from non-volatile memory, but prior to receipt of an application layer ACK and deletion of the record. record to be sent. This will result in retransmission of the record soon after the client or agent has rebooted.
- 不揮発性メモリからレコードを送信した後、アプリケーション層のACKを受信してレコードを削除する前の、クライアントまたはエージェントの障害。送信するレコード。これにより、クライアントまたはエージェントが再起動した直後にレコードが再送信されます。
- 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.
- RADIUSゲートウェイから受信した重複。 RADIUSの再送信動作は[RFC2865]で定義されていないため、重複の可能性は実装によって異なります。
- Implementation problems and misconfiguration.
- 実装の問題と設定ミス。
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 possible duplicate by setting the T flag. Since the Diameter server is responsible for duplicate detection, it can choose to make use of the T flag or not, in order to optimize duplicate detection. Since the T flag does not affect interoperability, and may not be needed by some servers, generation of the T flag is REQUIRED for Diameter clients and agents, but MAY be implemented by Diameter servers.
一般に、Diameterクライアントまたはエージェントが確実に検出できるのは、不揮発性ストレージ内のレコードのフェイルオーバーまたは再送信による重複の生成のみです。このような場合、Diameterクライアントまたはエージェントは、Tフラグを設定することにより、メッセージを重複可能としてマークできます。 Diameterサーバーは重複検出を担当するため、重複検出を最適化するために、Tフラグを使用するかどうかを選択できます。 Tフラグは相互運用性に影響せず、一部のサーバーでは必要ない場合があるため、Tフラグの生成はDiameterクライアントおよびエージェントで必須ですが、Diameterサーバーで実装できます（MAY）。
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 out of order duplicates, 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 has expired, then 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フラグのマークが付いたレコードの後に元のレコードが受信される可能性があります。これが発生する可能性は、フェイルオーバー間隔が短くなるにつれて増加します。順不同の重複を検出できるようにするには、Tフラグのマークが付いたリクエストの重複チェックを実行するときに、Diameterサーバーが逆方向および順方向の時間枠を使用する必要があります。たとえば、元のレコードがネットワークから出て、アカウンティングサーバーによって記録されるまでの時間を確保するために、Diameterサーバーは、Tフラグが設定されたレコードの処理を、を閉じてからTIME_WAIT + RECORD_PROCESSING_TIME時間が経過するまで遅らせることができます。元のトランスポート接続。この期間が満了すると、Tフラグのマークが付いたレコードをデータベースと照合して、元のレコードが送信された場合は受信および記録されたことを相対的に保証します。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETFは、このドキュメントで説明されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用可能。また、そのような権利を特定するために何らかの努力をしたことも表していません。標準化過程および標準化関連文書の権利に関するIETFの手順に関する情報は、BCP-11にあります。公開に利用できるようにされた権利の主張および利用可能にされるライセンスの保証のコピー、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用の許可を得ようとした試みの結果を入手できます。 IETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、この規格を実践するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IETF Executive Directorに情報を送信してください。
Authors' Addresses
著者のアドレス
Pat R. Calhoun Airespace, Inc. 110 Nortech Parkway San Jose, California, 95134 USA
Pat R. Calhoun Airespace、Inc. 110 Nortech Parkway San Jose、California、95134 USA
Phone: +1 408-635-2023
Fax: +1 408-635-2020
EMail: pcalhoun@airespace.com
John Loughney Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland
じょｈん ぉうｇｈねｙ のきあ れせあｒｃｈ せんてｒ いためれんかつ １１ー１３ ００１８０ へｌしんき ふぃんぁんｄ
Phone: +358 50 483 6242
EMail: john.Loughney@nokia.com
Jari Arkko Ericsson 02420 Jorvas Finland
Jari Arkko Ericsson 02420 Jorvasフィンランド
Phone: +358 40 5079256
EMail: Jari.Arkko@ericsson.com
Erik Guttman Sun Microsystems, Inc. Eichhoelzelstr. 7 74915 Waibstadt Germany
Erik Guttman Sun Microsystems、Inc. Eichhoelzelstr。 7 74915ワイプシュタットドイツ
Phone: +49 7263 911 701
EMail: erik.guttman@sun.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 USA
Glen Zorn Cisco Systems、Inc. 500 108th Avenue N.E.、Suite 500 Bellevue、WA 98004 USA
Phone: +1 425 438 8218
電話：+1 425 438 8218
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、この文書自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要に応じて行う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。