[要約] RFC 3588は、認証、認可、およびアカウンティング（AAA）のための次世代プロトコルであるDiameter基本プロトコルを定義しています。RADIUSの制限を解消し、信頼性の高いトランスポート、能力交渉、およびエラー通知などの強化された機能を提供します。モバイルIPやネットワークアクセスなど、複雑化するインターネットインフラにおいて、堅牢でスケーラブルな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 Base Protocol
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 で説明されているように解釈されるものとします。
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.
転送レベルのセキュリティ [RADIUS]は、Responseパケットでのみ使用が必要なアプリケーション層の認証および完全性の方式を定義します。[RADEXT]は追加の認証および完全性メカニズムを定義しますが、使用が必要なのはExtensible Authentication Protocol (EAP)セッション中だけです。属性秘匿はサポートされていますが、[RADIUS]はパケットごとの機密性をサポートしません。アカウンティングでは、[RADACCT]はリプレイ保護がプロトコル自体ではなくバックエンド課金サーバーによって提供されることを前提としています。
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.
- リソース使用量情報の交換。この情報は、アカウンティング、キャパシティプランニングなどの目的に使用してもよい (MAY)。
- 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ノードは、ある要求に対してエージェントとして動作し、別の要求に対してサーバーとして動作してもよい (MAY)。
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] に要求を送信しなければなりません (MUST)。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節に列挙されたデータ型のいずれかを使用しなければなりません (MUST)。
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に送信することが必須です (MUST)。リクエストには、AVPを使用するコマンドを含めることが必須です (MUST)。
Every Diameter application specification MUST have an IANA assigned Application Identifier (see Section 2.4) or a vendor specific Application Identifier.
各Diameterアプリケーション仕様は、IANAが割り当てたApplication Identifier（2.4節参照）またはベンダー固有のApplication Identifierを有しなければなりません (MUST)。
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を、アプリケーションで定義されている任意のコマンドに追加してもよい (MAY)。詳細は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つのCommand Codeを定義するか、ABNFに新しい必須AVPを追加しなければなりません (MUST)。
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]文法で定義しなければなりません (MUST)（セクション3.2を参照）。 Diameterアプリケーションにアカウンティング要件がある場合、Diameterアカウンティングメッセージに存在するAVPも指定しなければなりません (MUST)（セクション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.
Application Identifierは、Diameterの能力交換にも引き続き求められます。各Diameterアカウンティングアプリケーション仕様は、IANAが割り当てたApplication Identifier（2.4節参照）またはベンダー固有のApplication Identifierを有しなければなりません (MUST)。
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実装は、アカウンティングをサポートしなければなりません (MUST)。新しい必須AVPが追加されない限り、本書で定義されたACR/ACAコマンドを使用するどのアプリケーションも、基本的なアカウンティングサポートで処理できます。必須AVPとは、アカウンティングアプリケーションのABNFで必須とされるか任意とされるかにかかわらず、アカウンティングコマンド内で送信される際に「M」ビットが設定されているAVPと定義されます。
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を理解することが必須です (MUST)。 AVPが課金プロセスに関連していない場合、AVPがアカウンティングコマンドに含まれているとき、他のDiameter内で同じAVPが使用されているときに「M」ビットが設定されていても、「M」ビットが設定されていてはなりません (MUST NOT)。コマンド（つまり、認証/承認コマンド）。
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節）を使用しなければなりません (MUST)。
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)。すなわち、アプリケーション自体を変更せずに新しい認証方式を追加してもよい (MAY) 設計にします。この設計では、新しい認証変換、または同様の結果を生成するほかの方式を表すために、新しいAVP値の割り当てを要求してもよい (MAY)。可能な場合、Extensible Authentication Protocol [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 Server：特定のレルムに対する認証、認可、およびアカウンティング要求を処理するサーバーです。その性質上、Diameter Serverは、基本プロトコルに加えてDiameterアプリケーションをサポートしなければなりません (MUST)。
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.
Local Realm：ユーザーにサービスを提供する管理ドメインです。ある管理ドメインは、一部のユーザーにとってはローカルレルムとして、ほかのユーザーにとってはホームレルムとして動作してもよい (MAY)。
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.
Session：特定の活動に充てられた、相互に関連する一連のイベントです。各アプリケーションは、セッションがいつ開始し、いつ終了するかについて指針を示すべきです (SHOULD)。同じSession-Identifierを持つすべての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).
Mobile IPv4 [DIAMMIP]。これらのアプリケーションは本書で紹介しますが、仕様は別の文書で規定されています。将来、追加のDiameterアプリケーションを定義してもよい (MAY)（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クライアントは、アカウンティングを含む基本プロトコルをサポートすることが必須です (MUST)。さらに、クライアントのサービスを実装するために必要な各Diameterアプリケーション（NASREQやモバイルIPv4など）を完全にサポートすることが必須です (MUST)。 NASREQとモバイルIPv4の両方をサポートしないDiameterクライアントは、「Diameter Xクライアント」と呼ばれることが必須です (MUST)。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サーバーは、アカウンティングを含む基本プロトコルをサポートすることが必須です (MUST)。さらに、NASREQやモバイルIPv4などの目的のサービスを実装するために必要な各Diameterアプリケーションを完全にサポートすることが必須です (MUST)。 NASREQとモバイルIPv4の両方をサポートしないDiameterサーバーは、「Diameter Xサーバー」と呼ばなければなりません (MUST)。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アプリケーションを透過的にサポートしなければなりません (MUST)。
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プロキシは、アカウンティングを含む基本プロトコルをサポートすることが必須です (MUST)。さらに、NASREQやモバイルIPv4などのプロキシサービスの実装に必要な各Diameterアプリケーションを完全にサポートすることが必須です (MUST)。 NASREQとモバイルIPv4の両方をサポートしていないDiameterプロキシは、「Diameter Xプロキシ」と呼ばれなければなりません (MUST)。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-Termination-RequestまたはSession-Termination-Answerを受信したとき、Session-Timeout AVPで認可されたサービス時間が満了したとき、および特定のDiameterアプリケーションで定められた規則に従い、Session-Idに関連付けられたセッション状態を解放しなければなりません (MUST)。
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のいずれかをサポートすることが必須です (MUST) が、エージェントとサーバーは両方をサポートすることが必須です (MUST)。この仕様の将来のバージョンでは、クライアントがSCTPをサポートすることが義務付けられる場合があります (MAY)。
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ノードは、着信接続を受け入れると宣言しているポートとは別の送信元ポートから接続を開始してもよい (MAY)。また、ポート3868で接続を受信できるよう準備しなければなりません (MUST)。ピアステートマシンの特定の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)。この動作はTcタイマーによって処理され、その推奨値は30秒です。この規則には、ピアが通信を望まないことを示してトランスポート接続を終了した場合など、いくつかの例外があります。
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を試し、その後にTCPを試すべきです (SHOULD)。ピア検出の詳細については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から渡されたデータを受信し、そのデータを解析することも、ピアが生成したDiameterエラーとして識別することもできない場合、ストリームは破損しており、回復できません。トランスポート接続は、RESET呼び出し（TCP RSTビットを送信）またはSCTP ABORTメッセージを使用して閉じなければなりません (MUST)（正常なクローズは成立しません）。
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メッセージを受信できるよう準備しなければなりません (MUST)。
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).
Network Access Server (NAS)やMobility AgentなどのDiameterクライアントは、IP Security [SECARCH]をサポートしなければなりません (MUST)。また、TLS [TLS]をサポートしてもよい (MAY)。Diameterサーバーは、TLSとIPsecをサポートしなければなりません (MUST)。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
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.
リレーおよびリダイレクトエージェントは、リレーアプリケーション識別子をアドバタイズすることが必須です (MUST) が、他のすべてのDiameterノードは、ローカルでサポートされるアプリケーションをアドバタイズすることが必須です (MUST)。リレーサービスをアドバタイズするCapabilities Exchangeメッセージの受信者は、送信者が現在および将来のすべてのアプリケーションをサポートしていると想定することが必須です (MUST)。
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節に列挙された値のいずれかと一致しなければなりません (MUST)。
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.
Application Identifier：アプリケーションは、ベンダーIDとアプリケーションIDによって識別されます。IETF標準化過程のすべてのDiameterアプリケーションでは、ベンダーIDは0です。ルートエントリは、メッセージのアプリケーション識別AVPに基づいて異なる宛先を持つことができます。このフィールドは、ルーティングテーブル検索の副キーフィールドとして使用しなければなりません (MUST)。
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を一切変更せずに、ネクストホップサーバーへルーティングしなければなりません (MUST)。リレーの指針については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. PROXY - このカテゴリに該当するすべてのDiameterメッセージは、ネクストホップサーバーにルーティングしなければなりません (MUST)。ローカルサーバーは、ルーティング前に新しい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サーバー（複数可）の識別情報を追加したうえで、そのメッセージを送信者に返さなければなりません (MUST)。リダイレクトの指針については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.
Server Identifier：メッセージのルーティング先となる1台以上のサーバーを示します。これらのサーバーはPeer tableにも登録しなければなりません (MUST)。Local ActionがRELAYまたはPROXYに設定されている場合、このフィールドには、メッセージのルーティング先となるサーバーの識別情報が含まれます。Local ActionフィールドがREDIRECTに設定されている場合、このフィールドには、メッセージのリダイレクト先となる1台以上のサーバーの識別情報が含まれます。
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つをサポートすることが必須である (MUST) ことに注意することが重要です。エージェントはプロトコル仕様に準拠するためにすべての動作モードをサポートする必要はありませんが、セクション2のプロトコルコンプライアンスガイドラインに従うことが必須です (MUST)。リレーエージェントはAVPを並べ替えてはならず (MUST NOT)、プロキシはAVPを並べ替えてはなりません (MUST NOT)。
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.
ルーティングテーブルには、他のどのエントリとも一致しない要求に使用することが必須である (MUST) デフォルトのエントリを含めることができます (MAY)。ルーティングテーブルは、そのようなエントリのみで構成されている場合があります (MAY)。
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.
要求をルーティングする場合、対象サーバーは、そのメッセージのApplication Identifier（2.4節参照）をあらかじめ広告するか、自身をリレーエージェントまたはプロキシエージェントとしてあらかじめ広告しなければなりません (MUST)。そうでなければ、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:
セッション状態の維持は、次のような特定のアプリケーションで有用となることがあり、その場合は採用してもよい (MAY)：
- 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エージェントは、一部のリクエストではステートフルな方法で動作し、他のリクエストではステートレスになる場合があります (MAY)。 Diameterの実装は、一部のリクエストでは1つのタイプのエージェントとして機能し、他のタイプでは別のタイプのエージェントとして機能する場合があります (MAY)。
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メッセージを変更しますが、メッセージの他の部分は変更しません。リレーはセッション状態を維持するべきではありませんが (SHOULD NOT)、トランザクション状態を維持することが必須です (MUST)。
+------+ ---------> +------+ ---------> +------+
| | 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アプリケーションにリレーサービスを提供するため、Relay Application Identifierを広告しなければなりません (MUST)。
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に付加価値機能を提供してもよい (MAY) ものの、メッセージを変更すると認証が成立しなくなるため、アクセスデバイスではエンドツーエンドセキュリティを使用できないことに注意することが重要です。
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では、プロキシを使用してもよい (MAY)。プロキシは、使用中のポートの数と種類を監視し、その構成に従ってリソース割り当てと受付可否を決定できます。
Proxies that wish to limit resources MUST maintain session state. All proxies MUST maintain transaction state.
リソースを制限するプロキシは、セッション状態を維持することが必須です (MUST)。すべてのプロキシはトランザクションの状態を維持することが必須です (MUST)。
Since enforcing policies requires an understanding of the service being provided, Proxies MUST only advertise the Diameter applications they support.
ポリシーの適用には提供されるサービスの理解が求められるため、プロキシは、自身がサポートするDiameterアプリケーションだけを広告しなければなりません (MUST)。
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アプリケーションにリレーサービスを提供するため、Relay Application Identifierを広告しなければなりません (MUST)。
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プロトコルが長期間の承認済みセッションの概念を導入していることを考えると、変換エージェントはセッションステートフルであることが必須であり (MUST)、トランザクション状態を維持することが必須です (MUST)。
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ピアは、そのピアが役割で動作することを承認されていることを確認することが必須です (MUST)。たとえば、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）も実行することが必須です (MUST)。 Diameterセッションは、そのセッションで必要なDiameterアプリケーションのサポートをアドバタイズした承認済みノードを介してのみルーティングすることが必須です (MUST)。
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節で述べたように、リレーエージェントまたはプロキシエージェントは、転送するすべての要求にRoute-Record AVPを追加しなければなりません (MUST)。このAVPには、要求の受信元ピアの識別情報が含まれます。
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サーバーは、セッションを認可する前にRoute-Record AVPを検査し、要求が通過した経路が受け入れ可能であることを確認しなければなりません (MUST)。例えば、ホームレルムの管理者は、信頼できないレルムを経由してルーティングされた要求を受け入れたくない場合があります。要求を認可することで、ホーム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応答に対応しているか確認することも考えられます。対応する認可応答がないアカウンティング要求は、要求されたサービスと提供されたサービスの相違を示すアカウンティング要求と同様に、さらに精査すべきです (SHOULD)。
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応答を受信した際、応答が通過した経路が受け入れ可能であることを確認するため、Route-Record AVPを検査しなければなりません (MUST)。各段階で認可応答を転送することは、そのセッションに関する財務リスクを引き受ける意思の証拠と見なされます。ローカルレルムは、例えば中間レルムに与信限度を設定し、その限度に違反する応答の受け入れを拒否することで、このリスク負担を制限したい場合があります。認可応答に対応するアカウンティング要求を発行することにより、ローカルレルムは、認可応答に示されたサービスを提供することへの同意を暗黙に示します。ローカルレルムがそのサービスを提供できない場合、アカウンティング要求にDIAMETER_UNABLE_TO_COMPLYエラーメッセージを含めて送信しなければなりません (MUST)。実行できないサービスに対する認可応答を受信した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.
Version：Diameter Version 1を示すため、このVersionフィールドを1に設定しなければなりません (MUST)。
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(eserved) - these flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver.
r(eserved) - これらのフラグビットは将来使用するために予約されています。送信時には0に設定し、受信側では無視しなければなりません (MUST)。
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に格納された値とも同じにしなければなりません (MUST)。
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ビット整数フィールドであり、要求と応答の照合に役立ちます。送信者は、リクエスト内のホップバイホップ識別子が特定の接続で常に一意であることを確認することが必須であり (MUST)、再起動全体で番号が一意であることを確認しようとする場合があります (MAY)。 Answerメッセージの送信者は、Hop-by-Hop Identifierフィールドに、対応するリクエストで見つかったのと同じ値が含まれていることを確認することが必須です (MUST)。ホップバイホップ識別子は通常、単調に増加する数値であり、その開始値はランダムに生成されました。不明なホップバイホップ識別子を使用して受信した応答メッセージは破棄することが必須です (MUST)。
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.
End-to-End Identifier：End-to-End Identifierは、ネットワークバイトオーダーの符号なし32ビット整数フィールドであり、重複メッセージの検出に使用されます。実装は、再起動時に、上位12ビットを現在時刻の下位12ビットに設定し、下位20ビットをランダム値に設定してもよい (MAY)。リクエストメッセージの送信者は、各メッセージに一意の識別子を挿入しなければなりません (MUST)。この識別子は、再起動をまたぐ場合でも、少なくとも4分間はローカルで一意なままでなければなりません (MUST)。Answerメッセージの発信元は、End-to-End Identifierフィールドに、対応するリクエストで検出された値と同じ値が格納されていることを保証しなければなりません (MUST)。いかなる種類のDiameterエージェントも、End-to-End Identifierを変更してはなりません (MUST NOT)。Origin-Host（セクション6.3参照）とこのフィールドの組み合わせが、重複の検出に使用されます。重複リクエストに対しては、同じ応答を送信すべきです (SHOULD)（ただし、hop-by-hop Identifierフィールドおよび存在する可能性のあるルーティング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フィールドにコマンドコードを含めなければなりません (MUST)。このコードは、個々のメッセージに対して実行する処理の決定に使用されます。Diameter基本プロトコルでは、次のCommand Codeが定義されています：
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仕様を含めることが必須です (MUST)。これは、存在することが必須である (MUST) または存在する可能性のある (MAY) 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内に符号化された追加情報も、応答メッセージに含めてもよい (MAY)。
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は複数回列挙してもよい (MAY)。このような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ビット境界に揃うようパディングしなければなりません (MUST)。その他のAVP型は自然に整列します。ワード境界に達するまで、AVP Dataフィールドの末尾に値が0のバイトを追加します。パディングの長さはAVP Lengthフィールドには反映されません。
The fields in the AVP header MUST be sent in network byte order. The format of the header is:
AVPヘッダー内の各フィールドは、ネットワークバイトオーダーで送信しなければなりません (MUST)。ヘッダーの形式は次のとおりです：
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 Flags：AVP Flagsフィールドは、各属性をどのように処理するかを受信者に通知します。「r」(reserved)ビットは未使用であり、0に設定すべきです (SHOULD)。今後のDiameterアプリケーションは、AVP Header内に追加ビットを定義してもよい (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またはその値のいずれかが認識されない場合、メッセージは拒否されることが必須です (MUST)。 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に定義された規則に従って設定することが必須です (MUST)。相互運用性を維持するために、Diameter実装は、Diameterメッセージから、基本Diameterプロトコルでも、それが表示されるメッセージを管理するDiameterアプリケーション仕様でも定義されていない必須AVPを除外できることが必須です (MUST)。次のいずれかの方法でこれを行う場合があります (MAY)。
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」ビットを設定することが必須です (MUST)。 「V」ビットを設定してはなりません (MUST NOT)。
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.
Vendor-ID：AVP Flagsフィールドに「V」ビットが設定されている場合、Vendor-IDフィールドが存在します。オプションの4オクテットのVendor-IDフィールドには、IANAが割り当てた「SMI Network Management Private Enterprise Codes」[ASSIGNNO]の値が、ネットワークバイトオーダーでエンコードされて格納されます。ベンダー固有のDiameter AVPを実装しようとするベンダーは、独自に管理するAVPアドレス空間とともに、自身のVendor-IDを使用しなければなりません (MUST)。これにより、他のベンダーのベンダー固有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.
Dataフィールドは0オクテット以上の長さを持ち、属性固有の情報を格納します。Dataフィールドの形式と長さは、AVP CodeフィールドおよびAVP Lengthフィールドによって決まります。Dataフィールドの形式は、以下の基本データ型のいずれか、または基本データ型から派生したデータ型でなければなりません (MUST)。新しい基本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：Dataには可変長の任意のデータが格納されます。特に明記がない限り、AVP Lengthフィールドは8以上（「V」ビットが有効な場合は12）に設定しなければなりません (MUST)。この型のAVP値の長さが4オクテットの倍数でない場合、その後に必要なパディングが付加され、次の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 Lengthフィールドは12（「V」ビットが有効な場合は16）に設定しなければなりません (MUST)。
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 Lengthフィールドは16（「V」ビットが有効な場合は20）に設定しなければなりません (MUST)。
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 Lengthフィールドは12（「V」ビットが有効な場合は16）に設定しなければなりません (MUST)。
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 Lengthフィールドは16（「V」ビットが有効な場合は20）に設定しなければなりません (MUST)。
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 Lengthフィールドは12（「V」ビットが有効な場合は16）に設定しなければなりません (MUST)。
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 Lengthフィールドは16（「V」ビットが有効な場合は20）に設定しなければなりません (MUST)。
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 Derived Data Formats」という題名のセクションに含めなければなりません (MUST)。新しい定義はそれぞれ、定義内容を記載するか、その形式を定義する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基本形式から派生しています。文字列は、NTPタイムスタンプ形式の先頭4バイトと同じ形式の4オクテットを含まなければなりません (MUST)。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ノードは、この手順をサポートしなければなりません (MUST)。
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までの任意のコードポイントに遭遇する可能性に備えなければなりません (MUST)。コードポイントを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.
制御コードの使用は避けるべきです。新しい行を表すべきである (SHOULD) 場合は、制御コードシーケンスCR LF SHOULDを使用すべきです (SHOULD)。
The use of leading or trailing white space SHOULD be avoided.
先頭または末尾の空白の使用は避けるべきです (SHOULD)。
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進表記など、入力および表示の代替手段を提供してもよい (MAY)。
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であることが必須です (MUST)。同じホスト上で複数のDiameterノードが実行されている場合、各Diameterノードには一意のDiameterIdentityを割り当てることが必須です (MUST)。 Diameterノードを複数のFQDNで識別できる場合は、起動時に単一のFQDNを選択し、送信先の接続が何であれ、そのノードの唯一のDiameterIdentityとして使用する必要があります。
DiameterURI
ぢ編めてるり
The DiameterURI MUST follow the Uniform Resource Identifiers (URI) syntax [URI] rules specified below:
DiameterURIは、以下に示すUniform Resource Identifiers (URI)の構文規則[URI]に従わなければなりません (MUST)。
"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
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フィルターは、次の形式に従わなければなりません (MUST)。
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.
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番号はマスクを超えて設定されたビットを持っていてはなりません (MUST NOT)。一致が発生するには、IPアドレスの記述に使用されたパケットに同じIPバージョンが存在することが必須です (MUST)。特定の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.
denyルールを解釈または適用できないアクセスデバイスは、セッションを終了しなければなりません (MUST)。permitルールを解釈または適用できないアクセスデバイスは、より制限的なルールを適用してもよい (MAY)。アクセスデバイスは、例えばアクセスデバイス所有者のインフラストラクチャを保護するために、提供されたルールより前に独自のdenyルールを適用してもよい (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)
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.
該当する方向のルールは順番に評価され、最初に一致したルールで評価を終了します。各パケットは1回だけ評価されます。どのルールにも一致しない場合、そのパケットはベストエフォートとして扱われます。QoSルールを解釈または適用できないアクセスデバイスは、セッションを終了すべきではありません (SHOULD NOT)。
QoSFilterRule filters MUST follow the format:
QoSFilterRuleフィルターは、次の形式に従わなければなりません (MUST)。
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オプションを含めることが必須です (MUST)。 meter-メーターのトラフィック。計測オプションを含めることが必須です (MUST)。
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.
Grouped AVPに含まれるすべてのAVPのAVP Codeの番号空間は、グループ化されていないAVPのものと同じです。さらに、Grouped AVP内にカプセル化されたAVPのいずれかで「M」（必須）ビットが設定されている場合、そのGrouped AVP自体にも「M」ビットを設定しなければなりません (MUST)。
Every Grouped AVP defined MUST include a corresponding grammar, using ABNF [ABNF] (with modifications), as defined below.
定義されるすべてのGrouped AVPには、以下に定義されているとおり、ABNF [ABNF]（変更あり）を使用した対応する文法を含めなければなりません (MUST)。
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".
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を暗号化できるかどうか (MAY) を示しています。 Diameterメッセージの発信者の場合、 "Encr"（暗号化）は、そのAVPを含むメッセージがDiameterエージェント（プロキシ、リダイレクト、またはリレー）を介して送信される場合、エンドツーエンドがない限り、メッセージを送信してはならない (MUST NOT) ことを意味します。 -発信者と受信者の間のエンドセキュリティと整合性/機密性保護がこのAVPに提供されている、または発信者がローカルで信頼された構成であり、エンドツーエンドのセキュリティが不要であることを示している同様に、Diameterメッセージの発信者の場合、「MAY」列の「P」は、そのAVPを含むメッセージがDiameterエージェント（プロキシ、リダイレクト、またはリレー）経由で送信される場合、メッセージを送信してはならない (MUST NOT) ことを意味します。発信者と受信者の間にエンドツーエンドのセキュリティがない場合、または発信者がエンドツーエンドのセキュリティが不要であることを示すローカルで信頼された構成がない限り。
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)。もちろん、必要と思われる場合、ノードには追加の接続がある場合があります (MAY)。通常、レルムのすべてのメッセージはプライマリピアに送信されますが、フェイルオーバー手順が呼び出された場合、保留中の要求はすべてセカンダリピアに送信されます。ただし、実装はピアのセット間でリクエストを自由にロードバランスできます。
Note that a given peer MAY act as a primary for a given realm, while acting as a secondary for another realm.
特定のピアは、あるレルムではプライマリとして、別のレルムではセカンダリとして動作してもよい (MAY)。この点に注意してください。
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を受信できなかった場合など、さまざまな理由で起こり得ます）、そのピアには新しいリクエストを転送しないのが望ましく、代わりにフェイルオーバー手順を起動します。アクティブなピアがこのモードに移行した場合、必要な数のアクティブな接続を確保するため、追加の接続を確立すべきです (SHOULD)。
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）はサポートされる場合があります (MAY)。
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エージェントにキーを配布すべきです (SHOULD)）。これについては、付録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」でない解決サービスを識別するサービスフィールドをすべて破棄しなければなりません (MUST)。RFC 2915に記載されたNAPTR処理の結果、サーバーが提供するトランスポートプロトコルのうちクライアントがサポートする最優先のものと、そのサーバーのSRVレコードとが検出されます。
The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query.
NAPTR replacementフィールドのドメイン接尾辞は、元のクエリのドメインと一致すべきです (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交換でサーバーから渡されたサイト証明書に基づいて有効であることが必須です (MUST)。同様に、SRVクエリのドメイン名とSRVレコードのターゲットのドメイン名は、どちらも同じサイト証明書に基づいて有効であることが必須です (MUST)。そうでない場合、攻撃者は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ピアは、検出されたピアがその役割を果たす権限を持つことを確認しなければなりません (MUST)。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内で期限切れになる（または更新される）ことが必須である (MUST) ことに注意してください。ピアがローカルレルムの外部で検出された場合、ピアのレルムのルーティングテーブルエントリ（セクション2.7を参照）が作成されます。ルーティングテーブルエントリの有効期限は、ピアの有効期限値と一致することが必須です (MUST)。
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ピアがトランスポート接続を確立するときは、ピアステートマシンに指定されているとおり（セクション5.6参照）、Capabilities Exchangeメッセージを交換しなければなりません (MUST)。このメッセージにより、ピアの識別情報と能力（プロトコルバージョン番号、サポートする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を不必要に送信しないよう、ピアがサポートするアプリケーションをキャッシュしなければなりません (MUST)。
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)を返さなければなりません (MUST)。また、トランスポート層接続を切断すべきです (SHOULD)。自身をRelayとして広告しているピアからCERまたはCEAを受信した場合は、そのピアと共通するアプリケーションがあると解釈しなければなりません (MUST)（セクション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）を返さなければならず (MUST)、トランスポート層の接続を切断すべきです (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は通知なく破棄される場合があります (MAY)。または、結果コードAVPがDIAMETER_UNKNOWN_PEERに設定されたCEAが発行される場合があります (MAY)。どちらの場合も、トランスポート接続は閉じられます。ローカルポリシーが不明なホストからのCERの受信を許可している場合、成功したCEAが返される場合があります (MAY)。不明なピアからの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 AVPまたはAcct-Application-Id AVPを含むRequest型のメッセージ、あるいはアプリケーション固有のコマンドコードを持つメッセージは、そのアプリケーションのサポートを明示的に広告したホスト、またはRelay Application Identifierを広告したホストにのみ転送してもよい (MAY)。
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メッセージには、ローカルで使用される可能性がある (MAY) IPアドレスごとに1つのHost-IP-Address AVPを含めることが必須です (MUST)。 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メッセージには、ローカルで使用される可能性のある (MAY) IPアドレスごとに1つのHost-IP-Address AVPを含めることが必須です (MUST) 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の組み合わせが非常に有用なデバッグ情報を提供する場合があること (MAY) も想定されています。
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メッセージでのみ使用することが必須です (MUST)。
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が返されます。最近転送されたメッセージがまだ転送中である可能性が高く、そのままでは競合状態を引き起こす場合、Disconnect-Peer-Answerにはエラーを含めるべきです (SHOULD)。
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 Code 273）はEnumerated型です。Diameterノードは、トランスポート接続をシャットダウンしようとする理由をピアに通知するため、Disconnect-Peer-RequestメッセージにこのAVPを含めなければなりません (MUST)。次の値がサポートされています。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基本プロトコルに準拠するために、同仕様で定義されたアルゴリズムをサポートしなければなりません (MUST)。
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.
フェイルオーバーの結果として、複数の同一の要求または応答が受信される場合がある (MAY) ことに注意することが重要です。 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実装で監視することが必須である (MUST) 有限状態マシンが含まれています。各Diameterノードは、各ピアと通信するときに、以下で説明するステートマシンに従うことが必須です (MUST)。複数のアクションはコンマで区切られ、スペースが必要なため、後続の行に続く場合があります。同様に、状態に応じて、状態と次の状態も複数の行にまたがることがあります。
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-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-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
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-Peer-Disc R-Disc Closed
R-Rcv-CER R-Snd-CEA R-Open
R-Rcv-CEA Process-CEA R-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-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
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
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 AVPとDestination-Host AVPのいずれも含めてはなりません (MUST NOT)。
- 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.
- 特定のレルムを提供するホームサーバーに送信することが必須である (MUST) が、特定のサーバーには送信しない要求（一連の往復の最初の要求など）には、宛先レルムAVPを含めなければなりませんが (MUST)、宛先ホストAVPを含めてはなりません (MUST NOT)。
- 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.
- それ以外の場合、あるレルムにサービスを提供するホームサーバーのうち特定の1台が送信先となるリクエストには、Destination-Realm AVPとDestination-Host AVPの両方を含めなければなりません (MUST)。
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.
- サーバーが開始するメッセージであり、そのメッセージを特定のDiameterクライアント（アクセスデバイスなど）が受信しなければなりません (MUST)。たとえば、特定ユーザーのセッション終了を要求するAbort-Session-Requestメッセージが該当します。
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.
メッセージがプロキシ可能な場合、Destination-Realm AVPが存在しなければなりません (MUST)。Diameterエージェント（プロキシ、リダイレクト、またはリレー）が転送可能なリクエストメッセージには、Acct-Application-Id AVP、Auth-Application-Id AVP、またはVendor-Specific-Application-Id AVPのいずれかも含めなければなりません (MUST)。Diameterエージェントは、転送禁止と定められたメッセージを転送してはなりません (MUST NOT)。そのようなメッセージのABNFは、Destination-Realmを含まないものでなければなりません (MUST)。Destination-Realm AVPの値は、User-Name AVPから抽出するか、その他のアプリケーション固有の方法で取得してもよい (MAY)。
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ノードが互いにピアでなければなりません (MUST)。
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開発者向けの一般的なガイドラインとして使用することを意図しています。実装によっては、ここで説明したものとは異なる方法を使用してもよい (MAY)。その場合でも、プロトコル仕様に準拠できます。エラー処理の詳細はセクション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:
リクエストを作成するときは、そのリクエストに固有のアプリケーション定義に記載されたほかの手順に加え、次の手順に従わなければなりません (MUST)。
- 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は、メッセージの送信元を識別するための適切な値に設定しなければなりません (MUST)。
- the Destination-Host and Destination-Realm AVPs MUST be set to the appropriate values as described in Section 6.1.
- Destination-HostおよびDestination-Realm AVPは、セクション6.1に記載された適切な値に設定しなければなりません (MUST)。
- 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:
ローカルで生成したリクエスト、または転送もしくはルーティング処理の結果として生じたリクエストを送信するときは、次の手順に従わなければなりません (MUST)。
- 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.
リレーまたはプロキシエージェントは、リクエストを受信したときに転送ループをチェックすることが必須です (MUST)。サーバーがRoute-Record AVPで独自のIDを見つけた場合、ループが検出されます。このようなイベントが発生した場合、エージェントは、結果コードAVPをDIAMETER_LOOP_DETECTEDに設定して応答することが必須です (MUST)。
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のいずれかを含めることが必須です (MUST)。 -アプリケーション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)、外部でサポートされているレルムとアプリケーションのリストがある場合もあります (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に設定されたリクエストを受信した場合、ヘッダー内のHop-by-Hop Identifierを維持し、「E」ビットを設定した応答メッセージを返すとともに、そのメッセージにDIAMETER_REDIRECT_INDICATIONに設定したResult-Code AVPを含めなければなりません (MUST)。そのルーティングエントリに関連付けられた各サーバーは、それぞれ個別のRedirect-Host 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を追加しなければなりません (MUST)。このAVPには、その要求の受信元ピアの識別情報が格納されます。
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を含めてもよい (MAY)。Proxy-Info AVPには一定のセキュリティ上の影響があり、ノードローカルキーを用いた埋め込みHMACを含めるべきです (SHOULD)。別の方法として、エージェントは単にローカルストレージを使用して状態情報を格納してもよい (MAY)。
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アプリケーションで説明される可能性がある (MAY) 追加の手順に加えて、関連する回答を作成するために次の手順を適用することが必須です (MUST)。
- 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が存在する場合、それを応答に含めなければなりません (MUST)。
- 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を、その要求内に含まれていた順序と同じ順序で応答メッセージに追加しなければなりません (MUST)。
- 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クライアントまたはプロキシは、保留中のリクエストのリストに対して受信した応答のホップバイホップ識別子と一致することが必須です (MUST)。対応するメッセージは、保留中のリクエストのリストから削除すべきです (SHOULD)。既知のホップバイホップ識別子と一致しない受信した回答は無視する必要があります。
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ヘッダーのHop-by-Hop Identifierフィールドを元の値に戻さなければなりません (MUST)。
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を削除しなければなりません (MUST)。
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の内容を変更してはなりません (MUST NOT)。追加のローカルエラーが検出された場合はログに記録すべきです (SHOULD) が、結果コードAVPには反映されません。エージェントが成功を示すResult-Code AVPを含む応答メッセージを受信し、エラーを示すようにAVPを変更したい場合、アクセスデバイス宛てのメッセージに適切なエラーが含まれるようにResult-Code AVPを変更することが必須です (MUST)。また、Error-Reporting-Host AVPを含め、アクセスデバイスに代わってSTRを発行することが必須です (MUST)。
The agent MUST then send the answer to the host that it received the original request from.
その後、エージェントは、元の要求の送信元ホストへ応答を送信しなければなりません (MUST)。
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メッセージに存在することが必須です (MUST)。このAVPは、Diameterメッセージを発信したエンドポイントを識別します。リレーエージェントはこのAVPを変更してはなりません (MUST NOT)。
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 Code 296）はDiameterIdentity型です。このAVPには、Diameterメッセージ発信元のRealmが格納されます。また、このAVPはすべてのメッセージに存在しなければなりません (MUST)。
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.
Destination-Host AVP（AVP Code 293）はDiameterIdentity型です。このAVPは、エージェントが自発的に開始したすべてのメッセージに存在しなければなりません (MUST)。要求メッセージには存在してもよい (MAY)。ただし、Answerメッセージには存在してはなりません (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 Code 282）はDiameterIdentity型です。このAVPに追加される識別情報は、Capabilities ExchangeメッセージのOrigin-Hostで受信した識別情報と同じでなければなりません (MUST)。
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 Code 258）はUnsigned32型であり、アプリケーションの認証および認可部分をサポートしていることを広告するために使用されます（Section 2.4参照）。Auth-Application-Idは、別のDiameter仕様で定義され、Application IDが割り当てられているすべての認証および/または認可メッセージにも存在しなければなりません (MUST)。
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は、すべてのアカウンティングメッセージにも存在することが必須です (MUST)。 Auth-Application-IdおよびAcct-Application-Id AVPの1つだけが存在する場合があります (MAY)。
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 Code 260）はGrouped型であり、ベンダー固有のDiameterアプリケーションをサポートしていることを広告するために使用されます。Auth-Application-Id AVPとAcct-Application-Id AVPのうち、ちょうど1つが存在してもよい (MAY)。
This AVP MUST also be present as the first AVP in all experimental commands defined in the vendor-specific application.
また、このAVPは、ベンダー固有アプリケーションで定義されるすべての実験的コマンド内に、最初のAVPとして存在しなければなりません (MUST)。
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'ビットが設定され、かつResult-Code AVPがDIAMETER_REDIRECT_INDICATIONに設定されている場合、このAVPのインスタンスが1つ以上存在しなければなりません (MUST)。
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)。選択されたRedirect-Host 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 Code 261）はEnumerated型です。このAVPは、'E'ビットが設定され、かつResult-Code AVPがDIAMETER_REDIRECT_INDICATIONに設定されている応答メッセージに存在してもよい (MAY)。
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で指定されたホストへ送信してもよい (MAY)。
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で指定されたホストへ送信してもよい (MAY)。
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で指定されたホストへ送信してもよい (MAY)。
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で指定されたホストへ送信してもよい (MAY)。
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で指定されたホストへ送信してもよい (MAY)。
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で指定されたホストへ送信してもよい (MAY)。
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 Code 262）はUnsigned32型です。このAVPは、'E'ビットが設定され、Result-Code AVPがDIAMETER_REDIRECT_INDICATIONに設定され、かつRedirect-Host-Usage AVPがゼロ以外の値に設定されている応答メッセージに存在しなければなりません (MUST)。
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には、Redirect-Hostに基づいて作成されたピアテーブルおよびルーティングテーブルのエントリをキャッシュする最大秒数が格納されます。なお、リダイレクト指示によって作成されたホストへ到達できなくなった時点で、関連するピアテーブルおよびルーティングテーブルのエントリをすべて削除しなければなりません (MUST)。
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 Code 300）は、エンドツーエンドメッセージにアンチリプレイ保護を提供するGrouped型です。このAVPには、ランダム値（nonceを含むOctetString）とカウンター（Integer）が格納されます。ノードが通信している（または通信したことを記憶している）エンドツーエンドピアごとに異なるnonce値を使用しなければなりません (MUST)。カウンターは0から開始され、このAVPがそのピアに送出されるたびに1ずつ増加します。このAVPは、エンドツーエンド保護（例：CMS署名または暗号化）を使用するすべてのメッセージに含めなければなりません (MUST)。
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種類のエラーがあります。プロトコルエラーは基本プロトコルレベルで発生し、ホップごとの対応を要求してもよい (MAY) ものです（例：メッセージルーティングエラー）。一方、アプリケーションエラーは一般に、Diameterアプリケーションで規定された機能の問題（例：ユーザー認証、Missing 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'ビットが設定された応答メッセージだけに限定しなければなりません (MUST)。プロトコルエラーを引き起こす要求メッセージを受信した場合、'E'ビットを設定した応答メッセージが返され、Result-Code 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:
Result-Code AVPが示すアプリケーションエラーの中には、応答に追加のAVPを含めることが求められるものがあります。その場合、Result-Code AVPをエラーを示す値に設定するDiameterノードは、それらのAVPを追加しなければなりません (MUST)。例を次に示します。
- 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ノードは最初に遭遇したエラーだけを報告しなければなりません (MUST)（検出順序は実装に依存する可能性があります）。この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を含めることが必須です (MUST)。成功しないResult-Code AVP（DIAMETER_REDIRECT_INDICATION以外の2xxx以外の値を含むもの）は、Result-Code AVPを設定するホストがOrigin-Host AVPでエンコードされたIDと異なる場合、Error-Reporting-Host AVPを含めることが必須です (MUST)。
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.
認識されないクラス（先頭の桁が本節で定義されていないクラス）は、永続的障害として扱わなければなりません (MUST)。
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.
Protocol Errorカテゴリに属するエラーは、ホップごとに処理すべきです (SHOULD)。可能な場合、Diameterプロキシはエラーの修正を試みてもよい (MAY)。なお、これらのエラーだけを、'E'ビットが設定された応答メッセージでのみ使用しなければなりません (MUST)。
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 要求には、受信側が認識もサポートもしていないCommand-Codeが含まれていました。Diameterノードが理解できない実験的コマンドを受信した場合、この結果コードを使用しなければなりません (MUST)。
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)。このエラーの使用は、特定のサーバーが要求され、かつそのサーバーが要求されたサービスを提供できない場合だけに限定しなければなりません (MUST)。
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 エージェントは、意図された受信者へメッセージを届けようとしている間にループを検出しました。利用可能な代替ピアがある場合、メッセージをそのピアへ送信してもよい (MAY)。ただし、このエラーを報告するピアは構成上の問題を特定しています。
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が存在しなければなりません (MUST)。
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.
一時的障害カテゴリに属するエラーは、要求の受信時にはその要求を満たせなかったものの、将来はその要求を満たしてもよい (MAY) ことをピアに通知するために使用されます。
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 ユーザーの認証処理が失敗しました。ユーザーが無効なパスワードを使用したことが原因である可能性が最も高いです。それ以降の再試行は、ユーザーに新しいパスワードの入力を促した後にのみ行わなければなりません (MUST)。
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 ピアは、認識もサポートもされておらず、Mandatoryビットが設定されたAVPを含むメッセージを受信しました。このエラーを示すDiameterメッセージには、障害の原因となったAVPを格納する1つ以上のFailed-AVP AVPを含めなければなりません (MUST)。
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メッセージは、問題の原因となったAVPをFailed-AVP AVP内に含めなければなりません (MUST)。
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がメッセージに含まれるべきです (SHOULD)。 Failed-AVP AVPには、該当する場合、Vendor-Idを備えた欠落AVPの例を含めることが必須です (MUST)。欠落している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 ホームDiameterサーバーは、要求内で互いに矛盾するAVPを検出したため、ユーザーにサービスを提供しません。互いに矛盾したAVPを格納する1つ以上のFailed-AVP AVPが存在しなければなりません (MUST)。
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存在してはならない (MUST NOT) AVPを含むメッセージが受信されました。 Failed-AVP AVPが含まれていて、問題のAVPのコピーを含んでいることが必須です (MUST)。
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の最初のインスタンスのコピーを格納しなければなりません (MUST)。
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メッセージは、問題の原因となったAVPをFailed-AVP AVP内に含めなければなりません (MUST)。
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 Flagsフィールドで指定された値を持つことが許可されていないAVPが含まれていました。このエラーを示すDiameterメッセージは、問題の原因となったAVPをFailed-AVP AVP内に含めなければなりません (MUST)。
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メッセージを受信したものの、ピア間で共通してサポートされるセキュリティ機構がない場合に、このエラーが返されます。Result-Code AVPをDIAMETER_NO_COMMON_SECURITYに設定したCapabilities-Exchange-Answer (CEA)を返さなければなりません (MUST)。
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を伴う場合があります (MAY)。 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 Code 294）はDiameterIdentity型です。Result-Codeを設定したホストがOrigin-Host AVPにエンコードされたホストと異なる場合に限り、このAVPには、Result-Code AVPを2001 (Success)以外の値に設定して送信したDiameterホストの識別情報が格納されます。このAVPはトラブルシューティング用であり、Result-Code AVPが失敗を示す場合に設定しなければなりません (MUST)。
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全体を格納したFailed-AVP AVPを1つ含めてもよい (MAY)。失敗の原因が必須AVPの欠落である場合、欠落したAVPのコードとベンダーIDを持ち、かつ欠落したAVPに求められる最小長までゼロで埋めたペイロードを持つAVPが追加されます。
AVP Format
AVPフォーマット
<Failed-AVP> ::= < AVP Header: 279 >
1* {AVP}
The Experimental-Result AVP (AVP Code 297) is of type Grouped, and indicates whether a particular vendor-specific request was completed successfully or whether an error occurred. 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.
このGrouped AVP内のVendor-Id AVP（Section 5.3.3参照）は、後続する結果コードの割り当てを担当するベンダーを識別します。ベンダー固有アプリケーションで定義されるすべてのDiameter応答メッセージは、Result-Code AVPまたはExperimental-Result AVPのいずれか一方を1つ含めなければなりません (MUST)。
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を追加することが必須です (MUST)。 Authorization-Lifetime AVPは、ユーザーがリソースを利用できる (MAY) 最大秒数を定義します。この秒数を超えると、サーバーは別の承認リクエストを予期します。 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を含めることができます (MAY)。サーバーがヒントを受け入れると、ユーザーへのサービスが終了するとセッション終了メッセージが受信されないため、セッションの状態を維持できないことに同意します。サーバーからの応答メッセージにAuth-Session-State AVPに異なる値（またはAVPがない場合のデフォルト値）が含まれている場合、アクセスデバイスはサーバーの指示に従うことが必須です (MUST)。値NO_STATE_MAINTAINEDは、後続の再認証要求と応答で設定してはならない (MUST NOT) ことに注意してください。
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実装は、これらの状態機械に従わなければなりません (MUST)。以下のService-Specificという用語は、Diameterアプリケーションで定義されたメッセージ（例：Mobile 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.
セッションがIdle状態へ移行した場合、そのセッションに割り当てられたリソースはすべて解放されなければなりません。ステートマシンに記載されていないイベントは、エラー状態と見なさなければなりません (MUST)。また、該当する場合は、メッセージの発信元へ応答を返さなければなりません (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
Pending Successful Service-specific Grant Open
authorization answer Access
received with default
Auth-Session-State value
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.
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.
Open ASR Received, Send ASA Open
client will not comply with with
request to end the session 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
Open Service-specific authorization Send Open
request received, and user successful
is authorized serv. specific
answer
Open Service-specific authorization Send Idle
request received, and user failed serv.
is not authorized specific
answer,
Cleanup
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
Pending Failed Service-specific Cleanup Idle authorization answer received
保留中の失敗したサービス固有のCleanup Idle承認応答を受け取りました
Open Session-Timeout Expires on Discon. Idle
Access Device user/device
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.
以下のステートマシンは、アカウンティング部分を持つアプリケーション、またはアカウンティングサービスのみを必要とするアプリケーションでサポートされなければなりません (MUST)。最初のステートマシンには、クライアントが従います。
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基本プロトコルは、デフォルトのステートマシンを定義します。別のステートマシンを指定していないすべてのアプリケーションは、このデフォルトのステートマシンに従わなければなりません (MUST)。これは、このセクションで以下に示す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実装は、これらのレコードに基づく検査、順序付け、関連付け、不正検出、およびその他の処理を実行してもよい (MAY)。これらの処理の一環として、Diameter基本プロトコルのAVPとアプリケーション固有のAVPの両方を検査してもよい (MAY)。これらの処理は、レコードの受信直後または後処理段階で実行できます。ただし、通常はアプリケーションやポリシーに依存するため、Diameter仕様では標準化されていません。アプリケーションは、Accounting-Realtime-Required AVPに使用される値、信用限度の確認などに基づき、アカウンティングレコードを受け入れる時期に関する要件を定義してもよい (MAY)。
However, the Diameter base protocol defines one optional server side state machine that MAY be followed by applications that require keeping track of the session state at the accounting server. Note that such tracking is incompatible with the ability to sustain long duration connectivity problems. Therefore, the use of this state machine is recommended only in applications where the value of the Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, 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基本プロトコルは、アカウンティングサーバーでセッション状態を追跡する必要のあるアプリケーションが後に続く可能性がある (MAY) 1つのオプションのサーバー側の状態マシンを定義します。このようなトラッキングは、長時間の接続の問題を維持する機能と互換性がないことに注意してください。したがって、このステートマシンの使用は、Accounting-Realtime-Required AVPの値がDELIVER_AND_GRANTであるアプリケーションでのみ推奨されます。そのため、サービス対象ユーザーを切断するには、アカウンティング接続の問題が必要です。そうしないと、クライアントによって生成されたレコードがサーバーによって失われる可能性があり、サーバーは接続が再確立された後にそれらを受け入れなくなります。このステートマシンは、このセクションの3番目のステートマシンです。状態マシンは、監視セッションタイマーTsによって監視されます。この値は、Acct_Interim_Interval値よりもかなり高い必要があります。 TsをAcct_Interim_Intervalの値の2倍に設定してもよく (MAY)、短時間の一時的なネットワーク障害が発生した場合に、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)、該当する場合は対応する応答がメッセージの発信者に返されなければなりません (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」は、認可セッション状態テーブルにも影響を及ぼさなければなりません (MUST)。影響の例として、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
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 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 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 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 User service terminated Store PendingI
stop
record
PendingE Successful accounting Idle
event answer received
PendingE Failure to send and buffer Store Idle
space available event
record
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 Failure to send Idle
PendingBがアイドル送信に失敗
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 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 event request Send Idle
received, and successfully accounting
processed. event
answer
Idle Interim record received, Send Idle
and successfully processed. accounting
interim
answer
Idle Accounting stop request Send Idle
received, and successfully accounting
processed stop answer
Idle Accounting request received, Send Idle
no space left to store accounting
records answer,
Result-Code
= OUT_OF_
SPACE
SERVER, STATEFUL ACCOUNTING
State Event Action New State
-------------------------------------------------------------
Idle Accounting start request Send Open
received, and successfully accounting
processed. start
answer,
Start Ts
Idle Accounting event request Send Idle
received, and successfully accounting
processed. event
answer
Idle Accounting request received, Send Idle
no space left to store accounting
records answer,
Result-Code
= OUT_OF_
SPACE
Open Interim record received, Send Open
and successfully processed. accounting
interim
answer,
Restart Ts
Open Accounting stop request Send Idle
received, and successfully accounting
processed stop answer,
Stop Ts
Open Accounting request received, Send Idle
no space left to store accounting
records answer,
Result-Code
= OUT_OF_
SPACE,
Stop Ts
Open Session supervision timer Ts Stop Ts Idle expired
オープンセッション監視タイマー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メッセージを受信するアクセスデバイスは、ユーザーに対して再認証を開始することが必須です (MUST)。一部のアプリケーションでは、アクセスデバイスがユーザーに再認証を要求することを許可しないため、各Diameterアプリケーションは、サービスが開始した再認証がサポートされているかどうかを明示することが必須です (MUST)。
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メッセージの後には、アプリケーション固有の認証および/または認可メッセージが続かなければなりません (MUST)。
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）メッセージを発行して、セッションがアクティブでなくなったことを通知することが必須です (MUST)。 STRは、ユーザーのログオフ、Session-Timeoutの期限切れ、管理アクション、Abort-Session-Request（以下を参照）の受信による終了、アクセスデバイスの正常なシャットダウンなど、何らかの理由でユーザーセッションが終了したときに発行することが必須です (MUST)。 。
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を発行しなければなりません (MUST)。これは、例えばアクセスデバイスで突然リソースが不足した場合、認可で要求された種類のサービスをアクセスデバイスが提供しようとしない場合、認可応答で返された必須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を発行しなければなりません (MUST)。アクセスデバイスには、そのセッションが認可済みであったことを知る手段がないためです。
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を返さなければなりません (MUST)。
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サーバーは、そのセッションのSTRを受信したかどうかにかかわらず、Session-Timeoutの期限切れ時、または再認可要求を受信しないままAuthorization-Lifetime AVPおよびAuth-Grace-Period AVPが期限切れになった時にも、リソースをクリーンアップしなければなりません (MUST)。アクセスデバイスがこれらのタイマーの有効期間を超えてサービスを提供することは想定されていません。したがって、いずれかのタイマーの期限切れは、アクセスデバイスが予期せずシャットダウンした可能性を示します。
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のサービス中にエラーが発生したことを示す場合があります (MAY)。
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 Serverは、Session-Id AVPが示すセッションのリソースをすべて解放しなければなりません (MUST)。Proxy-Chain内の中間サーバーも、必要に応じてリソースを解放してもよい (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を受信するアクセスデバイスは、セッションを停止する場合があります (MAY)。アクセスデバイスがセッションを停止するかどうかは、実装や設定に依存します。たとえば、アクセスデバイスは特定のエージェントからのASRのみを受け入れる場合があります。いずれの場合でも、アクセスデバイスは、Result-Code AVPを含むAbort-Session-Answerで応答し、どのアクションを実行したかを示すことが必須です (MUST)。
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サーバーは、失われたセッションに関連するすべてのセッション状態をクリーンアップできます (MAY)。また、上流のサーバーで承認された失われたすべてのセッションに対してSTRを発行して、セッション状態をグローバルにクリーンアップできるようにする場合があります (MAY)。
The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is included in application-specific auth requests to inform the peers whether a user is to be authenticated only, authorized only or both. Note any value other than both MAY cause RADIUS interoperability issues. The following values are defined:
Auth-Request-Type AVP（AVPコード274）はEnumeratedタイプであり、アプリケーション固有の認証リクエストに含まれており、ユーザーが認証のみか、承認のみか、またはその両方かをピアに通知します。両方以外の値はRADIUSの相互運用性の問題を引き起こすことがある (MAY) ことに注意してください。以下の値が定義されています。
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を含めなければなりません (MUST)。
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を含めなければなりません (MUST)。
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：要求には認証と認可の両方に対する要求が含まれます。要求には、関連するアプリケーション固有の認証情報と、要求または提供されるサービスを識別するために必要となる認可情報の両方を含めなければなりません (MUST)。
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つだけ含めることが必須であり (MUST)、セッションの存続期間を通じて同じ値を使用することが必須です (MUST)。存在する場合、Session-IdはDiameterヘッダーの直後に表示すべきです (SHOULD)（セクション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は、他の情報を参照せずにユーザーセッションを一意に識別するためのものであり、過去の認証情報とアカウンティング情報との関連付けに必要になる場合があるため、グローバルかつ永続的に一意でなければなりません (MUST)。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で始まらなければなりません (MUST)（セクション4.4を参照）。 Session-Idの残りは「;」で区切られます。文字、およびクライアントが永久に一意であることを保証できる任意のシーケンスである場合があります (MAY)。ただし、次の形式をお勧めします（角括弧[]はオプションの要素を示します）。
<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.
Session-Idはセッションを開始するDiameterアプリケーションによって作成され、ほとんどの場合はクライアントが作成します。1つのSession-Idを、特定のアプリケーションの認可コマンドとアカウンティングコマンドの両方に使用してもよい (MAY) ことに注意してください。
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を再認可メッセージに含めてもよい (MAY)。この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は、クライアントが受け入れ可能な最大有効期間のヒントとしてクライアントから提供される場合があります (MAY)。ただし、サーバーは、クライアントによって提供された値以下の値を返す場合があります (MAY)。
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 Code 277）はEnumerated型であり、特定のセッションについて状態を維持するかどうかを指定します。クライアントはサーバーへのヒントとして要求にこのAVPを含めてもよい (MAY) ですが、サーバーの応答メッセージに含まれる値には拘束力があります。次の値がサポートされています。
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：この値はセッション状態が維持されることを指定するために使用され、ユーザーへのサービスが終了したとき、アクセスデバイスはセッション終了メッセージを発行しなければなりません (MUST)。これがデフォルト値です。
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 Code 285）はEnumerated型であり、Authorization-Lifetimeの期限切れ時に期待される動作をクライアントへ通知するため、アプリケーション固有の認証/認可応答に含まれます。応答メッセージに正の値を持つAuthorization-Lifetime AVPが含まれる場合、その応答メッセージにはRe-Auth-Request-Type AVPも含まれなければなりません (MUST)。次の値が定義されています。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).
Session-Timeoutの期限切れによってアクセスデバイス上で終了するセッションについては、アクセスデバイスとホームサーバーの両方がセッション終了メッセージを送信しないことにあらかじめ合意していた場合を除き、STRが発行されなければなりません (MUST)（セクション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.
Session-Timeout AVPを再認可応答メッセージに含めてもよい (MAY)。この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は、クライアントが許容できる最大タイムアウトのヒントとしてクライアントから提供される場合があります (MAY)。ただし、サーバーは、クライアントによって提供された値以下の値を返す場合があります (MAY)。
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 Code 278）は単調増加する値であり、Diameterエンティティが以前の状態を失って再起動するたび、例えばリブートするたびに増加します。Origin-State-Idは、CERを含む任意のDiameterメッセージに含めてもよい (MAY)。
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により高い値を作成することが必須です (MUST)。 Diameterエンティティは、Origin-State-Idを起動時の時間に設定する場合があります (MAY)。または、再起動時に不揮発性メモリに保持される増分カウンタを使用する場合があります (MAY)。
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によって示されるエンティティの状態を反映することが必須です (MUST)。プロキシがOrigin-Hostを変更する場合、Origin-State-Idを削除するか、適切に変更することが必須です (MUST)。
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に設定するかのいずれかを行わなければなりません (MUST)。
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.
Session-Binding AVP（AVP Code 270）はUnsigned32型であり、アプリケーション固有の認可応答メッセージに含まれてもよい (MAY)。このAVPが存在する場合、Diameterクライアントに次のことを通知してもよい (MAY)。このセッションに関する今後すべてのアプリケーション固有の再認可メッセージを、同じ認可サーバーへ送信しなければなりません (MUST)。また、このAVPは次のことも指定してもよい (MAY)。このセッションのSession-Termination-Requestメッセージを、同じ認可サーバーへ送信しなければなりません (MUST)。
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を含めてはなりません (MUST NOT)。オフにすると、デフォルト値のDestination-Host AVPが、このセッションのすべての再認証メッセージに存在することが必須です (MUST)。
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メッセージに存在することが必須です (MUST)。
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を含めてはなりません (MUST NOT)。クリアすると、デフォルト値のDestination-Host AVPがわかっている場合は、このセッションのすべてのアカウンティングメッセージに存在することが必須です (MUST)。
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 Code 271）はEnumerated型であり、Session-Binding AVPを含まないか、Session-Binding AVPを含む場合はそのビットのいずれかが0に設定されている、アプリケーション固有の認可応答メッセージに含まれてもよい (MAY)。このAVPが存在する場合、次のことをDiameterクライアントへ通知してもよい (MAY)。配送上の問題によって再認可メッセージまたはSTRメッセージが失敗した場合、DiameterクライアントはDestination-Host AVPを含まない後続メッセージを発行すべきです (SHOULD)。このAVPが存在しない場合、デフォルト値は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 Code 272）はUnsigned32型であり、Result-Code AVPがDIAMETER_MULTI_ROUND_AUTHに設定されているアプリケーション固有の認可応答メッセージに含まれるべきです (SHOULD)。このAVPには、認証要求への応答時間としてアクセスデバイスがユーザーに与える最大秒数が格納されます。アクセスデバイスは、この秒数をユーザーに与えなければなりません (MUST)。
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.
Class AVP（AVP Code 25）はOctetString型であり、Diameterサーバーがアクセスデバイスへ状態情報を返すために使用されます。アプリケーション固有の認可応答メッセージに1つ以上のClass AVPが含まれる場合、それらを後続の再認可メッセージ、セッション終了メッセージ、およびアカウンティングメッセージにも含めなければなりません (MUST)。再認可応答メッセージに含まれるClass AVPは、それ以前の認可応答メッセージに含まれていたClass AVPを上書きします。Diameterサーバー実装は、Diameterクライアント上で4096バイトを超える記憶領域を要求するClass AVPを返すべきではありません (SHOULD NOT)。ローカルで利用可能な記憶領域を超える大きさのClass AVPを受信したDiameterクライアントは、セッションを終了しなければなりません (MUST)。
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 Code 55）はTime型であり、報告対象のイベントが発生した時刻を1900年1月1日00:00 UTCからの秒数で記録するため、Accounting-RequestメッセージおよびAccounting-Answerメッセージに含めてもよい (MAY)。
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 AVPまたはAccounting-Realtime-Required AVPを含めることで、中間間隔またはリアルタイム要件を上書きしてもよい (MAY)。いずれかのAVPが存在する場合、同じセッションについてその後に行うアカウンティング処理では、最後に受信した値を使用すべきです (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ノードは、セッションのアカウンティング情報を収集することが必須です (MUST)。 Accounting-Requestメッセージは、アカウンティング情報をホームAAAサーバーに送信するために使用されます。ホームAAAサーバーは、受信を確認するためにAccounting-Answerメッセージで応答することが必須です (MUST)。 Accounting-Answerメッセージには、Result-Code AVPが含まれています。これは、アカウンティングメッセージにエラーが存在したことを示す場合があります (MAY)。拒否されたAccounting-Requestメッセージは、問題のセッションについて以前に受信したAccounting-Realtime-Required AVPの値に応じて、ユーザーのセッションを終了させる場合があります (MAY)。
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プロトコルメッセージは圧縮される場合があります (MAY)。 IPsecとIKEを使用してDiameterセッションを保護する場合、IP圧縮[IPComp]を使用してもよく (MAY)、IKE [IKE]を使用して圧縮パラメータをネゴシエートしてもよい (MAY)。 TLSを使用してDiameterセッションを保護する場合は、TLS圧縮[TLS]を使用できます (MAY)。
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メッセージに存在することが必須である (MUST) サービス固有のAVPを定義することが必須です (MUST)。アプリケーションは、このドキュメントで説明されているAVPがすべてのアカウンティングメッセージに存在すると想定することが必須である (MUST) ため、このセクションでは、それぞれのサービス固有の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ピアは、フェイルオーバーを使用してサーバーの障害や特定のネットワーク障害から保護することが必須です (MUST)。エージェントとして機能するDiameterピアまたは関連するオフライン処理システムは、複数のサーバーへの同じレコードの送信と送信中のメッセージの重複によって引き起こされる重複したアカウンティングレコードを検出することが必須です (MUST)。この検出は、Session-IdおよびAccounting-Record-Number AVPペアの検査に基づくことが必須です (MUST)。付録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クライアントは、再起動、長期のネットワーク障害、ネットワーク分断、またはサーバー障害をまたいでアカウンティングレコードを安全に保存するための不揮発性メモリを備えてもよい (MAY)。そのようなメモリを利用できる場合、クライアントは新しいアカウンティングレコードを作成後ただちにそこへ保存し、Diameter Serverから受信の肯定応答を受け取るまで保持すべきです (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)。クライアントは、メモリなどのリソースが不足した場合、最も古い、配信されていない、または未確認のアカウンティングデータを削除する場合があります (MAY)。この状況でクライアントが新しいセッションを受け入れるのは、実装に依存する問題です。
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が存在することが必須です (MUST)。ユーザー名AVPは、Diameterクライアントで使用できる場合に存在することが必須です (MUST)。エージェント間で強力な認証が必要な場合は、エンドツーエンドのセキュリティを認証目的で使用できます。
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.
アカウンティング対象サービスの実際の種類と、中間アカウンティングに関する認可サーバーの指示に応じて、異なる種類のアカウンティングレコードが送信されます。アカウンティング対象サービスが、開始と終了が同時に起きる一回限りのイベントである場合、Accounting-Record-Type AVPが含まれ、その値がEVENT_RECORDに設定されなければなりません (MUST)。
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を使用することが必須です (MUST)。承認サーバーがセッションで有効になっている中間アカウンティングを指示していない場合は、セッションタイプのサービスごとに2つのアカウンティングレコードを生成することが必須です (MUST)。特定のセッションの最初のAccounting-Requestが送信されるとき、Accounting-Record-Type AVPは値START_RECORDに設定することが必須です (MUST)。最後のAccounting-Requestが送信されるとき、値はSTOP_RECORDでなければなりません (MUST)。
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とマークされた追加のレコードを作成することが必須です (MUST)。これらのレコードの生成は、Acct-Interim-Intervalおよびセッションの再認証または再承認によって指示されます。同じレコードの新しいレコードが生成されている場合、Diameterクライアントは、配信のためにローカルに保存されている以前の中間アカウンティングレコードを上書きすることが必須です (MUST)。これにより、特定のセッションのアクセスデバイス上に保留中の中間レコードが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つのシーケンスのアカウンティングレコードにのみ出現することが必須です (MUST)。送信される1つのシーケンスは、Accounting-Record-Type AVPが値EVENT_RECORDに設定された1つのレコードか、値がSTART_RECORDのレコードで始まり、その後に0個以上のINTERIM_RECORDと単一のSTOP_RECORDが続くレコードであることが必須です (MUST)。特定のDiameterアプリケーション仕様では、使用することが必須である (MUST) シーケンスのタイプを定義することが必須です (MUST)。
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を使用する場合があります (MAY)。特定のアプリケーションでは、アカウンティングメッセージに異なるセッションIDが必要になる場合があります (MAY)。
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が使用されます。認可の間、要求が既存のセッションに対するものであることを決定するサーバーは、アクセスデバイスが後続のすべてのアカウンティングメッセージに含めるべきである (SHOULD) Acct-Multi-Session-Id AVPを含めることが必須です (MUST)。
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の値が含まれる場合があります (MAY)。その内容は実装固有ですが、他のAcct-Multi-Session-Id全体でグローバルに一意であることが必須であり (MUST)、セッションの存続期間中に変更してはなりません (MUST NOT)。
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.
このセクションで定義するCommand-Code値は、アカウンティングサービスを提供するすべてのDiameter実装でサポートされなければなりません (MUST)。
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 AVPとVendor-Specific-Application-Id AVPのいずれか一方が含まれなければなりません (MUST)。グループ化AVPであるVendor-Specific-Application-Idが含まれる場合、その内部に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.
Command-Codeフィールドが271に設定され、Command Flagsの「R」ビットがクリアされているAccounting-Answer（ACA）コマンドは、Accounting-Requestコマンドの受信を確認するために使用されます。Accounting-Answerコマンドは同じSession-Idを格納し、このコマンドの送信時にCMSを使用している場合に限って使用量AVPを含みます。CMSを使用していない場合に使用量AVPを含めると、応答メッセージが不必要に大きくなるうえ、サーバーがこれらのAVPをエンドツーエンドで受信したことの証明として使用することもできません。Accounting-Requestがエンドツーエンドセキュリティで保護されていた場合、対応するACAメッセージもエンドツーエンドセキュリティで保護されなければなりません (MUST)。
Only the target Diameter Server, known as the home Diameter Server, SHOULD respond with the Accounting-Answer command.
ホームDiameterサーバーと呼ばれる送信先Diameterサーバーだけが、Accounting-Answerコマンドで応答すべきです (SHOULD)。
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 AVPとVendor-Specific-Application-Id AVPのいずれか一方が含まれなければなりません (MUST)。グループ化AVPであるVendor-Specific-Application-Idが含まれる場合、その内部に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中間アカウンティングレコードには、既存のアカウンティングセッションの累積アカウンティング情報が含まれます。中間認証レコードは、再認証または再認証が発生するたびに送信すべきです (SHOULD)。さらに、追加の中間レコードトリガーは、アプリケーション固有のDiameterアプリケーションによって定義される場合があります (MAY)。 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レコードを作成することが必須である (MUST) ことを意味します。このAVPの値フィールドは、これらのレコード間の公称間隔（秒単位）です。クライアントと呼ばれるアカウンティング情報を発信するDiameterノードは、おおよそこの公称間隔がSTART_RECORDから経過したときにおおよそ最初のINTERIM_RECORDレコードを生成し、間隔がもう一度経過すると次のレコードを生成することが必須です (MUST)。セッションが終了し、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.
クライアントは、複数の中間レコードが互いに集中したり、共通のサービス開始時刻付近に集中したりして大規模なアカウンティングメッセージストームが発生しないよう、中間レコードの生成時刻をランダム化しなければなりません (MUST)。
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サーバーによって認証応答で返される場合があり (MAY)、特定のセッションのすべてのアカウンティングメッセージで使用することが必須です (MUST)。
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の組み合わせはサブセッションごとに一意であることが必須であり (MUST)、このAVPの値はすべての新しいサブセッションで1ずつ単調に増加することが必須です (MUST)。この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は、アカウンティングサーバーへの接続がある限り、サービスを許可することが必須である (MUST) ことを意味します。この意味では、代替の会計サーバーのセットは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：ValueフィールドをGRANT_AND_STOREに設定したAVPは、次の意味を持ちます。接続が存在する場合、またはセクション9.4で説明されているようにレコードを引き続き保存できる間は、サービスを許可すべきです (SHOULD)。
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：ValueフィールドをGRANT_AND_LOSEに設定したAVPは、次の意味を持ちます。レコードを配信することも保存することもできない場合であっても、サービスを許可すべきです (SHOULD)。
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メッセージに存在してもよく (MAY)、または存在しなくてもよいか (MAY) を示しています。グループ化された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.
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は汎用プロトコルを意図したものではないため、認証、認可、またはアカウンティングと無関係な目的の割り当てを行うべきではありません (SHOULD NOT)。
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.
Designated Expertへの諮問が求められる登録要求については、担当IESGエリアディレクターがDesignated Expertを任命することが望まれます。Specification Requiredを伴うDesignated Expertの場合、要求はコメントとレビューのためにAAA WGメーリングリスト（解散済みの場合はエリアディレクターが指定した後継組織）へ投稿され、公開仕様への参照を含めなければなりません (MUST)。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ヘッダーのCommand Flagsフィールドには8ビットがあります。この文書では、ビット0（'R'equest）、ビット1（'P'roxy）、ビット2（'E'rror）、およびビット3（'T'）を割り当てます。ビット4から7を割り当てる場合は、Standards Action [IANA]によってのみ行わなければなりません (MUST)。
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
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における登録には、次の情報を含めなければなりません (MUST)：
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".
Protocol：そのサービスフィールドに関連付けられた特定のトランスポートプロトコルです。これには、プロトコルの名前と頭字語、およびそのトランスポートプロトコルを説明する文書への参照を含めなければなりません (MUST)。例："New Connectionless Transport Protocol (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
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]をサポートすることが必須であり (MUST)、TLS [TLS]をサポートする場合があります (MAY)。 DiameterサーバーはTLSおよびIPsecをサポートすることが必須です (MUST)。 Diameterの実装では、各接続で何らかの送信レベルのセキュリティ（IPsecまたはTLS）を使用することが必須です (MUST)。
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を含めなければなりません (MUST)。TLSを使用する場合、CER/CEA交換の完了後、両端がopen状態になるとTLSハンドシェイクを開始します。TLSハンドシェイクに成功すると、以降のすべてのメッセージをTLS経由で送信します。ハンドシェイクに失敗すると、両端はclosed状態へ移行します。
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]をサポートし、パケットごとの認証、整合性保護、および機密性を提供することが必須であり (MUST)、IPsecのリプレイ保護メカニズムをサポートすることが必須です (MUST)。
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をサポートしなければなりません (MUST)。Diameter実装は、事前共有鍵を用いたピア認証をサポートしなければなりません (MUST)。また、デジタル署名を用いた証明書ベースのピア認証をサポートしてもよい (MAY)。IKEのSections 5.2および5.3 [IKE]に示された公開鍵暗号方式を用いるピア認証は、使用すべきではありません (SHOULD NOT)。
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 Main ModeとIKE Aggressive Modeの両方をサポートしなければなりません (MUST)。認証に事前共有鍵を使用する場合、IKE Aggressive Modeを使用すべきです (SHOULD)。また、IKE Main Modeを使用すべきではありません (SHOULD NOT)。認証にデジタル署名を使用する場合、IKE Main ModeとIKE Aggressive Modeのいずれを使用してもよい (MAY)。
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 Certificate Request Payload(s)を使用して、ローカルポリシーに従って信頼する認証局を指定すべきです (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）を明示的に運ぶことが必須です (MUST)。 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セッション確立の一部として相互認証することが必須です (MUST)。相互認証を確実にするために、TLSサーバーとして機能するDiameterノードは、TLSクライアントとして機能するDiameterノードに証明書を要求することが必須であり (MUST)、TLSクライアントとして機能するDiameterノードは、要求に応じて証明書を提供できるように準備する必要があります。
Diameter nodes MUST be able to negotiate the following TLS cipher suites:
Diameterノードは、次のTLS暗号スイートをネゴシエートする能力を備えなければなりません (MUST)：
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 Phase 1ではPort識別子の使用が禁止されているため、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.
Diameterのピア間接続をIPsecで保護する場合、インバウンド接続にはIPsec保護を必須とし、アウトバウンド接続ではIPsec保護を開始するように、IPsecポリシーを設定すべきです (SHOULD)。これは、インバウンドおよびアウトバウンドのフィルターポリシーによって実現できます。
[AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[AAATRANS] Aboba, B. and 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. and 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. and 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. and 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] 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、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. and 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. and 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. and 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. and 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. and 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. and 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.
[KEYWORDS] 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. and 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. and 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. and 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. and 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] Postel, J、「伝送制御プロトコル」、STD 7、RFC 793、1981年1月。
[TEMPLATE] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999.
[TEMPLATE] Guttman, E., Perkins, C. and 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. and 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. and 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. and 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. Calhoun, W. Bulley, S. Farrell、「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. and 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. Calhoun, C. Perkins、「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. Narten、「有用と見なされる実験およびテスト番号の割り当て」、進行中の作業。
[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. and 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] Mitton, D. and M. Beadles、「ネットワークアクセスサーバー要件次世代（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. and 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] Simpson, 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. and J. Vollbrecht、「Proxy Chaining and Policy Implementation in Roaming」、RFC 2607、1999年6月。
[RADACCT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RADACCT] Rigney, 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. and 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. and 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. and W. Wang、「ローミング実装のレビュー」、RFC 2194、1997年9月。
[ROAMCRIT] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[ROAMCRIT] Aboba, B. and G. Zorn、「ローミングプロトコルの評価基準」、RFC 2477、1999年1月。
[SECARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[SECARCH] Kent, S. and R. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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をサポートすることが必須です (MUST) が、他のトランスポートもサポートする場合があります (MAY)。 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
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
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フラグを使用する場合があります (MAY)。ただし、これを行うサーバーは、再送信された要求の後に最初に送信された要求がサーバーに到着した場合でも、重複が検出されるようにすることが必須です (MUST)。これは、サーバーから要求に対する応答が受信されず、要求が再送信された場合にのみ使用できます（たとえば、代替ピアへのフェイルオーバー、回復されたプライマリピア、またはクライアントの再接続が原因で）。 -クライアントまたはエージェントの再起動後など、不揮発性メモリから保存されたレコードを送信する）。
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クライアントおよびエージェントで必須 (REQUIRED) ですが、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に情報を送信してください。
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
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から提供されています。