[要約] この文書は、認証、認可、アカウンティング（AAA）のための次世代プロトコル「Diameter」のベース仕様を定義しています（RFC 3588を廃止）。RADIUSの欠点を解消し、信頼性の高いトランスポート、エラー通知、機能交渉、およびスケーラビリティを強化した、現代のモバイル通信やエンタープライズ網の基盤プロトコルです。
Internet Engineering Task Force (IETF) V. Fajardo, Ed.
Request for Comments: 6733 Telcordia Technologies
Obsoletes: 3588, 5719 J. Arkko
Category: Standards Track Ericsson Research
ISSN: 2070-1721 J. Loughney
Nokia Research Center
G. Zorn, Ed.
Network Zen
October 2012
Diameter Base Protocol
Diameterベースプロトコル
Abstract
概要
The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations.
Diameter基本プロトコルは、ローカルおよびローミングの両方の状況でのネットワークアクセスやIPモビリティなどのアプリケーションに認証、承認、およびアカウンティング（AAA）フレームワークを提供することを目的としています。このドキュメントでは、すべてのDiameterアプリケーションで使用されるメッセージフォーマット、トランスポート、エラーレポート、アカウンティング、およびセキュリティサービスについて説明します。このドキュメントで定義されているDiameterベースプロトコルはRFC 3588およびRFC 5719を廃止し、すべての新しいDiameter実装でサポートされる必要があります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6733.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc6733で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの資料が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................7 1.1. Diameter Protocol ..........................................9 1.1.1. Description of the Document Set ....................10 1.1.2. Conventions Used in This Document ..................11 1.1.3. Changes from RFC 3588 ..............................11 1.2. Terminology ...............................................12 1.3. Approach to Extensibility .................................17 1.3.1. Defining New AVP Values ............................18 1.3.2. Creating New AVPs ..................................18 1.3.3. Creating New Commands ..............................18 1.3.4. Creating New Diameter Applications .................19 2. Protocol Overview ..............................................20 2.1. Transport .................................................22 2.1.1. SCTP Guidelines ....................................23 2.2. Securing Diameter Messages ................................24 2.3. Diameter Application Compliance ...........................24 2.4. Application Identifiers ...................................24 2.5. Connections vs. Sessions ..................................25 2.6. Peer Table ................................................26
2.7. Routing Table .............................................27
2.8. Role of Diameter Agents ...................................28
2.8.1. Relay Agents .......................................30
2.8.2. Proxy Agents .......................................31
2.8.3. Redirect Agents ....................................31
2.8.4. Translation Agents .................................32
2.9. Diameter Path Authorization ...............................33
3. Diameter Header ................................................34
3.1. Command Codes .............................................37
3.2. Command Code Format Specification .........................38
3.3. Diameter Command Naming Conventions .......................40
4. Diameter AVPs ..................................................40
4.1. AVP Header ................................................41
4.1.1. Optional Header Elements ...........................42
4.2. Basic AVP Data Formats ....................................43
4.3. Derived AVP Data Formats ..................................44
4.3.1. Common Derived AVP Data Formats ....................44
4.4. Grouped AVP Values ........................................51
4.4.1. Example AVP with a Grouped Data Type ...............52
4.5. Diameter Base Protocol AVPs ...............................55
5. Diameter Peers .................................................58
5.1. Peer Connections ..........................................58
5.2. Diameter Peer Discovery ...................................59
5.3. Capabilities Exchange .....................................60
5.3.1. Capabilities-Exchange-Request ......................62
5.3.2. Capabilities-Exchange-Answer .......................63
5.3.3. Vendor-Id AVP ......................................63
5.3.4. Firmware-Revision AVP ..............................64
5.3.5. Host-IP-Address AVP ................................64
5.3.6. Supported-Vendor-Id AVP ............................64
5.3.7. Product-Name AVP ...................................64
5.4. Disconnecting Peer Connections ............................64
5.4.1. Disconnect-Peer-Request ............................65
5.4.2. Disconnect-Peer-Answer .............................65
5.4.3. Disconnect-Cause AVP ...............................66
5.5. Transport Failure Detection ...............................66
5.5.1. Device-Watchdog-Request ............................67
5.5.2. Device-Watchdog-Answer .............................67
5.5.3. Transport Failure Algorithm ........................67
5.5.4. Failover and Failback Procedures ...................67
5.6. Peer State Machine ........................................68
5.6.1. Incoming Connections ...............................71
5.6.2. Events .............................................71
5.6.3. Actions ............................................72
5.6.4. The Election Process ...............................74
6. Diameter Message Processing ....................................74 6.1. Diameter Request Routing Overview .........................74 6.1.1. Originating a Request ..............................75 6.1.2. Sending a Request ..................................76 6.1.3. Receiving Requests .................................76 6.1.4. Processing Local Requests ..........................76 6.1.5. Request Forwarding .................................77 6.1.6. Request Routing ....................................77 6.1.7. Predictive Loop Avoidance ..........................77 6.1.8. Redirecting Requests ...............................78 6.1.9. Relaying and Proxying Requests .....................79 6.2. Diameter Answer Processing ................................80 6.2.1. Processing Received Answers ........................81 6.2.2. Relaying and Proxying Answers ......................81 6.3. Origin-Host AVP ...........................................81 6.4. Origin-Realm AVP ..........................................82 6.5. Destination-Host AVP ......................................82 6.6. Destination-Realm AVP .....................................82 6.7. Routing AVPs ..............................................83 6.7.1. Route-Record AVP ...................................83 6.7.2. Proxy-Info AVP .....................................83 6.7.3. Proxy-Host AVP .....................................83 6.7.4. Proxy-State AVP ....................................83 6.8. Auth-Application-Id AVP ...................................83 6.9. Acct-Application-Id AVP ...................................84 6.10. Inband-Security-Id AVP ...................................84 6.11. Vendor-Specific-Application-Id AVP .......................84 6.12. Redirect-Host AVP ........................................85 6.13. Redirect-Host-Usage AVP ..................................85 6.14. Redirect-Max-Cache-Time AVP ..............................87 7. Error Handling .................................................87 7.1. Result-Code AVP ...........................................89 7.1.1. Informational ......................................90 7.1.2. Success ............................................90 7.1.3. Protocol Errors ....................................90 7.1.4. Transient Failures .................................92 7.1.5. Permanent Failures .................................92 7.2. Error Bit .................................................95 7.3. Error-Message AVP .........................................96 7.4. Error-Reporting-Host AVP ..................................96 7.5. Failed-AVP AVP ............................................96 7.6. Experimental-Result AVP ...................................97 7.7. Experimental-Result-Code AVP ..............................97 8. Diameter User Sessions .........................................98 8.1. Authorization Session State Machine .......................99 8.2. Accounting Session State Machine .........................104
8.3. Server-Initiated Re-Auth .................................110
8.3.1. Re-Auth-Request ...................................110
8.3.2. Re-Auth-Answer ....................................110
8.4. Session Termination ......................................111
8.4.1. Session-Termination-Request .......................112
8.4.2. Session-Termination-Answer ........................113
8.5. Aborting a Session .......................................113
8.5.1. Abort-Session-Request .............................114
8.5.2. Abort-Session-Answer ..............................114
8.6. Inferring Session Termination from Origin-State-Id .......115
8.7. Auth-Request-Type AVP ....................................116
8.8. Session-Id AVP ...........................................116
8.9. Authorization-Lifetime AVP ...............................117
8.10. Auth-Grace-Period AVP ...................................118
8.11. Auth-Session-State AVP ..................................118
8.12. Re-Auth-Request-Type AVP ................................118
8.13. Session-Timeout AVP .....................................119
8.14. User-Name AVP ...........................................119
8.15. Termination-Cause AVP ...................................120
8.16. Origin-State-Id AVP .....................................120
8.17. Session-Binding AVP .....................................120
8.18. Session-Server-Failover AVP .............................121
8.19. Multi-Round-Time-Out AVP ................................122
8.20. Class AVP ...............................................122
8.21. Event-Timestamp AVP .....................................122
9. Accounting ....................................................123
9.1. Server Directed Model ....................................123
9.2. Protocol Messages ........................................124
9.3. Accounting Application Extension and Requirements ........124
9.4. Fault Resilience .........................................125
9.5. Accounting Records .......................................125
9.6. Correlation of Accounting Records ........................126
9.7. Accounting Command Codes .................................127
9.7.1. Accounting-Request ................................127
9.7.2. Accounting-Answer .................................128
9.8. Accounting AVPs ..........................................129
9.8.1. Accounting-Record-Type AVP ........................129
9.8.2. Acct-Interim-Interval AVP .........................130
9.8.3. Accounting-Record-Number AVP ......................131
9.8.4. Acct-Session-Id AVP ...............................131
9.8.5. Acct-Multi-Session-Id AVP .........................131
9.8.6. Accounting-Sub-Session-Id AVP .....................131
9.8.7. Accounting-Realtime-Required AVP ..................132
10. AVP Occurrence Tables ........................................132
10.1. Base Protocol Command AVP Table .........................133
10.2. Accounting AVP Table ....................................134
11. IANA Considerations ..........................................135 11.1. AVP Header ..............................................135 11.1.1. AVP Codes ........................................136 11.1.2. AVP Flags ........................................136 11.2. Diameter Header .........................................136 11.2.1. Command Codes ....................................136 11.2.2. Command Flags ....................................137 11.3. AVP Values ..............................................137 11.3.1. Experimental-Result-Code AVP .....................137 11.3.2. Result-Code AVP Values ...........................137 11.3.3. Accounting-Record-Type AVP Values ................137 11.3.4. Termination-Cause AVP Values .....................137 11.3.5. Redirect-Host-Usage AVP Values ...................137 11.3.6. Session-Server-Failover AVP Values ...............137 11.3.7. Session-Binding AVP Values .......................137 11.3.8. Disconnect-Cause AVP Values ......................138 11.3.9. Auth-Request-Type AVP Values .....................138 11.3.10. Auth-Session-State AVP Values ...................138 11.3.11. Re-Auth-Request-Type AVP Values .................138 11.3.12. Accounting-Realtime-Required AVP Values .........138 11.3.13. Inband-Security-Id AVP (code 299) ...............138 11.4. _diameters Service Name and Port Number Registration ....138 11.5. SCTP Payload Protocol Identifiers .......................139 11.6. S-NAPTR Parameters ......................................139 12. Diameter Protocol-Related Configurable Parameters ............139 13. Security Considerations ......................................140 13.1. TLS/TCP and DTLS/SCTP Usage .............................140 13.2. Peer-to-Peer Considerations .............................141 13.3. AVP Considerations ......................................141 14. References ...................................................142 14.1. Normative References ....................................142 14.2. Informative References ..................................144 Appendix A. Acknowledgements .....................................147 A.1. This Document .............................................147 A.2. RFC 3588 ..................................................148 Appendix B. S-NAPTR Example ......................................148 Appendix C. Duplicate Detection ..................................149 Appendix D. Internationalized Domain Names .......................151
Authentication, Authorization, and Accounting (AAA) protocols such as TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to provide dial-up PPP [RFC1661] and terminal server access. Over time, AAA support was needed on many new access technologies, the scale and complexity of AAA networks grew, and AAA was also used on new applications (such as voice over IP). This led to new demands on AAA protocols.
Network access requirements for AAA protocols are summarized in Aboba, et al. [RFC2989]. These include:
AAAプロトコルのネットワークアクセス要件は、Abobaらにまとめられています。 [RFC2989]。これらには以下が含まれます：
Failover
フェイルオーバー
[RFC2865] does not define failover mechanisms and, as a result, failover behavior differs between implementations. In order to provide well-defined failover behavior, Diameter supports application-layer acknowledgements and defines failover algorithms and the associated state machine.
[RFC2865]はフェイルオーバーメカニズムを定義していないため、フェイルオーバーの動作は実装によって異なります。明確に定義されたフェイルオーバー動作を提供するために、Diameterはアプリケーション層の確認応答をサポートし、フェイルオーバーアルゴリズムと関連するステートマシンを定義します。
Transmission-level security
伝送レベルのセキュリティ
RADIUS [RFC2865] defines an application-layer authentication and integrity scheme that is required only for use with response packets. While [RFC2869] defines an additional authentication and integrity mechanism, use is only required during Extensible Authentication Protocol (EAP) [RFC3748] sessions. While attribute hiding is supported, [RFC2865] does not provide support for per-packet confidentiality. In accounting, [RFC2866] assumes that replay protection is provided by the backend billing server rather than within the protocol itself.
While [RFC3162] defines the use of IPsec with RADIUS, support for IPsec is not required. In order to provide universal support for transmission-level security, and enable both intra- and inter-domain AAA deployments, Diameter provides support for TLS/TCP and DTLS/SCTP. Security is discussed in Section 13.
[RFC3162]はRADIUSでのIPsecの使用を定義していますが、IPsecのサポートは必要ありません。 Diameterは、伝送レベルのセキュリティに対するユニバーサルサポートを提供し、ドメイン内およびドメイン間のAAA展開を可能にするために、TLS/TCPおよびDTLS/SCTPをサポートしています。セキュリティについては、セクション13で説明します。
Reliable transport
信頼できる輸送
RADIUS runs over UDP, and does not define retransmission behavior; as a result, reliability varies between implementations. As described in [RFC2975], this is a major issue in accounting, where packet loss may translate directly into revenue loss. In order to provide well-defined transport behavior, Diameter runs over reliable transport mechanisms (TCP, Stream Control Transmission Protocol (SCTP)) as defined in [RFC3539].
Agent support
エージェントサポート
RADIUS does not provide for explicit support for agents, including proxies, redirects, and relays. Since the expected behavior is not defined, it varies between implementations. Diameter defines agent behavior explicitly; this is described in Section 2.8.
RADIUSは、プロキシ、リダイレクト、リレーなどのエージェントを明示的にサポートしていません。期待される動作は定義されていないため、実装によって異なります。 Diameterはエージェントの動作を明示的に定義します。これについては、セクション2.8で説明します。
Server-initiated messages
サーバー起動メッセージ
While server-initiated messages are defined in RADIUS [RFC5176], support is optional. This makes it difficult to implement features such as unsolicited disconnect or re-authentication/ re-authorization on demand across a heterogeneous deployment. To address this issue, support for server-initiated messages is mandatory in Diameter.
サーバー開始メッセージはRADIUS [RFC5176]で定義されていますが、サポートはオプションです。これにより、要求のない切断や再認証/再認証などの機能を、異種混合のデプロイメント全体でオンデマンドで実装することが困難になります。この問題に対処するには、Diameterでサーバー起動メッセージのサポートが必須です。
Transition support
移行サポート
While Diameter does not share a common protocol data unit (PDU) with RADIUS, considerable effort has been expended in enabling backward compatibility with RADIUS so that the two protocols may be deployed in the same network. Initially, it is expected that Diameter will be deployed within new network devices, as well as within gateways enabling communication between legacy RADIUS devices and Diameter agents. This capability enables Diameter support to be added to legacy networks, by addition of a gateway or server speaking both RADIUS and Diameter.
DiameterはRADIUSと共通のプロトコルデータユニット（PDU）を共有しませんが、RADIUSとの下位互換性を有効にするためにかなりの労力が費やされ、2つのプロトコルを同じネットワークに展開できるようになりました。最初は、Diameterが新しいネットワークデバイス内に配備されるだけでなく、レガシーRADIUSデバイスとDiameterエージェント間の通信を可能にするゲートウェイ内に配備されることが期待されています。この機能により、RADIUSとDiameterの両方を話すゲートウェイまたはサーバーを追加することにより、Diameterサポートをレガシーネットワークに追加できます。
In addition to addressing the above requirements, Diameter also provides support for the following:
上記の要件への対応に加えて、Diameterは以下のサポートも提供します。
Capability negotiation
能力交渉
RADIUS does not support error messages, capability negotiation, or a mandatory/non-mandatory flag for attributes. Since RADIUS clients and servers are not aware of each other's capabilities, they may not be able to successfully negotiate a mutually acceptable service or, in some cases, even be aware of what service has been implemented. Diameter includes support for error handling (Section 7), capability negotiation (Section 5.3), and mandatory/non-mandatory Attribute-Value Pairs (AVPs) (Section 4.1).
RADIUSは、エラーメッセージ、機能ネゴシエーション、または属性の必須/非必須フラグをサポートしていません。 RADIUSクライアントとサーバーは互いの機能を認識していないため、相互に受け入れ可能なサービスを正常にネゴシエートできなかったり、場合によっては、実装されているサービスを認識できなかったりすることがあります。 Diameterには、エラー処理（セクション7）、機能ネゴシエーション（セクション5.3）、および必須/非必須の属性値ペア（AVP）（セクション4.1）のサポートが含まれています。
Peer discovery and configuration
ピアの検出と構成
RADIUS implementations typically require that the name or address of servers or clients be manually configured, along with the corresponding shared secrets. This results in a large administrative burden and creates the temptation to reuse the RADIUS shared secret, which can result in major security vulnerabilities if the Request Authenticator is not globally and temporally unique as required in [RFC2865]. Through DNS, Diameter enables dynamic discovery of peers (see Section 5.2). Derivation of dynamic session keys is enabled via transmission-level security.
RADIUSの実装では、通常、サーバーまたはクライアントの名前またはアドレスを、対応する共有シークレットとともに手動で構成する必要があります。これにより、管理上の負担が大きくなり、RADIUS共有シークレットを再利用しようとする誘惑が生まれます。これは、[RFC2865]で要求されているように、リクエスト認証がグローバルかつ一時的に一意でない場合に、セキュリティ上の重大な脆弱性をもたらす可能性があります。 DiameterはDNSを通じて、ピアの動的な検出を可能にします（セクション5.2を参照）。動的セッションキーの派生は、伝送レベルのセキュリティによって有効になります。
Over time, the capabilities of Network Access Server (NAS) devices have increased substantially. As a result, while Diameter is a considerably more sophisticated protocol than RADIUS, it remains feasible to implement it within embedded devices.
時間の経過とともに、ネットワークアクセスサーバー（NAS）デバイスの機能は大幅に増加しました。その結果、DiameterはRADIUSよりもかなり高度なプロトコルですが、組み込みデバイス内に実装することは引き続き可能です。
The Diameter base protocol provides the following facilities:
Diameter基本プロトコルは、次の機能を提供します。
o Ability to exchange messages and deliver AVPs
o メッセージを交換し、AVPを配信する機能
o Capabilities negotiation
o 能力交渉
o Error notification
o エラー通知
o Extensibility, required in [RFC2989], through addition of new applications, commands, and AVPs
o 新しいアプリケーション、コマンド、およびAVPの追加による、[RFC2989]で必要な拡張性
o Basic services necessary for applications, such as the handling of user sessions or accounting
o ユーザーセッションの処理や課金など、アプリケーションに必要な基本的なサービス
All data delivered by the protocol is in the form of AVPs. Some of these AVP values are used by the Diameter protocol itself, while others deliver data associated with particular applications that employ Diameter. AVPs may be arbitrarily added to Diameter messages, the only restriction being that the Command Code Format (CCF) specification (Section 3.2) be satisfied. AVPs are used by the base Diameter protocol to support the following required features:
プロトコルによって配信されるすべてのデータは、AVPの形式です。これらのAVP値には、Diameterプロトコル自体で使用されるものと、Diameterを使用する特定のアプリケーションに関連するデータを提供するものがあります。 AVPは、Diameterメッセージに任意に追加できます。唯一の制限は、コマンドコードフォーマット（CCF）仕様（セクション3.2）が満たされていることです。 AVPは、以下の必須機能をサポートするために基本Diameterプロトコルによって使用されます。
o Transporting of user authentication information, for the purposes of enabling the Diameter server to authenticate the user
o Diameterサーバーがユーザーを認証できるようにするための、ユーザー認証情報の転送
o Transporting of service-specific authorization information, between client and servers, allowing the peers to decide whether a user's access request should be granted
o クライアントとサーバー間でのサービス固有の承認情報の転送。これにより、ピアはユーザーのアクセス要求を許可するかどうかを決定できます。
o Exchanging resource usage information, which may be used for accounting purposes, capacity planning, etc.
o 会計目的、容量計画などに使用される可能性のあるリソース使用情報の交換
o Routing, relaying, proxying, and redirecting of Diameter messages through a server hierarchy
o サーバー階層を介したDiameterメッセージのルーティング、リレー、プロキシ、リダイレクト
The Diameter base protocol satisfies the minimum requirements for a AAA protocol, as specified by [RFC2989]. The base protocol may be used by itself for accounting purposes only, or it may be used with a Diameter application, such as Mobile IPv4 [RFC4004], or network access [RFC4005]. It is also possible for the base protocol to be extended for use in new applications, via the addition of new commands or AVPs. The initial focus of Diameter was network access and accounting applications. A truly generic AAA protocol used by many applications might provide functionality not provided by Diameter. Therefore, it is imperative that the designers of new applications understand their requirements before using Diameter. See Section 1.3.4 for more information on Diameter applications.
Diameter基本プロトコルは、[RFC2989]で指定されているAAAプロトコルの最小要件を満たしています。基本プロトコルは、アカウンティングの目的でのみ単独で使用することも、モバイルIPv4 [RFC4004]やネットワークアクセス[RFC4005]などのDiameterアプリケーションで使用することもできます。新しいコマンドまたはAVPを追加することにより、基本プロトコルを拡張して新しいアプリケーションで使用することもできます。 Diameterの最初の焦点は、ネットワークアクセスおよびアカウンティングアプリケーションでした。多くのアプリケーションで使用されている真に一般的なAAAプロトコルは、Diameterで提供されていない機能を提供する場合があります。したがって、Diameterを使用する前に、新しいアプリケーションの設計者が要件を理解することが不可欠です。 Diameterアプリケーションの詳細については、セクション1.3.4を参照してください。
Any node can initiate a request. In that sense, Diameter is a peer-to-peer protocol. In this document, a Diameter client is a device at the edge of the network that performs access control, such as a Network Access Server (NAS) or a Foreign Agent (FA). A Diameter client generates Diameter messages to request authentication, authorization, and accounting services for the user. A Diameter agent is a node that does not provide local user authentication or authorization services; agents include proxies, redirects, and relay agents. A Diameter server performs authentication and/or authorization of the user. A Diameter node may act as an agent for certain requests while acting as a server for others.
どのノードでもリクエストを開始できます。その意味で、Diameterはピアツーピアプロトコルです。このドキュメントでは、Diameterクライアントは、ネットワークアクセスサーバー（NAS）や外部エージェント（FA）など、アクセス制御を実行するネットワークエッジのデバイスです。 Diameterクライアントは、Diameterメッセージを生成して、ユーザーの認証、承認、およびアカウンティングサービスを要求します。 Diameterエージェントは、ローカルユーザー認証または承認サービスを提供しないノードです。エージェントには、プロキシ、リダイレクト、およびリレーエージェントが含まれます。 Diameterサーバーは、ユーザーの認証や承認を実行します。 Diameterノードは、特定のリクエストのエージェントとして機能する一方で、他のリクエストのサーバーとして機能する場合があります。
The Diameter protocol also supports server-initiated messages, such as a request to abort service to a particular user.
Diameterプロトコルは、特定のユーザーへのサービスを中止する要求など、サーバーが開始するメッセージもサポートします。
The Diameter specification consists of an updated version of the base protocol specification (this document) and the Transport Profile [RFC3539]. This document obsoletes both RFC 3588 and RFC 5719. A summary of the base protocol updates included in this document can be found in Section 1.1.3.
Diameter仕様は、基本プロトコル仕様（このドキュメント）の更新バージョンとトランスポートプロファイル[RFC3539]で構成されています。このドキュメントはRFC 3588とRFC 5719の両方を廃止します。このドキュメントに含まれる基本プロトコルの更新の概要は、セクション1.1.3にあります。
This document defines the base protocol specification for AAA, which includes support for accounting. There are also a myriad of applications documents describing applications that use this base specification for Authentication, Authorization, and Accounting. These application documents specify how to use the Diameter protocol within the context of their application.
このドキュメントは、アカウンティングのサポートを含む、AAAの基本プロトコル仕様を定義しています。認証、承認、およびアカウンティングにこの基本仕様を使用するアプリケーションを説明する無数のアプリケーションドキュメントもあります。これらのアプリケーションドキュメントは、アプリケーションのコンテキスト内でDiameterプロトコルを使用する方法を指定します。
The Transport Profile document [RFC3539] discusses transport layer issues that arise with AAA protocols and recommendations on how to overcome these issues. This document also defines the Diameter failover algorithm and state machine.
トランスポートプロファイルドキュメント[RFC3539]では、AAAプロトコルで発生するトランスポート層の問題と、これらの問題を克服する方法に関する推奨事項について説明しています。このドキュメントでは、Diameterフェイルオーバーアルゴリズムとステートマシンも定義しています。
"Clarifications on the Routing of Diameter Request Based on the Username and the Realm" [RFC5729] defines specific behavior on how to route requests based on the content of the User-Name AVP (Attribute Value Pair).
「ユーザー名とレルムに基づくDiameterリクエストのルーティングに関する説明」[RFC5729]は、ユーザー名AVP（属性値ペア）の内容に基づいてリクエストをルーティングする方法に関する特定の動作を定義しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] で説明されているように解釈されるものとします。
This document obsoletes RFC 3588 but is fully backward compatible with that document. The changes introduced in this document focus on fixing issues that have surfaced during the implementation of Diameter (RFC 3588). An overview of some the major changes are given below.
このドキュメントはRFC 3588を廃止しますが、そのドキュメントと完全に下位互換性があります。このドキュメントで紹介する変更は、Diameter（RFC 3588）の実装中に発生した問題の修正に重点を置いています。主な変更点の概要を以下に示します。
o Deprecated the use of the Inband-Security AVP for negotiating Transport Layer Security (TLS) [RFC5246]. It has been generally considered that bootstrapping of TLS via Inband-Security AVP creates certain security risks because it does not completely protect the information carried in the CER/CEA (Capabilities-Exchange-Request/Capabilities-Exchange-Answer). This version of Diameter adopts the common approach of defining a well-known secured port that peers should use when communicating via TLS/TCP and DTLS/SCTP. This new approach augments the existing in-band security negotiation, but it does not completely replace it. The old method is kept for backward compatibility reasons.
o トランスポート層セキュリティ（TLS）[RFC5246]をネゴシエートするためのインバンドセキュリティAVPの使用を非推奨にしました。 Inband-Security AVPを介したTLSのブートストラップは、CER/CEA（Capabilities-Exchange-Request/Capabilities-Exchange-Answer）に含まれる情報を完全には保護しないため、特定のセキュリティリスクを生み出すと一般に考えられています。 Diameterのこのバージョンは、ピアがTLS/TCPおよびDTLS/SCTPを介して通信するときに使用する必要がある既知の保護されたポートを定義する一般的なアプローチを採用しています。この新しいアプローチは、既存のインバンドセキュリティネゴシエーションを強化しますが、完全に置き換えるわけではありません。古いメソッドは、下位互換性のために残されています。
o Deprecated the exchange of CER/CEA messages in the open state. This feature was implied in the peer state machine table of RFC 3588, but it was not clearly defined anywhere else in that document. As work on this document progressed, it became clear that the multiplicity of meaning and use of Application-Id AVPs in the CER/CEA messages (and the messages themselves) is seen as an abuse of the Diameter extensibility rules and thus required simplification. Capabilities exchange in the open state has been re-introduced in a separate specification [RFC6737], which clearly defines new commands for this feature.
o オープン状態でのCER/CEAメッセージの交換を非推奨にしました。この機能はRFC 3588のピアステートマシンテーブルに含まれていましたが、そのドキュメントの他の場所では明確に定義されていません。このドキュメントの作業が進むにつれて、CER/CEAメッセージ（およびメッセージ自体）でのApplication-Id AVPの多様性と使用が、Diameter拡張ルールの乱用と見なされ、簡略化が必要であることが明らかになりました。オープン状態での機能交換は、この機能の新しいコマンドを明確に定義する別の仕様[RFC6737]で再導入されました。
o Simplified security requirements. The use of a secured transport for exchanging Diameter messages remains mandatory. However, TLS/ TCP and DTLS/SCTP have become the primary methods of securing Diameter with IPsec as a secondary alternative. See Section 13 for details. The support for the End-to-End security framework (E2E-Sequence AVP and 'P'-bit in the AVP header) has also been deprecated.
o 簡素化されたセキュリティ要件。 Diameterメッセージを交換するためのセキュアなトランスポートの使用は、引き続き必須です。ただし、TLS / TCPおよびDTLS/SCTPは、二次的な代替手段としてIPsecでDiameterを保護する主要な方法になっています。詳細については、セクション13を参照してください。エンドツーエンドのセキュリティフレームワーク（E2E-Sequence AVPおよびAVPヘッダーの「P」ビット）のサポートも廃止されました。
o Changed Diameter extensibility. This includes fixes to the Diameter extensibility description (Section 1.3 and others) to better aid Diameter application designers; in addition, the new specification relaxes the policy with respect to the allocation of Command Codes for vendor-specific uses.
o Diameterの拡張性が変更されました。これには、Diameterアプリケーションの設計者を支援するためのDiameter拡張性の説明（セクション1.3など）の修正が含まれます。さらに、新しい仕様では、ベンダー固有の使用のためのコマンドコードの割り当てに関するポリシーが緩和されています。
o Clarified Application Id usage. Clarify the proper use of Application Id information, which can be found in multiple places within a Diameter message. This includes correlating Application Ids found in the message headers and AVPs. These changes also clearly specify the proper Application Id value to use for specific base protocol messages (ASR/ASA, STR/STA) as well as clarify the content and use of Vendor-Specific-Application-Id.
o アプリケーションIDの使用法を明確にしました。 Diameterメッセージ内の複数の場所にあるアプリケーションID情報の適切な使用を明確にします。これには、メッセージヘッダーとAVPで見つかったアプリケーションIDの関連付けが含まれます。これらの変更により、特定の基本プロトコルメッセージ（ASR/ASA、STR/STA）に使用する適切なアプリケーションID値が明確に指定され、ベンダー固有のアプリケーションIDの内容と使用が明確になります。
o Clarified routing fixes. This document more clearly specifies what information (AVPs and Application Ids) can be used for making general routing decisions. A rule for the prioritization of redirect routing criteria when multiple route entries are found via redirects has also been added (see Section 6.13).
o ルーティングの修正を明確にしました。このドキュメントでは、一般的なルーティングの決定に使用できる情報（AVPおよびアプリケーションID）をより明確に規定しています。リダイレクトを介して複数のルートエントリが見つかった場合のリダイレクトルーティング基準の優先順位付けのルールも追加されました（セクション6.13を参照）。
o Simplified Diameter peer discovery. The Diameter discovery process now supports only widely used discovery schemes; the rest have been deprecated (see Section 5.2 for details).
o 簡略化されたDiameterピアの検出。 Diameter検出プロセスは、広く使用されている検出スキームのみをサポートするようになりました。残りは廃止されました（詳細はセクション5.2を参照）。
There are many other miscellaneous fixes that have been introduced in this document that may not be considered significant, but they have value nonetheless. Examples are removal of obsolete types, fixes to the state machine, clarification of the election process, message validation, fixes to Failed-AVP and Result-Code AVP values, etc. All of the errata filed against RFC 3588 prior to the publication of this document have been addressed. A comprehensive list of changes is not shown here for practical reasons.
このドキュメントで紹介されている他の多くの修正には、重要とは見なされないものもありますが、それでも価値があります。例としては、廃止されたタイプの削除、状態マシンの修正、選出プロセスの明確化、メッセージ検証、Failed-AVPとResult-Code AVP値の修正などがあります。これが公開される前にRFC 3588に対して提出されたすべての正誤表ドキュメントが対処されました。変更の包括的なリストは、実際的な理由のため、ここでは示されていません。
AAA
AAA
Authentication, Authorization, and Accounting.
認証、承認、およびアカウンティング。
ABNF
ABNF
Augmented Backus-Naur Form [RFC5234]. A metalanguage with its own formal syntax and rules. It is based on the Backus-Naur Form and is used to define message exchanges in a bi-directional communications protocol.
拡張バッカスナウアフォーム[RFC5234]。独自の正式な構文とルールを持つメタ言語。これはBackus-Naurフォームに基づいており、双方向通信プロトコルでメッセージ交換を定義するために使用されます。
Accounting
経理
The act of collecting information on resource usage for the purpose of capacity planning, auditing, billing, or cost allocation.
キャパシティプランニング、監査、請求、またはコスト割り当てのために、リソース使用状況に関する情報を収集する行為。
Accounting Record
会計記録
An accounting record represents a summary of the resource consumption of a user over the entire session. Accounting servers creating the accounting record may do so by processing interim accounting events or accounting events from several devices serving the same user.
アカウンティングレコードは、セッション全体にわたるユーザーのリソース消費の概要を表します。アカウンティングレコードを作成するアカウンティングサーバーは、同じユーザーにサービスを提供している複数のデバイスからの中間アカウンティングイベントまたはアカウンティングイベントを処理することによって、そうすることができます。
Authentication
認証
The act of verifying the identity of an entity (subject).
エンティティ（サブジェクト）の身元を確認する行為。
Authorization
認可
The act of determining whether a requesting entity (subject) will be allowed access to a resource (object).
要求エンティティ（サブジェクト）がリソース（オブジェクト）へのアクセスを許可されるかどうかを決定する行為。
Attribute-Value Pair (AVP)
属性値ペア（AVP）
The Diameter protocol consists of a header followed by one or more Attribute-Value-Pairs (AVPs). An AVP includes a header and is used to encapsulate protocol-specific data (e.g., routing information) as well as authentication, authorization, or accounting information.
Diameterプロトコルは、ヘッダーとそれに続く1つ以上の属性値ペア（AVP）で構成されます。 AVPにはヘッダーが含まれており、プロトコル固有のデータ（ルーティング情報など）だけでなく、認証、承認、またはアカウンティング情報をカプセル化するために使用されます。
Command Code Format (CCF)
コマンドコードフォーマット（CCF）
A modified form of ABNF used to define Diameter commands (see Section 3.2).
Diameterコマンドの定義に使用されるABNFの変更された形式（セクション3.2を参照）。
Diameter Agent
直径エージェント
A Diameter Agent is a Diameter node that provides relay, proxy, redirect, or translation services.
Diameterエージェントは、リレー、プロキシ、リダイレクト、または変換サービスを提供するDiameterノードです。
Diameter Client
Diameterクライアント
A Diameter client is a Diameter node that supports Diameter client applications as well as the base protocol. Diameter clients are often implemented in devices situated at the edge of a network and provide access control services for that network. Typical examples of Diameter clients include the Network Access Server (NAS) and the Mobile IP Foreign Agent (FA).
Diameterクライアントは、Diameterクライアントアプリケーションと基本プロトコルをサポートするDiameterノードです。 Diameterクライアントは、多くの場合、ネットワークのエッジにあるデバイスに実装され、そのネットワークにアクセス制御サービスを提供します。 Diameterクライアントの一般的な例には、ネットワークアクセスサーバー（NAS）やモバイルIPフォーリンエージェント（FA）などがあります。
Diameter Node
ぢあめてｒ ので
A Diameter node is a host process that implements the Diameter protocol and acts as either a client, an agent, or a server.
Diameterノードは、Diameterプロトコルを実装するホストプロセスであり、クライアント、エージェント、またはサーバーとして機能します。
Diameter Peer
直径ピア
Two Diameter nodes sharing a direct TCP or SCTP transport connection are called Diameter peers.
直接TCPまたはSCTPトランスポート接続を共有する2つのDiameterノードは、Diameterピアと呼ばれます。
Diameter Server
Diameterサーバー
A Diameter server is a Diameter node that handles authentication, authorization, and accounting requests for a particular realm. By its very nature, a Diameter server must support Diameter server applications in addition to the base protocol.
Diameterサーバーは、特定のレルムの認証、承認、およびアカウンティング要求を処理するDiameterノードです。その性質上、Diameterサーバーは、基本プロトコルに加えてDiameterサーバーアプリケーションをサポートする必要があります。
Downstream
下流
Downstream is used to identify the direction of a particular Diameter message from the home server towards the Diameter client.
ダウンストリームは、特定のDiameterメッセージのホームサーバーからDiameterクライアントへの方向を識別するために使用されます。
Home Realm
ホームレルム
A Home Realm is the administrative domain with which the user maintains an account relationship.
ホームレルムは、ユーザーがアカウント関係を維持するための管理ドメインです。
Home Server
ホームサーバー
A Diameter server that serves the Home Realm.
ホームレルムを提供するDiameterサーバー。
Interim Accounting
中間会計
An interim accounting message provides a snapshot of usage during a user's session. Typically, it is implemented in order to provide for partial accounting of a user's session in case a device reboot or other network problem prevents the delivery of a session summary message or session record.
中間アカウンティングメッセージは、ユーザーのセッション中の使用状況のスナップショットを提供します。通常、デバイスの再起動またはその他のネットワークの問題によりセッションサマリーメッセージまたはセッションレコードの配信が妨げられた場合に、ユーザーのセッションの部分的なアカウンティングを提供するために実装されます。
Local Realm
ローカルレルム
A local realm is the administrative domain providing services to a user. An administrative domain may act as a local realm for certain users while being a home realm for others.
ローカルレルムは、ユーザーにサービスを提供する管理ドメインです。管理ドメインは、他のユーザーのホームレルムでありながら、特定のユーザーのローカルレルムとして機能する場合があります。
Multi-session
マルチセッション
A multi-session represents a logical linking of several sessions. Multi-sessions are tracked by using the Acct-Multi-Session-Id. An example of a multi-session would be a Multi-link PPP bundle. Each leg of the bundle would be a session while the entire bundle would be a multi-session.
マルチセッションは、いくつかのセッションの論理的なリンクを表します。マルチセッションは、Acct-Multi-Session-Idを使用して追跡されます。マルチセッションの例は、マルチリンクPPPバンドルです。バンドルの各レッグはセッションであり、バンドル全体はマルチセッションです。
Network Access Identifier
ネットワークアクセス識別子
The Network Access Identifier, or NAI [RFC4282], is used in the Diameter protocol to extract a user's identity and realm. The identity is used to identify the user during authentication and/or authorization while the realm is used for message routing purposes.
ネットワークアクセス識別子（NAI [RFC4282]）は、DiameterプロトコルでユーザーのIDと領域を抽出するために使用されます。 IDは、認証や許可の際にユーザーを識別するために使用され、レルムはメッセージルーティングの目的で使用されます。
Proxy Agent or Proxy
プロキシエージェントまたはプロキシ
In addition to forwarding requests and responses, proxies make policy decisions relating to resource usage and provisioning. Typically, this is accomplished by tracking the state of NAS devices. While proxies usually do not respond to client requests prior to receiving a response from the server, they may originate Reject messages in cases where policies are violated. As a result, proxies need to understand the semantics of the messages passing through them, and they may not support all Diameter applications.
リクエストとレスポンスの転送に加えて、プロキシはリソースの使用とプロビジョニングに関連するポリシー決定を行います。通常、これはNASデバイスの状態を追跡することによって行われます。プロキシは通常、サーバーからの応答を受信する前にクライアントの要求に応答しませんが、ポリシーに違反している場合は拒否メッセージを発信することがあります。その結果、プロキシはメッセージを通過するメッセージのセマンティクスを理解する必要があり、すべてのDiameterアプリケーションをサポートするわけではありません。
Realm
レルム
The string in the NAI that immediately follows the '@' character. NAI realm names are required to be unique and are piggybacked on the administration of the DNS namespace. Diameter makes use of the realm, also loosely referred to as domain, to determine whether messages can be satisfied locally or whether they must be routed or redirected. In RADIUS, realm names are not necessarily piggybacked on the DNS namespace but may be independent of it.
「@」文字の直後に続くNAIの文字列。 NAIレルム名は一意である必要があり、DNS名前空間の管理に便乗します。 Diameterは、ドメインとも呼ばれるレルムを使用して、メッセージをローカルで満たすことができるかどうか、またはメッセージをルーティングまたはリダイレクトする必要があるかどうかを決定します。 RADIUSでは、レルム名は必ずしもDNSネームスペースに便乗しているわけではありませんが、DNSネームスペースから独立している場合があります。
Real-Time Accounting
リアルタイム会計
Real-time accounting involves the processing of information on resource usage within a defined time window. Typically, time constraints are imposed in order to limit financial risk. The Diameter Credit-Control Application [RFC4006] is an example of an application that defines real-time accounting functionality.
リアルタイムアカウンティングには、定義された時間枠内のリソース使用量に関する情報の処理が含まれます。通常、財務上のリスクを制限するために時間的な制約が課されます。 Diameter Credit-Controlアプリケーション[RFC4006]は、リアルタイムのアカウンティング機能を定義するアプリケーションの例です。
Relay Agent or Relay
リレーエージェントまたはリレー
Relays forward requests and responses based on routing-related AVPs and routing table entries. Since relays do not make policy decisions, they do not examine or alter non-routing AVPs. As a result, relays never originate messages, do not need to understand the semantics of messages or non-routing AVPs, and are capable of handling any Diameter application or message type. Since relays make decisions based on information in routing AVPs and realm forwarding tables, they do not keep state on NAS resource usage or sessions in progress.
リレーは、ルーティング関連のAVPとルーティングテーブルエントリに基づいて要求と応答を転送します。リレーはポリシー決定を行わないため、非ルーティングAVPを検査または変更しません。その結果、リレーはメッセージを発信することはなく、メッセージまたは非ルーティングAVPのセマンティクスを理解する必要がなく、Diameterアプリケーションまたはメッセージタイプを処理できます。リレーは、ルーティングAVPとレルム転送テーブルの情報に基づいて決定を行うため、NASリソースの使用状況や進行中のセッションの状態は保持されません。
Redirect Agent
リダイレクトエージェント
Rather than forwarding requests and responses between clients and servers, redirect agents refer clients to servers and allow them to communicate directly. Since redirect agents do not sit in the forwarding path, they do not alter any AVPs transiting between client and server. Redirect agents do not originate messages and are capable of handling any message type, although they may be configured only to redirect messages of certain types, while acting as relay or proxy agents for other types. As with relay agents, redirect agents do not keep state with respect to sessions or NAS resources.
リダイレクトエージェントは、クライアントとサーバー間で要求と応答を転送するのではなく、クライアントをサーバーに参照させ、直接通信できるようにします。リダイレクトエージェントは転送パスに存在しないため、クライアントとサーバー間を通過するAVPは変更されません。リダイレクトエージェントはメッセージを生成せず、任意のメッセージタイプを処理できますが、他のタイプのリレーエージェントまたはプロキシエージェントとして機能する一方で、特定のタイプのメッセージをリダイレクトするようにのみ設定できます。リレーエージェントと同様に、リダイレクトエージェントはセッションやNASリソースに関して状態を保持しません。
Session
セッション
A session is a related progression of events devoted to a particular activity. Diameter application documents provide guidelines as to when a session begins and ends. All Diameter packets with the same Session-Id are considered to be part of the same session.
セッションは、特定のアクティビティに特化したイベントの関連する進行です。 Diameterアプリケーションドキュメントは、セッションの開始と終了に関するガイドラインを提供します。同じセッションIDを持つすべてのDiameterパケットは、同じセッションの一部と見なされます。
Stateful Agent
ステートフルエージェント
A stateful agent is one that maintains session state information, by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered active either until it is notified otherwise or until expiration.
ステートフルエージェントは、承認されたすべてのアクティブセッションを追跡することにより、セッション状態情報を維持するエージェントです。承認された各セッションは特定のサービスにバインドされており、その状態は、他の方法で通知されるまで、または有効期限が切れるまでアクティブと見なされます。
Sub-session
サブセッション
A sub-session represents a distinct service (e.g., QoS or data characteristics) provided to a given session. These services may happen concurrently (e.g., simultaneous voice and data transfer during the same session) or serially. These changes in sessions are tracked with the Accounting-Sub-Session-Id.
サブセッションは、特定のセッションに提供される個別のサービス（QoSやデータの特性など）を表します。これらのサービスは、並行して（たとえば、同じセッション中に音声とデータの同時転送）または連続して発生する可能性があります。セッションのこれらの変更は、Accounting-Sub-Session-Idで追跡されます。
Transaction State
トランザクション状態
The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, the Hop-by-Hop Identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state.
Diameterプロトコルでは、エージェントがフェイルオーバーの目的で使用されるトランザクション状態を維持する必要があります。トランザクション状態は、要求を転送するとホップバイホップ識別子が保存されることを意味します。フィールドはローカルで一意の識別子に置き換えられ、対応する回答を受信すると元の値に復元されます。リクエストの状態は、回答を受け取ると解放されます。ステートレスエージェントは、トランザクション状態のみを維持するエージェントです。
Translation Agent
翻訳エージェント
A translation agent (TLA in Figure 4) is a stateful Diameter node that performs protocol translation between Diameter and another AAA protocol, such as RADIUS.
変換エージェント（図4のTLA）は、DiameterとRADIUSなどの別のAAAプロトコルとの間のプロトコル変換を実行するステートフルDiameterノードです。
Upstream
上流の
Upstream is used to identify the direction of a particular Diameter message from the Diameter client towards the home server.
アップストリームは、Diameterクライアントからホームサーバーへの特定のDiameterメッセージの方向を識別するために使用されます。
User
ユーザー
The entity or device requesting or using some resource, in support of which a Diameter client has generated a request.
Diameterクライアントがリクエストを生成したことをサポートするリソースをリクエストまたは使用しているエンティティまたはデバイス。
The Diameter protocol is designed to be extensible, using several mechanisms, including:
Diameterプロトコルは、以下を含むいくつかのメカニズムを使用して、拡張できるように設計されています。
o Defining new AVP values
o 新しいAVP値の定義
o Creating new AVPs
o 新しいAVPの作成
o Creating new commands
o 新しいコマンドを作成する
o Creating new applications From the point of view of extensibility, Diameter authentication, authorization, and accounting applications are treated in the same way.
o新しいアプリケーションの作成拡張性の観点から、Diameterの認証、承認、およびアカウンティングアプリケーションは同じ方法で処理されます。
Note: Protocol designers should try to reuse existing functionality, namely AVP values, AVPs, commands, and Diameter applications. Reuse simplifies standardization and implementation. To avoid potential interoperability issues, it is important to ensure that the semantics of the reused features are well understood. Given that Diameter can also carry RADIUS attributes as Diameter AVPs, such reuse considerations also apply to existing RADIUS attributes that may be useful in a Diameter application.
注：プロトコル設計者は、AVP値、AVP、コマンド、Diameterアプリケーションなどの既存の機能を再利用する必要があります。再利用により、標準化と実装が簡素化されます。潜在的な相互運用性の問題を回避するには、再利用される機能のセマンティクスが十分に理解されていることを確認することが重要です。 DiameterはRADIUS属性をDiameter AVPとしても伝送できるため、このような再利用に関する考慮事項は、Diameterアプリケーションで役立つ可能性がある既存のRADIUS属性にも適用されます。
In order to allocate a new AVP value for AVPs defined in the Diameter base protocol, the IETF needs to approve a new RFC that describes the AVP value. IANA considerations for these AVP values are discussed in Section 11.3.
Diameter基本プロトコルで定義されたAVPに新しいAVP値を割り当てるために、IETFはAVP値を説明する新しいRFCを承認する必要があります。これらのAVP値に関するIANAの考慮事項については、セクション11.3で説明します。
The allocation of AVP values for other AVPs is guided by the IANA considerations of the document that defines those AVPs. Typically, allocation of new values for an AVP defined in an RFC would require IETF Review [RFC5226], whereas values for vendor-specific AVPs can be allocated by the vendor.
他のAVPに対するAVP値の割り当ては、それらのAVPを定義するドキュメントのIANAの考慮事項によって導かれます。通常、RFCで定義されたAVPの新しい値の割り当てにはIETFレビュー[RFC5226]が必要ですが、ベンダー固有のAVPの値はベンダーが割り当てることができます。
A new AVP being defined MUST use one of the data types listed in Sections 4.2 or 4.3. If an appropriate derived data type is already defined, it SHOULD be used instead of a base data type to encourage reusability and good design practice.
新たに定義するAVPは、セクション4.2または4.3に列挙されているデータ型のいずれかを使用しなければなりません (MUST)。適切な派生データ型がすでに定義されている場合、再利用性と適切な設計慣行を促すため、基本データ型ではなくその派生データ型を使用すべきです (SHOULD)。
In the event that a logical grouping of AVPs is necessary, and multiple "groups" are possible in a given command, it is recommended that a Grouped AVP be used (see Section 4.4).
AVPの論理グループ化が必要で、特定のコマンドで複数の「グループ」が可能である場合は、グループ化されたAVPを使用することをお勧めします（セクション4.4を参照）。
The creation of new AVPs can happen in various ways. The recommended approach is to define a new general-purpose AVP in a Standards Track RFC approved by the IETF. However, as described in Section 11.1.1, there are other mechanisms.
新しいAVPの作成は、さまざまな方法で行われます。推奨されるアプローチは、IETFによって承認されたStandards Track RFCで新しい汎用AVPを定義することです。ただし、セクション11.1.1で説明されているように、他のメカニズムがあります。
A new Command Code MUST be allocated when required AVPs (those indicated as {AVP} in the CCF definition) are added to, deleted from, or redefined in (for example, by changing a required AVP into an optional one) an existing command.
必須AVP（CCF定義で{AVP}と示されるもの）を既存のコマンドに追加する場合、既存のコマンドから削除する場合、または既存のコマンド内で再定義する場合（たとえば、必須AVPをオプションAVPに変更する場合）、新しいCommand Codeを割り当てなければなりません (MUST)。
Furthermore, if the transport characteristics of a command are changed (for example, with respect to the number of round trips required), a new Command Code MUST be registered.
さらに、コマンドのトランスポート特性（たとえば、必要なラウンドトリップ回数）を変更する場合、新しいCommand Codeを登録しなければなりません (MUST)。
A change to the CCF of a command, such as described above, MUST result in the definition of a new Command Code. This subsequently leads to the need to define a new Diameter application for any application that will use that new command.
上記のようなコマンドのCCF変更は、新しいCommand Codeの定義を伴わなければなりません (MUST)。その結果、この新しいコマンドを使用するアプリケーションごとに、新しいDiameterアプリケーションを定義する必要も生じます。
The IANA considerations for Command Codes are discussed in Section 3.1.
コマンドコードに関するIANAの考慮事項については、セクション3.1で説明します。
Every Diameter application specification MUST have an IANA-assigned Application Id (see Section 2.4). The managed Application ID space is flat, and there is no relationship between different Diameter applications with respect to their Application Ids. As such, there is no versioning support provided by these Application Ids themselves; every Diameter application is a standalone application. If the application has a relationship with other Diameter applications, such a relationship is not known to Diameter.
すべてのDiameterアプリケーション仕様は、IANAが割り当てたApplication Idを持たなければなりません (MUST)（セクション2.4を参照）。管理対象のApplication ID空間はフラットであり、Application Idに関して異なるDiameterアプリケーション間に関係はありません。したがって、Application Id自体はバージョン管理を提供せず、各Diameterアプリケーションは独立したアプリケーションです。あるアプリケーションが他のDiameterアプリケーションと関係していても、Diameterはその関係を認識しません。
Before describing the rules for creating new Diameter applications, it is important to discuss the semantics of the AVP occurrences as stated in the CCF and the M-bit flag (Section 4.1) for an AVP. There is no relationship imposed between the two; they are set independently.
新しいDiameterアプリケーションを作成するためのルールを説明する前に、CCFおよびAVPのMビットフラグ（セクション4.1）に記載されているAVPオカレンスのセマンティクスについて説明することが重要です。 2つの間に課される関係はありません。それらは独立して設定されます。
o The CCF indicates what AVPs are placed into a Diameter command by the sender of that command. Often, since there are multiple modes of protocol interactions, many of the AVPs are indicated as optional.
o CCFは、そのコマンドの送信者によってDiameterコマンドに配置されるAVPを示します。多くの場合、プロトコルの相互作用には複数のモードがあるため、AVPの多くはオプションとして示されます。
o The M-bit allows the sender to indicate to the receiver whether or not understanding the semantics of an AVP and its content is mandatory. If the M-bit is set by the sender and the receiver does not understand the AVP or the values carried within that AVP, then a failure is generated (see Section 7).
o Mビットにより、AVPのセマンティクスとその内容の理解が必須かどうかを送信者が受信者に示すことができます。 Mビットが送信側によって設定され、受信側がAVPまたはそのAVP内で伝送される値を理解できない場合、障害が生成されます（セクション7を参照）。
It is the decision of the protocol designer when to develop a new Diameter application rather than extending Diameter in other ways. However, a new Diameter application MUST be created when one or more of the following criteria are met: M-bit Setting
Diameterを他の方法で拡張せず、新しいDiameterアプリケーションをいつ開発するかは、プロトコル設計者が決定します。ただし、次の基準のうち1つ以上を満たす場合、新しいDiameterアプリケーションを作成しなければなりません (MUST)：M-bitの設定
An AVP with the M-bit in the MUST column of the AVP flag table is added to an existing Command/Application. An AVP with the M-bit in the MAY column of the AVP flag table is added to an existing Command/Application.
AVPフラグテーブルのMUST列にMビットを持つAVPが既存のコマンド/アプリケーションに追加されます。 AVPフラグテーブルのMAY列にMビットを持つAVPが、既存のコマンド/アプリケーションに追加されます。
Note: The M-bit setting for a given AVP is relevant to an Application and each command within that application that includes the AVP. That is, if an AVP appears in two commands for application Foo and the M-bit settings are different in each command, then there should be two AVP flag tables describing when to set the M-bit.
注：特定のAVPのMビット設定は、アプリケーションと、AVPを含むそのアプリケーション内の各コマンドに関連しています。つまり、アプリケーションFooの2つのコマンドにAVPが表示され、Mビット設定が各コマンドで異なる場合、Mビットを設定するタイミングを説明する2つのAVPフラグテーブルが必要です。
Commands
コマンド
A new command is used within the existing application because either an additional command is added, an existing command has been modified so that a new Command Code had to be registered, or a command has been deleted.
追加のコマンドが追加されるか、既存のコマンドが変更されて新しいコマンドコードを登録する必要があるか、またはコマンドが削除されたため、既存のアプリケーション内で新しいコマンドが使用されています。
AVP Flag bits
AVPフラグビット
If an existing application changes the meaning/semantics of its AVP Flags or adds new flag bits, then a new Diameter application MUST be created.
既存のアプリケーションがAVP Flagsの意味またはセマンティクスを変更する場合、あるいは新しいフラグビットを追加する場合、新しいDiameterアプリケーションを作成しなければなりません (MUST)。
If the CCF definition of a command allows it, an implementation may add arbitrary optional AVPs with the M-bit cleared (including vendor-specific AVPs) to that command without needing to define a new application. Please refer to Section 11.1.1 for details.
コマンドのCCF定義で許可されている場合、実装は、Mビットがクリアされた任意のオプションのAVP（ベンダー固有のAVPを含む）をそのコマンドに追加できます。新しいアプリケーションを定義する必要はありません。詳細については、セクション11.1.1を参照してください。
The base Diameter protocol concerns itself with establishing connections to peers, capabilities negotiation, how messages are sent and routed through peers, and how the connections are eventually torn down. The base protocol also defines certain rules that apply to all message exchanges between Diameter nodes.
基本Diameterプロトコルは、ピアへの接続の確立、機能のネゴシエーション、メッセージがピアを介して送信およびルーティングされる方法、および接続が最終的に切断される方法に関係しています。基本プロトコルは、Diameterノード間のすべてのメッセージ交換に適用される特定のルールも定義します。
Communication between Diameter peers begins with one peer sending a message to another Diameter peer. The set of AVPs included in the message is determined by a particular Diameter application. One AVP that is included to reference a user's session is the Session-Id.
Diameterピア間の通信は、あるピアが別のDiameterピアにメッセージを送信することから始まります。メッセージに含まれるAVPのセットは、特定のDiameterアプリケーションによって決定されます。ユーザーのセッションを参照するために含まれている1つのAVPは、Session-Idです。
The initial request for authentication and/or authorization of a user would include the Session-Id AVP. The Session-Id is then used in all subsequent messages to identify the user's session (see Section 8 for
ユーザーの認証または承認、あるいはその両方の最初の要求には、Session-Id AVPが含まれます。その後、Session-Idは後続のすべてのメッセージで使用され、ユーザーのセッションを識別します（セクション8
more information). The communicating party may accept the request or reject it by returning an answer message with the Result-Code AVP set to indicate that an error occurred. The specific behavior of the Diameter server or client receiving a request depends on the Diameter application employed.
詳しくは）。通信側は、エラーが発生したことを示すためにResult-Code AVPが設定された応答メッセージを返すことにより、要求を受け入れるか拒否することができます。リクエストを受信するDiameterサーバーまたはクライアントの特定の動作は、採用されているDiameterアプリケーションによって異なります。
Session state (associated with a Session-Id) MUST be freed upon receipt of the Session-Termination-Request, Session-Termination-Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular Diameter application.
Session-Idに関連付けられたセッション状態は、Session-Termination-RequestまたはSession-Termination-Answerの受信時、Session-Timeout AVPに示された認可済みサービス時間の満了時、および個々のDiameterアプリケーションで定められた規則に従って解放しなければなりません (MUST)。
The base Diameter protocol may be used by itself for accounting applications. For authentication and authorization, it is always extended for a particular application.
基本のDiameterプロトコルは、それ自体で会計アプリケーションに使用できます。認証と承認のために、それは常に特定のアプリケーションのために拡張されます。
Diameter clients MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement the client's service, e.g., Network Access Server Requirements (NASREQ) [RFC2881] and/or Mobile IPv4. A Diameter client MUST be referred to as "Diameter X Client" where X is the application that it supports and not a "Diameter Client".
Diameterクライアントは、アカウンティングを含む基本プロトコルをサポートしなければなりません (MUST)。さらに、Network Access Server Requirements（NASREQ）[RFC2881]やMobile IPv4など、クライアントのサービスを実装するために必要なDiameterアプリケーションをすべて完全にサポートしなければなりません (MUST)。Diameterクライアントは単に「Diameter Client」と呼ばず、Xがサポートするアプリケーションを表す「Diameter X Client」と呼ばなければなりません (MUST)。
Diameter servers MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement the intended service, e.g., NASREQ and/or Mobile IPv4. A Diameter server MUST be referred to as "Diameter X Server" where X is the application that it supports, and not a "Diameter Server".
Diameterサーバーは、アカウンティングを含む基本プロトコルをサポートしなければなりません (MUST)。さらに、NASREQやMobile IPv4など、意図したサービスを実装するために必要なDiameterアプリケーションをすべて完全にサポートしなければなりません (MUST)。Diameterサーバーは単に「Diameter Server」と呼ばず、Xがサポートするアプリケーションを表す「Diameter X Server」と呼ばなければなりません (MUST)。
Diameter relays and redirect agents are transparent to the Diameter applications, but they MUST support the Diameter base protocol, which includes accounting, and all Diameter applications.
DiameterリレーおよびリダイレクトエージェントはDiameterアプリケーションに対して透過的ですが、アカウンティングを含むDiameter基本プロトコルと、すべてのDiameterアプリケーションをサポートしなければなりません (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 MUST be referred to as "Diameter X Proxy" where X is the application which it supports, and not a "Diameter Proxy".
Diameterプロキシは、アカウンティングを含む基本プロトコルをサポートしなければなりません (MUST)。さらに、NASREQやMobile IPv4など、プロキシ対象サービスを実装するために必要なDiameterアプリケーションをすべて完全にサポートしなければなりません (MUST)。Diameterプロキシは単に「Diameter Proxy」と呼ばず、Xがサポートするアプリケーションを表す「Diameter X Proxy」と呼ばなければなりません (MUST)。
The Diameter Transport profile is defined in [RFC3539].
Diameter Transportプロファイルは[RFC3539]で定義されています。
The base Diameter protocol is run on port 3868 for both TCP [RFC0793] and SCTP [RFC4960]. For TLS [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347], a Diameter node that initiates a connection prior to any message exchanges MUST run on port 5658. It is assumed that TLS is run on top of TCP when it is used, and DTLS is run on top of SCTP when it is used.
If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP connections on port 5658 (i.e., the peer complies only with RFC 3588), then the initiator MAY revert to using TCP or SCTP on port 3868. Note that this scheme is kept only for the purpose of backward compatibility and that there are inherent security vulnerabilities when the initial CER/CEA messages are sent unprotected (see Section 5.6).
Diameterピアがポート5658でTLS/TCP接続およびDTLS/SCTP接続を受け付ける機能をサポートしていない場合（すなわち、そのピアがRFC 3588にしか準拠していない場合）、接続開始側はポート3868でTCPまたはSCTPを使用する方式に戻してもよい (MAY)。この方式は後方互換性のためだけに維持されており、最初のCER/CEAメッセージを保護せずに送信すると固有のセキュリティ脆弱性が生じることに注意してください（セクション5.6を参照）。
Diameter clients MUST support either TCP or SCTP; agents and servers SHOULD support both.
DiameterクライアントはTCPまたはSCTPのいずれかをサポートしなければなりません (MUST)。エージェントおよびサーバーは、その両方をサポートすべきです (SHOULD)。
A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and it MUST always be prepared to receive connections on port 3868 for TCP or SCTP and port 5658 for TLS/TCP and DTLS/SCTP connections. When DNS-based peer discovery (Section 5.2) is used, the port numbers received from SRV records take precedence over the default ports (3868 and 5658).
Diameterノードは、着信接続を受け付けると宣言したポートとは異なる送信元ポートから接続を開始してもよい (MAY)。また、TCPまたはSCTP接続についてはポート3868、TLS/TCPまたはDTLS/SCTP接続についてはポート5658で接続を受け付けられるよう、常に準備しておかなければなりません (MUST)。DNSベースのピア発見（セクション5.2）を使用する場合、SRVレコードから得たポート番号がデフォルトポート（3868および5658）に優先します。
A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer, in which, case a separate connection per process is allowed.
ピア上に複数のインスタンスが存在する場合を除き、ピアステートマシンの1つのDiameterインスタンスは、特定のピアとの通信に複数のトランスポート接続を使用してはなりません (MUST NOT)。複数のインスタンスが存在する場合は、プロセスごとに別個の接続が許されます。
When no transport connection exists with a peer, an attempt to connect SHOULD be made periodically. This behavior is handled via the Tc timer (see Section 12 for details), whose recommended value is 30 seconds. There are certain exceptions to this rule, such as when a peer has terminated the transport connection stating that it does not wish to communicate.
ピアとのトランスポート接続が存在しない場合、接続の試行は定期的に行われる必要があります（SHOULD）。この動作は、推奨値が30秒のTcタイマー（詳細はセクション12を参照）を介して処理されます。このルールには特定の例外があります。たとえば、通信したくないとピアがトランスポート接続を終了した場合などです。
When connecting to a peer and either zero or more transports are specified, TLS SHOULD be tried first, followed by DTLS, then by TCP, and finally by SCTP. See Section 5.2 for more information on peer discovery.
ピアへの接続時にトランスポートが0個以上指定されている場合、最初にTLS、次にDTLS、その次にTCP、最後にSCTPを試すべきです (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. Further guidance regarding the treatment of ICMP errors can be found in [RFC5927] and [RFC5461]. Diameter implementations SHOULD also be able to interpret a reset from the transport and timed-out connection attempts. If Diameter receives data from the lower layer that cannot be parsed or identified as a Diameter error made by the peer, the stream is compromised and cannot be recovered. The transport connection MUST be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT message (graceful closure is compromised).
Diameter実装は、ICMPプロトコルのport unreachableメッセージを信頼するかどうかに関するセキュリティポリシーに従い、このメッセージをサーバーへ到達できないことの明示的な通知として解釈できるようにすべきです (SHOULD)。ICMPエラーの扱いに関する詳細な指針は、[RFC5927]および[RFC5461]にあります。Diameter実装は、トランスポートからのリセットと、タイムアウトした接続試行も解釈できるようにすべきです (SHOULD)。Diameterが下位層から受信したデータを解析できず、かつピアが生成したDiameterエラーとも識別できない場合、ストリームは破損しており回復できません。トランスポート接続は、RESET呼び出し（TCP RSTビットの送信）またはSCTP ABORTメッセージを使用して閉じなければなりません (MUST)（正常なクローズはできません）。
Diameter messages SHOULD be mapped into SCTP streams in a way that avoids head-of-the-line (HOL) blocking. Among different ways of performing the mapping that fulfill this requirement it is RECOMMENDED that a Diameter node send every Diameter message (request or response) over stream zero with the unordered flag set. However, Diameter nodes MAY select and implement other design alternatives for avoiding HOL blocking such as using multiple streams with the unordered flag cleared (as originally instructed in RFC 3588). On the receiving side, a Diameter entity MUST be ready to receive Diameter messages over any stream, and it is free to return responses over a different stream. This way, both sides manage the available streams in the sending direction, independently of the streams chosen by the other side to send a particular Diameter message. These messages can be out-of-order and belong to different Diameter sessions.
Diameterメッセージは、head-of-the-line（HOL）ブロッキングを回避するようSCTPストリームへ割り当てるべきです (SHOULD)。この要件を満たす複数の割り当て方法のうち、Diameterノードはunorderedフラグを設定し、すべてのDiameterメッセージ（要求または応答）をストリーム0で送信すべきです (RECOMMENDED)。ただし、Diameterノードは、RFC 3588で当初指示されていたようにunorderedフラグをクリアした複数のストリームを使用するなど、HOLブロッキングを回避する別の設計を選択して実装してもよい (MAY)。受信側のDiameterエンティティは、どのストリームでもDiameterメッセージを受信できるよう準備しなければならず (MUST)、別のストリームで自由に応答を返せます。この方法では、相手側が特定のDiameterメッセージの送信に選んだストリームとは無関係に、双方が送信方向で利用可能なストリームを管理します。これらのメッセージは順不同になることがあり、異なるDiameterセッションに属することもあります。
Out-of-order delivery has special concerns during a connection establishment and termination. When a connection is established, the responder side sends a CEA message and moves to R-Open state as specified in Section 5.6. If an application message is sent shortly after the CEA and delivered out-of-order, the initiator side, still in Wait-I-CEA state, will discard the application message and close the connection. In order to avoid this race condition, the receiver side SHOULD NOT use out-of-order delivery methods until the first message has been received from the initiator, proving that it has moved to I-Open state. To trigger such a message, the receiver side could send a DWR immediately after sending a CEA. Upon reception of the corresponding DWA, the receiver side should start using out-of-order delivery methods to counter the HOL blocking.
順不同配信は、接続の確立と終了時に特別な懸念があります。接続が確立されると、レスポンダー側はCEAメッセージを送信し、セクション5.6で指定されているR-Open状態に移行します。アプリケーションメッセージがCEAの直後に送信され、順序どおりに配信されない場合、イニシエーター側はまだWait-I-CEA状態であり、アプリケーションメッセージを破棄して接続を閉じます。この競合状態を回避するために、受信側は、最初のメッセージがイニシエーターから受信され、I-Open状態に移行したことを証明するまで、順不同の配信方法を使用してはなりません（SHOULD NOT）。このようなメッセージをトリガーするために、受信側はCEAを送信した直後にDWRを送信できます。対応するDWAを受信すると、受信側は、順序が正しくない配信方法を使用して、HOLブロッキングに対抗する必要があります。
Another race condition may occur when DPR and DPA messages are used. Both DPR and DPA are small in size; thus, they may be delivered to the peer faster than application messages when an out-of-order delivery mechanism is used. Therefore, it is possible that a DPR/DPA exchange completes while application messages are still in transit, resulting in a loss of these messages. An implementation could mitigate this race condition, for example, using timers, and wait for a short period of time for pending application level messages to arrive before proceeding to disconnect the transport connection. Eventually, lost messages are handled by the retransmission mechanism described in Section 5.5.4.
DPRおよびDPAメッセージを使用すると、別の競合状態が発生する可能性があります。 DPRとDPAはどちらもサイズが小さいです。したがって、順不同の配信メカニズムを使用すると、アプリケーションメッセージよりも速くピアに配信される可能性があります。したがって、アプリケーションメッセージがまだ転送中にDPR/DPA交換が完了し、これらのメッセージが失われる可能性があります。実装は、たとえばタイマーを使用してこの競合状態を緩和し、保留中のアプリケーションレベルのメッセージが到着するまでしばらく待ってから、トランスポート接続の切断に進むことができます。最終的に、失われたメッセージは、セクション5.5.4で説明されている再送信メカニズムによって処理されます。
A Diameter agent SHOULD use dedicated payload protocol identifiers (PPIDs) for clear text and encrypted SCTP DATA chunks instead of only using the unspecified payload protocol identifier (value 0). For this purpose, two PPID values are allocated: the PPID value 46 is for Diameter messages in clear text SCTP DATA chunks, and the PPID value 47 is for Diameter messages in protected DTLS/SCTP DATA chunks.
Diameterエージェントは、未指定のペイロードプロトコル識別子（値0）のみを使用する代わりに、クリアテキストと暗号化されたSCTP DATAチャンクに専用のペイロードプロトコル識別子（PPID）を使用する必要があります（SHOULD）。この目的のために、2つのPPID値が割り当てられます。PPID値46はクリアテキストSCTP DATAチャンクのDiameterメッセージ用であり、PPID値47は保護されたDTLS/SCTP DATAチャンクのDiameterメッセージ用です。
Connections between Diameter peers SHOULD be protected by TLS/TCP and DTLS/SCTP. All Diameter base protocol implementations MUST support the use of TLS/TCP and DTLS/SCTP. If desired, alternative security mechanisms that are independent of Diameter, such as IPsec [RFC4301], can be deployed to secure connections between peers. The Diameter protocol MUST NOT be used without one of TLS, DTLS, or IPsec.
Diameterピア間の接続は、TLS/TCPおよびDTLS/SCTPで保護すべきです (SHOULD)。Diameter基本プロトコルのすべての実装は、TLS/TCPおよびDTLS/SCTPの使用をサポートしなければなりません (MUST)。必要に応じて、IPsec [RFC4301]などDiameterから独立した代替セキュリティ機構を配備し、ピア間の接続を保護できます。Diameterプロトコルは、TLS、DTLS、IPsecのいずれかを使用せずに運用してはなりません (MUST NOT)。
Application Ids are advertised during the capabilities exchange phase (see Section 5.3). Advertising support of an application implies that the sender supports the functionality specified in the respective Diameter application specification.
アプリケーションIDは、機能交換フェーズ中に通知されます（セクション5.3を参照）。アプリケーションのアドバタイズサポートは、送信者がそれぞれのDiameterアプリケーション仕様で指定された機能をサポートすることを意味します。
Implementations MAY add arbitrary optional AVPs with the M-bit cleared (including vendor-specific AVPs) to a command defined in an application, but only if the command's CCF syntax specification allows for it. Please refer to Section 11.1.1 for details.
コマンドのCCF構文仕様で許可されている場合に限り、実装はM-bitをクリアした任意のオプションAVP（ベンダー固有AVPを含む）を、そのアプリケーションで定義されたコマンドに追加してもよい (MAY)。詳細についてはセクション11.1.1を参照してください。
Each Diameter application MUST have an IANA-assigned Application ID. The base protocol does not require an Application Id since its support is mandatory. During the capabilities exchange, Diameter nodes inform their peers of locally supported applications. Furthermore, all Diameter messages contain an Application Id, which is used in the message forwarding process.
各Diameterアプリケーションは、IANAが割り当てたApplication IDを持たなければなりません (MUST)。基本プロトコルはサポートが必須であるため、Application Idを必要としません。能力交換時に、Diameterノードはローカルでサポートするアプリケーションをピアへ通知します。さらに、すべてのDiameterメッセージには、メッセージ転送処理で使用するApplication Idが含まれます。
The following Application Id values are defined:
次のアプリケーションID値が定義されています。
Diameter common message 0
Diameter base accounting 3
Relay 0xffffffff
Relay and redirect agents MUST advertise the Relay Application ID, while all other Diameter nodes MUST advertise locally supported applications. The receiver of a Capabilities Exchange message advertising relay service MUST assume that the sender supports all current and future applications.
リレーおよびリダイレクトエージェントはRelay Application IDを通知しなければならず (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 refers to a transport-level connection between two peers that is used to send and receive Diameter messages. A session is a logical concept at the application layer that exists between the Diameter client and the Diameter server; it is identified via the Session-Id AVP.
接続とは、Diameterメッセージの送受信に使用される2つのピア間のトランスポートレベルの接続を指します。セッションとは、DiameterクライアントとDiameterサーバーの間に存在するアプリケーション層の論理的な概念です。これは、Session-Id AVPを介して識別されます。
+--------+ +-------+ +--------+
| Client | | Relay | | Server |
+--------+ +-------+ +--------+
<----------> <---------->
peer connection A peer connection B
<----------------------------->
User session x
Figure 1: Diameter Connections and Sessions
図1：Diameter接続とセッション
In the example provided in Figure 1, peer connection A is established between the client and the relay. Peer connection B is established between the relay and the server. User session X spans from the client via the relay to the server. Each "user" of a service causes an auth request to be sent, with a unique session identifier. Once accepted by the server, both the client and the server are aware of the session.
図1の例では、クライアントとリレーの間にピア接続Aが確立されています。ピア接続Bがリレーとサーバー間で確立されます。ユーザーセッションXは、クライアントからリレーを経由してサーバーに及びます。サービスの「ユーザー」ごとに、一意のセッション識別子を使用して認証リクエストが送信されます。サーバーに受け入れられると、クライアントとサーバーの両方がセッションを認識します。
It is important to note that there is no relationship between a connection and a session, and that Diameter messages for multiple sessions are all multiplexed through a single connection. Also, note that Diameter messages pertaining to the session, both application-specific and those that are defined in this document such as ASR/ASA, RAR/RAA, and STR/STA, MUST carry the Application Id of the application. Diameter messages pertaining to peer connection establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA MUST carry an Application Id of zero (0).
接続とセッションの間には関係がなく、複数セッションのDiameterメッセージがすべて1つの接続上で多重化される点に注意することが重要です。また、セッションに関係するDiameterメッセージは、アプリケーション固有のものでも、ASR/ASA、RAR/RAA、STR/STAのように本文書で定義するものでも、そのアプリケーションのApplication Idを含まなければなりません (MUST)。CER/CEA、DWR/DWA、DPR/DPAのようにピア接続の確立および保守に関係するDiameterメッセージは、0のApplication Idを含まなければなりません (MUST)。
The Diameter peer table is used in message forwarding and is referenced by the routing table. A peer table entry contains the following fields:
Diameterピアテーブルはメッセージ転送で使用され、ルーティングテーブルによって参照されます。ピアテーブルエントリには、次のフィールドが含まれます。
Host Identity
ホストID
Following the conventions described for the DiameterIdentity-derived AVP data format in Section 4.3.1, this field contains the contents of the Origin-Host (Section 6.3) AVP found in the CER or CEA message.
セクション4.3.1のDiameterIdentity派生AVPデータ形式について説明した規則に従って、このフィールドには、CERまたはCEAメッセージにあるOrigin-Host（セクション6.3）AVPの内容が含まれます。
StatusT
StatusT
This is the state of the peer entry, and it MUST match one of the values listed in Section 5.6.
これはピアエントリの状態であり、セクション5.6に列挙する値のいずれかと一致しなければなりません (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. If public key certificates are used for Diameter security (e.g., with TLS), this value MUST NOT be greater than the expiry times in the relevant certificates.
動的に検出されたピアテーブルエントリが更新または期限切れになる時刻を指定します。公開鍵証明書がDiameterのセキュリティ（TLSなど）に使用されている場合、この値は、関連する証明書の有効期限を超えてはなりません（MUST NOT）。
TLS/TCP and DTLS/SCTP Enabled
TLS/TCPおよびDTLS/SCTPが有効
Specifies whether TLS/TCP and DTLS/SCTP is to be used when communicating with the peer.
ピアとの通信時にTLS/TCPおよびDTLS/SCTPを使用するかどうかを指定します。
Additional security information, when needed (e.g., keys, certificates).
必要な場合の追加のセキュリティ情報（キー、証明書など）。
All Realm-Based routing lookups are performed against what is commonly known as the routing table (see Section 12). Each routing table entry contains the following fields:
すべてのレルムベースのルーティングルックアップは、一般にルーティングテーブルと呼ばれるものに対して実行されます（セクション12を参照）。各ルーティングテーブルエントリには、次のフィールドが含まれています。
Realm Name
レルム名
This is the field that MUST be used as a primary key in the routing table lookups. Note that some implementations perform their lookups based on longest-match-from-the-right on the realm rather than requiring an exact match.
これは、ルーティングテーブル検索の主キーとして使用しなければならない (MUST) フィールドです。一部の実装では、完全一致を必須とせず、realmを右端から最長一致させて検索することに注意してください。
Application Identifier
アプリケーション識別子
An application is identified by an Application Id. A route entry can have a different destination based on the Application Id in the message header. This field MUST be used as a secondary key field in routing table lookups.
アプリケーションはApplication Idで識別します。ルートエントリは、メッセージヘッダー内のApplication Idに応じて異なる宛先を持つことができます。このフィールドは、ルーティングテーブル検索の副キーとして使用しなければなりません (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 can be satisfied locally and do not need to be routed to another Diameter entity.
1. LOCAL-ローカルで満たすことができ、別のDiameterエンティティにルーティングする必要がないDiameterメッセージ。
2. RELAY - All Diameter messages that fall within this category MUST be routed to a next-hop Diameter entity that is indicated by the identifier described below. Routing is done without modifying any non-routing AVPs. See Section 6.1.9 for relaying guidelines.
2. RELAY - このカテゴリに該当するすべてのDiameterメッセージは、以下で説明する識別子が示す次ホップのDiameterエンティティへルーティングしなければなりません (MUST)。ルーティングは、ルーティング用でないAVPを変更せずに行います。リレーの指針についてはセクション6.1.9を参照してください。
3. PROXY - All Diameter messages that fall within this category MUST be routed to a next Diameter entity that is indicated by the identifier described below. The local server MAY apply its local policies to the message by including new AVPs to the message prior to routing. See Section 6.1.9 for proxying guidelines.
3. PROXY - このカテゴリに該当するすべてのDiameterメッセージは、以下で説明する識別子が示す次のDiameterエンティティへルーティングしなければなりません (MUST)。ローカルサーバーは、ルーティング前にメッセージへ新しいAVPを含めることで、そのメッセージにローカルポリシーを適用してもよい (MAY)。プロキシの指針についてはセクション6.1.9を参照してください。
4. REDIRECT - Diameter messages that fall within this category MUST have the identity of the home Diameter server(s) appended, and returned to the sender of the message. See Section 6.1.8 for redirection guidelines.
4. REDIRECT - このカテゴリに該当するDiameterメッセージには、ホームDiameterサーバーの識別情報を追加し、そのメッセージの送信側へ返さなければなりません (MUST)。リダイレクトの指針についてはセクション6.1.8を参照してください。
Server Identifier
サーバー識別子
The identity of one or more servers to which the message is to be routed. This identity MUST also be present in the Host Identity field of the peer table (Section 2.6). When the Local Action is set to RELAY or PROXY, this field contains the identity of the server(s) to which the message MUST be routed. When the Local Action field is set to REDIRECT, this field contains the identity of one or more servers to which the message MUST be redirected.
メッセージのルーティング先となる1つ以上のサーバーの識別情報です。この識別情報は、ピアテーブルのHost Identityフィールドにも存在しなければなりません (MUST)（セクション2.6）。Local ActionがRELAYまたはPROXYの場合、このフィールドには、メッセージをルーティングしなければならない (MUST) サーバーの識別情報が入ります。Local ActionフィールドがREDIRECTの場合、このフィールドには、メッセージをリダイレクトしなければならない (MUST) 1つ以上のサーバーの識別情報が入ります。
Static or Dynamic
静的または動的
Specifies whether a route entry was statically configured or dynamically discovered.
ルートエントリが静的に構成されたか動的に検出されたかを指定します。
Expiration Time
有効期限
Specifies the time at which a dynamically discovered route table entry expires. If public key certificates are used for Diameter security (e.g., with TLS), this value MUST NOT be greater than the expiry time in the relevant certificates.
動的に検出されたルートテーブルエントリの有効期限が切れる時刻を指定します。公開鍵証明書がDiameterのセキュリティ（TLSなど）に使用されている場合、この値は、関連する証明書の有効期限を超えてはなりません（MUST NOT）。
It is important to note that Diameter agents MUST support at least one of the LOCAL, RELAY, PROXY, or REDIRECT modes of operation. Agents do not need to support all modes of operation in order to conform with the protocol specification, but they MUST follow the protocol compliance guidelines in Section 2. Relay agents and proxies MUST NOT reorder AVPs.
Diameterエージェントは、LOCAL、RELAY、PROXY、REDIRECTの動作モードのうち少なくとも1つをサポートしなければならない (MUST) 点が重要です。プロトコル仕様へ準拠するためにすべての動作モードをサポートする必要はありませんが、エージェントはセクション2のプロトコル準拠指針に従わなければなりません (MUST)。リレーエージェントおよびプロキシは、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.
ルーティングテーブルはデフォルトエントリを含んでもよい (MAY)。このデフォルトエントリは、他のどのエントリにも一致しない要求に使用しなければなりません (MUST)。ルーティングテーブルを、このようなエントリだけで構成してもよい (MAY)。
When a request is routed, the target server MUST have advertised the Application Id (see Section 2.4) for the given message or have advertised itself as a relay or proxy agent. Otherwise, an error is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
要求をルーティングする場合、対象サーバーは、そのメッセージのApplication Id（セクション2.4を参照）を通知済みであるか、自身をリレーエージェントまたはプロキシエージェントとして通知済みでなければなりません (MUST)。そうでない場合、Result-Code AVPをDIAMETER_UNABLE_TO_DELIVERに設定したエラーが返されます。
In addition to clients and servers, the Diameter protocol introduces relay, proxy, redirect, and translation agents, each of which is defined in Section 1.2. Diameter agents are useful for several reasons:
クライアントとサーバーに加えて、Diameterプロトコルはリレー、プロキシ、リダイレクト、および変換エージェントを導入します。それぞれのエージェントはセクション1.2で定義されています。 Diameterエージェントは、いくつかの理由で役立ちます。
o They can distribute administration of systems to a configurable grouping, including the maintenance of security associations.
o 彼らは、セキュリティアソシエーションのメンテナンスなど、システムの管理を構成可能なグループに分散できます。
o They can be used for concentration of requests from a number of co-located or distributed NAS equipment sets to a set of like user groups.
o それらは、多数の同じ場所に配置または分散されたNAS機器セットから、同様のユーザーグループのセットへの要求の集中に使用できます。
o They can do value-added processing to the requests or responses.
o 要求または応答に付加価値処理を実行できます。
o They can be used for load balancing.
o ロードバランシングに使用できます。
o A complex network will have multiple authentication sources, they can sort requests and forward towards the correct target.
o 複雑なネットワークには複数の認証ソースがあり、リクエストを並べ替えて正しいターゲットに転送できます。
The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, its Hop-by-Hop Identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state.
Diameterプロトコルでは、エージェントがフェイルオーバーの目的で使用されるトランザクション状態を維持する必要があります。トランザクション状態は、要求を転送すると、そのホップバイホップ識別子が保存されることを意味します。フィールドはローカルで一意の識別子に置き換えられ、対応する回答を受信すると元の値に復元されます。リクエストの状態は、回答を受け取ると解放されます。ステートレスエージェントは、トランザクション状態のみを維持するエージェントです。
The Proxy-Info AVP allows stateless agents to add local state to a Diameter request, with the guarantee that the same state will be present in the answer. However, the protocol's failover procedures require that agents maintain a copy of pending requests.
Proxy-Info AVPにより、ステートレスエージェントはローカル状態をDiameterリクエストに追加でき、同じ状態が応答に存在することが保証されます。ただし、プロトコルのフェイルオーバー手順では、エージェントが保留中の要求のコピーを維持する必要があります。
A stateful agent is one that maintains session state information by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered active until either the agent is notified otherwise or the session expires. Each authorized session has an expiration, which is communicated by Diameter servers via the Session-Timeout AVP.
ステートフルエージェントは、承認されたすべてのアクティブセッションを追跡することにより、セッション状態情報を維持するエージェントです。承認された各セッションは特定のサービスにバインドされ、その状態は、エージェントに通知されるか、セッションの有効期限が切れるまでアクティブと見なされます。承認された各セッションには有効期限があり、これはセッションタイムアウトAVPを介してDiameterサーバーによって通知されます。
Maintaining session state may be useful in certain applications, such as:
セッション状態の維持は、次のような特定のアプリケーションで役立ちます。
o Protocol translation (e.g., RADIUS <-> Diameter)
o プロトコル変換（例：RADIUS <-> Diameter）
o Limiting resources authorized to a particular user
o 特定のユーザーに許可されたリソースを制限する
o Per-user or per-transaction auditing
o ユーザーごとまたはトランザクションごとの監査
A Diameter agent MAY act in a stateful manner for some requests and be stateless for others. A Diameter implementation MAY act as one type of agent for some requests and as another type of agent for others.
Diameterエージェントは、一部の要求にはステートフルに動作し、他の要求にはステートレスに動作してもよい (MAY)。Diameter実装は、一部の要求にはある種類のエージェントとして動作し、他の要求には別の種類のエージェントとして動作してもよい (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., the value of the Destination-Realm AVP Section 6.6). This routing decision is performed using a list of supported realms and known peers. This is known as the routing table, as is defined further in Section 2.7.
リレーエージェントは、要求を受け入れ、メッセージ内の情報（たとえば、宛先レルムAVPセクション6.6の値）に基づいて他のDiameterノードにメッセージをルーティングするDiameterエージェントです。このルーティングの決定は、サポートされているレルムと既知のピアのリストを使用して実行されます。セクション2.7でさらに定義されるように、これはルーティングテーブルと呼ばれます。
Relays may, for example, be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (Point of Presence, POP). The use of relays is advantageous since it eliminates the need for NASes to be configured with the necessary security information they would otherwise require to communicate with Diameter servers in other realms. Likewise, this reduces the configuration load on Diameter servers that would otherwise be necessary when NASes are added, changed, or deleted.
リレーは、たとえば、共通の地理的領域（Point of Presence、POP）内の複数のネットワークアクセスサーバー（NAS）からの要求を集約するために使用できます。リレーを使用すると、他のレルムのDiameterサーバーと通信するために必要となる必要なセキュリティ情報をNASに構成する必要がなくなるため、利点があります。同様に、これにより、NASが追加、変更、または削除されたときに必要となるDiameterサーバーの構成負荷が軽減されます。
Relays modify Diameter messages by inserting and removing routing information, but they do not modify any other portion of a message. Relays SHOULD NOT maintain session state but MUST maintain transaction state.
リレーは、ルーティング情報を挿入および削除してDiameterメッセージを変更しますが、メッセージのその他の部分は変更しません。リレーはセッション状態を維持すべきではありません (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 a NAS, which is an access device, for the user bob@example.com. Prior to issuing the request, the NAS performs a Diameter route lookup, using "example.com" as the key, and determines that the message is to be relayed to a DRL, which is a Diameter relay. The DRL performs the same route lookup as the NAS, and relays the message to the HMS, which is example.com's home server. The HMS identifies that the request can be locally supported (via the realm), processes the authentication and/or authorization request, and replies with an answer, which is routed back to the NAS using saved transaction state.
図2の例は、アクセスデバイスであるNASからユーザーbob@example.comに対して発行されたリクエストを示しています。 NASはリクエストを発行する前に、「example.com」をキーとして使用してDiameterルートルックアップを実行し、メッセージがDiameterリレーであるDRLにリレーされることを決定します。 DRLはNASと同じルートルックアップを実行し、メッセージをexample.comのホームサーバーであるHMSにリレーします。 HMSは、要求がローカルで（レルムを介して）サポートできることを識別し、認証および/または許可要求を処理し、保存されたトランザクション状態を使用してNASにルーティングされる応答で応答します。
Since relays do not perform any application-level processing, they provide relaying services for all Diameter applications; therefore, they MUST advertise the Relay Application Id.
リレーはアプリケーションレベルの処理を行わないため、すべてのDiameterアプリケーションにリレーサービスを提供します。したがって、Relay Application Idを通知しなければなりません (MUST)。
Similar to relays, proxy agents route Diameter messages using the Diameter routing table. However, they differ since they modify messages to implement policy enforcement. This requires that proxies maintain the state of their downstream peers (e.g., access devices) to enforce resource usage, provide admission control, and provide provisioning.
リレーと同様に、プロキシエージェントはDiameterルーティングテーブルを使用してDiameterメッセージをルーティングします。ただし、ポリシーを実施するためにメッセージを変更するため、両者は異なります。これには、リソースの使用を強制し、アドミッションコントロールを提供し、プロビジョニングを提供するために、プロキシがダウンストリームピア（アクセスデバイスなど）の状態を維持する必要があります。
Proxies may, for example, be used in call control centers or access ISPs that provide outsourced connections; they can monitor the number and type of ports in use and make allocation and admission decisions according to their configuration.
プロキシは、たとえば、外部接続を提供する呼制御センターまたはアクセスISPで使用できます。使用中のポートの数とタイプを監視し、構成に応じて割り当てとアドミッションの決定を行うことができます。
Since enforcing policies requires an understanding of the service being provided, proxies MUST only advertise the Diameter applications they support.
ポリシーを適用するには提供中のサービスを理解する必要があるため、プロキシは自身がサポートするDiameterアプリケーションだけを通知しなければなりません (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.
リダイレクトエージェントはメッセージをリレーせず、Diameterエージェントが直接通信するために必要な情報を含む応答のみを返すため、メッセージは変更されません。リダイレクトエージェントは応答メッセージを受信しないため、セッション状態を維持できません。
The example provided in Figure 3 depicts a request issued from the access device, NAS, for the user bob@example.com. The message is forwarded by the NAS to its relay, DRL, which does not have a routing entry in its Diameter routing table for example.com. The DRL has a default route configured to DRD, which is a redirect agent that returns a redirect notification to DRL, as well as the HMS' contact information. Upon receipt of the redirect notification, the DRL establishes a transport connection with the HMS, if one doesn't already exist, and forwards the request to it.
図3の例は、アクセスデバイスであるNASからユーザーbob@example.comに対して発行されたリクエストを示しています。メッセージはNASによってリレーDRLに転送されます。DRLは、example.comのDiameterルーティングテーブルにルーティングエントリがありません。 DRLには、DRDに構成されたデフォルトルートがあります。これは、DRLにリダイレクト通知を返すリダイレクトエージェントであり、HMSの連絡先情報です。リダイレクト通知を受信すると、DRLはHMSとのトランスポート接続を確立し（存在しない場合）、要求を転送します。
+------+
| |
| DRD |
| |
+------+
^ |
2. Request | | 3. Redirection
| | Notification
| v
+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 4. Request | |
| NAS | | DRL | | HMS |
| | 6. Answer | | 5. Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 3: Redirecting a Diameter Message
図3：Diameterメッセージのリダイレクト
Since redirect agents do not perform any application-level processing, they provide relaying services for all Diameter applications; therefore, they MUST advertise the Relay Application ID.
リダイレクトエージェントはアプリケーションレベルの処理を行わないため、すべてのDiameterアプリケーションにリレーサービスを提供します。したがって、Relay Application IDを通知しなければなりません (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; 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への変換
As noted in Section 2.2, Diameter provides transmission-level security for each connection using TLS/TCP and DTLS/SCTP. Therefore, each connection can be authenticated and can be replay and integrity protected.
セクション2.2で述べたように、DiameterはTLS/TCPおよびDTLS/SCTPを使用する各接続に伝送レベルのセキュリティを提供します。したがって、各接続を認証し、再生と整合性を保護できます。
In addition to authenticating each connection, the entire session MUST also be authorized. Before initiating a connection, a Diameter peer MUST check that its peers are authorized to act in their roles. For example, a Diameter peer may be authentic, but that does not mean that it is authorized to act as a Diameter server advertising a set of Diameter applications.
各接続を認証することに加え、セッション全体も認可しなければなりません (MUST)。接続を開始する前に、Diameterピアは、相手のピアがそれぞれの役割で動作することを認可されているか確認しなければなりません (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.9, a relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer from which the request was received.
セクション6.1.9で述べたように、リレーエージェントまたはプロキシエージェントは、転送するすべての要求に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 any contractual relationship between the server and the previous hop. A DIAMETER_AUTHORIZATION_REJECTED error message (see Section 7.1.5) is sent if the route traversed by the request is unacceptable.
ホームDiameterサーバーは、セッションを認可する前にRoute-Record AVPを検査し、要求が通過した経路を受け入れられることを確認しなければなりません (MUST)。たとえば、ホームrealmの管理者は、信頼していないrealmを経由した要求を受け入れたくない場合があります。要求を認可することにより、ホーム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.
ホームrealmは、各アカウンティング要求メッセージがセッションを認可したDiameter応答に対応しているか確認することもできます。対応する認可応答がないアカウンティング要求は、要求されたサービスと提供されたサービスとの差異を示すアカウンティング要求と同様に、さらに精査すべきです (SHOULD)。
Forwarding of an authorization response is considered evidence of a willingness to take on financial risk relative to the session. A local realm may wish to limit this exposure, for example, by establishing credit limits for intermediate realms and refusing to accept responses that would violate those limits. By issuing an accounting request corresponding to the authorization response, the local realm implicitly indicates its agreement to provide the service indicated in the authorization response. If the service cannot be provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error message MUST be sent within the accounting request; a Diameter client receiving an authorization response for a service that it cannot perform MUST NOT substitute an alternate service and then send accounting requests for the alternate service instead.
認可応答の転送は、そのセッションに関する財務リスクを引き受ける意思の証拠とみなされます。ローカルrealmは、たとえば中間realmに信用限度を設定し、その限度に違反する応答の受け入れを拒否することで、このリスク負担を制限したい場合があります。認可応答に対応するアカウンティング要求を発行することにより、ローカルrealmは、その認可応答が示すサービスを提供することへの同意を暗黙に示します。ローカルrealmがサービスを提供できない場合、アカウンティング要求内で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.
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 and the padded AVPs. Thus, the Message Length field is always a multiple of 4.
メッセージ長フィールドは3オクテットで、ヘッダーフィールドとパディングされたAVPを含むDiameterメッセージの長さを示します。したがって、メッセージ長フィールドは常に4の倍数になります。
Command Flags
コマンドフラグ
The Command Flags field is eight bits. The following bits are assigned:
コマンドフラグフィールドは8ビットです。以下のビットが割り当てられています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R P E T r r r r|
+-+-+-+-+-+-+-+-+
R(equest)
リクエスト）
If set, the message is a request. If cleared, the message is an answer.
設定されている場合、メッセージは要求です。クリアされている場合、メッセージは回答です。
P(roxiable)
P（roxiable）
If set, the message MAY be proxied, relayed, or redirected. If cleared, the message MUST be locally processed.
設定されている場合、メッセージをプロキシ、リレー、またはリダイレクトしてもよい (MAY)。クリアされている場合、メッセージをローカルで処理しなければなりません (MUST)。
E(rror)
エラー）
If set, the message contains a protocol error, and the message will not conform to the CCF described for this command. Messages with the 'E' bit set are commonly referred to as error messages. This bit MUST NOT be set in request messages (see Section 7.2).
このビットが設定されている場合、メッセージはプロトコルエラーを含み、このコマンドについて記述されたCCFには準拠しません。「E」ビットを設定したメッセージは、一般にエラーメッセージと呼ばれます。このビットを要求メッセージで設定してはなりません (MUST NOT)（セクション7.2を参照）。
T(Potentially retransmitted message)
T（潜在的に再送信されたメッセージ）
This flag is set after a link failover procedure, to aid the removal of duplicate requests. It is set when resending requests not yet acknowledged, as an indication of a possible duplicate due to a link failure. This bit MUST be cleared when sending a request for the first time; otherwise, the sender MUST set this flag. Diameter agents only need to be concerned about the number of requests they send based on a single received request; retransmissions by other entities need not be tracked. Diameter agents that receive a request with the T flag set, MUST keep the T flag set in the forwarded request. This flag MUST NOT be set if an error answer message (e.g., a protocol error) has been received for the earlier message. It can be set only in cases where no answer has been received from the server for a request, and the request has been sent again. This flag MUST NOT be set in answer messages.
このフラグは、リンクのフェイルオーバー手順後に、重複要求の除去を支援するため設定します。まだ確認応答されていない要求を再送信する際、リンク障害により重複した可能性があることを示すために設定します。要求を初めて送信する場合、このビットをクリアしなければなりません (MUST)。それ以外の場合、送信側はこのフラグを設定しなければなりません (MUST)。Diameterエージェントが考慮する必要があるのは、受信した1つの要求に基づいて自身が送信する要求の数だけであり、他のエンティティによる再送信を追跡する必要はありません。T flagを設定した要求を受信したDiameterエージェントは、転送する要求でもT flagを設定したままにしなければなりません (MUST)。以前のメッセージに対するエラー応答メッセージ（プロトコルエラーなど）を受信済みの場合、このフラグを設定してはなりません (MUST NOT)。このフラグを設定できるのは、要求に対する応答をサーバーから受信しておらず、その要求を再送信した場合だけです。応答メッセージでこのフラグを設定してはなりません (MUST NOT)。
r(eserved)
予約済み）
These flag bits are reserved for future use; they MUST be set to zero and ignored by the receiver.
これらのフラグビットは将来の使用のために予約されています。送信側はこれらを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 3.1). Command Code values 16,777,214 and 16,777,215 (hexadecimal values FFFFFE-FFFFFF) are reserved for experimental use (see Section 11.2).
コマンドコードフィールドは3オクテットであり、メッセージに関連付けられたコマンドを伝達するために使用されます。 24ビットのアドレス空間はIANAによって管理されます（セクション3.1を参照）。コマンドコード値16,777,214および16,777,215（16進値FFFFFE-FFFFFF）は実験用に予約されています（セクション11.2を参照）。
Application-ID
アプリケーションID
Application-ID is four octets and is used to identify for which application the message is applicable. The application can be an authentication application, an accounting application, or a vendor-specific application.
Application-IDは4オクテットであり、メッセージが適用されるアプリケーションを識別するために使用されます。アプリケーションは、認証アプリケーション、会計アプリケーション、またはベンダー固有のアプリケーションです。
The value of the Application-ID field in the header MUST be the same as any relevant Application-Id AVPs contained in the message.
ヘッダー内のApplication-IDフィールドの値は、メッセージに含まれる関連するすべてのApplication-Id AVPと同じでなければなりません (MUST)。
Hop-by-Hop Identifier
ホップバイホップ識別子
The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) that aids in matching requests and replies. The sender MUST ensure that the Hop-by-Hop Identifier in a request is unique on a given connection at any given time, and it MAY attempt to ensure that the number is unique across reboots. The sender of an answer message MUST ensure that the Hop-by-Hop Identifier field contains the same value that was found in the corresponding request. The Hop-by-Hop Identifier is normally a monotonically increasing number, whose start value was randomly generated. An answer message that is received with an unknown Hop-by-Hop Identifier MUST be discarded.
Hop-by-Hop Identifierは、要求と応答の対応付けに役立つ、ネットワークバイト順の符号なし32ビット整数フィールドです。送信側は、要求内のHop-by-Hop Identifierが、ある時点でその接続上において一意であることを保証しなければならず (MUST)、再起動をまたいでもその番号が一意となるよう試みてもよい (MAY)。応答メッセージの送信側は、Hop-by-Hop Identifierフィールドに対応する要求で得た値と同じ値が入るよう保証しなければなりません (MUST)。Hop-by-Hop Identifierは通常、開始値をランダムに生成した単調増加値です。未知のHop-by-Hop Identifierを持つ応答メッセージを受信した場合、そのメッセージを破棄しなければなりません (MUST)。
End-to-End Identifier
エンドツーエンド識別子
The End-to-End Identifier is an unsigned 32-bit integer field (in network byte order) that is used to detect duplicate messages. Upon reboot, implementations MAY set the high order 12 bits to contain the low order 12 bits of current time, and the low order 20 bits to a random value. Senders of request messages MUST insert a unique identifier on each message. The identifier MUST remain locally unique for a period of at least 4 minutes, even across reboots. The originator of an answer message MUST ensure that the End-to-End Identifier field contains the same value that was found in the corresponding request. The End-to-End Identifier MUST NOT be modified by Diameter agents of any kind. The combination of the Origin-Host AVP (Section 6.3) and this field is used to detect duplicates. Duplicate requests SHOULD cause the same answer to be transmitted (modulo the Hop-by-Hop Identifier field and any routing AVPs that may be present), and they MUST NOT affect any state that was set when the original request was processed. Duplicate answer messages that are to be locally consumed (see Section 6.2) SHOULD be silently discarded.
End-to-End Identifierは、重複メッセージの検出に使用する、ネットワークバイト順の符号なし32ビット整数フィールドです。再起動時、実装は上位12ビットを現在時刻の下位12ビットに、下位20ビットをランダム値に設定してもよい (MAY)。要求メッセージの送信側は、各メッセージへ一意の識別子を挿入しなければなりません (MUST)。この識別子は、再起動をまたいだ場合も、少なくとも4分間はローカルで一意のままでなければなりません (MUST)。応答メッセージの生成元は、End-to-End Identifierフィールドに、対応する要求で得た値と同じ値が入るよう保証しなければなりません (MUST)。どの種類のDiameterエージェントもEnd-to-End Identifierを変更してはなりません (MUST NOT)。Origin-Host AVP（セクション6.3）とこのフィールドの組み合わせを重複検出に使用します。重複要求に対しては同じ応答を送信すべきであり (SHOULD)（ただし、Hop-by-Hop Identifierフィールドおよび存在する可能性があるルーティングAVPを除きます）、元の要求の処理時に設定した状態へ影響を与えてはなりません (MUST NOT)。ローカルで消費する重複応答メッセージ（セクション6.2を参照）は、通知せずに破棄すべきです (SHOULD)。
AVPs
AVP
AVPs are a method of encapsulating information relevant to the Diameter message. See Section 4 for more information on AVPs.
AVPは、Diameterメッセージに関連する情報をカプセル化する方法です。 AVPの詳細については、セクション4を参照してください。
Each command Request/Answer pair is assigned a Command Code, and the sub-type (i.e., request or answer) is identified via the 'R' bit in the Command Flags field of the Diameter header.
各コマンド要求/応答ペアにはコマンドコードが割り当てられ、サブタイプ（要求または応答）は、Diameterヘッダーのコマンドフラグフィールドの「R」ビットを介して識別されます。
Every Diameter message MUST contain a Command Code in its header's Command Code field, which is used to determine the action that is to be taken for a particular message. The following Command Codes are defined in the Diameter base protocol:
すべてのDiameterメッセージは、ヘッダーのCommand CodeフィールドにCommand Codeを含まなければなりません (MUST)。この値は、個々のメッセージに対して実行する処理の決定に使用します。Diameter基本プロトコルでは、次のCommand Codeを定義します：
Section
Command Name Abbrev. Code Reference
--------------------------------------------------------
Abort-Session-Request ASR 274 8.5.1
Abort-Session-Answer ASA 274 8.5.2
Accounting-Request ACR 271 9.7.1
Accounting-Answer ACA 271 9.7.2
Capabilities-Exchange- CER 257 5.3.1
Request
Capabilities-Exchange- CEA 257 5.3.2
Answer
Device-Watchdog-Request DWR 280 5.5.1
Device-Watchdog-Answer DWA 280 5.5.2
Disconnect-Peer-Request DPR 282 5.4.1
Disconnect-Peer-Answer DPA 282 5.4.2
Re-Auth-Request RAR 258 8.3.1
Re-Auth-Answer RAA 258 8.3.2
Session-Termination- STR 275 8.4.1
Request
Session-Termination- STA 275 8.4.2
Answer
Every Command Code defined MUST include a corresponding Command Code Format (CCF) specification, which is used to define the AVPs that MUST or MAY be present when sending the message. The following ABNF specifies the CCF used in the definition:
定義するすべてのCommand Codeは、対応するCommand Code Format（CCF）仕様を含まなければなりません (MUST)。この仕様は、メッセージ送信時に存在しなければならない (MUST)、または存在してもよい (MAY) AVPを定義するために使用します。次のABNFは、定義で使用するCCFを規定します：
command-def = "<" command-name ">" "::=" diameter-message
command-name = diameter-name
diameter-name = ALPHA *(ALPHA / DIGIT / "-")
diameter-message = header *fixed *required *optional
header = "<Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
application-id = 1*DIGIT
command-id = 1*DIGIT
; The Command Code assigned to the command.
r-bit = ", REQ"
; If present, the 'R' bit in the Command
; Flags is set, indicating that the message
; is a request as opposed to an answer.
p-bit = ", PXY"
; If present, the 'P' bit in the Command
; Flags is set, indicating that the message
; is proxiable.
e-bit = ", ERR"
; If present, the 'E' bit in the Command
; Flags is set, indicating that the answer
; message contains a Result-Code AVP in
; the "protocol error" class.
fixed = [qual] "<" avp-spec ">"
; Defines the fixed position of an AVP.
required = [qual] "{" avp-spec "}"
; The AVP MUST be present and can appear
; anywhere in the message.
optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name that is included
; in a fixed or required rule. The AVP can
; appear anywhere in the message.
;
; NOTE: "[" and "]" have a slightly different
; meaning than in ABNF. These braces
; cannot be used to express optional fixed rules
; (such as an optional ICV at the end). To do
; this, the convention is '0*1fixed'.
qual = [min] "*" [max]
; See ABNF conventions, RFC 5234, Section 4.
; The absence of any qualifier depends on
; whether it precedes a fixed, required, or
; optional rule. If a fixed or required rule has
; no qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be
; present. If an optional rule has a qualifier,
; then the value of min MUST be 0 if present.
min = 1*DIGIT
; The minimum number of times the element may
; be present. If absent, the default value is 0
; for fixed and optional rules and 1 for
; required rules. The value MUST be at least 1
; for required rules.
max = 1*DIGIT
; The maximum number of times the element may
; be present. If absent, the default value is
; infinity. A value of 0 implies the AVP MUST
; NOT be present.
avp-spec = diameter-name
; The avp-spec has to be an AVP Name, defined
; in the base or extended Diameter
; specifications.
avp-name = avp-spec / "AVP"
; The string "AVP" stands for *any* arbitrary AVP
; Name, not otherwise listed in that Command Code
; definition. The inclusion of this string
; is recommended for all CCFs to allow for
; extensibility.
The following is a definition of a fictitious Command Code:
以下は、架空のコマンドコードの定義です。
Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
{ User-Name }
1* { Origin-Host }
* [ AVP ]
Diameter command names typically includes one or more English words followed by the verb "Request" or "Answer". Each English word is delimited by a hyphen. A three-letter acronym for both the request and answer is also normally provided.
Diameterコマンド名には、通常、1つ以上の英語の単語の後に「Request」または「Answer」という動詞が続きます。各英単語はハイフンで区切られています。通常、要求と応答の両方の3文字の頭字語も提供されます。
An example is a message set used to terminate a session. The command name is Session-Terminate-Request and Session-Terminate-Answer, while the acronyms are STR and STA, respectively.
たとえば、セッションを終了するために使用されるメッセージセットです。コマンド名はSession-Terminate-RequestおよびSession-Terminate-Answerで、頭字語はそれぞれSTRおよびSTAです。
Both the request and the answer for a given command share the same Command Code. The request is identified by the R(equest) bit in the Diameter header set to one (1), to ask that a particular action be performed, such as authorizing a user or terminating a session. Once the receiver has completed the request, it issues the corresponding answer, which includes a result code that communicates one of the following:
特定のコマンドの要求と応答の両方が同じコマンドコードを共有します。リクエストは、DiameterヘッダーのR（equest）ビットが1に設定されていることで識別され、ユーザーの承認やセッションの終了など、特定のアクションの実行を要求します。受信側が要求を完了すると、対応する応答が発行されます。これには、次のいずれかを伝える結果コードが含まれます。
o The request was successful
o リクエストは成功しました
o The request failed
o リクエストは失敗しました
o An additional request has to be sent to provide information the peer requires prior to returning a successful or failed answer.
o 成功または失敗した回答を返す前に、ピアが必要とする情報を提供するために追加のリクエストを送信する必要があります。
o The receiver could not process the request, but provides information about a Diameter peer that is able to satisfy the request, known as redirect.
o 受信側は要求を処理できませんでしたが、リダイレクトと呼ばれる、要求を満たすことができるDiameterピアに関する情報を提供します。
Additional information, encoded within AVPs, may also be included in answer messages.
AVP内でエンコードされた追加情報も、応答メッセージに含まれる場合があります。
Diameter AVPs carry specific authentication, accounting, authorization, and routing information as well as configuration details for the request and reply.
Diameter AVPは、特定の認証、アカウンティング、許可、ルーティング情報、および要求と応答の構成の詳細を伝達します。
Each AVP of type OctetString MUST be padded to align on a 32-bit boundary, while other AVP types align naturally. A number of zero-valued bytes are added to the end of the AVP Data field until a word boundary is reached. The length of the padding is not reflected in the AVP Length field.
OctetString型の各AVPは、32ビット境界に整列するようパディングしなければなりません (MUST)。他のAVP型は自然に整列します。ワード境界に達するまで、値が0のバイトをAVP Dataフィールドの末尾へ追加します。パディングの長さは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
AVPコード
The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for reuse of RADIUS attributes, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA (see Section 11.1.1).
AVPコードとVendor-Idフィールドを組み合わせて、属性を一意に識別します。 AVP番号1〜255は、Vendor-Idフィールドを設定せずに、RADIUS属性の再利用のために予約されています。 Diameterには、AANAによって割り当てられたAVP番号256以上が使用されます（セクション11.1.1を参照）。
AVP Flags
AVPフラグ
The AVP Flags field informs the receiver how each attribute must be handled. New Diameter applications SHOULD NOT define additional AVP Flag bits. However, note that new Diameter applications MAY define additional bits within the AVP header, and an unrecognized bit SHOULD be considered an error. The sender of the AVP MUST set 'R' (reserved) bits to 0 and the receiver SHOULD ignore all 'R' (reserved) bits. The 'P' bit has been reserved for future usage of end-to-end security. At the time of writing, there are no end-to-end security mechanisms specified; therefore, the 'P' bit SHOULD be set to 0.
AVP Flagsフィールドは、各属性をどのように処理する必要があるかを受信側へ通知します。新しいDiameterアプリケーションは、AVP Flagのビットを追加定義すべきではありません (SHOULD NOT)。ただし、新しいDiameterアプリケーションはAVPヘッダー内に追加ビットを定義してもよく (MAY)、認識できないビットはエラーとみなすべきです (SHOULD)。AVPの送信側は「R」（reserved）ビットを0に設定しなければならず (MUST)、受信側はすべての「R」（reserved）ビットを無視すべきです (SHOULD)。「P」ビットは将来のエンドツーエンドセキュリティ用に予約されています。執筆時点ではエンドツーエンドセキュリティ機構が規定されていないため、「P」ビットを0に設定すべきです (SHOULD)。
The 'M' bit, known as the Mandatory bit, indicates whether the receiver of the AVP MUST parse and understand the semantics of the AVP including its content. The receiving entity MUST return an appropriate error message if it receives an AVP that has the M-bit set but does not understand it. An exception applies when the AVP is embedded within a Grouped AVP. See Section 4.4 for details. Diameter relay and redirect agents MUST NOT reject messages with unrecognized AVPs.
Mandatory bitと呼ばれる「M」ビットは、AVPの受信側が、その内容を含めてAVPのセマンティクスを解析し理解しなければならない (MUST) かどうかを示します。M-bitが設定されているものの理解できないAVPを受信した場合、受信エンティティは適切なエラーメッセージを返さなければなりません (MUST)。AVPがGrouped AVPに埋め込まれている場合には例外が適用されます。詳細についてはセクション4.4を参照してください。Diameterリレーエージェントおよびリダイレクトエージェントは、認識できないAVPを含むメッセージを拒否してはなりません (MUST NOT)。
The 'M' bit MUST be set according to the rules defined in the application specification that introduces or reuses this AVP. Within a given application, the M-bit setting for an AVP is defined either for all command types or for each command type.
「M」ビットは、このAVPを導入または再利用するアプリケーション仕様で定めた規則に従って設定しなければなりません (MUST)。あるアプリケーション内では、AVPのM-bit設定を、全コマンド型に対して一括で、またはコマンド型ごとに定義します。
AVPs with the 'M' bit cleared are informational only; a receiver that receives a message with such an AVP that is not supported, or whose value is not supported, MAY simply ignore the AVP.
「M」ビットがクリアされたAVPは、情報提供のみを目的としています。サポートされていないか、その値がサポートされていないAVPを持つメッセージを受信する受信者は、単にAVPを無視してもよい（MAY）。
The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set, the AVP Code belongs to the specific vendor code address space.
Vendor-Specificビットと呼ばれる「V」ビットは、オプションのVendor-IDフィールドがAVPヘッダーに存在するかどうかを示します。設定すると、AVPコードは特定のベンダーコードアドレス空間に属します。
AVP Length
AVPの長さ
The AVP Length field is three octets, and indicates the number of octets in this AVP including the AVP Code field, AVP Length field, AVP Flags field, Vendor-ID field (if present), and the AVP Data field. If a message is received with an invalid attribute length, the message MUST be rejected.
AVP長さフィールドは3オクテットであり、AVPコードフィールド、AVP長さフィールド、AVPフラグフィールド、ベンダーIDフィールド（存在する場合）、およびAVPデータフィールドを含む、このAVPのオクテット数を示します。無効な属性長でメッセージを受信した場合、メッセージは拒否されなければなりません（MUST）。
The AVP header contains one optional field. This field is only present if the respective bit-flag is enabled.
AVPヘッダーには、オプションのフィールドが1つ含まれています。このフィールドは、それぞれのビットフラグが有効な場合にのみ存在します。
Vendor-ID
ベンダーID
The Vendor-ID field is present if the 'V' bit is set in the AVP Flags field. The optional four-octet Vendor-ID field contains the IANA-assigned "SMI Network Management Private Enterprise Codes" [ENTERPRISE] value, encoded in network byte order. Any vendors or standardization organizations that are also treated like vendors in the IANA-managed "SMI Network Management Private Enterprise Codes" space wishing to implement a vendor-specific Diameter AVP MUST use their own Vendor-ID along with their privately managed AVP address space, guaranteeing that they will not collide with any other vendor's vendor-specific AVP(s) or with future IETF AVPs.
AVP Flagsフィールドで「V」ビットが設定されている場合、Vendor-IDフィールドが存在します。オプションの4オクテットのVendor-IDフィールドには、IANAが割り当てた「SMI Network Management Private Enterprise Codes」[ENTERPRISE]の値をネットワークバイト順で符号化して格納します。ベンダー固有のDiameter AVPを実装しようとするベンダー、またはIANA管理の「SMI Network Management Private Enterprise Codes」空間でベンダーと同様に扱われる標準化団体は、非公開で管理するAVPアドレス空間とともに自身のVendor-IDを使用し、他のベンダーのベンダー固有AVPや将来のIETF AVPと衝突しないことを保証しなければなりません (MUST)。
A Vendor-ID value of zero (0) corresponds to the IETF-adopted AVP values, as managed by IANA. Since the absence of the Vendor-ID field implies that the AVP in question is not vendor specific, implementations MUST NOT use the value of zero (0) for the Vendor-ID field.
ベンダーID値ゼロ（0）は、IANAが管理するIETF採用AVP値に対応します。 Vendor-IDフィールドがないことは、問題のAVPがベンダー固有ではないことを意味するため、実装はVendor-IDフィールドにゼロ（0）の値を使用してはなりません（MUST NOT）。
The Data field is zero or more octets and contains information specific to the Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the Data field MUST be one of the following base data types or a data type derived from the base data types. In the event that a new Basic AVP Data Format is needed, a new version of this RFC MUST be created.
Dataフィールドは0オクテット以上であり、Attribute固有の情報を格納します。Dataフィールドの形式と長さは、AVP CodeフィールドおよびAVP Lengthフィールドで決まります。Dataフィールドの形式は、次の基本データ型のいずれか、または基本データ型から派生したデータ型でなければなりません (MUST)。新しいBasic AVP Data Formatが必要になった場合、このRFCの新しい版を作成しなければなりません (MUST)。
OctetString
ByteString
The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP values of this type that are not a multiple of 4 octets in length are followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary.
データには、可変長の任意データが入ります。特記しない限り、AVP Lengthフィールドを8以上（「V」ビットが有効なら12以上）に設定しなければなりません (MUST)。長さが4オクテットの倍数でないこの型のAVP値の後には、後続AVPが存在する場合に32ビット境界から始まるよう、必要なパディングが続きます。
Integer32
Integer32
32-bit signed value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled).
ネットワークバイト順の32ビット符号付き値です。AVP Lengthフィールドを12（「V」ビットが有効な場合は16）に設定しなければなりません (MUST)。
Integer64
Integer64
64-bit signed value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled).
ネットワークバイト順の64ビット符号付き値です。AVP Lengthフィールドを16（「V」ビットが有効な場合は20）に設定しなければなりません (MUST)。
Unsigned32
署名なし32
32-bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled).
ネットワークバイト順の32ビット符号なし値です。AVP Lengthフィールドを12（「V」ビットが有効な場合は16）に設定しなければなりません (MUST)。
Unsigned64
Unsigned64
64-bit unsigned value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled).
ネットワークバイト順の64ビット符号なし値です。AVP Lengthフィールドを16（「V」ビットが有効な場合は20）に設定しなければなりません (MUST)。
Float32
Float32
This represents floating point values of single precision as described by [FLOATPOINT]. The 32-bit value is transmitted in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled).
[FLOATPOINT]で説明されている単精度浮動小数点値を表します。32ビット値はネットワークバイト順で送信します。AVP Lengthフィールドを12（「V」ビットが有効な場合は16）に設定しなければなりません (MUST)。
Float64
Float64
This represents floating point values of double precision as described by [FLOATPOINT]. The 64-bit value is transmitted in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled).
[FLOATPOINT]で説明されている倍精度浮動小数点値を表します。64ビット値はネットワークバイト順で送信します。AVP Lengthフィールドを16（「V」ビットが有効な場合は20）に設定しなければなりません (MUST)。
Grouped
グループ化
The Data field is specified as a sequence of AVPs. These AVPs are concatenated -- including their headers and padding -- in the order in which they are specified and the result encapsulated in the Data field. The AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the total length of all included AVPs, including their headers and padding. Thus, the AVP Length field of an AVP of type Grouped is always a multiple of 4.
データフィールドは、AVPのシーケンスとして指定されます。これらのAVPは、ヘッダーとパディングを含め、指定された順序で連結され、結果はデータフィールドにカプセル化されます。 AVP長さフィールドは、8（「V」ビットが有効な場合は12）に、ヘッダーとパディングを含む、含まれるすべてのAVPの全長を加えたものに設定されます。したがって、GroupedタイプのAVPのAVP Lengthフィールドは常に4の倍数です。
In addition to using the Basic AVP Data Formats, applications may define data formats derived from the Basic AVP Data Formats. An application that defines new Derived AVP Data Formats MUST include them in a section titled "Derived AVP Data Formats", using the same format as the definitions below. Each new definition MUST be either defined or listed with a reference to the RFC that defines the format.
アプリケーションはBasic AVP Data Formatを使用するだけでなく、そこから派生したデータ形式も定義できます。新しいDerived AVP Data Formatを定義するアプリケーションは、以下の定義と同じ書式を使用し、「Derived AVP Data Formats」という表題の節にその形式を含めなければなりません (MUST)。新しい定義はそれぞれ、実際の定義を記載するか、その形式を定義するRFCへの参照とともに列挙しなければなりません (MUST)。
The following are commonly used Derived AVP Data Formats.
以下は、一般的に使用される派生AVPデータ形式です。
Address
住所
The Address format is derived from the OctetString Basic AVP Format. It is a discriminated union representing, for example, a 32-bit (IPv4) [RFC0791] or 128-bit (IPv6) [RFC4291] address, most significant octet first. The first two octets of the Address AVP represent the AddressType, which contains an Address Family, defined in [IANAADFAM]. The AddressType is used to discriminate the content and format of the remaining octets.
Time
時間
The Time format is derived from the OctetString Basic AVP Format. The string MUST contain four octets, in the same format as the first four bytes are in the NTP timestamp format. The NTP timestamp format is defined in Section 3 of [RFC5905].
Time形式はOctetString Basic AVP Formatから派生しています。この文字列は、NTPタイムスタンプ形式の先頭4バイトと同じ形式で4オクテットを含まなければなりません (MUST)。NTPタイムスタンプ形式は[RFC5905]のセクション3で定義されています。
This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC).
これは、協定世界時（UTC）に関して、1900年1月1日0時からの秒数を表します。
On 6h 28m 16s UTC, 7 February 2036, the time value will overflow. Simple Network Time Protocol (SNTP) [RFC5905] describes a procedure to extend the time to 2104. This procedure MUST be supported by all Diameter nodes.
2036年2月7日6時28分16秒（UTC）にTime値はオーバーフローします。Simple Network Time Protocol（SNTP）[RFC5905]は、時刻を2104年まで拡張する手順を説明しています。すべてのDiameterノードはこの手順をサポートしなければなりません (MUST)。
UTF8String
UTF8String
The UTF8String format is derived from the OctetString Basic AVP Format. This is a human-readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an OctetString using the UTF-8 transformation format [RFC3629].
UTF8String形式は、OctetString Basic AVP Formatから派生しています。これは、ISO/IEC IS 10646-1文字セットを使用して表される人間が読める文字列であり、UTF-8変換形式[RFC3629]を使用してOctetStringとしてエンコードされます。
Since additional code points are added by amendments to the 10646 standard from time to time, implementations MUST be prepared to encounter any code point from 0x00000001 to 0x7fffffff. Byte sequences that do not correspond to the valid encoding of a code point into UTF-8 charset or are outside this range are prohibited.
10646規格の改訂によりコードポイントが随時追加されるため、実装は0x00000001から0x7fffffffまでの任意のコードポイントを処理できるよう準備しなければなりません (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)。
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 a UTF8String in octets may be different from the number of characters encoded.
UTF-8では、単一の文字/コードポイントを表すために複数のバイトが必要になる場合があります。したがって、オクテット単位のUTF8Stringの長さは、エンコードされた文字数とは異なる場合があります。
Note that the AVP Length field of an UTF8String is measured in octets not characters.
UTF8StringのAVP長さフィールドは、文字ではなくオクテットで測定されることに注意してください。
DiameterIdentity
DiameterIdentity
The DiameterIdentity format is derived from the OctetString Basic AVP Format.
DiameterIdentity形式は、OctetString Basic AVP Formatから派生しています。
DiameterIdentity = FQDN/Realm
The DiameterIdentity value is used to uniquely identify either:
DiameterIdentity値は、次のいずれかを一意に識別するために使用されます。
* A Diameter node for purposes of duplicate connection and routing loop detection.
* 重複した接続とルーティングループの検出を目的としたDiameterノード。
* A Realm to determine whether messages can be satisfied locally or whether they must be routed or redirected.
* メッセージをローカルで満たすことができるかどうか、またはメッセージをルーティングまたはリダイレクトする必要があるかどうかを決定するレルム。
When a DiameterIdentity value is used to identify a Diameter node, the contents of the string MUST be the Fully Qualified Domain Name (FQDN) of the Diameter node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter node can be identified by several FQDNs, a single FQDN should be picked at startup and used as the only DiameterIdentity for that node, whatever the connection on which it is sent. In this document, note that DiameterIdentity is in ASCII form in order to be compatible with existing DNS infrastructure. See Appendix D for interactions between the Diameter protocol and Internationalized Domain Names (IDNs).
Diameterノードの識別にDiameterIdentity値を使用する場合、その文字列の内容はDiameterノードのFully Qualified Domain Name（FQDN）でなければなりません (MUST)。同じホスト上で複数のDiameterノードを実行する場合、各Diameterノードに一意のDiameterIdentityを割り当てなければなりません (MUST)。Diameterノードを複数のFQDNで識別できる場合、起動時に1つのFQDNを選び、送信にどの接続を使うかにかかわらず、そのノード唯一のDiameterIdentityとして使用するのが望まれます。既存のDNSインフラストラクチャとの互換性を確保するため、本文書のDiameterIdentityはASCII形式であることに注意してください。DiameterプロトコルとInternationalized Domain Names（IDN）の相互作用については、付録Dを参照してください。
DiameterURI
ぢ編めてるり
The DiameterURI MUST follow the Uniform Resource Identifiers (RFC 3986) syntax [RFC3986] rules specified below:
DiameterURIは、以下に規定するUniform Resource Identifiers（RFC 3986）の構文規則[RFC3986]に従わなければなりません (MUST)：
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
; No transport security
;輸送セキュリティなし
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transport security used
;使用されるトランスポートセキュリティ
FQDN = < Fully Qualified Domain Name >
port = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections.
; If absent, the default Diameter port
; (3868) is assumed if no transport
; security is used and port 5658 when
; transport security (TLS/TCP and DTLS/SCTP)
; is used.
transport = ";transport=" transport-protocol
; One of the transports used to listen
; for incoming connections. If absent,
; the default protocol is assumed to be TCP.
; UDP MUST NOT be used when the aaa-protocol
; field is set to diameter.
transport-protocol = ( "tcp" / "sctp" / "udp" )
protocol = ";protocol=" aaa-protocol
; If absent, the default AAA protocol ; is Diameter.
;存在しない場合、デフォルトのAAAプロトコル。直径です。
aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
The following are examples of valid Diameter host identities:
次に、有効なDiameterホストIDの例を示します。
aaa://host.example.com;transport=tcp
aaa://host.example.com:6666;transport=tcp
aaa://host.example.com;protocol=diameter
aaa://host.example.com:6666;protocol=diameter
aaa://host.example.com:6666;transport=tcp;protocol=diameter
aaa://host.example.com:1813;transport=udp;protocol=radius
Enumerated
列挙
The Enumerated format is derived from the Integer32 Basic AVP Format. The definition contains a list of valid values and their interpretation and is described in the Diameter application introducing the AVP.
列挙型フォーマットは、Integer32 Basic AVP Formatから派生しています。定義には有効な値とその解釈のリストが含まれ、AVPを導入するDiameterアプリケーションで説明されています。
IPFilterRule
IPFilterRule
The IPFilterRule format is derived from the OctetString Basic AVP Format and uses the ASCII charset. The rule syntax is a modified subset of ipfw(8) from FreeBSD. Packets may be filtered based on the following information that is associated with it:
IPFilterRule形式はOctetString Basic AVP Formatから派生し、ASCII文字セットを使用します。ルールの構文は、FreeBSDのipfw（8）の修正サブセットです。パケットは、それに関連付けられている次の情報に基づいてフィルタリングできます。
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types
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.
<address/mask>は次のように指定できます。ipnoドット付きクワッド形式または正規のIPv6形式のIPv4またはIPv6番号。この正確なIP番号のみがルールに一致します。
ipno/bits An IP number as above with a mask width of the form 192.0.2.10/24. In this case, all IP numbers from 192.0.2.0 to 192.0.2.255 will match. The bit width MUST be valid for the IP version, and the IP number MUST NOT have bits set beyond the mask. For a match to occur, the same IP version must be present in the packet that was used in describing the IP address. To test for a particular IP version, the bits part can be set to zero. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. For IPv4, a typical first rule is often "deny in ip! assigned".
ipno/bits 192.0.2.10/24のような形式のマスク幅を伴う、上記のIP番号です。この例では、192.0.2.0から192.0.2.255までのすべてのIP番号が一致します。ビット幅はIPバージョンに対して有効でなければならず (MUST)、IP番号ではマスクの範囲を超えるビットを設定してはなりません (MUST NOT)。一致するには、IPアドレスの記述に使用したものと同じIPバージョンがパケットに存在する必要があります。特定のIPバージョンを検査するには、bits部分を0に設定できます。キーワード「any」は0.0.0.0/0またはIPv6での同等値です。キーワード「assigned」は、端末に割り当てられた1つまたは一組のアドレスです。IPv4では、典型的な先頭規則として「deny in ip! assigned」がよく使われます。
The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers.
アドレスの前にnot修飾子（！）を付けることで一致の意味を逆にでき、代わりに他のすべてのアドレスが一致します。これはポート番号の選択には影響しません。
With the TCP, UDP, and SCTP protocols, optional ports may be specified as:
TCP、UDP、およびSCTPプロトコルでは、オプションのポートを次のように指定できます。
{port/port-port}[,ports[,...]]
The '-' notation specifies a range of ports (including boundaries).
「-」表記は、ポートの範囲（境界を含む）を指定します。
Fragmented packets that have a non-zero offset (i.e., not the first fragment) will never match a rule that has one or more port specifications. See the frag option for details on matching fragmented packets.
ゼロ以外のオフセット（つまり、最初のフラグメントではない）を持つ断片化されたパケットは、1つ以上のポート指定を持つルールに一致することはありません。フラグメント化されたパケットの照合の詳細については、fragオプションを参照してください。
options: frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications.
オプション：fragパケットがフラグメントであり、これがデータグラムの最初のフラグメントでない場合に一致します。 fragは、tcpflagsまたはTCP/UDPポート指定と組み合わせて使用することはできません。
ipoptions spec Match if the IP header contains the comma-separated list of options specified in spec. The supported IP options are:
ipoptions spec IPヘッダーに、specで指定されたオプションのコンマ区切りリストが含まれている場合に一致します。サポートされているIPオプションは次のとおりです。
ssrr (strict source route), lsrr (loose source route), rr (record packet route), and ts (timestamp). The absence of a particular option may be denoted with a '!'.
ssrr（厳密なソースルート）、lsrr（ルーズソースルート）、rr（レコードパケットルート）、およびts（タイムスタンプ）。特定のオプションがないことは、「！」で示される場合があります。
tcpoptions spec Match if the TCP header contains the comma-separated list of options specified in spec. The supported TCP options are:
tcpoptions spec TCPヘッダーにspecで指定されたオプションのコンマ区切りリストが含まれている場合に一致します。サポートされているTCPオプションは次のとおりです。
mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp), and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'.
mss（最大セグメントサイズ）、ウィンドウ（tcpウィンドウアドバタイズ）、sack（選択的ack）、ts（rfc1323タイムスタンプ）、およびcc（rfc1644 t/tcp接続カウント）。特定のオプションがないことは、「！」で示される場合があります。
established TCP packets only. Match packets that have the RST or ACK bits set.
確立されたTCPパケットのみ。 RSTまたはACKビットが設定されているパケットを照合します。
setup TCP packets only. Match packets that have the SYN bit set but no ACK bit.
TCPパケットのみをセットアップします。 SYNビットが設定されているがACKビットがないパケットに一致します。
tcpflags spec TCP packets only. Match if the TCP header contains the comma-separated list of flags specified in spec. The supported TCP flags are:
tcpflags spec TCPパケットのみ。 TCPヘッダーに、specで指定されたフラグのコンマ区切りリストが含まれている場合に一致します。サポートされるTCPフラグは次のとおりです。
fin, syn, rst, psh, ack, and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets.
fin、syn、rst、psh、ack、urg。特定のフラグがないことは、 '！'で表すことができます。 tcpflags指定を含むルールは、ゼロ以外のオフセットを持つフラグメント化されたパケットと一致することはできません。フラグメント化されたパケットの照合の詳細については、fragオプションを参照してください。
icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17), and address mask reply (18).
icmptypesは、ICMPパケットのみをタイプします。 ICMPタイプがリストタイプにある場合に一致します。リストは、範囲の任意の組み合わせ、またはコンマで区切られた個々のタイプとして指定できます。以下の数値と記号値の両方を使用できます。サポートされるICMPタイプは、エコー応答（0）、宛先到達不能（3）、送信元抑制（4）、リダイレクト（5）、エコー要求（8）、ルーター通知（9）、ルーター要請（10）、期限-ライブ超過（11）、IPヘッダー不良（12）、タイムスタンプ要求（13）、タイムスタンプ応答（14）、情報要求（15）、情報応答（16）、アドレスマスク要求（17）、およびアドレスマスク応答（ 18）。
There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls.
アクセスデバイスが常に破棄しなければならない (MUST) パケットが1種類あります。それはフラグメントオフセットが1のIPフラグメントです。これは有効なパケットですが、ファイアウォールの回避を試みる以外に用途はありません。
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 Diameter protocol allows AVP values of type 'Grouped'. This implies that the Data field is actually a sequence of AVPs. It is possible to include an AVP with a Grouped type within a Grouped type, that is, to nest them. AVPs within an AVP of type Grouped have the same padding requirements as non-Grouped AVPs, as defined in Section 4.4.
Diameterプロトコルでは、「グループ化」タイプのAVP値を使用できます。これは、データフィールドが実際にはAVPのシーケンスであることを意味します。 Groupedタイプの中にAVPをGroupedタイプに含めることができます。つまり、それらをネストすることができます。セクション4.4で定義されているように、グループ化されたタイプのAVP内のAVPには、グループ化されていないAVPと同じパディング要件があります。
The AVP Code numbering space of all AVPs included in a Grouped AVP is the same as for non-Grouped AVPs. Receivers of a Grouped AVP that does not have the 'M' (mandatory) bit set and one or more of the encapsulated AVPs within the group has the 'M' (mandatory) bit set MAY simply be ignored if the Grouped AVP itself is unrecognized. The rule applies even if the encapsulated AVP with its 'M' (mandatory) bit set is further encapsulated within other sub-groups, i.e., other Grouped AVPs embedded within the Grouped AVP.
Grouped AVPに含まれるすべてのAVPのAVP Code番号空間は、GroupedでないAVPと同じです。「M」（mandatory）ビットが設定されていないGrouped AVPの内部で、1つ以上のAVPに「M」（mandatory）ビットが設定されていても、そのGrouped AVP自体を受信側が認識できなければ、Grouped AVP全体を単に無視してもよい (MAY)。この規則は、「M」（mandatory）ビットを設定した内部AVPが、他のサブグループ、すなわち外側のGrouped AVPに埋め込まれた別のGrouped AVP内へさらにカプセル化されている場合にも適用します。
Every Grouped AVP definition MUST include a corresponding grammar, using ABNF [RFC5234] (with modifications), as defined below.
すべてのGrouped AVP定義は、以下で定義する、ABNF [RFC5234]（一部変更あり）を用いた対応する文法を含まなければなりません (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
header = "<" "AVP-Header:" avpcode [vendor] ">"
avpcode = 1*DIGIT
; The AVP Code assigned to the Grouped AVP.
vendor = 1*DIGIT
; The Vendor-ID assigned to the Grouped AVP.
; If absent, the default value of zero is
; used.
The Example-AVP (AVP Code 999999) is of type Grouped and is used to clarify how Grouped AVP values work. The Grouped Data field has the following CCF grammar:
Example-AVP（AVPコード999999）はGroupedタイプであり、Grouped AVP値がどのように機能するかを明確にするために使用されます。 Grouped Dataフィールドには、次のCCF文法があります。
Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ]
An Example-AVP with Grouped Data follows.
グループ化されたデータを使用したAVPの例を次に示します。
The Origin-Host AVP (Section 6.3) is required. In this case:
Origin-Host AVP（セクション6.3）が必要です。この場合：
Origin-Host = "example.com".
One or more Session-Ids must follow. Here there are two:
1つ以上のセッションIDが続く必要があります。ここには2つあります。
Session-Id =
"grump.example.com:33041;23432;893;0AF3B81"
Session-Id =
"grump.example.com:33054;23561;2358;0AF3B82"
optional AVPs included are
含まれるオプションのAVPは
Recovery-Policy = <binary>
2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
Futuristic-Acct-Record = <binary>
fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
d3427475e49968f841
The data for the optional AVPs is represented in hexadecimal form since the format of these AVPs is not known at the time of definition of the Example-AVP group nor (likely) at the time when the example instance of this AVP is interpreted -- except by Diameter implementations that support the same set of AVPs. The encoding example illustrates how padding is used and how length fields are calculated. Also, note that AVPs may be present in the Grouped AVP value that the receiver cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record AVPs). The length of the Example-AVP is the sum of all the length of the member AVPs, including their padding, plus the Example-AVP header size.
オプションのAVPのデータは16進数形式で表されます。これは、これらのAVPの形式が、サンプルAVPグループの定義時には不明であるか、このAVPのサンプルインスタンスが解釈される時点では（おそらく）不明であるためです。同じAVPセットをサポートするDiameter実装によって。エンコードの例は、パディングの使用方法と長さフィールドの計算方法を示しています。また、AVPは、受信者が解釈できないグループ化されたAVP値に存在する可能性があることに注意してください（ここでは、Recover-PolicyおよびFuturistic-Acct-Record AVP）。 Example-AVPの長さは、メンバーAVPのパディングを含むすべての長さの合計に、Example-AVPヘッダーサイズを加えたものです。
This AVP would be encoded as follows:
このAVPは次のようにエンコードされます。
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
0 | Example AVP Header (AVP Code = 999999), Length = 496 |
+-------+-------+-------+-------+-------+-------+-------+-------+
8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
+-------+-------+-------+-------+-------+-------+-------+-------+
16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
+-------+-------+-------+-------+-------+-------+-------+-------+
24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
32 | (AVP Code = 263), Length = 49 | 'g' | 'r' | 'u' | 'm' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
72 | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
80 | Session-Id AVP Header (AVP Code = 263), Length = 50 |
+-------+-------+-------+-------+-------+-------+-------+-------+
88 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
120| '5' | '8' | ';' | '0' | 'A' | 'F' | '3' | 'B' |
+-------+-------+-------+-------+-------+-------+-------+-------+
128| '8' | '2' |Padding|Padding| Recovery-Policy Header (AVP |
+-------+-------+-------+-------+-------+-------+-------+-------+
136| Code = 8341), Length = 223 | 0x21 | 0x63 | 0xbc | 0x1d |
+-------+-------+-------+-------+-------+-------+-------+-------+
144| 0x0a | 0xd8 | 0x23 | 0x71 | 0xf6 | 0xbc | 0x09 | 0x48 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
352| 0x8c | 0x7f | 0x92 |Padding| Futuristic-Acct-Record Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
328|(AVP Code = 15930),Length = 137| 0xfe | 0x19 | 0xda | 0x58 |
+-------+-------+-------+-------+-------+-------+-------+-------+
336| 0x02 | 0xac | 0xd9 | 0x8b | 0x07 | 0xa5 | 0xb8 | 0xc6 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
488| 0xe4 | 0x99 | 0x68 | 0xf8 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, and possible flag values.
次の表は、基本プロトコルで定義されているDiameter AVP、それらのAVPコード値、タイプ、および可能なフラグ値について説明しています。
Due to space constraints, the short form DiamIdent is used to represent DiameterIdentity.
スペースの制約により、DiamIdentityを表すために短い形式のDiamIdentが使用されています。
+----------+
| AVP Flag |
| rules |
|----+-----|
AVP Section | |MUST |
Attribute Name Code Defined Data Type |MUST| NOT |
-----------------------------------------|----+-----|
Acct- 85 9.8.2 Unsigned32 | M | V |
Interim-Interval | | |
Accounting- 483 9.8.7 Enumerated | M | V |
Realtime-Required | | |
Acct- 50 9.8.5 UTF8String | M | V |
Multi-Session-Id | | |
Accounting- 485 9.8.3 Unsigned32 | M | V |
Record-Number | | |
Accounting- 480 9.8.1 Enumerated | M | V |
Record-Type | | |
Acct- 44 9.8.4 OctetString| M | V |
Session-Id | | |
Accounting- 287 9.8.6 Unsigned64 | M | V |
Sub-Session-Id | | |
Acct- 259 6.9 Unsigned32 | M | V |
Application-Id | | |
Auth- 258 6.8 Unsigned32 | M | V |
Application-Id | | |
Auth-Request- 274 8.7 Enumerated | M | V |
Type | | |
Authorization- 291 8.9 Unsigned32 | M | V |
Lifetime | | |
Auth-Grace- 276 8.10 Unsigned32 | M | V |
Period | | |
Auth-Session- 277 8.11 Enumerated | M | V |
State | | |
Re-Auth-Request- 285 8.12 Enumerated | M | V |
Type | | |
Class 25 8.20 OctetString| M | V |
Destination-Host 293 6.5 DiamIdent | M | V |
Destination- 283 6.6 DiamIdent | M | V |
Realm | | |
Disconnect-Cause 273 5.4.3 Enumerated | M | V |
Error-Message 281 7.3 UTF8String | | V,M |
Error-Reporting- 294 7.4 DiamIdent | | V,M |
Host | | |
Event-Timestamp 55 8.21 Time | M | V |
Experimental- 297 7.6 Grouped | M | V |
Result | | |
-----------------------------------------|----+-----|
+----------+
| AVP Flag |
| rules |
|----+-----|
AVP Section | |MUST |
Attribute Name Code Defined Data Type |MUST| NOT |
-----------------------------------------|----+-----|
Experimental- 298 7.7 Unsigned32 | M | V |
Result-Code | | |
Failed-AVP 279 7.5 Grouped | M | V |
Firmware- 267 5.3.4 Unsigned32 | | V,M |
Revision | | |
Host-IP-Address 257 5.3.5 Address | M | V |
Inband-Security | M | V |
-Id 299 6.10 Unsigned32 | | |
Multi-Round- 272 8.19 Unsigned32 | M | V |
Time-Out | | |
Origin-Host 264 6.3 DiamIdent | M | V |
Origin-Realm 296 6.4 DiamIdent | M | V |
Origin-State-Id 278 8.16 Unsigned32 | M | V |
Product-Name 269 5.3.7 UTF8String | | V,M |
Proxy-Host 280 6.7.3 DiamIdent | M | V |
Proxy-Info 284 6.7.2 Grouped | M | V |
Proxy-State 33 6.7.4 OctetString| M | V |
Redirect-Host 292 6.12 DiamURI | M | V |
Redirect-Host- 261 6.13 Enumerated | M | V |
Usage | | |
Redirect-Max- 262 6.14 Unsigned32 | M | V |
Cache-Time | | |
Result-Code 268 7.1 Unsigned32 | M | V |
Route-Record 282 6.7.1 DiamIdent | M | V |
Session-Id 263 8.8 UTF8String | M | V |
Session-Timeout 27 8.13 Unsigned32 | M | V |
Session-Binding 270 8.17 Unsigned32 | M | V |
Session-Server- 271 8.18 Enumerated | M | V |
Failover | | |
Supported- 265 5.3.6 Unsigned32 | M | V |
Vendor-Id | | |
Termination- 295 8.15 Enumerated | M | V |
Cause | | |
User-Name 1 8.14 UTF8String | M | V |
Vendor-Id 266 5.3.3 Unsigned32 | M | V |
Vendor-Specific- 260 6.11 Grouped | M | V |
Application-Id | | |
-----------------------------------------|----+-----|
This section describes how Diameter nodes establish connections and communicate with peers.
このセクションでは、Diameterノードがどのように接続を確立し、ピアと通信するかについて説明します。
Connections between diameter peers are established using their valid DiameterIdentity. A Diameter node initiating a connection to a peer MUST know the peer's DiameterIdentity. Methods for discovering a Diameter peer can be found in Section 5.2.
Diameterピア間の接続は、有効なDiameterIdentityを使用して確立します。ピアへの接続を開始するDiameterノードは、そのピアのDiameterIdentityを把握していなければなりません (MUST)。Diameterピアの発見方法についてはセクション5.2を参照してください。
Although a Diameter node may have many possible peers with which it is able to communicate, it may not be economical to have an established connection to all of them. At a minimum, a Diameter node SHOULD have an established connection with two peers per realm, known as the primary and secondary peers. Of course, a node MAY have additional connections, if it is deemed necessary. Typically, all messages for a realm are sent to the primary peer but, in the event that failover procedures are invoked, any pending requests are sent to the secondary peer. However, implementations are free to load balance requests between a set of peers.
Diameterノードには通信可能な候補ピアが多数存在し得ますが、そのすべてと接続を確立しておくことは経済的でない場合があります。Diameterノードは最低限、realmごとにprimary peerおよびsecondary peerと呼ばれる2つのピアとの接続を確立しておくべきです (SHOULD)。もちろん、必要と判断する場合、ノードは追加の接続を持ってもよい (MAY)。通常、あるrealm宛ての全メッセージをprimary peerへ送信しますが、フェイルオーバー手順を開始した場合、保留中の要求をsecondary peerへ送信します。ただし、実装は一組のピア間で自由に要求を負荷分散できます。
Note that a given peer MAY act as a primary for a given realm while acting as a secondary for another realm.
あるピアは、あるrealmにはprimaryとして動作しながら、別のrealmにはsecondaryとして動作してもよい (MAY) ことに注意してください。
When a peer is deemed suspect, which could occur for various reasons, including not receiving a DWA within an allotted time frame, no new requests should be forwarded to the peer, but failover procedures are invoked. When an active peer is moved to this mode, additional connections SHOULD be established to ensure that the necessary number of active connections exists.
割り当てられた時間内にDWAを受信しない場合など、さまざまな理由でピアを疑わしいと判断することがあります。この場合、そのピアへ新しい要求を転送せず、フェイルオーバー手順を開始します。アクティブなピアをこのモードへ移した場合、必要な数のアクティブな接続を確保するため、追加の接続を確立すべきです (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 shut down. The peer is moved to the closed state.
1. ピアに到達できなくなったため、トランスポート接続がシャットダウンされました。ピアがクローズ状態に移行しました。
2. Three watchdog messages are exchanged with accepted round-trip times, and the connection to the peer is considered stabilized.
2. 3つのウォッチドッグメッセージが受け入れられた往復時間で交換され、ピアへの接続は安定していると見なされます。
In the event the peer being removed is either the primary or secondary, an alternate peer SHOULD replace the deleted peer and assume the role of either primary or secondary.
削除されるピアがプライマリまたはセカンダリのいずれかである場合、代替ピアは削除されたピアを置き換え、プライマリまたはセカンダリのいずれかの役割を担う必要があります（SHOULD）。
Allowing for dynamic Diameter agent discovery makes possible simpler and more robust deployment of Diameter services. In order to promote interoperable implementations of Diameter peer discovery, the following mechanisms (manual configuration and DNS) are described. These are based on existing IETF standards. Both mechanisms MUST be supported by all Diameter implementations; either MAY be used.
Diameterエージェントの動的発見を可能にすることで、Diameterサービスをより簡単かつ堅牢に配備できます。相互運用可能なDiameterピア発見の実装を促すため、既存のIETF規格に基づく手動設定とDNSという機構を以下で説明します。すべてのDiameter実装は両方の機構をサポートしなければなりません (MUST)。どちらを使用してもよい (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 statically (manually) configured Diameter agent locations. These will be used if they exist and respond.
1. Diameterの実装は、静的（手動）に構成されたDiameterエージェントの場所のリストを調べます。これらは、存在して応答する場合に使用されます。
2. The Diameter implementation performs a NAPTR query for a server in a particular realm. The Diameter implementation has to know, in advance, in which realm to look for a Diameter agent. This could be deduced, for example, from the 'realm' in an NAI on which a Diameter implementation needed to perform a Diameter operation.
2. Diameter実装は、特定のレルムのサーバーに対してNAPTRクエリを実行します。 Diameterの実装では、Diameterエージェントを探すレルムを事前に知っておく必要があります。これは、たとえば、Diameter実装がDiameter操作を実行するために必要なNAIの「レルム」から推定できます。
The NAPTR usage in Diameter follows the S-NAPTR DDDS application [RFC3958] in which the SERVICE field includes tags for the desired application and supported application protocol. The application service tag for a Diameter application is 'aaa' and the supported application protocol tags are 'diameter.tcp', 'diameter.sctp', 'diameter.dtls', or 'diameter.tls.tcp' [RFC6408].
The client can follow the resolution process defined by the S-NAPTR DDDS [RFC3958] application to find a matching SRV, A, or AAAA record of a suitable peer. The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. An example can be found in Appendix B.
クライアントは、S-NAPTR DDDS [RFC3958]アプリケーションで定義された解決プロセスに従って、適切なピアの一致するSRV、A、またはAAAAレコードを見つけることができます。 NAPTR置換フィールドのドメインサフィックスは、元のクエリのドメインと一致する必要があります（SHOULD）。例は付録Bにあります。
3. If no NAPTR records are found, the requester directly queries for one of the following SRV records: for Diameter over TCP, use "_diameter._tcp.realm"; for Diameter over TLS, use "_diameters._tcp.realm"; for Diameter over SCTP, use "_diameter._sctp.realm"; for Diameter over DTLS, use "_diameters._sctp.realm". If SRV records are found, then the requester can perform address record query (A RR's and/or AAAA RR's) for the target hostname specified in the SRV records following the rules given in [RFC2782]. If no SRV records are found, the requester gives up.
3. NAPTRレコードが見つからない場合、リクエスターは次のSRVレコードのいずれかを直接照会します。Diameterover TCPの場合は、「_ diameter._tcp.realm」を使用します。 Diameter over TLSの場合、 "_ diameters._tcp.realm"を使用します。 Diameter over SCTPの場合は、「_ diameter._sctp.realm」を使用します。 Diameter over DTLSの場合は、「_ diameters._sctp.realm」を使用します。 SRVレコードが見つかった場合、リクエスタは、[RFC2782]で規定されているルールに従って、SRVレコードで指定されたターゲットホスト名に対してアドレスレコードクエリ（A RRおよび/またはAAAA RR）を実行できます。 SRVレコードが見つからない場合、要求者はあきらめます。
If the server is using a site certificate, the domain name in the NAPTR query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS/TCP and DTLS/SCTP or Internet Key Exchange Protocol (IKE) exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate whether this was the desired behavior or the result of an attack.
サーバーがサイト証明書を使用する場合、NAPTR問い合わせ内のドメイン名とreplacementフィールド内のドメイン名は、いずれもTLS/TCP、DTLS/SCTP、またはInternet Key Exchange Protocol（IKE）の交換でサーバーが提示したサイト証明書に照らして有効でなければなりません (MUST)。同様に、SRV問い合わせ内のドメイン名とSRVレコードのtarget内のドメイン名も、いずれも同じサイト証明書に照らして有効でなければなりません (MUST)。そうでなければ、攻撃者がDNSレコードを変更して別ドメインのreplacement値を含めることができ、クライアントはそれが意図した動作なのか攻撃の結果なのかを検証できません。
Also, the Diameter peer MUST check to make sure that the discovered peers are authorized to act in its role. Authentication via IKE or TLS/TCP and DTLS/SCTP, or validation of DNS RRs via DNSSEC is not sufficient to conclude this. For example, a web server may have obtained a valid TLS/TCP and DTLS/SCTP certificate, and secured RRs may be included in the DNS, but this does not imply that it is authorized to act as a Diameter server.
また、Diameterピアは、発見したピアがその役割で動作する認可を受けているか確認しなければなりません (MUST)。IKE、TLS/TCP、DTLS/SCTPによる認証、またはDNSSECによるDNS RRの検証だけでは、この結論を得るのに十分ではありません。たとえば、Webサーバーが有効なTLS/TCPおよびDTLS/SCTP証明書を取得し、保護されたRRがDNSに登録されていても、そのサーバーがDiameterサーバーとして動作する認可を受けているとは限りません。
Authorization can be achieved, for example, by the configuration of a Diameter server Certification Authority (CA). The server CA issues a certificate to the Diameter server, which includes an Object Identifier (OID) to indicate the subject is a Diameter server in the Extended Key Usage extension [RFC5280]. This certificate is then used during TLS/TCP, DTLS/SCTP, or IKE security negotiation. However, note that, at the time of writing, no Diameter server Certification Authorities exist.
承認は、たとえば、Diameterサーバー認証局（CA）の構成によって実現できます。サーバーCAは、サブジェクトが拡張キー使用法拡張[RFC5280]のDiameterサーバーであることを示すオブジェクト識別子（OID）を含む証明書をDiameterサーバーに発行します。この証明書は、TLS/TCP、DTLS/SCTP、またはIKEのセキュリティネゴシエーション中に使用されます。ただし、これを書いている時点では、Diameterサーバー認証局は存在しないことに注意してください。
A dynamically discovered peer causes an entry in the peer table (see Section 2.6) to be created. Note that entries created via DNS MUST expire (or be refreshed) within the DNS Time to Live (TTL). If a peer is discovered outside of the local realm, a routing table entry (see Section 2.7) for the peer's realm is created. The routing table entry's expiration MUST match the peer's expiration value.
ピアを動的に発見すると、ピアテーブル（セクション2.6を参照）にエントリを作成します。DNSを介して作成したエントリは、DNS Time to Live（TTL）以内に期限切れにするか更新しなければなりません (MUST)。ローカルrealmの外でピアを発見した場合、そのピアのrealmについてルーティングテーブルエントリ（セクション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, the identifiers of 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 Application Ids in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer.
受信側がコマンドを発行するのは、そのコマンドを定義するDiameterアプリケーションのサポートを通知済みのピアだけです。Diameterノードは、認識されないコマンドやAVPをピアへ不必要に送信しないよう、サポート対象のApplication Idをキャッシュしなければなりません (MUST)。
A receiver of a Capabilities-Exchange-Request (CER) message that does not have any applications in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION and SHOULD disconnect the transport layer connection. Note that receiving a CER or CEA from a peer advertising itself as a relay (see Section 2.4) MUST be interpreted as having common applications with the peer.
送信側との共通アプリケーションがないCapabilities-Exchange-Request（CER）メッセージの受信側は、Result-Code AVPをDIAMETER_NO_COMMON_APPLICATIONに設定したCapabilities-Exchange-Answer（CEA）を返さなければならず (MUST)、トランスポート層の接続を切断すべきです (SHOULD)。自身をリレーとして通知するピア（セクション2.4を参照）からCERまたはCEAを受信した場合、そのピアとの共通アプリケーションがあると解釈しなければならない (MUST) ことに注意してください。
The receiver of the Capabilities-Exchange-Request (CER) MUST determine common applications by computing the intersection of its own set of supported Application Ids against all of the Application-Id AVPs (Auth-Application-Id, Acct-Application-Id, and Vendor-Specific-Application-Id) present in the CER. The value of the Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used during computation. The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include all of its supported applications as a hint to the receiver regarding all of its application capabilities.
Capabilities-Exchange-Request（CER）の受信側は、自身がサポートするApplication Idの集合と、CER内に存在するすべてのApplication-Id AVP（Auth-Application-Id、Acct-Application-Id、Vendor-Specific-Application-Id）との積集合を求め、共通アプリケーションを判定しなければなりません (MUST)。計算時にVendor-Specific-Application-Id内のVendor-Id AVPの値を使用してはなりません (MUST NOT)。Capabilities-Exchange-Answer（CEA）の送信側は、自身の全アプリケーション能力を受信側へ示す手掛かりとして、サポートするすべてのアプリケーションを含めるべきです (SHOULD)。
Diameter implementations SHOULD first attempt to establish a TLS/TCP and DTLS/SCTP connection prior to the CER/CEA exchange. This protects the capabilities information of both peers. To support older Diameter implementations that do not fully conform to this document, the transport security MAY still be negotiated via an Inband-Security AVP. In this case, the receiver of a Capabilities-Exchange-Request (CER) message that does not have any security mechanisms in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY and SHOULD disconnect the transport layer connection.
Diameter実装は、CER/CEA交換より前に、まずTLS/TCP接続およびDTLS/SCTP接続の確立を試みるべきです (SHOULD)。これにより、両ピアの能力情報を保護します。本文書へ完全には準拠しない旧Diameter実装をサポートするため、Inband-Security AVPを介してトランスポートセキュリティを引き続きネゴシエーションしてもよい (MAY)。この場合、送信側との共通セキュリティ機構がないCapabilities-Exchange-Request（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)、またはResult-Code 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メッセージをプロキシ、リダイレクト、またはリレーしてはなりません (MUST NOT)。
Since the CER/CEA messages cannot be proxied, it is still possible that an upstream agent will receive a message for which it has no available peers to handle the application that corresponds to the Command Code. In such instances, the 'E' bit is set in the answer message (Section 7) with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER to inform the downstream agent to take action (e.g., re-routing request to an alternate peer).
CER/CEAメッセージはプロキシできないため、コマンドコードに対応するアプリケーションを処理するために使用できるピアがないメッセージを上流のエージェントが受信する可能性があります。このような場合、結果メッセージAVPがDIAMETER_UNABLE_TO_DELIVERに設定された応答メッセージ（セクション7）で「E」ビットが設定され、アクション（たとえば、代替ピアへの再ルーティング要求）をダウンストリームエージェントに通知します。
With the exception of the Capabilities-Exchange-Request message, a message of type Request that includes the Auth-Application-Id or Acct-Application-Id AVPs, or a message with an application-specific Command Code MAY only be forwarded to a host that has explicitly advertised support for the application (or has advertised the Relay Application Id).
Capabilities-Exchange-Requestメッセージを除き、Auth-Application-Id AVPまたはAcct-Application-Id AVPを含むRequest型のメッセージ、あるいはアプリケーション固有のCommand Codeを持つメッセージは、そのアプリケーションのサポートを明示的に通知した（またはRelay Application Idを通知した）ホストだけへ転送してもよい (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.
コマンドコードが257に設定され、コマンドフラグの「R」ビットがセットされていることで示されるCapabilities-Exchange-Request（CER）は、ローカル機能を交換するために送信されます。トランスポート障害の検出時に、このメッセージを代替ピアに送信してはならない（MUST NOT）。
When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083], which allow for connections to span multiple interfaces and multiple IP addresses, the Capabilities-Exchange-Request message MUST contain one Host-IP-Address AVP for each potential IP address that MAY be locally used when transmitting Diameter messages.
Message Format
メッセージフォーマット
<CER> ::= < Diameter Header: 257, REQ >
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]
The Capabilities-Exchange-Answer (CEA), indicated by the Command Code set to 257 and the Command Flags' 'R' bit cleared, is sent in response to a CER message.
コマンドコードが257に設定され、コマンドフラグの「R」ビットがクリアされていることで示されるCapabilities-Exchange-Answer（CEA）は、CERメッセージに応答して送信されます。
When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083], which allow connections to span multiple interfaces, hence, multiple IP addresses, the Capabilities-Exchange-Answer message MUST contain one Host-IP-Address AVP for each potential IP address that MAY be locally used when transmitting Diameter messages.
Message Format
メッセージフォーマット
<CEA> ::= < Diameter Header: 257 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
[ Error-Message ]
[ Failed-AVP ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]
The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [ENTERPRISE] value assigned to the Diameter Software vendor. It is envisioned that the combination of the Vendor-Id, Product-Name (Section 5.3.7), and Firmware-Revision (Section 5.3.4) AVPs may provide useful debugging information.
Vendor-Id AVP（AVPコード266）はタイプUnsigned32であり、Diameterソフトウェアベンダーに割り当てられたIANA "SMI Network Management Private Enterprise Codes" [ENTERPRISE]値が含まれています。 Vendor-Id、Product-Name（セクション5.3.7）、およびFirmware-Revision（セクション5.3.4）AVPの組み合わせは、有用なデバッグ情報を提供することが想定されています。
A Vendor-Id value of zero in the CER or CEA message is reserved and indicates that this field is ignored.
CERまたはCEAメッセージのVendor-Id値がゼロで予約されており、このフィールドが無視されることを示しています。
The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is used to inform a Diameter peer of the firmware revision of the issuing device.
ファームウェアリビジョンAVP（AVPコード267）はタイプUnsigned32であり、Diameterピアに発行デバイスのファームウェアリビジョンを通知するために使用されます。
For devices that do not have a firmware revision (general-purpose computers running Diameter software modules, for instance), the revision of the Diameter software module may be reported instead.
ファームウェアリビジョンのないデバイス（たとえば、Diameterソフトウェアモジュールを実行している汎用コンピューター）では、Diameterソフトウェアモジュールのリビジョンが代わりに報告される場合があります。
The Host-IP-Address AVP (AVP Code 257) is of type Address and is used to inform a Diameter peer of the sender's IP address. All source addresses that a Diameter node expects to use with SCTP [RFC4960] or DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages by including a Host-IP-Address AVP for each address.
The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [ENTERPRISE] value assigned to a vendor other than the device vendor but including the application vendor. This is used in the CER and CEA messages in order to inform the peer that the sender supports (a subset of) the Vendor-Specific AVPs defined by the vendor identified in this AVP. The value of this AVP MUST NOT be set to zero. Multiple instances of this AVP containing the same value SHOULD NOT be sent.
Supported-Vendor-Id AVP（AVPコード265）はUnsigned32タイプであり、デバイスベンダー以外のベンダーに割り当てられたIANA "SMI Network Management Private Enterprise Codes" [ENTERPRISE]値が含まれていますが、アプリケーションベンダーも含まれます。これは、送信者がこのAVPで識別されたベンダーによって定義されたベンダー固有のAVP（のサブセット）をサポートすることをピアに通知するために、CERおよびCEAメッセージで使用されます。このAVPの値はゼロに設定してはなりません（MUST NOT）。同じ値を含むこのAVPの複数のインスタンスは送信してはなりません（SHOULD NOT）。
The Product-Name AVP (AVP Code 269) is of type UTF8String and contains the vendor-assigned name for the product. The Product-Name AVP SHOULD remain constant across firmware revisions for the same product.
Product-Name AVP（AVPコード269）はUTF8Stringタイプであり、ベンダーが割り当てた製品名が含まれています。 Product-Name AVPは、同じ製品のファームウェアリビジョン間で一定である必要があります（SHOULD）。
When a Diameter node disconnects one of its transport connections, its peer cannot know the reason for the disconnect and will most likely assume that a connectivity problem occurred or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in Section 2.1. In the event that the disconnect was a result of either a shortage of internal resources or simply that the node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future, a periodic connection request would not be welcomed. The Disconnection-Reason AVP contains the reason the Diameter node issued the Disconnect-Peer-Request message.
Diameterノードがトランスポート接続の1つを切断すると、そのピアは切断の理由を知ることができず、接続の問題が発生したか、ピアが再起動したと想定します。これらの場合、2.1節で述べたように、ピアは定期的に再接続を試みる場合があります。切断が内部リソースの不足の結果であった場合、または問題のノードが予見可能な将来にピアにDiameterメッセージを転送する意図がない場合、定期的な接続要求は歓迎されません。 Disconnection-Reason AVPには、DiameterノードがDisconnect-Peer-Requestメッセージを発行した理由が含まれています。
The Disconnect-Peer-Request message is used by a Diameter node to inform its peer of its intent to disconnect the transport layer and that the peer shouldn't reconnect unless it has a valid reason to do so (e.g., message to be forwarded). Upon receipt of the message, the Disconnect-Peer-Answer message is returned, which SHOULD contain an error if messages have recently been forwarded, and are likely in flight, which would otherwise cause a race condition.
Disconnect-Peer-Requestメッセージは、Diameterノードがトランスポート層を切断する意図と、転送すべきメッセージがある場合など正当な理由がない限り再接続しないよう求めることをピアへ通知するために使用します。このメッセージを受信するとDisconnect-Peer-Answerメッセージを返します。メッセージを最近転送しており、まだ転送中である可能性が高く、そうしなければ競合状態が生じる場合、この応答はエラーを含むべきです (SHOULD)。
The receiver of the Disconnect-Peer-Answer message initiates the transport disconnect. The sender of the Disconnect-Peer-Answer message should be able to detect the transport closure and clean up the connection.
Disconnect-Peer-Answerメッセージの受信者は、トランスポートの切断を開始します。 Disconnect-Peer-Answerメッセージの送信者は、トランスポートの閉鎖を検出し、接続をクリーンアップできる必要があります。
The Disconnect-Peer-Request (DPR), indicated by the Command Code set to 282 and the Command Flags' 'R' bit set, is sent to a peer to inform it of its intentions to shut down the transport connection. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.
Command Codeを282に設定し、Command Flagsの「R」ビットを設定することで示されるDisconnect-Peer-Request（DPR）は、トランスポート接続を閉じる意図を通知するためピアへ送信します。トランスポート障害を検出した場合、このメッセージを代替ピアへ送信してはなりません (MUST NOT)。
Message Format
メッセージフォーマット
<DPR> ::= < Diameter Header: 282, REQ >
{ Origin-Host }
{ Origin-Realm }
{ Disconnect-Cause }
* [ AVP ]
The Disconnect-Peer-Answer (DPA), indicated by the Command Code set to 282 and the Command Flags' 'R' bit cleared, is sent as a response to the Disconnect-Peer-Request message. Upon receipt of this message, the transport connection is shut down.
Disconnect-Peer-Requestメッセージへの応答として、コマンドコードが282に設定され、コマンドフラグの「R」ビットがクリアされることで示されるDisconnect-Peer-Answer（DPA）が送信されます。このメッセージを受信すると、トランスポート接続がシャットダウンされます。
Message Format
メッセージフォーマット
<DPA> ::= < Diameter Header: 282 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
[ Failed-AVP ]
* [ AVP ]
The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A Diameter node MUST include this AVP in the Disconnect-Peer-Request message to inform the peer of the reason for its intention to shut down the transport connection. The following values are supported:
Disconnect-Cause AVP（AVP Code 273）はEnumerated型です。Diameterノードは、トランスポート接続を閉じようとする理由をピアへ通知するため、Disconnect-Peer-RequestメッセージにこのAVPを含めなければなりません (MUST)。次の値をサポートします：
REBOOTING 0 A scheduled reboot is imminent. A receiver of a DPR with above result code MAY attempt reconnection.
REBOOTING 0 予定された再起動が迫っています。上記のresult codeを持つDPRの受信側は、再接続を試みてもよい (MAY)。
BUSY 1 The peer's internal resources are constrained, and it has determined that the transport connection needs to be closed. A receiver of a DPR with above result code SHOULD NOT attempt reconnection.
BUSY 1ピアの内部リソースに制約があり、トランスポート接続を閉じる必要があると判断しました。上記の結果コードを持つDPRの受信者は、再接続を試みるべきではありません（SHOULD NOT）。
DO_NOT_WANT_TO_TALK_TO_YOU 2 The peer has determined that it does not see a need for the transport connection to exist, since it does not expect any messages to be exchanged in the near future. A receiver of a DPR with above result code SHOULD NOT attempt reconnection.
DO_NOT_WANT_TO_TALK_TO_YOU 2ピアは、近い将来メッセージが交換されることを予期していないため、トランスポート接続が存在する必要がないと判断しました。上記の結果コードを持つDPRの受信者は、再接続を試みるべきではありません（SHOULD NOT）。
Given the nature of the Diameter protocol, it is recommended that transport failures be detected as soon as possible. Detecting such failures will minimize the occurrence of messages sent to unavailable agents, resulting in unnecessary delays, and will provide better failover performance. The Device-Watchdog-Request and Device-Watchdog-Answer messages, defined in this section, are used to pro-actively detect transport failures.
Diameterプロトコルの性質を考えると、トランスポート障害はできるだけ早く検出することをお勧めします。このような障害を検出すると、使用できないエージェントに送信されるメッセージの発生が最小限に抑えられ、不要な遅延が発生し、フェイルオーバーのパフォーマンスが向上します。このセクションで定義されているDevice-Watchdog-RequestおよびDevice-Watchdog-Answerメッセージは、トランスポート障害を予防的に検出するために使用されます。
The Device-Watchdog-Request (DWR), indicated by the Command Code set to 280 and the Command Flags' 'R' bit set, is sent to a peer when no traffic has been exchanged between two peers (see Section 5.5.3). Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.
280に設定されたコマンドコードとコマンドフラグの「R」ビットセットで示されるデバイスウォッチドッグ要求（DWR）は、2つのピア間でトラフィックが交換されていない場合にピアに送信されます（セクション5.5.3を参照）。 。トランスポート障害の検出時に、このメッセージを代替ピアに送信してはならない（MUST NOT）。
Message Format
メッセージフォーマット
<DWR> ::= < Diameter Header: 280, REQ >
{ Origin-Host }
{ Origin-Realm }
[ Origin-State-Id ]
* [ AVP ]
The Device-Watchdog-Answer (DWA), indicated by the Command Code set to 280 and the Command Flags' 'R' bit cleared, is sent as a response to the Device-Watchdog-Request message.
コマンドコードが280に設定され、コマンドフラグの「R」ビットがクリアされることで示されるデバイスウォッチドッグ応答（DWA）は、デバイスウォッチドッグ要求メッセージへの応答として送信されます。
Message Format
メッセージフォーマット
<DWA> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
[ Failed-AVP ]
[ Origin-State-Id ]
* [ AVP ]
The transport failure algorithm is defined in [RFC3539]. All Diameter implementations MUST support the algorithm defined in that specification in order to be compliant to the Diameter base protocol.
トランスポート障害アルゴリズムは[RFC3539]で定義されています。Diameter基本プロトコルへ準拠するため、すべてのDiameter実装は同仕様で定義するアルゴリズムをサポートしなければなりません (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 remaining records in non-volatile storage that are still waiting to be transmitted. An example of a case where it is not possible to forward the message to an alternate server is when the message has a fixed destination, and the unavailable peer is the message's final destination (see Destination-Host AVP). Such an error requires that the agent return an answer message with the 'E' bit set and the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
トランスポート障害が検出されると、可能であれば、キュー内のすべてのメッセージがTフラグが設定された代替エージェントに送信されます。 Diameterクライアントまたはエージェントの起動時に、Tフラグは、送信を待機している不揮発性ストレージの残りのレコードにも設定されます。メッセージを代替サーバーに転送できない場合の例は、メッセージの宛先が固定で、利用できないピアがメッセージの最終宛先である場合です（宛先ホストAVPを参照）。このようなエラーでは、エージェントが「E」ビットが設定され、Result-Code AVPがDIAMETER_UNABLE_TO_DELIVERに設定された応答メッセージを返す必要があります。
It is important to note that multiple identical requests or answers MAY be received as a result of a failover. The End-to-End Identifier field in the Diameter header along with the Origin-Host AVP MUST be used to identify duplicate messages.
フェイルオーバーの結果、同一の要求または応答を複数受信してもよい (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 [RFC3539], which is used to open, close, failover, probe, and reopen transport connections. In particular, note that [RFC3539] requires the use of watchdog messages to probe connections. For Diameter, DWR and DWA messages are to be used.
The I- prefix is used to represent the initiator (connecting) connection, while the R- prefix is used to represent the responder (listening) connection. The lack of a prefix indicates that the event or action is the same regardless of the connection on which the event occurred.
I-プレフィックスはイニシエーター（接続）接続を表すために使用され、R-プレフィックスはレスポンダー（リスニング）接続を表すために使用されます。接頭辞がないことは、イベントが発生した接続に関係なく、イベントまたはアクションが同じであることを示します。
The stable states that a state machine may be in are Closed, I-Open, and R-Open; all other states are intermediate. Note that I-Open and R-Open are equivalent except for whether the initiator or responder transport connection is used for communication.
ステートマシンが存在する可能性のある安定状態は、Closed、I-Open、およびR-Openです。他のすべての状態は中間です。 I-OpenとR-Openは、通信にイニシエータートランスポート接続とレスポンダートランスポート接続のどちらを使用するかを除いて同等であることに注意してください。
A CER message is always sent on the initiating connection immediately after the connection request is successfully completed. In the case of an election, one of the two connections will shut down. The responder connection will survive if the Origin-Host of the local Diameter entity is higher than that of the peer; the initiator connection will survive if the peer's Origin-Host is higher. All subsequent messages are sent on the surviving connection. Note that the results of an election on one peer are guaranteed to be the inverse of the results on the other.
CERメッセージは、接続要求が正常に完了した直後に、常に開始接続で送信されます。選挙の場合、2つの接続のうちの1つがシャットダウンします。ローカルDiameterエンティティのOrigin-HostがピアのOrigin-Hostよりも高い場合、レスポンダ接続は存続します。ピアのOrigin-Hostの方が高い場合、イニシエーター接続は存続します。後続のすべてのメッセージは、残っている接続で送信されます。 1つのピアでの選挙の結果は、他のピアでの結果の逆になることが保証されていることに注意してください。
For TLS/TCP and DTLS/SCTP usage, a TLS/TCP and DTLS/SCTP handshake SHOULD begin when both ends are in the closed state prior to any Diameter message exchanges. The TLS/TCP and DTLS/SCTP connection SHOULD be established before sending any CER or CEA message to secure and protect the capabilities information of both peers. The TLS/TCP and DTLS/SCTP connection SHOULD be disconnected when the state machine moves to the closed state. When connecting to responders that do not conform to this document (i.e., older Diameter implementations that are not prepared to received TLS/TCP and DTLS/ SCTP connections in the closed state), the initial TLS/TCP and DTLS/ SCTP connection attempt will fail. The initiator MAY then attempt to connect via TCP or SCTP and initiate the TLS/TCP and DTLS/SCTP handshake when both ends are in the open state. If the handshake is successful, all further messages will be sent via TLS/TCP and DTLS/ SCTP. If the handshake fails, both ends move to the closed state.
TLS/TCPおよびDTLS/SCTPを使用する場合、Diameterメッセージを交換する前に双方がClosed状態にある時点で、TLS/TCPおよびDTLS/SCTPのハンドシェイクを開始すべきです (SHOULD)。両ピアの能力情報を保護するため、CERまたはCEAメッセージを送信する前にTLS/TCPおよびDTLS/SCTP接続を確立すべきです (SHOULD)。ステートマシンがClosed状態へ移る際、TLS/TCPおよびDTLS/SCTP接続を切断すべきです (SHOULD)。本文書へ準拠しない応答側、すなわちClosed状態でTLS/TCPおよびDTLS/SCTP接続を受け付ける準備がない旧Diameter実装へ接続すると、最初のTLS/TCPおよびDTLS/SCTP接続試行は失敗します。その場合、接続開始側はTCPまたはSCTPで接続し、双方がOpen状態になってからTLS/TCPおよびDTLS/SCTPのハンドシェイクを開始してもよい (MAY)。ハンドシェイクに成功した場合、以後のすべてのメッセージをTLS/TCPおよびDTLS/SCTPで送信します。失敗した場合、双方がClosed状態へ移ります。
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 Closing
R-Peer-Disc R-Disc Closed
I-Open Send-Message I-Snd-Message I-Open
I-Rcv-Message Process I-Open
I-Rcv-DWR Process-DWR, I-Open
I-Snd-DWA
I-Rcv-DWA Process-DWA I-Open
R-Conn-CER R-Reject I-Open
Stop I-Snd-DPR Closing
I-Rcv-DPR I-Snd-DPA Closing
I-Peer-Disc I-Disc Closed
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; the source port of an incoming connection is arbitrary. Upon receipt of a CER, the identity of the connecting peer can be uniquely determined from the Origin-Host.
接続要求がDiameterピアから受信された場合、一般的には、CERが受信されるまで、そのピアのIDを知ることはできません。これは、ホストとポートがDiameterピアのIDを決定するためです。着信接続の送信元ポートは任意です。 CERを受信すると、接続ピアのIDは、Origin-Hostから一意に決定できます。
For this reason, a Diameter peer must employ logic separate from the state machine to receive connection requests, accept them, and await the CER. Once the CER arrives on a new connection, the Origin-Host that identifies the peer is used to locate the state machine associated with that peer, and the new connection and CER are passed to the state machine as an R-Conn-CER event.
このため、Diameterピアは、ステートマシンとは別のロジックを使用して、接続要求を受信し、それらを受け入れ、CERを待機する必要があります。 CERが新しい接続に到着すると、ピアを識別するOrigin-Hostを使用して、そのピアに関連付けられたステートマシンが検索され、新しい接続とCERがR-Conn-CERイベントとしてステートマシンに渡されます。
The logic that handles incoming connections SHOULD close and discard the connection if any message other than a CER arrives or if an implementation-defined timeout occurs prior to receipt of CER.
着信接続を処理するロジックは、CER以外のメッセージが到着した場合、またはCERの受信前に実装定義のタイムアウトが発生した場合、接続を閉じて破棄する必要があります（SHOULD）。
Because handling of incoming connections up to and including receipt of a CER requires logic, separate from that of any individual state machine associated with a particular peer, it is described separately in this section rather than in the state machine above.
CERの受信までの着信接続の処理には、特定のピアに関連付けられた個々のステートマシンとは別のロジックが必要であるため、上記のステートマシンではなく、このセクションで個別に説明します。
Transitions and actions in the automaton are caused by events. In this section, we will ignore the I- and R- prefixes, since the actual event would be identical, but it would occur on one of two possible connections.
Transitions and actions in the automaton are caused by events. In this section, we will ignore the I- and R- prefixes, since the actual event would be identical, but it would occur on one of two possible connections.
Start The Diameter application has signaled that a connection should be initiated with the peer.
開始Diameterアプリケーションが、ピアとの接続を開始する必要があることを通知しました。
R-Conn-CER An acknowledgement is received stating that the transport connection has been established, and the associated CER has arrived.
R-Conn-CERトランスポート接続が確立され、関連するCERが到着したことを示す確認が受信されます。
Rcv-Conn-Ack A positive acknowledgement is received confirming that the transport connection is established.
Rcv-Conn-Ackトランスポート接続が確立されたことを確認する肯定応答が受信されます。
Rcv-Conn-Nack A negative acknowledgement was received stating that the transport connection was not established.
Rcv-Conn-Nackトランスポート接続が確立されなかったことを示す否定応答が受信されました。
Timeout An application-defined timer has expired while waiting for some event.
タイムアウト何らかのイベントを待機している間に、アプリケーション定義のタイマーが満了しました。
Rcv-CER A CER message from the peer was received.
Rcv-CERピアからのCERメッセージが受信されました。
Rcv-CEA A CEA message from the peer was received.
Rcv-CEAピアからのCEAメッセージを受信しました。
Rcv-Non-CEA A message, other than a CEA, from the peer was received.
Rcv-Non-CEAピアからCEA以外のメッセージが受信されました。
Peer-Disc A disconnection indication from the peer was received.
Peer-Discピアからの切断指示を受信しました。
Rcv-DPR A DPR message from the peer was received.
Rcv-DPRピアからのDPRメッセージが受信されました。
Rcv-DPA A DPA message from the peer was received.
Rcv-DPAピアからのDPAメッセージが受信されました。
Win-Election An election was held, and the local node was the winner.
勝利選挙選挙が行われ、ローカルノードが勝者となりました。
Send-Message A message is to be sent.
Send-Messageメッセージが送信されます。
Rcv-Message A message other than CER, CEA, DPR, DPA, DWR, or DWA was received.
Rcv-Message CER、CEA、DPR、DPA、DWR、またはDWA以外のメッセージが受信されました。
Stop The Diameter application has signaled that a connection should be terminated (e.g., on system shutdown).
停止Diameterアプリケーションが、接続を終了する必要があることを通知しました（システムのシャットダウン時など）。
Actions in the automaton are caused by events and typically indicate the transmission of packets and/or an action to be taken on the connection. In this section, we will ignore the I- and R- prefixes, since the actual action would be identical, but it would occur on one of two possible connections.
オートマトンのアクションはイベントによって引き起こされ、通常はパケットの送信や接続で行われるアクションを示します。このセクションでは、実際のアクションは同じであるため、I-およびR-プレフィックスは無視しますが、2つの可能な接続のいずれかで発生します。
Snd-Conn-Req A transport connection is initiated with the peer.
Snd-Conn-Reqトランスポート接続がピアで開始されました。
Accept The incoming connection associated with the R-Conn-CER is accepted as the responder connection.
Accept R-Conn-CERに関連付けられた着信接続は、レスポンダ接続として受け入れられます。
Reject The incoming connection associated with the R-Conn-CER is disconnected.
拒否R-Conn-CERに関連付けられた着信接続が切断されます。
Process-CER The CER associated with the R-Conn-CER is processed.
Process-CER R-Conn-CERに関連付けられたCERが処理されます。
Snd-CER A CER message is sent to the peer.
Snd-CER CERメッセージがピアに送信されます。
Snd-CEA A CEA message is sent to the peer.
Snd-CEA A CEA message is sent to the peer.
Cleanup If necessary, the connection is shut down, and any local resources are freed.
クリーンアップ必要に応じて、接続がシャットダウンされ、ローカルリソースが解放されます。
Error The transport layer connection is disconnected, either politely or abortively, in response to an error condition. Local resources are freed.
エラートランスポート層接続は、エラー状態に応じて、丁寧にまたは中止して切断されます。ローカルリソースが解放されます。
Process-CEA A received CEA is processed.
Process-CEA受信したCEAが処理されます。
Snd-DPR A DPR message is sent to the peer.
Snd-DPR DPRメッセージがピアに送信されます。
Snd-DPA A DPA message is sent to the peer.
Snd-DPA DPAメッセージがピアに送信されます。
Disc The transport layer connection is disconnected, and local resources are freed.
Discトランスポート層の接続が切断され、ローカルリソースが解放されます。
Elect An election occurs (see Section 5.6.4 for more information).
選出選挙が行われます（詳細は、セクション5.6.4を参照）。
Snd-Message A message is sent.
Snd-Messageメッセージが送信されます。
Snd-DWR A DWR message is sent.
Snd-DWR DWRメッセージが送信されます。
Snd-DWA A DWA message is sent.
Snd-DWA A DWA message is sent.
Process-DWR The DWR message is serviced.
Process-DWR DWRメッセージが処理されます。
Process-DWA The DWA message is serviced.
Process-DWA DWAメッセージが処理されます。
Process A message is serviced.
プロセスメッセージが処理されます。
The election is performed on the responder. The responder compares the Origin-Host received in the CER with its own Origin-Host as two streams of octets. If the local Origin-Host lexicographically succeeds the received Origin-Host, a Win-Election event is issued locally. Diameter identities are in ASCII form; therefore, the lexical comparison is consistent with DNS case insensitivity, where octets that fall in the ASCII range 'a' through 'z' MUST compare equally to their uppercase counterparts between 'A' and 'Z'. See Appendix D for interactions between the Diameter protocol and Internationalized Domain Name (IDNs).
選択処理は応答側で行います。応答側は、CERで受信したOrigin-Hostと自身のOrigin-Hostを、2つのオクテット列として比較します。ローカルのOrigin-Hostが受信したOrigin-Hostより辞書順で後なら、ローカルでWin-Electionイベントを発行します。Diameter識別子はASCII形式であるため、辞書順比較はDNSの大文字小文字を区別しない性質と整合します。ASCII範囲の「a」から「z」に該当するオクテットは、「A」から「Z」の対応する大文字と同値として比較しなければなりません (MUST)。DiameterプロトコルとInternationalized Domain Name（IDN）の相互作用については、付録Dを参照してください。
The winner of the election MUST close the connection it initiated. Historically, maintaining the responder side of a connection was more efficient than maintaining the initiator side. However, current practices makes this distinction irrelevant.
選択処理の勝者は、自身が開始した接続を閉じなければなりません (MUST)。歴史的には、接続の応答側を維持する方が開始側を維持するより効率的でした。しかし、現在の実情ではこの区別に意味はありません。
This section describes how Diameter requests and answers are created and processed.
このセクションでは、Diameter要求と応答がどのように作成および処理されるかについて説明します。
A request is sent towards its final destination using one of the following three combinations of the Destination-Realm and Destination-Host AVPs:
Destination-RealmとDestination-Host AVPの次の3つの組み合わせのいずれかを使用して、リクエストが最終的な宛先に送信されます。
o A request that is not able to be proxied (such as a CER) MUST NOT contain either Destination-Realm or Destination-Host AVPs.
o プロキシできない要求（CERなど）は、Destination-Realm AVPとDestination-Host AVPのいずれも含んではなりません (MUST NOT)。
o A request that needs to be sent to a home server serving a specific realm, but not to a specific server (such as the first request of a series of round trips), MUST contain a Destination-Realm AVP but MUST NOT contain a Destination-Host AVP. For Diameter clients, the value of the Destination-Realm AVP MAY be extracted from the User-Name AVP, or other methods.
o 特定のrealmを担当するホームサーバーへ送信する必要があるものの、特定のサーバー宛てではない要求（たとえば、一連のラウンドトリップにおける最初の要求）は、Destination-Realm AVPを含まなければなりません (MUST) が、Destination-Host AVPを含んではなりません (MUST NOT)。Diameterクライアントでは、Destination-Realm AVPの値をUser-Name AVPまたは別の方法から抽出してもよい (MAY)。
o Otherwise, a request that needs to be sent to a specific home server among those serving a given realm MUST contain both the Destination-Realm and Destination-Host AVPs.
o それ以外の場合、あるrealmを担当するホームサーバーのうち特定のサーバーへ送信する必要がある要求は、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は、リクエストの宛先が次のように固定されている場合に、上記のように使用されます。
o Authentication requests that span multiple round trips.
o 複数のラウンドトリップにまたがる認証リクエスト。
o A Diameter message that uses a security mechanism that makes use of a pre-established session key shared between the source and the final destination of the message.
o メッセージの送信元と最終的な送信先の間で共有される事前に確立されたセッションキーを利用するセキュリティメカニズムを使用するDiameterメッセージ。
o Server-initiated messages that MUST be received by a specific Diameter client (e.g., access device), such as the Abort-Session-Request message, which is used to request that a particular user's session be terminated.
o 特定ユーザーのセッション終了を要求するために使用するAbort-Session-Requestメッセージなど、特定のDiameterクライアント（アクセスデバイスなど）が受信しなければならない (MUST)、サーバー主導のメッセージ。
Note that an agent can only forward a request to a host described in the Destination-Host AVP if the host in question is included in its peer table (see Section 2.6). Otherwise, the request is routed based on the Destination-Realm only (see Section 6.1.6).
問題のホストがそのピアテーブルに含まれている場合（セクション2.6を参照）、エージェントはDestination-Host AVPに記述されているホストにのみリクエストを転送できることに注意してください。それ以外の場合、要求は宛先レルムのみに基づいてルーティングされます（セクション6.1.6を参照）。
When a message is received, the message is processed in the following order:
メッセージを受信すると、メッセージは次の順序で処理されます。
o If the message is destined for the local host, the procedures listed in Section 6.1.4 are followed.
o メッセージの宛先がローカルホストの場合は、セクション6.1.4に記載されている手順に従います。
o If the message is intended for a Diameter peer with whom the local host is able to directly communicate, the procedures listed in Section 6.1.5 are followed. This is known as "Request Forwarding".
o メッセージがローカルホストが直接通信できるDiameterピアを対象としている場合は、セクション6.1.5に記載されている手順に従います。これは「リクエスト転送」として知られています。
o The procedure listed in Section 6.1.6 is followed, which is known as "Request Routing".
o セクション6.1.6にリストされている手順に従います。これは「リクエストルーティング」として知られています。
o If none of the above are successful, an answer is returned with the Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the 'E' bit set.
o 上記のいずれも成功しなかった場合は、結果コードがDIAMETER_UNABLE_TO_DELIVERに設定され、「E」ビットが設定された応答が返されます。
For routing of Diameter messages to work within an administrative domain, all Diameter nodes within the realm MUST be peers.
管理ドメイン内でDiameterメッセージをルーティングできるようにするには、そのrealm内のすべてのDiameterノードが互いにピアでなければなりません (MUST)。
The overview contained in this section (6.1) is intended to provide general guidelines to Diameter developers. Implementations are free to use different methods than the ones described here as long as they conform to the requirements specified in Sections 6.1.1 through 6.1.9. See Section 7 for more details on error handling.
このセクション（6.1）に含まれる概要は、Diameter開発者に一般的なガイドラインを提供することを目的としています。実装は、セクション6.1.1から6.1.9で指定された要件に準拠している限り、ここで説明されている方法とは異なる方法を自由に使用できます。エラー処理の詳細については、セクション7を参照してください。
When creating a request, in addition to any other procedures described in the application definition for that specific request, the following procedures MUST be followed: o the Command Code is set to the appropriate value;
要求を作成する際、その要求についてアプリケーション定義に記載された他の手順に加え、次の手順に従わなければなりません (MUST)：o Command Codeを適切な値に設定します。
o the 'R' bit is set;
o 「R」ビットが設定されます。
o the End-to-End Identifier is set to a locally unique value;
o エンドツーエンド識別子はローカルで一意の値に設定されます。
o the Origin-Host and Origin-Realm AVPs MUST be set to the appropriate values, used to identify the source of the message; and
o Origin-Host AVPおよびOrigin-Realm AVPは、メッセージの送信元を識別する適切な値に設定しなければなりません (MUST)。さらに、
o the Destination-Host and Destination-Realm AVPs MUST be set to the appropriate values, as described in Section 6.1.
o Destination-Host AVPおよびDestination-Realm AVPは、セクション6.1の説明に従って適切な値に設定しなければなりません (MUST)。
When sending a request, originated either locally or as the result of a forwarding or routing operation, the following procedures SHOULD be followed:
ローカルで生成した要求、または転送処理やルーティング処理の結果として生じた要求を送信する際、次の手順に従うべきです (SHOULD)：
o The Hop-by-Hop Identifier SHOULD be set to a locally unique value.
o ホップバイホップ識別子は、ローカルで一意の値に設定する必要があります（SHOULD）。
o The message SHOULD be saved in the list of pending requests.
o メッセージは、保留中のリクエストのリストに保存する必要があります（SHOULD）。
Other actions to perform on the message based on the particular role the agent is playing are described in the following sections.
次のセクションでは、エージェントが果たしている特定の役割に基づいてメッセージに対して実行するその他のアクションについて説明します。
A relay or proxy agent MUST check for forwarding loops when receiving requests. A loop is detected if the server finds its own identity in a Route-Record AVP. When such an event occurs, the agent MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.
リレーエージェントまたはプロキシエージェントは、要求の受信時に転送ループを検査しなければなりません (MUST)。サーバーがRoute-Record AVP内に自身の識別情報を見つけた場合、ループを検出したことになります。その場合、エージェントはResult-Code AVPをDIAMETER_LOOP_DETECTEDに設定して応答しなければなりません (MUST)。
A request is known to be for local consumption when one of the following conditions occurs:
次のいずれかの条件が発生した場合、リクエストはローカルでの消費であることがわかっています。
o The Destination-Host AVP contains the local host's identity;
o Destination-Host AVPには、ローカルホストのIDが含まれています。
o The Destination-Host AVP is not present, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported; or
o Destination-Host AVPが存在せず、Destination-Realm AVPには、サーバーがローカルで処理するように構成されているレルムが含まれており、Diameterアプリケーションがローカルでサポートされている。または
o Both the Destination-Host and the Destination-Realm are not present.
o 宛先ホストと宛先レルムの両方が存在しません。
When a request is locally processed, the rules in Section 6.2 should be used to generate the corresponding answer.
リクエストがローカルで処理される場合、セクション6.2のルールを使用して、対応する回答を生成する必要があります。
Request forwarding is done using the Diameter peer table. The Diameter peer table contains all of the peers with which the local node is able to directly communicate.
要求の転送は、Diameterピアテーブルを使用して行われます。 Diameterピアテーブルには、ローカルノードが直接通信できるすべてのピアが含まれています。
When a request is received, and the host encoded in the Destination-Host AVP is one that is present in the peer table, the message SHOULD be forwarded to the peer.
リクエストが受信され、Destination-Host AVPでエンコードされたホストがピアテーブルに存在する場合、メッセージはピアに転送されるべきです（SHOULD）。
Diameter request message routing is done via realms and Application Ids. A Diameter message that may be forwarded by Diameter agents (proxies, redirect agents, or relay agents) MUST include the target realm in the Destination-Realm AVP. Request routing SHOULD rely on the Destination-Realm AVP and the Application Id present in the request message header to aid in the routing decision. The realm MAY be retrieved from the User-Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP.
Diameter要求メッセージのルーティングは、realmとApplication Idを使用して行います。Diameterエージェント（プロキシ、リダイレクトエージェント、リレーエージェント）が転送できるDiameterメッセージは、Destination-Realm AVPに対象realmを含まなければなりません (MUST)。要求のルーティングでは、ルーティング判断を補助するため、Destination-Realm AVPと要求メッセージヘッダー内のApplication Idを利用すべきです (SHOULD)。realmは、Network Access Identifier（NAI）形式のUser-Name AVPから取得してもよい (MAY)。NAIのrealm部分をDestination-Realm AVPへ挿入します。
Diameter agents MAY have a list of locally supported realms and applications, and they MAY have a list of externally supported realms and applications. When a request is received that includes a realm and/or application that is not locally supported, the message is routed to the peer configured in the routing table (see Section 2.7).
Diameterエージェントは、ローカルでサポートされているレルムとアプリケーションのリストを持っている場合があり（MAY）、外部でサポートされているレルムとアプリケーションのリストを持っている場合があります（MAY）。ローカルでサポートされていないレルムやアプリケーションを含む要求を受信すると、メッセージはルーティングテーブルで構成されたピアにルーティングされます（セクション2.7を参照）。
Realm names and Application Ids are the minimum supported routing criteria, additional information may be needed to support redirect semantics.
レルム名とアプリケーションIDは、サポートされる最小のルーティング基準です。リダイレクトセマンティクスをサポートするには、追加情報が必要になる場合があります。
Before forwarding or routing a request, Diameter agents, in addition to performing the processing described in Section 6.1.3, SHOULD check for the presence of a candidate route's peer identity in any of the Route-Record AVPs. In the event of the agent detecting the presence of a candidate route's peer identity in a Route-Record AVP, the agent MUST ignore such a route for the Diameter request message and attempt alternate routes if any exist. In case all the candidate routes are eliminated by the above criteria, the agent SHOULD return a DIAMETER_UNABLE_TO_DELIVER message.
Diameterエージェントは、要求を転送またはルーティングする前に、セクション6.1.3で説明する処理に加え、いずれかのRoute-Record AVP内に候補経路のピア識別情報が存在するか検査すべきです (SHOULD)。Route-Record AVP内に候補経路のピア識別情報が存在すると検出した場合、エージェントはその経路をDiameter要求メッセージの経路候補から除外し、代替経路があれば試行しなければなりません (MUST)。上記の基準ですべての候補経路が除外された場合、エージェントはDIAMETER_UNABLE_TO_DELIVERメッセージを返すべきです (SHOULD)。
When a redirect agent receives a request whose routing entry is set to REDIRECT, it MUST reply with an answer message with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header, and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of the servers associated with the routing entry are added in a separate Redirect-Host AVP.
ルーティングエントリがREDIRECTに設定された要求をリダイレクトエージェントが受信した場合、ヘッダー内のHop-by-Hop Identifierを維持し、「E」ビットを設定した応答メッセージを返すとともに、Result-Code AVPをDIAMETER_REDIRECT_INDICATIONに設定しなければなりません (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
Figure 5: Diameter Redirect Agent
The receiver of an answer message with the 'E' bit set and the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the Hop-by-Hop Identifier in the Diameter header to identify the request in the pending message queue (see Section 5.5.4) that is to be redirected. If no transport connection exists with the new peer, one is created, and the request is sent directly to it.
「E」ビットが設定され、Result-Code AVPがDIAMETER_REDIRECT_INDICATIONに設定された応答メッセージの受信者は、Diameterヘッダーのホップバイホップ識別子を使用して、保留中のメッセージキュー内の要求を識別します（5.5.4を参照）リダイレクトされます。新しいピアとのトランスポート接続が存在しない場合は、トランスポート接続が作成され、要求が直接ピアに送信されます。
Multiple Redirect-Host AVPs are allowed. The receiver of the answer message with the 'E' bit set selects exactly one of these hosts as the destination of the redirected message.
複数のリダイレクトホストAVPが許可されます。 「E」ビットが設定された応答メッセージの受信者は、リダイレクトされたメッセージの宛先としてこれらのホストの1つだけを選択します。
When the Redirect-Host-Usage AVP included in the answer message has a non-zero value, a route entry for the redirect indications is created and cached by the receiver. The redirect usage for such a route entry is set by the value of Redirect-Host-Usage AVP and the lifetime of the cached route entry is set by Redirect-Max-Cache-Time AVP value.
応答メッセージに含まれるRedirect-Host-Usage AVPの値がゼロ以外の場合、リダイレクトインジケーションのルートエントリが作成され、レシーバーによってキャッシュされます。このようなルートエントリのリダイレクトの使用は、Redirect-Host-Usage AVPの値によって設定され、キャッシュされたルートエントリのライフタイムは、Redirect-Max-Cache-Time AVP値によって設定されます。
It is possible that multiple redirect indications can create multiple cached route entries differing only in their redirect usage and the peer to forward messages to. As an example, two(2) route entries that are created by two(2) redirect indications results in two(2) cached routes for the same realm and Application Id. However, one has a redirect usage of ALL_SESSION, where matching requests will be forwarded to one peer; the other has a redirect usage of ALL_REALM, where request are forwarded to another peer. Therefore, an incoming request that matches the realm and Application Id of both routes will need additional resolution. In such a case, a routing precedence rule MUST be used against the redirect usage value to resolve the contention. The precedence rule can be found in Section 6.13.
複数のリダイレクト通知により、redirect usageとメッセージ転送先のピアだけが異なる複数の経路エントリをキャッシュする可能性があります。たとえば、2つのリダイレクト通知から作成した2つの経路エントリにより、同じrealmおよびApplication Idに対する2つの経路がキャッシュされます。一方のredirect usageはALL_SESSIONで、一致する要求をあるピアへ転送し、他方のredirect usageはALL_REALMで、要求を別のピアへ転送します。このため、両経路のrealmおよびApplication Idに一致する着信要求では、追加の競合解決が必要です。この場合、競合を解決するため、redirect usage値に対してルーティング優先規則を適用しなければなりません (MUST)。優先規則はセクション6.13にあります。
A relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer from which the request was received.
リレーエージェントまたはプロキシエージェントは、転送するすべての要求にRoute-Record AVPを追加しなければなりません (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. The Proxy-Info AVP has security implications as state information is distributed to other entities. As such, it is RECOMMENDED that the content of the Proxy-Info AVP be protected with cryptographic mechanisms, for example, by using a keyed message digest such as HMAC-SHA1 [RFC2104]. Such a mechanism, however, requires the management of keys, although only locally at the Diameter server. Still, a full description of the management of the keys used to protect the Proxy-Info AVP is beyond the scope of this document. Below is a list of common recommendations:
対応する応答を受信した際にローカルの状態情報へアクセスする必要がある場合、リレーエージェントまたはプロキシエージェントは要求にProxy-Info AVPを含めてもよい (MAY)。Proxy-Info AVPは状態情報を他のエンティティへ配布するため、セキュリティ上の影響があります。このため、たとえばHMAC-SHA1 [RFC2104]のような鍵付きメッセージダイジェストを使い、Proxy-Info AVPの内容を暗号学的機構で保護すべきです (RECOMMENDED)。ただし、このような機構は、Diameterサーバー内だけであっても鍵の管理を必要とします。Proxy-Info AVPの保護に使用する鍵の管理を完全に記述することは本文書の範囲外です。一般的な推奨事項を以下に示します：
o The keys should be generated securely following the randomness recommendations in [RFC4086].
o 鍵は、[RFC4086]のランダム性の推奨事項に従って安全に生成する必要があります。
o The keys and cryptographic protection algorithms should be at least 128 bits in strength.
o 鍵と暗号保護アルゴリズムは、少なくとも128ビットの強度である必要があります。
o The keys should not be used for any other purpose than generating and verifying instances of the Proxy-Info AVP.
o キーは、Proxy-Info AVPのインスタンスの生成と検証以外の目的で使用しないでください。
o The keys should be changed regularly.
o キーは定期的に変更する必要があります。
o The keys should be changed if the AVP format or cryptographic protection algorithms change.
o AVP形式または暗号化保護アルゴリズムが変更された場合は、キーを変更する必要があります。
The message is then forwarded to the next hop, as identified in the routing table.
次に、メッセージはルーティングテーブルで識別された次のホップに転送されます。
Figure 6 provides an example of message routing using the procedures listed in these sections.
図6は、これらのセクションにリストされている手順を使用したメッセージルーティングの例を示しています。
(Origin-Host=nas.example.net) (Origin-Host=nas.example.net)
(Origin-Realm=example.net) (Origin-Realm=example.net)
(Destination-Realm=example.com) (Destination-Realm=example.com)
(Route-Record=nas.example.net)
+------+ ------> +------+ ------> +------+
| | (Request) | | (Request) | |
| NAS +-------------------+ DRL +-------------------+ HMS |
| | | | | |
+------+ <------ +------+ <------ +------+
example.net (Answer) example.net (Answer) example.com
(Origin-Host=hms.example.com) (Origin-Host=hms.example.com)
(Origin-Realm=example.com) (Origin-Realm=example.com)
Figure 6: Routing of Diameter messages
図6：Diameterメッセージのルーティング
Relay and proxy agents are not required to perform full inspection of incoming messages. At a minimum, validation of the message header and relevant routing AVPs has to be done when relaying messages. Proxy agents may optionally perform more in-depth message validation for applications in which it is interested.
リレーおよびプロキシエージェントは、着信メッセージの完全な検査を実行する必要はありません。メッセージをリレーする場合、少なくとも、メッセージヘッダーと関連するルーティングAVPの検証を行う必要があります。プロキシエージェントは、必要に応じて、アプリケーションの詳細なメッセージ検証をオプションで実行できます。
When a request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command:
要求をローカルで処理する場合、対応する応答を作成するため、次の手順を適用しなければなりません (MUST)。これは、そのコマンドを定義するDiameterアプリケーションが追加手順を記載してもよい (MAY) こととは別に適用します：
o The same Hop-by-Hop Identifier in the request is used in the answer.
o リクエストでは同じホップバイホップ識別子が回答で使用されます。
o The local host's identity is encoded in the Origin-Host AVP.
o ローカルホストのIDは、Origin-Host AVPでエンコードされます。
o The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message.
o Destination-Host AVPおよびDestination-Realm AVPは、応答メッセージ内に存在してはなりません (MUST NOT)。
o The Result-Code AVP is added with its value indicating success or failure.
o Result-Code AVPに、成功または失敗を示す値が追加されます。
o If the Session-Id is present in the request, it MUST be included in the answer.
o 要求にSession-Idが存在する場合、応答にそれを含めなければなりません (MUST)。
o Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request.
o 要求内のすべてのProxy-Info AVPを、要求内に存在した順序のまま応答メッセージへ追加しなければなりません (MUST)。
o The 'P' bit is set to the same value as the one in the request.
o 「P」ビットは、要求のビットと同じ値に設定されます。
o The same End-to-End identifier in the request is used in the answer.
o 要求では、同じエンドツーエンド識別子が応答で使用されます。
Note that the error messages (see Section 7) are also subjected to the above processing rules.
エラーメッセージ（セクション7を参照）も上記の処理規則に従うことに注意してください。
A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an answer received against the list of pending requests. The corresponding message should be removed from the list of pending requests. It SHOULD ignore answers received that do not match a known Hop-by-Hop Identifier.
Diameterクライアントまたはプロキシは、受信した応答のHop-by-Hop Identifierを保留中の要求リストと照合しなければなりません (MUST)。対応するメッセージは、保留中の要求リストから削除する必要があります。既知のHop-by-Hop Identifierに一致しない受信応答は無視すべきです (SHOULD)。
If the answer is for a request that was proxied or relayed, the agent MUST restore the original value of the Diameter header's Hop-by-Hop Identifier field.
プロキシまたはリレーした要求に対する応答の場合、エージェントはDiameterヘッダー内の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; it MUST also issue an STR on behalf of the access device towards the Diameter server.
リレーエージェントまたはプロキシエージェントが、失敗を示すResult-Code AVPを含む応答を受信した場合、そのAVPの内容を変更してはなりません (MUST NOT)。追加で検出したローカルエラーはログへ記録すべきです (SHOULD) が、Result-Code AVPには反映しません。エージェントが成功を示すResult-Code AVPを含む応答メッセージを受信し、そのAVPをエラー表示へ変更しようとする場合、アクセスデバイス宛てのメッセージ内でResult-Code AVPが適切なエラーを含むよう変更するとともに、Error-Reporting-Host AVPを含めなければなりません (MUST)。さらに、アクセスデバイスに代わってDiameterサーバーへ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 it MUST be present in all Diameter messages. This AVP identifies the endpoint that originated the Diameter message. Relay agents MUST NOT modify this AVP.
Origin-Host AVP（AVP Code 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.
このAVPは、Diameterヘッダーのできるだけ近くに配置する必要があります（SHOULD）。
The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity. This AVP contains the Realm of the originator of any Diameter message and MUST be present in all messages.
Origin-Realm AVP（AVP Code 296）はDiameterIdentity型です。このAVPには、Diameterメッセージ生成元のRealmが入り、すべてのメッセージ内に存在しなければなりません (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) 一方、応答メッセージ内に存在してはなりません (MUST NOT)。
The absence of the Destination-Host AVP will cause a message to be sent to any Diameter server supporting the application within the realm specified in Destination-Realm AVP.
Destination-Host AVPがない場合、Destination-Realm AVPで指定されたレルム内のアプリケーションをサポートするすべてのDiameterサーバーにメッセージが送信されます。
This AVP SHOULD be placed as close to the Diameter header as possible.
このAVPは、Diameterヘッダーのできるだけ近くに配置する必要があります（SHOULD）。
The Destination-Realm AVP (AVP Code 283) is of type DiameterIdentity and contains the realm to which the message is to be routed. The Destination-Realm AVP MUST NOT be present in answer messages. Diameter clients insert the realm portion of the User-Name AVP. Diameter servers initiating a request message use the value of the Origin-Realm AVP from a previous message received from the intended target host (unless it is known a priori). When present, the Destination-Realm AVP is used to perform message routing decisions.
Destination-Realm AVP（AVP Code 283）はDiameterIdentity型であり、メッセージのルーティング先realmを格納します。Destination-Realm AVPは応答メッセージ内に存在してはなりません (MUST NOT)。DiameterクライアントはUser-Name AVPのrealm部分を挿入します。要求メッセージを開始するDiameterサーバーは、対象ホストから以前に受信したメッセージのOrigin-Realm AVP値を使用します（事前に判明している場合を除きます）。Destination-Realm AVPが存在する場合、メッセージのルーティング判断に使用します。
The CCF for a request message that includes the Destination-Realm AVP SHOULD list the Destination-Realm AVP as a required AVP (an AVP indicated as {AVP}); otherwise, the message is inherently a non-routable message.
Destination-Realm AVPを含む要求メッセージのCCFは、Destination-Realm AVPを必須のAVP（{AVP}として示されるAVP）としてリストする必要があります（SHOULD）。それ以外の場合、メッセージは本質的にルーティング不可能なメッセージです。
This AVP SHOULD be placed as close to the Diameter header as possible.
このAVPは、Diameterヘッダーのできるだけ近くに配置する必要があります（SHOULD）。
The AVPs defined in this section are Diameter AVPs used for routing purposes. These AVPs change as Diameter messages are processed by agents.
The AVPs defined in this section are Diameter AVPs used for routing purposes. These AVPs change as Diameter messages are processed by agents.
The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The identity added in this AVP MUST be the same as the one received in the Origin-Host of the Capabilities Exchange message.
Route-Record AVP（AVP Code 282）はDiameterIdentity型です。このAVPへ追加する識別情報は、Capabilities ExchangeメッセージのOrigin-Hostで受信した識別情報と同じでなければなりません (MUST)。
The Proxy-Info AVP (AVP Code 284) is of type Grouped. This AVP contains the identity and local state information of the Diameter node that creates and adds it to a message. The Grouped Data field has the following CCF grammar:
Proxy-Info AVP（AVPコード284）のタイプはGroupedです。このAVPには、メッセージを作成してメッセージに追加するDiameterノードのIDとローカル状態情報が含まれています。 Grouped Dataフィールドには、次のCCF文法があります。
Proxy-Info ::= < AVP Header: 284 >
{ Proxy-Host }
{ Proxy-State }
* [ AVP ]
The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. This AVP contains the identity of the host that added the Proxy-Info AVP.
Proxy-Host AVP（AVPコード280）のタイプはDiameterIdentityです。このAVPには、Proxy-Info AVPを追加したホストのIDが含まれています。
The Proxy-State AVP (AVP Code 33) is of type OctetString. It contains state information that would otherwise be stored at the Diameter entity that created it. As such, this AVP MUST be treated as opaque data by other Diameter entities.
Proxy-State AVP（AVP Code 33）はOctetString型です。このAVPには、そうでなければ生成元のDiameterエンティティに保存される状態情報が入ります。したがって、他のDiameterエンティティはこのAVPを不透明なデータとして扱わなければなりません (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). If present in a message other than CER and CEA, the value of the Auth-Application-Id AVP MUST match the Application Id present in the Diameter message header.
Auth-Application-Id AVP（AVP Code 258）はUnsigned32型であり、アプリケーションの認証および認可部分のサポートを通知するために使用します（セクション2.4を参照）。CERおよびCEA以外のメッセージ内に存在する場合、Auth-Application-Id AVPの値は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). If present in a message other than CER and CEA, the value of the Acct-Application-Id AVP MUST match the Application Id present in the Diameter message header.
Acct-Application-Id AVP（AVP Code 259）はUnsigned32型であり、アプリケーションのアカウンティング部分のサポートを通知するために使用します（セクション2.4を参照）。CERおよびCEA以外のメッセージ内に存在する場合、Acct-Application-Id AVPの値はDiameterメッセージヘッダー内のApplication Idと一致しなければなりません (MUST)。
The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and is used in order to advertise support of the security portion of the application. The use of this AVP in CER and CEA messages is NOT RECOMMENDED. Instead, discovery of a Diameter entity's security capabilities can be done either through static configuration or via Diameter Peer Discovery as described in Section 5.2.
Inband-Security-Id AVP（AVP Code 299）はUnsigned32型であり、アプリケーションのセキュリティ部分のサポートを通知するために使用します。CERおよびCEAメッセージでこのAVPを使用すべきではありません (NOT RECOMMENDED)。代わりに、Diameterエンティティのセキュリティ能力は、静的設定またはセクション5.2で説明するDiameter Peer Discoveryのいずれかで発見できます。
The following values are supported:
次の値がサポートされています。
NO_INBAND_SECURITY 0
NO_INBAND_SECURITY 0
This peer does not support TLS/TCP and DTLS/SCTP. This is the default value, if the AVP is omitted.
This peer does not support TLS/TCP and DTLS/SCTP. This is the default value, if the AVP is omitted.
TLS 1
TLS 1
The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter application. Exactly one instance of either Auth-Application-Id or Acct-Application-Id AVP MUST be present. The Application Id carried by either Auth-Application-Id or Acct-Application-Id AVP MUST comply with vendor-specific Application Id assignment described in Section 11.3. It MUST also match the Application Id present in the Diameter header except when used in a CER or CEA message.
Vendor-Specific-Application-Id AVP（AVP Code 260）はGrouped型であり、ベンダー固有Diameterアプリケーションのサポートを通知するために使用します。Auth-Application-Id AVPまたはAcct-Application-Id AVPのいずれか一方が、正確に1つ存在しなければなりません (MUST)。いずれかのAVPが運ぶApplication Idは、セクション11.3で説明するベンダー固有Application Idの割り当てに従わなければなりません (MUST)。さらに、CERまたはCEAメッセージで使用する場合を除き、Diameterヘッダー内のApplication Idと一致しなければなりません (MUST)。
The Vendor-Id AVP is an informational AVP pertaining to the vendor who may have authorship of the vendor-specific Diameter application. It MUST NOT be used as a means of defining a completely separate vendor-specific Application Id space.
Vendor-Id AVPは、ベンダー固有のDiameterアプリケーションの作成者である可能性があるベンダーに関連する情報AVPです。完全に別個のベンダー固有のアプリケーションIDスペースを定義する手段として使用してはなりません（MUST NOT）。
The Vendor-Specific-Application-Id AVP SHOULD be placed as close to the Diameter header as possible.
Vendor-Specific-Application-Id AVPは、可能な限りDiameterヘッダーの近くへ配置すべきです (SHOULD)。
AVP Format
AVPフォーマット
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
{ Vendor-Id }
[ Auth-Application-Id ]
[ Acct-Application-Id ]
A Vendor-Specific-Application-Id AVP MUST contain exactly one of either Auth-Application-Id or Acct-Application-Id. If a Vendor-Specific-Application-Id is received without one of these two AVPs, then the recipient SHOULD issue an answer with a Result-Code set to DIAMETER_MISSING_AVP. The answer SHOULD also include a Failed-AVP, which MUST contain an example of an Auth-Application-Id AVP and an Acct-Application-Id AVP.
Vendor-Specific-Application-Id AVPは、Auth-Application-IdまたはAcct-Application-Idのいずれか一方だけを含まなければなりません (MUST)。この2つのAVPのどちらも含まないVendor-Specific-Application-Idを受信した場合、受信側はResult-CodeをDIAMETER_MISSING_AVPに設定した応答を発行すべきです (SHOULD)。その応答はFailed-AVPも含むべきであり (SHOULD)、Failed-AVPはAuth-Application-Id AVPおよびAcct-Application-Id AVPの例を含まなければなりません (MUST)。
If a Vendor-Specific-Application-Id is received that contains both Auth-Application-Id and Acct-Application-Id, then the recipient MUST issue an answer with Result-Code set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer MUST also include a Failed-AVP, which MUST contain the received Auth-Application-Id AVP and Acct-Application-Id AVP.
Auth-Application-IdとAcct-Application-Idの両方を含むVendor-Specific-Application-Idを受信した場合、受信側はResult-CodeをDIAMETER_AVP_OCCURS_TOO_MANY_TIMESに設定した応答を発行しなければなりません (MUST)。その応答はFailed-AVPも含まなければならず (MUST)、Failed-AVPは受信したAuth-Application-Id AVPおよびAcct-Application-Id AVPを含まなければなりません (MUST)。
The Redirect-Host AVP (AVP Code 292) is of type DiameterURI. One or more instances of this AVP MUST be present if the answer message's 'E' bit is set and the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
Redirect-Host AVP（AVP Code 292）はDiameterURI型です。応答メッセージの「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 matching the criteria set by the Redirect-Host-Usage AVP.
上記を受信すると、受信側のDiameterノードは、これらのAVPで識別されたホストの1つにリクエストを直接転送する必要があります（SHOULD）。選択されたRedirect-Host AVPに含まれるサーバーは、Redirect-Host-Usage AVPによって設定された基準に一致するすべてのメッセージに使用されるべきです（SHOULD）。
The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated. This AVP MAY be present in answer messages whose 'E' bit is set and the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
Redirect-Host-Usage AVP（AVP Code 261）はEnumerated型です。このAVPは、「E」ビットが設定され、Result-Code AVPがDIAMETER_REDIRECT_INDICATIONに設定された応答メッセージ内に存在してもよい (MAY)。
When present, this AVP provides hints about how the routing entry resulting from the Redirect-Host is to be used. The following values are supported: DONT_CACHE 0
存在する場合、このAVPは、Redirect-Hostに起因するルーティングエントリがどのように使用されるかについてのヒントを提供します。次の値がサポートされています：DONT_CACHE 0
The host specified in the Redirect-Host AVP SHOULD NOT be cached. This is the default value.
Redirect-Host AVPで指定されたホストはキャッシュされるべきではない（SHOULD NOT）。これがデフォルト値です。
ALL_SESSION 1
ALL_SESSION 1
All messages within the same session, as defined by the same value of the Session-ID AVP SHOULD be sent to the host specified in the Redirect-Host AVP.
同じセッション内のすべてのメッセージは、Session-ID AVPの同じ値で定義されているように、Redirect-Host AVPで指定されたホストに送信する必要があります（SHOULD）。
ALL_REALM 2
ALL_REALM 2
All messages destined for the realm requested SHOULD be sent to the host specified in the Redirect-Host AVP.
レルム宛てのすべてのメッセージは、リダイレクトホストAVPで指定されたホストに送信する必要があります（SHOULD）。
REALM_AND_APPLICATION 3
REALM_AND_APPLICATION 3
All messages for the application requested to the realm specified SHOULD be sent to the host specified in the Redirect-Host AVP.
指定されたrealmへ要求されたアプリケーションのすべてのメッセージは、Redirect-Host AVPで指定されたホストへ送信すべきです (SHOULD)。
ALL_APPLICATION 4
ALL_APPLICATION 4
All messages for the application requested SHOULD be sent to the host specified in the Redirect-Host AVP.
要求されたアプリケーションのすべてのメッセージは、リダイレクトホストAVPで指定されたホストに送信する必要があります（SHOULD）。
ALL_HOST 5
ALL_HOST 5
All messages that would be sent to the host that generated the Redirect-Host SHOULD be sent to the host specified in the Redirect-Host AVP.
Redirect-Hostを生成したホストに送信されるすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信される必要があります（SHOULD）。
ALL_USER 6
ALL_USER 6
All messages for the user requested SHOULD be sent to the host specified in the Redirect-Host AVP.
要求されたユーザーのすべてのメッセージは、Redirect-Host AVPで指定されたホストに送信する必要があります（SHOULD）。
When multiple cached routes are created by redirect indications and they differ only in redirect usage and peers to forward requests to (see Section 6.1.8), a precedence rule MUST be applied to the redirect usage values of the cached routes during normal routing to resolve contentions that may occur. The precedence rule is the order that dictate which redirect usage should be considered before any other as they appear. The order is as follows: 1. ALL_SESSION
リダイレクト通知によって複数の経路をキャッシュし、その違いがredirect usageと要求転送先のピアだけである場合（セクション6.1.8を参照）、通常のルーティング時に生じ得る競合を解決するため、キャッシュした経路のredirect usage値へ優先規則を適用しなければなりません (MUST)。この優先規則は、どのredirect usageを他より先に考慮すべきかを、以下に現れる順序で定めます：1. ALL_SESSION
2. ALL_USER
2. すべてのユーザー
3. REALM_AND_APPLICATION
3. REALM_AND_APPLICATION
4. ALL_REALM
4. ALL_REALM
5. ALL_APPLICATION
5. ALL_APPLICATION
6. ALL_HOST
6. ALL_HOST
The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32. This AVP MUST be present in answer messages whose 'E' bit is set, whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and whose Redirect-Host-Usage AVP set to a non-zero value.
Redirect-Max-Cache-Time AVP（AVP Code 262）はUnsigned32型です。このAVPは、「E」ビットが設定され、Result-Code AVPがDIAMETER_REDIRECT_INDICATIONに設定され、かつRedirect-Host-Usage AVPが0以外に設定された応答メッセージ内に存在しなければなりません (MUST)。
This AVP contains the maximum number of seconds the peer and route table entries, created as a result of the Redirect-Host, SHOULD be cached. Note that once a host is no longer reachable, any associated cache, peer, and routing table entries MUST be deleted.
このAVPには、Redirect-Hostの結果として作成したピアテーブルエントリおよびルートテーブルエントリをキャッシュすべき最大秒数が入ります (SHOULD)。ホストへ到達できなくなった時点で、関連するキャッシュエントリ、ピアテーブルエントリ、ルーティングテーブルエントリをすべて削除しなければならない (MUST) ことに注意してください。
There are two different types of errors in Diameter; protocol errors and application errors. A protocol error is one that occurs at the base protocol level and MAY require per-hop attention (e.g., a message routing error). Application errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application (e.g., user authentication, missing AVP).
Diameterのエラーには、プロトコルエラーとアプリケーションエラーの2種類があります。プロトコルエラーは基本プロトコルのレベルで発生し、ホップごとの対応が必要になる場合があります (MAY)（メッセージルーティングエラーなど）。一方、アプリケーションエラーは通常、Diameterアプリケーションで規定した機能の問題（ユーザー認証やAVPの欠落など）によって発生します。
Result-Code AVP values that are used to report protocol errors MUST only be present in answer messages whose 'E' bit is set. When a request message is received that causes a protocol error, an answer message is returned with the 'E' bit set, and the Result-Code AVP is set to the appropriate protocol error value. As the answer is sent back towards the originator of the request, each proxy or relay agent MAY take action on the message.
プロトコルエラーの報告に使用するResult-Code AVP値は、「E」ビットが設定された応答メッセージ内だけに存在しなければなりません (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; therefore, the message would be forwarded back to the originator of the request.
図8に、アプリケーションエラーの原因となったDiameterメッセージの例を示します。アプリケーションエラーが発生すると、エラーを報告しているDiameterエンティティがコマンドフラグの「R」ビットをクリアし、適切な値で結果コードAVPを追加します。アプリケーションエラーは、プロキシまたはリレーエージェントの関与を必要としません。したがって、メッセージは要求の発信者に転送されます。
In the case where the answer message itself contains errors, any related session SHOULD be terminated by sending an STR or ASR message. The Termination-Cause AVP in the STR MAY be filled with the appropriate value to indicate the cause of the error. An application MAY also send an application-specific request instead of an STR or ASR message to signal the error in the case where no state is maintained or to allow for some form of error recovery with the corresponding Diameter entity.
応答メッセージ自体にエラーがある場合、STRまたはASRメッセージを送信して、関連するセッションを終了すべきです (SHOULD)。STR内のTermination-Cause AVPには、エラー原因を示す適切な値を設定してもよい (MAY)。状態を維持していない場合にエラーを通知するため、または対応するDiameterエンティティとの間で何らかのエラー回復を可能にするため、アプリケーションはSTRまたはASRメッセージに代えてアプリケーション固有の要求を送信してもよい (MAY)。
There are certain Result-Code AVP application errors that require additional AVPs to be present in the answer. In these cases, the Diameter node that sets the Result-Code AVP to indicate the error MUST add the AVPs. Examples are as follows:
Result-Code AVPで示すアプリケーションエラーの中には、応答内に追加のAVPが必要となるものがあります。その場合、エラーを示すようResult-Code AVPを設定するDiameterノードは、そのAVPを追加しなければなりません (MUST)。例を以下に示します：
o A request with an unrecognized AVP is received with the 'M' bit (Mandatory bit) set causes an answer to be sent with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED and the Failed-AVP AVP containing the offending AVP.
o 'M'ビット（必須ビット）が設定された認識されないAVPを持つ要求を受信すると、結果コードAVPがDIAMETER_AVP_UNSUPPORTEDに設定された応答が送信され、問題のAVPを含むFailed-AVP AVPが送信されます。
o A request with an AVP that is received with an unrecognized value causes an answer to be returned with the Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing the AVP causing the error.
o 認識されない値で受信されたAVPを含むリクエストにより、Result-Code AVPがDIAMETER_INVALID_AVP_VALUEに設定された応答が返され、Failed-AVP AVPにエラーの原因となったAVPが含まれます。
o A received command that is missing AVPs that are defined as required in the commands CCF; examples are AVPs indicated as {AVP}. The receiver issues an answer with the Result-Code set to DIAMETER_MISSING_AVP and creates an AVP with the AVP Code and other fields set as expected in the missing AVP. The created AVP is then added to the Failed-AVP AVP.
o コマンドCCFで必要と定義されているAVPが欠落している受信コマンド。例は、{AVP}として示されるAVPです。受信者は、Result-CodeをDIAMETER_MISSING_AVPに設定して回答を発行し、欠落しているAVPで予想されるAVPコードとその他のフィールドが設定されたAVPを作成します。作成されたAVPは、Failed-AVP AVPに追加されます。
The Result-Code AVP describes the error that the Diameter node encountered in its processing. In case there are multiple errors, the Diameter node MUST report only the first error it encountered (detected possibly in some implementation-dependent order). The specific errors that can be described by this AVP are described in the following section.
Result-Code AVPは、Diameterノードが処理中に検出したエラーを示します。複数のエラーがある場合、Diameterノードは最初に検出したエラーだけを報告しなければなりません (MUST)（検出順序は実装依存の場合があります）。このAVPで示せる個々のエラーは、次のセクションで説明します。
The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whether a particular request was completed successfully or an error occurred. All Diameter answer messages in IETF-defined Diameter application specifications MUST include one Result-Code AVP. A non-successful Result-Code AVP (one containing a non-2xxx value other than DIAMETER_REDIRECT_INDICATION) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP.
Result-Code AVP（AVP Code 268）はUnsigned32型であり、個々の要求が正常に完了したか、エラーが発生したかを示します。IETFが定義するDiameterアプリケーション仕様のすべてのDiameter応答メッセージは、Result-Code AVPを1つ含まなければなりません (MUST)。成功以外のResult-Code AVP（DIAMETER_REDIRECT_INDICATIONを除く、2xxx以外の値を含むもの）は、Result-Code AVPを設定したホストがOrigin-Host AVPに符号化された識別情報と異なる場合、Error-Reporting-Host AVPを含まなければなりません (MUST)。
The Result-Code data field contains an IANA-managed 32-bit address space representing errors (see Section 11.3.2). Diameter provides the following classes of errors, all identified by the thousands digit in the decimal notation: o 1xxx (Informational)
結果コードデータフィールドには、エラーを表すIANA管理の32ビットアドレス空間が含まれます（セクション11.3.2を参照）。 Diameterは、次のエラークラスを提供します。これらはすべて、10進表記の数千桁で識別されます。o 1xxx（情報のみ）
o 2xxx (Success)
o 2xxx（成功）
o 3xxx (Protocol Errors)
o 3xxx（プロトコルエラー）
o 4xxx (Transient Failures)
o 4xxx（一時的な障害）
o 5xxx (Permanent Failure)
o 5xxx（永続的な障害）
An unrecognized class (one whose first digit is not defined in this section) MUST be handled as a permanent failure.
認識できないクラス（先頭桁をこのセクションで定義していないクラス）は、永続的障害として処理しなければなりません (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.
Errors that fall within this category are used to inform the requester that a request could not be satisfied, and additional action is required on its part before access is granted.
DIAMETER_MULTI_ROUND_AUTH 1001
DIAMETER_MULTI_ROUND_AUTH 1001
This informational error is returned by a Diameter server to inform the access device that the authentication mechanism being used requires multiple round trips, and a subsequent request needs to be issued in order for access to be granted.
この情報エラーはDiameterサーバーによって返され、使用されている認証メカニズムに複数のラウンドトリップが必要であること、およびアクセスを許可するために後続のリクエストを発行する必要があることをアクセスデバイスに通知します。
Errors that fall within the Success category are used to inform a peer that a request has been successfully completed.
成功カテゴリに含まれるエラーは、リクエストが正常に完了したことをピアに通知するために使用されます。
DIAMETER_SUCCESS 2001
DIAMETER_SUCCESS 2001
The request was successfully completed.
リクエストは正常に完了しました。
DIAMETER_LIMITED_SUCCESS 2002
DIAMETER_LIMITED_SUCCESS 2002
When returned, the request was successfully completed, but additional processing is required by the application in order to provide service to the user.
返されると、要求は正常に完了しましたが、ユーザーにサービスを提供するために、アプリケーションによる追加の処理が必要です。
Errors that fall within the Protocol Error category SHOULD be treated on a per-hop basis, and Diameter proxies MAY attempt to correct the error, if it is possible. Note that these errors MUST only be used in answer messages whose 'E' bit is set.
Protocol Errorカテゴリに該当するエラーはホップごとに処理すべきであり (SHOULD)、可能であればDiameterプロキシはエラーの修正を試みてもよい (MAY)。これらのエラーは、「E」ビットを設定した応答メッセージだけで使用しなければならない (MUST) ことに注意してください。
DIAMETER_COMMAND_UNSUPPORTED 3001
DIAMETER_COMMAND_UNSUPPORTED 3001
This error code is used when a Diameter entity receives a message with a Command Code that it does not support.
このエラーコードは、Diameterエンティティが、サポートしていないコマンドコードを含むメッセージを受信したときに使用されます。
DIAMETER_UNABLE_TO_DELIVER 3002
DIAMETER_UNABLE_TO_DELIVER 3002
This error is given when Diameter cannot deliver the message to the destination, either because no host within the realm supporting the required application was available to process the request or because the Destination-Host AVP was given without the associated Destination-Realm AVP.
このエラーは、要求を処理するために必要なアプリケーションをサポートするレルム内のホストが利用できなかったか、関連付けられた宛先レルムAVPなしで宛先ホストAVPが与えられたために、Diameterが宛先にメッセージを配信できない場合に発生します。
DIAMETER_REALM_NOT_SERVED 3003
DIAMETER_REALM_NOT_SERVED 3003
The intended realm of the request is not recognized.
要求の意図されたレルムが認識されていません。
DIAMETER_TOO_BUSY 3004
DIAMETER_TOO_BUSY 3004
When returned, a Diameter node SHOULD attempt to send the message to an alternate peer. This error MUST only be used when a specific server is requested, and it cannot provide the requested service.
このエラーが返された場合、Diameterノードは代替ピアへのメッセージ送信を試みるべきです (SHOULD)。このエラーは、特定のサーバーが指定され、そのサーバーが要求されたサービスを提供できない場合に限り使用しなければなりません (MUST)。
DIAMETER_LOOP_DETECTED 3005
DIAMETER_LOOP_DETECTED 3005
An agent detected a loop while trying to get the message to the intended recipient. The message MAY be sent to an alternate peer, if one is available, but the peer reporting the error has identified a configuration problem.
意図した受信側へメッセージを届けようとした際に、エージェントがループを検出しました。代替ピアが利用可能なら、メッセージをそのピアへ送信してもよい (MAY) ものの、このエラーを報告したピアは設定上の問題を特定しています。
DIAMETER_REDIRECT_INDICATION 3006
DIAMETER_REDIRECT_INDICATION 3006
A redirect agent has determined that the request could not be satisfied locally, and the initiator of the request SHOULD direct the request directly to the server, whose contact information has been added to the response. When set, the Redirect-Host AVP MUST be present.
リダイレクトエージェントは、要求をローカルでは満たせないと判断しました。要求の開始側は、応答に連絡先情報が追加されたサーバーへ要求を直接送るべきです (SHOULD)。この値を設定する場合、Redirect-Host AVPが存在しなければなりません (MUST)。
DIAMETER_APPLICATION_UNSUPPORTED 3007
DIAMETER_APPLICATION_UNSUPPORTED 3007
A request was sent for an application that is not supported.
サポートされていないアプリケーションのリクエストが送信されました。
DIAMETER_INVALID_HDR_BITS 3008
DIAMETER_INVALID_HDR_BITS 3008
A request was received whose bits in the Diameter header were set either to an invalid combination or to a value that is inconsistent with the Command Code's definition.
A request was received whose bits in the Diameter header were set either to an invalid combination or to a value that is inconsistent with the Command Code's definition.
DIAMETER_INVALID_AVP_BITS 3009
DIAMETER_INVALID_AVP_BITS 3009
A request was received that included an AVP whose flag bits are set to an unrecognized value or that is inconsistent with the AVP's definition.
フラグビットが認識されない値に設定されているAVPを含む要求、またはAVPの定義と矛盾する要求が受信されました。
DIAMETER_UNKNOWN_PEER 3010
DIAMETER_UNKNOWN_PEER 3010
A CER was received from an unknown peer.
不明なピアからCERを受信しました。
Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received but MAY be able to satisfy the request in the future. Note that these errors MUST be used in answer messages whose 'E' bit is not set.
一時的障害カテゴリに該当するエラーは、要求を受信した時点では満たせなかったものの、将来は満たせる可能性がある (MAY) ことをピアへ通知するために使用します。これらのエラーは、「E」ビットを設定していない応答メッセージで使用しなければならない (MUST) ことに注意してください。
DIAMETER_AUTHENTICATION_REJECTED 4001
DIAMETER_AUTHENTICATION_REJECTED 4001
The authentication process for the user failed, most likely due to an invalid password used by the user. Further attempts MUST only be tried after prompting the user for a new password.
ユーザーの認証処理が失敗しました。ユーザーが無効なパスワードを使用したことが原因である可能性が高い状況です。以後の試行は、ユーザーに新しいパスワードの入力を促した後に限り行わなければなりません (MUST)。
DIAMETER_OUT_OF_SPACE 4002
DIAMETER_OUT_OF_SPACE 4002
A Diameter node received the accounting request but was unable to commit it to stable storage due to a temporary lack of space.
A Diameter node received the accounting request but was unable to commit it to stable storage due to a temporary lack of space.
ELECTION_LOST 4003
ELECTION_LOST 4003
The peer has determined that it has lost the election process and has therefore disconnected the transport connection.
ピアは、選択プロセスを失ったと判断したため、トランスポート接続を切断しました。
Errors that fall within the permanent failures category are used to inform the peer that the request failed and should not be attempted again. Note that these errors SHOULD be used in answer messages whose 'E' bit is not set. In error conditions where it is not possible or efficient to compose application-specific answer grammar, answer messages with the 'E' bit set and which comply to the grammar described in Section 7.2 MAY also be used for permanent errors.
永続的障害カテゴリに該当するエラーは、要求が失敗し、再試行すべきでないことをピアへ通知するために使用します。これらのエラーは、「E」ビットを設定していない応答メッセージで使用すべきです (SHOULD)。アプリケーション固有の応答文法を構成できない、または構成するのが非効率なエラー状態では、「E」ビットを設定し、セクション7.2で説明する文法へ準拠する応答メッセージを永続的エラーにも使用してもよい (MAY)。
DIAMETER_AVP_UNSUPPORTED 5001
DIAMETER_AVP_UNSUPPORTED 5001
The peer received a message that contained an AVP that is not recognized or supported and was marked with the 'M' (Mandatory) bit. A Diameter message with this error MUST contain one or more Failed-AVP AVPs containing the AVPs that caused the failure.
ピアは、認識またはサポートできず、「M」（Mandatory）ビットが設定されたAVPを含むメッセージを受信しました。このエラーを含むDiameterメッセージは、障害原因となったAVPを格納したFailed-AVP AVPを1つ以上含まなければなりません (MUST)。
DIAMETER_UNKNOWN_SESSION_ID 5002
DIAMETER_UNKNOWN_SESSION_ID 5002
The request contained an unknown Session-Id.
リクエストに不明なセッションIDが含まれていました。
DIAMETER_AUTHORIZATION_REJECTED 5003
DIAMETER_AUTHORIZATION_REJECTED 5003
A request was received for which the user could not be authorized. This error could occur if the service requested is not permitted to the user.
ユーザーを許可できない要求を受け取りました。このエラーは、要求されたサービスがユーザーに許可されていない場合に発生する可能性があります。
DIAMETER_INVALID_AVP_VALUE 5004
DIAMETER_INVALID_AVP_VALUE 5004
The request contained an AVP with an invalid value in its data portion. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP.
要求に、データ部分の値が無効なAVPが含まれていました。このエラーを示すDiameterメッセージは、問題のAVPをFailed-AVP AVP内に含めなければなりません (MUST)。
DIAMETER_MISSING_AVP 5005
DIAMETER_MISSING_AVP 5005
The request did not contain an AVP that is required by the Command Code definition. If this value is sent in the Result-Code AVP, a Failed-AVP AVP SHOULD be included in the message. The Failed-AVP AVP MUST contain an example of the missing AVP complete with the Vendor-Id if applicable. The value field of the missing AVP should be of correct minimum length and contain zeroes.
要求に、Command Code定義が必要とするAVPが含まれていませんでした。この値をResult-Code AVPで送信する場合、メッセージにFailed-AVP AVPを含めるべきです (SHOULD)。Failed-AVP AVPは、該当する場合にはVendor-Idまで含め、不足しているAVPの例を格納しなければなりません (MUST)。不足しているAVPのvalueフィールドは、正しい最小長とし、0を格納するのが望まれます。
DIAMETER_RESOURCES_EXCEEDED 5006
DIAMETER_RESOURCES_EXCEEDED 5006
A request was received that cannot be authorized because the user has already expended allowed resources. An example of this error condition is when a user that is restricted to one dial-up PPP port attempts to establish a second PPP connection.
ユーザーが既に許可されたリソースを消費しているため、許可できない要求を受け取りました。このエラー状態の例は、1つのダイヤルアップPPPポートに制限されているユーザーが2番目のPPP接続を確立しようとした場合です。
DIAMETER_CONTRADICTING_AVPS 5007
DIAMETER_CONTRADICTING_AVPS 5007
The Home Diameter server has detected AVPs in the request that contradicted each other, and it is not willing to provide service to the user. The Failed-AVP AVP MUST be present, which contain the AVPs that contradicted each other.
ホームDiameterサーバーは、要求内に互いに矛盾するAVPを検出し、ユーザーへサービスを提供する意思がありません。Failed-AVP AVPが存在しなければならず (MUST)、互いに矛盾するAVPを格納します。
DIAMETER_AVP_NOT_ALLOWED 5008
DIAMETER_AVP_NOT_ALLOWED 5008
A message was received with an AVP that MUST NOT be present. The Failed-AVP AVP MUST be included and contain a copy of the offending AVP.
存在してはならない (MUST NOT) AVPを含むメッセージを受信しました。Failed-AVP AVPを含めなければならず (MUST)、その中に問題のAVPのコピーを格納します。
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
A message was received that included an AVP that appeared more often than permitted in the message definition. The Failed-AVP AVP MUST be included and contain a copy of the first instance of the offending AVP that exceeded the maximum number of occurrences.
メッセージ定義が許可する回数を超えて出現するAVPを含むメッセージを受信しました。Failed-AVP AVPを含めなければならず (MUST)、その中に、最大出現回数を超過した最初の問題AVPのコピーを格納します。
DIAMETER_NO_COMMON_APPLICATION 5010
DIAMETER_NO_COMMON_APPLICATION 5010
This error is returned by a Diameter node that receives a CER whereby no applications are common between the CER sending peer and the CER receiving peer.
このエラーは、CERを受信するDiameterノードによって返され、CER送信ピアとCER受信ピアの間で共通のアプリケーションはありません。
DIAMETER_UNSUPPORTED_VERSION 5011
DIAMETER_UNSUPPORTED_VERSION 5011
This error is returned when a request was received, whose version number is unsupported.
このエラーは、サポートされていないバージョン番号のリクエストを受け取ったときに返されます。
DIAMETER_UNABLE_TO_COMPLY 5012
DIAMETER_UNABLE_TO_COMPLY 5012
This error is returned when a request is rejected for unspecified reasons.
このエラーは、不特定の理由でリクエストが拒否された場合に返されます。
DIAMETER_INVALID_BIT_IN_HEADER 5013
DIAMETER_INVALID_BIT_IN_HEADER 5013
This error is returned when a reserved bit in the Diameter header is set to one (1) or the bits in the Diameter header are set incorrectly.
このエラーは、Diameterヘッダーの予約済みビットが1に設定されているか、Diameterヘッダーのビットが正しく設定されていない場合に返されます。
DIAMETER_INVALID_AVP_LENGTH 5014
DIAMETER_INVALID_AVP_LENGTH 5014
The request contained an AVP with an invalid length. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. In cases where the erroneous AVP length value exceeds the message length or is less than the minimum AVP header length, it is sufficient to include the offending AVP header and a zero filled payload of the minimum required length for the payloads data type. If the AVP is a Grouped AVP, the Grouped AVP header with an empty payload would be sufficient to indicate the offending AVP. In the case where the offending AVP header cannot be fully decoded when the AVP length is less than the minimum AVP header length, it is sufficient to include an offending AVP header that is formulated by padding the incomplete AVP header with zero up to the minimum AVP header length.
要求に、長さが無効なAVPが含まれていました。このエラーを示すDiameterメッセージは、問題のAVPをFailed-AVP AVP内に含めなければなりません (MUST)。誤ったAVP Length値がメッセージ長を超える場合、またはAVPヘッダーの最小長を下回る場合は、問題のAVPヘッダーと、ペイロードのデータ型が必要とする最小長まで0で埋めたペイロードを含めれば十分です。AVPがGrouped AVPの場合、ペイロードを空にしたGrouped AVPヘッダーで問題のAVPを示せます。AVP LengthがAVPヘッダーの最小長を下回り、問題のAVPヘッダーを完全には復号できない場合、不完全なAVPヘッダーをAVPヘッダーの最小長まで0で埋めて構成した、問題のAVPヘッダーを含めれば十分です。
DIAMETER_INVALID_MESSAGE_LENGTH 5015
DIAMETER_INVALID_MESSAGE_LENGTH 5015
This error is returned when a request is received with an invalid message length.
このエラーは、無効なメッセージ長でリクエストを受信した場合に返されます。
DIAMETER_INVALID_AVP_BIT_COMBO 5016
DIAMETER_INVALID_AVP_BIT_COMBO 5016
The request contained an AVP with which is not allowed to have the given value in the AVP Flags field. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP.
要求に、AVP Flagsフィールドで指定された値を持つことが許可されていないAVPが含まれていました。このエラーを示すDiameterメッセージは、問題のAVPをFailed-AVP AVP内に含めなければなりません (MUST)。
DIAMETER_NO_COMMON_SECURITY 5017
DIAMETER_NO_COMMON_SECURITY 5017
This error is returned when a CER message is received, and there are no common security mechanisms supported between the peers. A Capabilities-Exchange-Answer (CEA) message MUST be returned with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY.
このエラーは、CERメッセージを受信し、ピア間で共通してサポートするセキュリティ機構がない場合に返します。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 CCF specification for the command; instead, it and will conform to the following CCF:
要求がプロトコル関連エラーを引き起こした場合、Diameterヘッダー内の「E」（Error Bit）を設定します（セクション7.1.3を参照）。「E」ビットを設定したメッセージを、応答メッセージに対する応答として送信してはなりません (MUST NOT)。「E」ビットを設定したメッセージも、セクション6.2で定義する処理規則の対象になることに注意してください。このビットを設定した場合、応答メッセージはそのコマンドのCCF仕様には準拠せず、代わりに次のCCFへ準拠します：
Message Format
メッセージフォーマット
<answer-message> ::= < Diameter Header: code, ERR [, PXY] >
0*1< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Experimental-Result ]
* [ Proxy-Info ]
* [ AVP ]
Note that the code used in the header is the same than the one found in the request message, but with the 'R' bit cleared and the 'E' bit set. The 'P' bit in the header is set to the same value as the one found in the request message.
ヘッダーで使用されるコードは要求メッセージで見つかったものと同じですが、「R」ビットがクリアされ、「E」ビットが設定されていることに注意してください。ヘッダーの「P」ビットは、要求メッセージにあるものと同じ値に設定されます。
The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY accompany a Result-Code AVP as a human-readable error message. The Error-Message AVP is not intended to be useful in an environment where error messages are processed automatically. It SHOULD NOT be expected that the content of this AVP be parsed by network entities.
Error-Message AVP（AVP Code 281）はUTF8String型です。人間が読めるエラーメッセージとしてResult-Code AVPに付随してもよい (MAY)。Error-Message AVPは、エラーメッセージを自動処理する環境で役立つことを意図していません。ネットワークエンティティがこの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 it MUST be set when the Result-Code AVP indicates a failure.
Error-Reporting-Host AVP（AVP Code 294）はDiameterIdentity型です。このAVPには、Result-Codeを設定したホストがOrigin-Host 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. A Diameter answer message SHOULD contain an instance of the Failed-AVP AVP that corresponds to the error indicated by the Result-Code AVP. For practical purposes, this Failed-AVP would typically refer to the first AVP processing error that a Diameter node encounters.
Failed-AVP AVP（AVPコード279）はグループ化されたタイプであり、特定のAVPの誤った情報が原因でリクエストが拒否された場合や完全に処理されなかった場合のデバッグ情報を提供します。 Result-Code AVPの値は、Failed-AVP AVPの理由に関する情報を提供します。 Diameter応答メッセージには、Result-Code AVPによって示されるエラーに対応するFailed-AVP AVPのインスタンスが含まれる必要があります（SHOULD）。実際には、このFailed-AVPは通常、Diameterノードで発生する最初のAVP処理エラーを参照します。
The possible reasons for this AVP are the presence of an improperly constructed AVP, an unsupported or unrecognized AVP, an invalid AVP value, the omission of a required AVP, the presence of an explicitly excluded AVP (see tables in Section 10) or the presence of two or more occurrences of an AVP that is restricted to 0, 1, or 0-1 occurrences.
このAVPの考えられる理由は、不適切に構築されたAVPの存在、サポートされていない、または認識されていないAVP、無効なAVP値、必要なAVPの省略、明示的に除外されたAVPの存在（セクション10の表を参照）または存在です。 0、1、または0-1の発生に制限されているAVPの2つ以上の発生の。
A Diameter message SHOULD contain one Failed-AVP AVP, containing the entire AVP that could not be processed successfully. If the failure reason is omission of a required AVP, an AVP with the missing AVP code, the missing Vendor-Id, and a zero-filled payload of the minimum required length for the omitted AVP will be added. If the failure reason is an invalid AVP length where the reported length is less than the minimum AVP header length or greater than the reported message length, a copy of the offending AVP header and a zero-filled payload of the minimum required length SHOULD be added.
Diameterメッセージには、正常に処理できなかったAVP全体を含むFailed-AVP AVPが1つ含まれる必要があります（SHOULD）。失敗の理由が必要なAVPの省略である場合は、AVPコードが欠落しているAVP、欠落しているベンダーID、および省略されたAVPに必要な最小長のゼロで満たされたペイロードが追加されます。失敗の理由が無効なAVPの長さであり、報告された長さが最小のAVPヘッダー長よりも短いか、報告されたメッセージの長さよりも長い場合、問題のAVPヘッダーのコピーとゼロで埋められた最小必要長のペイロードを追加する必要があります（SHOULD） 。
In the case where the offending AVP is embedded within a Grouped AVP, the Failed-AVP MAY contain the grouped AVP, which in turn contains the single offending AVP. The same method MAY be employed if the grouped AVP itself is embedded in yet another grouped AVP and so on. In this case, the Failed-AVP MAY contain the grouped AVP hierarchy up to the single offending AVP. This enables the recipient to detect the location of the offending AVP when embedded in a group.
問題のAVPがGrouped AVP内に埋め込まれている場合、Failed-AVPは、その問題のAVPだけを内部に含むGrouped AVPを格納してもよい (MAY)。そのGrouped AVP自体がさらに別のGrouped AVPへ埋め込まれている場合などにも、同じ方法を使用してもよい (MAY)。この場合、Failed-AVPは、単一の問題AVPまでのGrouped AVP階層を格納してもよい (MAY)。これにより、受信側はグループ内に埋め込まれた問題AVPの位置を検出できます。
AVP Format
AVPフォーマット
<Failed-AVP> ::= < AVP Header: 279 >
1* {AVP}
The Experimental-Result AVP (AVP Code 297) is of type Grouped, and indicates whether a particular vendor-specific request was completed successfully or whether an error occurred. This AVP has the following structure:
The Experimental-Result AVP (AVP Code 297) is of type Grouped, and indicates whether a particular vendor-specific request was completed successfully or whether an error occurred. This AVP has the following structure:
AVP Format
AVPフォーマット
Experimental-Result ::= < AVP Header: 297 >
{ Vendor-Id }
{ Experimental-Result-Code }
The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP identifies the vendor responsible for the assignment of the result code that follows. All Diameter answer messages defined in vendor-specific applications MUST include either one Result-Code AVP or one Experimental-Result AVP.
このGrouped AVP内のVendor-Id AVP（セクション5.3.3を参照）は、後続するresult codeの割り当てを担当するベンダーを識別します。ベンダー固有アプリケーションで定義するすべての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に指定された同じ規則に従うことをお勧めします。
In general, Diameter can provide two different types of services to applications. The first involves authentication and authorization, and it can optionally make use of accounting. The second only makes use of accounting.
一般に、Diameterは2つの異なるタイプのサービスをアプリケーションに提供できます。 1つ目は認証と承認を含み、オプションでアカウンティングを利用できます。 2つ目はアカウンティングのみを使用します。
When a service makes use of the authentication and/or authorization portion of an application, and a user requests access to the network, the Diameter client issues an auth request to its local server. The auth request is defined in a service-specific Diameter application (e.g., NASREQ). The request contains a Session-Id AVP, which is used in subsequent messages (e.g., subsequent authorization, accounting, etc.) relating to the user's session. The Session-Id AVP is a means for the client and servers to correlate a Diameter message with a user session.
サービスがアプリケーションの認証および/または承認部分を利用し、ユーザーがネットワークへのアクセスをリクエストすると、Diameterクライアントはローカルサーバーに認証リクエストを発行します。認証要求は、サービス固有のDiameterアプリケーション（NASREQなど）で定義されます。リクエストには、ユーザーのセッションに関連する後続のメッセージ（たとえば、後続の承認、アカウンティングなど）で使用されるSession-Id AVPが含まれています。 Session-Id AVPは、クライアントとサーバーがDiameterメッセージをユーザーセッションと関連付けるための手段です。
When a Diameter server authorizes a user to implement network resources for a finite amount of time, and it is willing to extend the authorization via a future request, it MUST add the Authorization- Lifetime AVP to the answer message. The Authorization-Lifetime AVP defines the maximum number of seconds a user MAY make use of the resources before another authorization request is expected by the server. The Auth-Grace-Period AVP contains the number of seconds following the expiration of the Authorization-Lifetime, after which the server will release all state information related to the user's session. Note that if payment for services is expected by the serving realm from the user's home realm, the Authorization-Lifetime AVP, combined with the Auth-Grace-Period AVP, implies the maximum length of the session for which the home realm is willing to be fiscally responsible. Services provided past the expiration of the Authorization-Lifetime and Auth-Grace-Period AVPs are the responsibility of the access device. Of course, the actual cost of services rendered is clearly outside the scope of the protocol.
Diameterサーバーがユーザーに有限時間だけネットワークリソースの使用を認可し、将来の要求によって認可を延長する意思がある場合、応答メッセージにAuthorization-Lifetime AVPを追加しなければなりません (MUST)。Authorization-Lifetime AVPは、サーバーが次の認可要求を予期するまでユーザーがリソースを使用してもよい (MAY) 最大秒数を定義します。Auth-Grace-Period AVPには、Authorization-Lifetimeの満了後、サーバーがユーザーのセッションに関する全状態情報を解放するまでの秒数が入ります。サービス提供realmがユーザーのホームrealmへサービス料金の支払いを期待する場合、Authorization-Lifetime AVPとAuth-Grace-Period AVPを合わせた値は、ホームrealmが金銭的責任を負う意思のあるセッションの最大長を意味します。Authorization-Lifetime AVPおよび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 are used to terminate user sessions. These are used to allow servers that maintain state information to free resources.
これらは主にアプリケーション固有であり、Diameterアプリケーションドキュメントで定義されているため、ベースプロトコルには認証要求メッセージは含まれていません。ただし、基本プロトコルは、ユーザーセッションの終了に使用される一連のメッセージを定義します。これらは、状態情報を維持するサーバーがリソースを解放できるようにするために使用されます。
When a service only makes use of the accounting portion of the Diameter protocol, even in combination with an application, the Session-Id is still used to identify user sessions. However, the session termination messages are not used, since a session is signaled as being terminated by issuing an accounting stop message.
When a service only makes use of the accounting portion of the Diameter protocol, even in combination with an application, the Session-Id is still used to identify user sessions. However, the session termination messages are not used, since a session is signaled as being terminated by issuing an accounting stop message.
Diameter may also be used for services that cannot be easily categorized as authentication, authorization, or accounting (e.g., certain Third Generation Partnership Project Internet Multimedia System (3GPP IMS) interfaces). In such cases, the finite state machine defined in subsequent sections may not be applicable. Therefore, the application itself MAY need to define its own finite state machine. However, such application-specific state machines SHOULD follow the general state machine framework outlined in this document such as the use of Session-Id AVPs and the use of STR/STA, ASR/ASA messages for stateful sessions.
Diameterは、認証、認可、アカウンティングへ容易に分類できないサービス（たとえば、Third Generation Partnership Project Internet Multimedia System（3GPP IMS）の一部インターフェース）にも使用される場合があります。その場合、後続のセクションで定義する有限状態マシンは適用できない可能性があります。したがって、アプリケーション自体が独自の有限状態マシンを定義する必要が生じてもよい (MAY)。ただし、このようなアプリケーション固有のステートマシンは、Session-Id AVPの使用や、状態を保持するセッションでのSTR/STAおよびASR/ASAメッセージの使用など、本文書で概説する一般的なステートマシンの枠組みに従うべきです (SHOULD)。
This section contains a set of finite state machines, which represent the life cycle of Diameter sessions and which MUST be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. The term "Service-Specific" below refers to a message defined in a Diameter application (e.g., Mobile IPv4, NASREQ).
このセクションには、Diameterセッションのライフサイクルを表す一組の有限状態マシンを示します。Diameterアプリケーションの認証部分または認可部分、あるいはその両方を使用するすべてのDiameter実装は、これらを遵守しなければなりません (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.
There are four different authorization session state machines supported in the Diameter base protocol. The first two describe a session in which the server is maintaining session state, indicated by the value of the Auth-Session-State AVP (or its absence). One describes the session from a client perspective, the other from a server perspective. The second two state machines are used when the server does not maintain session state. Here again, one describes the session from a client perspective, the other from a server perspective.
When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered an error condition, and an answer, if applicable, MUST be returned to the originator of the message.
セッションがIdle状態へ移ると、そのセッションに割り当てていたすべてのリソースを解放する必要があります。ステートマシンに列挙されていないイベントはエラー状態とみなさなければならず (MUST)、該当する場合はメッセージの生成元へ応答を返さなければなりません (MUST)。
In the case that an application does not support re-auth, the state transitions related to server-initiated re-auth, when both client and server sessions maintain state (e.g., Send RAR, Pending, Receive RAA), MAY be ignored.
アプリケーションが再認証をサポートしていない場合、クライアントとサーバーの両方のセッションが状態を維持するとき（たとえば、RARの送信、保留、RAAの受信）、サーバーが開始した再認証に関連する状態遷移は無視されます（MAY）。
In the state table, the event "Failure to send X" means that the Diameter agent is unable to send command X to the desired destination. This could be due to the peer being down or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the Result-Code AVP of the corresponding Answer command. The event 'X successfully sent' is the complement of 'Failure to send X'.
状態テーブルで、「Xの送信に失敗しました」というイベントは、DiameterエージェントがコマンドXを目的の宛先に送信できないことを意味します。これは、ピアがダウンしているか、ピアが一時的な障害または対応するAnswerコマンドのResult-Code AVPの一時的なプロトコルエラー通知DIAMETER_TOO_BUSYまたはDIAMETER_LOOP_DETECTEDを送り返していることが原因である可能性があります。イベント「Xの送信に成功しました」は、「Xの送信に失敗しました」の補足です。
The following state machine is observed by a client when state is maintained on the server:
次のステートマシンは、サーバー上で状態が維持されるときにクライアントによって監視されます。
CLIENT, STATEFUL
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send Pending
access service-
specific
auth req
Idle ASR Received Send ASA Idle
for unknown session with
Result-Code =
UNKNOWN_
SESSION_ID
Idle RAR Received Send RAA Idle
for unknown session with
Result-Code =
UNKNOWN_
SESSION_ID
Pending Successful service-specific Grant Open
authorization answer Access
received with default
Auth-Session-State value
Pending Successful service-specific Sent STR Discon authorization answer received, but service not provided
保留中のサービス固有の送信済みSTR Discon承認応答を受信しましたが、サービスは提供されていません
Pending Error processing successful Sent STR Discon service-specific authorization answer
保留中のエラー処理が正常に送信されましたSTR Disconサービス固有の認証回答
Pending Failed service-specific Clean up Idle authorization answer received
保留中の失敗したサービス固有のクリーンアップアイドル認証応答を受信
Open User or client device Send Open
requests access to service service-
specific
auth req
Open Successful service-specific Provide Open authorization answer received service
Open成功したサービス固有のOpen Open認証の回答を受け取った
Open Failed service-specific Discon. Idle
authorization answer user/device
received.
Open RAR received and client will Send RAA Open
perform subsequent re-auth with
Result-Code =
SUCCESS
Open RAR received and client will Send RAA Idle
not perform subsequent with
re-auth Result-Code !=
SUCCESS,
Discon.
user/device
Open Session-Timeout expires on Send STR Discon access device
Send STR DisconアクセスデバイスでOpen Session-Timeoutが期限切れになる
Open ASR received, Send ASA Discon
client will comply with
with request to end the Result-Code =
session = SUCCESS,
Send STR.
Open ASR Received, Send ASA Open
client will not comply with
with request to end the Result-Code !=
session != SUCCESS
Open Authorization-Lifetime + Send STR Discon Auth-Grace-Period expires on access device
Open Authorization-Lifetime + Send STR Discon Auth-Grace-Period expires on access device
Discon ASR received Send ASA Discon
Discon STA received Discon. Idle
user/device
The following state machine is observed by a server when it is maintaining state for the session:
次の状態マシンは、サーバーがセッションの状態を維持しているときに監視されます。
SERVER, STATEFUL
State Event Action New State
---------------------------------------------------------------
Idle Service-specific authorization Send Open
request received, and successful
user is authorized service-
specific
answer
Idle Service-specific authorization Send Idle
request received, and failed
user is not authorized service-
specific
answer
Open Service-specific authorization Send Open
request received, and user successful
is authorized service-
specific
answer
Open Service-specific authorization Send Idle
request received, and user failed
is not authorized service-
specific
answer,
Clean up
Open Home server wants to confirm Send RAR Pending authentication and/or authorization of the user
Open Homeサーバーが、RAR送信の保留中の認証やユーザーの承認を確認したい
Pending Received RAA with a failed Clean up Idle Result-Code
クリーンアップアイドル結果コードが失敗した保留中の受信RAA
Pending Received RAA with Result-Code Update Open
= SUCCESS session
Open Home server wants to Send ASR Discon terminate the service
Open HomeサーバーがASR Disconを送信してサービスを終了したい
Open Authorization-Lifetime (and Clean up Idle Auth-Grace-Period) expires on home server
ホームサーバーでOpen Authorization-Lifetime（およびClean up Idle Auth-Grace-Period）が期限切れになる
Open Session-Timeout expires on Clean up Idle home server
クリーンアップアイドルホームサーバーでオープンセッションタイムアウトが期限切れになる
Discon Failure to send ASR Wait, Discon resend ASR
DisconはASR待機の送信に失敗し、DisconはASRを再送信します
Discon ASR successfully sent and Clean up Idle ASA Received with Result-Code
Discon ASRは正常に送信され、結果コードで受信されたアイドルASAをクリーンアップします
Not ASA Received None No Change Discon
ASAが受け取らなかったなし変更ディスコンなし
Any STR Received Send STA, Idle Clean up
STRを受信して送信STA、アイドルクリーンアップ
The following state machine is observed by a client when state is not maintained on the server:
次の状態マシンは、サーバー上で状態が維持されていないときにクライアントによって監視されます。
CLIENT, STATELESS
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send Pending
access service-
specific
auth req
Pending Successful service-specific Grant Open
authorization answer access
received with Auth-Session-
State set to
NO_STATE_MAINTAINED
Pending Failed service-specific Clean up Idle authorization answer received
保留中の失敗したサービス固有のクリーンアップアイドル認証応答を受信
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 Idle
request received, and service-
successfully processed specific
answer
The following state machines MUST be supported for applications that have an accounting portion or that require only accounting services. The first state machine is to be observed by clients.
アカウンティング部分を持つアプリケーション、またはアカウンティングサービスだけを必要とするアプリケーションでは、次のステートマシンをサポートしなければなりません (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 it does not place any standards requirement on the processing of these records. Implementations of Diameter may perform checking, ordering, correlation, fraud detection, and other tasks based on these records. AVPs may need to be inspected as a part of these tasks. The tasks can happen either immediately after record reception or in a post-processing phase. However, as these tasks are typically application or even policy dependent, they are not standardized by the Diameter specifications. Applications MAY define requirements on when to accept accounting records based on the used value of Accounting-Realtime-Required AVP, credit-limit checks, and so on.
デフォルトのサーバー側のステートマシンでは、アカウンティングレコードを任意の順序でいつでも受信する必要があり、これらのレコードの処理に関する標準要件はありません。 Diameterの実装では、これらのレコードに基づいて、チェック、順序付け、相関、不正検出、およびその他のタスクを実行できます。 AVPは、これらのタスクの一部として検査する必要がある場合があります。タスクは、レコードの受信直後または後処理フェーズで発生する可能性があります。ただし、これらのタスクは通常アプリケーションまたはポリシーに依存するため、Diameter仕様によって標準化されていません。アプリケーションは、Accounting-Realtime-Required AVP、信用限度チェックなどの使用された値に基づいて、会計記録をいつ受け入れるかについての要件を定義できます（MAY）。
However, the Diameter base protocol defines one optional server side state machine that MAY be followed by applications that require keeping track of the session state at the accounting server. Note that such tracking is incompatible with the ability to sustain long duration connectivity problems. Therefore, the use of this state machine is recommended only in applications where the value of the Accounting-Realtime-Required AVP is DELIVER_AND_GRANT; hence, accounting connectivity problems are required to cause the serviced user to be disconnected. Otherwise, records produced by the client may be lost by the server, which no longer accepts them after the connectivity is re-established. This state machine is the third state machine in this section. The state machine is supervised by a supervision session timer Ts, whose value should be reasonably higher than the Acct_Interim_Interval value. Ts MAY be set to two times the value of the Acct_Interim_Interval so as to avoid the accounting session in the Diameter server to change to Idle state in case of short transient network failure.
ただしDiameter基本プロトコルは、アカウンティングサーバーでセッション状態を追跡する必要があるアプリケーションが従ってもよい (MAY)、オプションのサーバー側ステートマシンを1つ定義します。このような追跡は、長時間の接続障害へ耐える能力と両立しないことに注意してください。そのため、このステートマシンの使用は、Accounting-Realtime-Required AVPの値がDELIVER_AND_GRANTであり、したがってアカウンティング接続の障害時にサービス対象ユーザーを切断する必要があるアプリケーションだけに推奨します。そうでない場合、クライアントが生成したレコードをサーバーが失い、接続の再確立後には受け付けなくなる可能性があります。これは、このセクションの3番目のステートマシンです。ステートマシンは監視セッションタイマーTsで監視し、その値はAcct_Interim_Interval値より十分大きくすることが望まれます。短時間の一時的なネットワーク障害でDiameterサーバー上のアカウンティングセッションがIdle状態へ移ることを避けるため、TsをAcct_Interim_Interval値の2倍に設定してもよい (MAY)。
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クライアントが目的の宛先と通信できないことを意味します。これは、ピアがダウンしているか、ピアが一時的な障害または一時的なプロトコルエラー通知を返しているためである可能性があります。
The event "Failed answer" means that the Diameter client received a non-transient failure notification in the Accounting Answer command.
イベント「失敗した回答」は、Diameterクライアントがアカウンティング回答コマンドで非一時的な失敗通知を受け取ったことを意味します。
Note that the action "Disconnect user/dev" MUST also have an effect on the authorization session state table, e.g., cause the STR message to be sent, if the given application has both authentication/ authorization and accounting portions.
あるアプリケーションが認証/認可部分とアカウンティング部分の両方を持つ場合、アクション「Disconnect user/dev」は、たとえばSTRメッセージを送信させるなど、認可セッション状態テーブルにも影響を与えなければならない (MUST) ことに注意してください。
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 real time Start not equal to DELIVER_AND_GRANT Record
PendingS送信およびバッファのオープンに失敗しました。利用可能なリアルタイムの空き領域とリアルタイムの開始がDELIVER_AND_GRANTレコードと等しくありません
PendingS Failure to send and no buffer Open space available and real time equal to GRANT_AND_LOSE
PendingS送信に失敗し、バッファがありません。使用可能な空き領域があり、リアルタイムはGRANT_AND_LOSEと同じです
PendingS Failure to send and no Disconnect Idle
buffer space available and user/dev
real time not equal to
GRANT_AND_LOSE
PendingS Failed accounting start answer Open received and real time equal to GRANT_AND_LOSE
PendingS失敗したアカウンティング開始応答Openが受信され、リアルタイムはGRANT_AND_LOSEに等しい
PendingS Failed accounting start answer Disconnect Idle
received and real time not user/dev
equal to GRANT_AND_LOSE
PendingS User service terminated Store PendingS stop record
PendingSユーザーサービスが終了しましたStore PendingS停止レコード
Open Interim interval elapses Send PendingI accounting interim record
Open Interimインターバルが経過し、Send PendingIアカウンティング中間レコード
Open User service terminated Send PendingL accounting stop req.
オープンユーザーサービスが終了しましたPendingLアカウンティング停止要求の送信。
PendingI Successful accounting interim Open answer received
PendingI成功した会計中間オープン回答を受け取りました
PendingI Failure to send and (buffer Store Open
space available or old interim
record can be overwritten) record
and real time not equal to
DELIVER_AND_GRANT
PendingI Failure to send and no buffer Open space available and real time equal to GRANT_AND_LOSE
PendingI送信に失敗し、バッファオープンスペースがなく、リアルタイムでGRANT_AND_LOSEに等しい
PendingI Failure to send and no Disconnect Idle
buffer space available and user/dev
real time not equal to
GRANT_AND_LOSE
PendingI Failed accounting interim Open answer received and real time equal to GRANT_AND_LOSE
PendingI失敗したアカウンティング暫定オープン回答を受け取り、リアルタイムはGRANT_AND_LOSEに等しい
PendingI Failed accounting interim Disconnect Idle
answer received and user/dev
real time not equal to
GRANT_AND_LOSE
PendingI 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 Failure to send Idle
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
Open Session supervision timer Ts Stop Ts Idle expired
A Diameter server may initiate a re-authentication and/or re-authorization service for a particular session by issuing a Re-Auth-Request (RAR).
Diameterサーバーは、再認証リクエスト（RAR）を発行することにより、特定のセッションの再認証サービスや再認証サービスを開始できます。
For example, for prepaid services, the Diameter server that originally authorized a session may need some confirmation that the user is still using the services.
たとえば、プリペイドサービスの場合、最初にセッションを承認したDiameterサーバーは、ユーザーがまだサービスを使用していることを確認する必要があります。
An access device that receives an RAR message with the Session-Id equal to a currently active session MUST initiate a re-auth towards the user, if the service supports this particular feature. Each Diameter application MUST state whether server-initiated re-auth is supported, since some applications do not allow access devices to prompt the user for re-auth.
サービスがこの機能をサポートしている場合、現在アクティブなセッションと同じSession-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.
258に設定されたコマンドコードとメッセージフラグの「R」ビットセットで示される再認証要求（RAR）は、セッションサービスを提供しているアクセスデバイスにサーバーから送信され、ユーザーに再認証および/または再承認されます。
Message Format
メッセージフォーマット
<RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Re-Auth-Answer (RAA), indicated by the Command Code set to 258 and the message flags' 'R' bit clear, is sent in response to the RAR. The Result-Code AVP MUST be present, and it indicates the disposition of the request.
コマンドコードが258に設定され、メッセージフラグの「R」ビットがクリアされていることで示される再認証応答（RAA）は、RARに応答して送信されます。 Result-Code AVPが存在しなければならず（MUST）、リクエストの処理を示します。
A successful RAA message MUST be followed by an application-specific authentication and/or authorization message.
成功を示すRAAメッセージの後には、アプリケーション固有の認証メッセージ、認可メッセージ、またはその両方が続かなければなりません (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-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
It is necessary for a Diameter server that authorized a session, for which it is maintaining state, to be notified when that session is no longer active, both for tracking purposes as well as to allow stateful agents to release any resources that they may have provided for the user's session. For sessions whose state is not being maintained, this section is not used.
状態を維持しているセッションを承認したDiameterサーバーは、そのセッションがアクティブでなくなったときに通知される必要があります。これは、追跡の目的と、ステートフルエージェントが提供したリソースを解放できるようにするための両方です。ユーザーのセッション用。状態が維持されていないセッションの場合、このセクションは使用されません。
When a user session that required Diameter authorization terminates, the access device that provided the service MUST issue a Session-Termination-Request (STR) message to the Diameter server that authorized the service, to notify it that the session is no longer active. An STR MUST be issued when a user session terminates for any reason, including user logoff, expiration of Session-Timeout, administrative action, termination upon receipt of an Abort-Session-Request (see below), orderly shutdown of the access device, etc.
Diameter認可を必要としたユーザーセッションが終了した場合、サービスを提供したアクセスデバイスは、そのサービスを認可したDiameterサーバーへSession-Termination-Request（STR）メッセージを発行し、セッションがアクティブでなくなったことを通知しなければなりません (MUST)。ユーザーのログオフ、Session-Timeoutの満了、管理操作、Abort-Session-Request（後述）の受信による終了、アクセスデバイスの正常な停止など、理由を問わずユーザーセッションが終了した場合にSTRを発行しなければなりません (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 expire without receipt of a re-authorization request, regardless of whether an STR for that session is received. The access device is not expected to provide service beyond the expiration of these timers; thus, expiration of either of these timers implies that the access device may have unexpectedly shut down.
Diameterサーバーは、そのセッションの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 a Diameter client or by a Diameter proxy to inform the Diameter server that an authenticated and/or authorized session is being terminated.
コマンドコードが275に設定され、コマンドフラグの「R」ビットが設定されていることで示されるセッション終了要求（STR）は、DiameterクライアントまたはDiameterプロキシによって送信され、Diameterサーバーに認証済みおよび/またはまたは、許可されたセッションが終了しています。
Message Format
メッセージフォーマット
<STR> ::= < Diameter Header: 275, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Termination-Cause }
[ User-Name ]
[ Destination-Host ]
* [ Class ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Session-Termination-Answer (STA), indicated by the Command Code set to 275 and the message flags' 'R' bit clear, is sent by the Diameter server to acknowledge the notification that the session has been terminated. The Result-Code AVP MUST be present, and it MAY contain an indication that an error occurred while servicing the STR.
Command Codeを275に設定し、メッセージフラグの「R」ビットをクリアすることで示されるSession-Termination-Answer（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サーバーは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 lack of credit or other reasons that were not anticipated when the session was first authorized.
たとえば、最初にセッションを承認したDiameterサーバーは、クレジットの不足や、セッションが最初に承認されたときに予期されなかったその他の理由により、そのセッションを停止する必要がある場合があります。
An access device that receives an ASR with Session-ID equal to a currently active session MAY stop the session. Whether the access device stops the session or not is implementation and/or configuration dependent. For example, an access device may honor ASRs from certain agents only. In any case, the access device MUST respond with an Abort-Session-Answer, including a Result-Code AVP to indicate what action it took.
現在アクティブなセッションと同じSession-Idを持つASRを受信したアクセスデバイスは、そのセッションを停止してもよい (MAY)。アクセスデバイスがセッションを停止するかどうかは、実装または設定、あるいはその両方に依存します。たとえば、アクセスデバイスが特定エージェントからのASRだけを受け入れる場合があります。いずれの場合も、アクセスデバイスは、実行した処理を示すResult-Code AVPを含むAbort-Session-Answerで応答しなければなりません (MUST)。
The Abort-Session-Request (ASR), indicated by the Command Code set to 274 and the message flags' 'R' bit set, may be sent by any Diameter server or any Diameter proxy to the access device that is providing session service, to request that the session identified by the Session-Id be stopped.
274に設定されたコマンドコードとメッセージフラグの「R」ビットセットで示される中止セッション要求（ASR）は、任意のDiameterサーバーまたは任意のDiameterプロキシによって、セッションサービスを提供しているアクセスデバイスに送信できます。 Session-Idで識別されるセッションの停止を要求する。
Message Format
メッセージフォーマット
<ASR> ::= < Diameter Header: 274, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Abort-Session-Answer (ASA), indicated by the Command Code set to 274 and the message flags' 'R' bit clear, is sent in response to the ASR. The Result-Code AVP MUST be present and indicates the disposition of the request.
Command Codeを274に設定し、メッセージフラグの「R」ビットをクリアすることで示されるAbort-Session-Answer（ASA）は、ASRへの応答として送信します。Result-Code AVPが存在しなければならず (MUST)、要求をどう処理したかを示します。
If the session identified by Session-Id in the ASR was successfully terminated, the Result-Code is set to DIAMETER_SUCCESS. If the session is not currently active, the Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the session for any other reason, the Result-Code is set to DIAMETER_UNABLE_TO_COMPLY.
ASRのSession-Idで識別されるセッションが正常に終了した場合、Result-CodeはDIAMETER_SUCCESSに設定されます。セッションが現在アクティブでない場合、Result-CodeはDIAMETER_UNKNOWN_SESSION_IDに設定されます。アクセスデバイスが他の理由でセッションを停止しない場合、Result-CodeはDIAMETER_UNABLE_TO_COMPLYに設定されます。
Message Format
メッセージフォーマット
<ASA> ::= < Diameter Header: 274, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
The Origin-State-Id is used to allow detection of terminated sessions for which no STR would have been issued, due to unanticipated shutdown of an access device.
Origin-State-Idは、アクセスデバイスの予期しないシャットダウンが原因でSTRが発行されなかった終了したセッションの検出を可能にするために使用されます。
A Diameter client or access device increments the value of the Origin-State-Id every time it is started or powered up. The new Origin-State-Id is then sent in the CER/CEA message immediately upon connection to the server. The Diameter server receiving the new Origin-State-Id can determine whether the sending Diameter client had abruptly shut down by comparing the old value of the Origin-State-Id it has kept for that specific client is less than the new value and whether it has un-terminated sessions originating from that client.
A Diameter client or access device increments the value of the Origin-State-Id every time it is started or powered up. The new Origin-State-Id is then sent in the CER/CEA message immediately upon connection to the server. The Diameter server receiving the new Origin-State-Id can determine whether the sending Diameter client had abruptly shut down by comparing the old value of the Origin-State-Id it has kept for that specific client is less than the new value and whether it has un-terminated sessions originating from that client.
An access device can also include the Origin-State-Id in request messages other than the CER if there are relays or proxies in between the access device and the server. In this case, however, the server cannot discover that the access device has been restarted unless and until it receives a new request from it. Therefore, this mechanism is more opportunistic across proxies and relays.
アクセスデバイスとサーバーの間にリレーまたはプロキシがある場合、アクセスデバイスはCER以外の要求メッセージにOrigin-State-Idを含めることもできます。ただし、この場合、サーバーは、アクセスデバイスから新しいリクエストを受信しない限り、アクセスデバイスが再起動されたことを検出できません。したがって、このメカニズムはプロキシとリレー全体でより便宜的です。
The Diameter server may assume that all sessions that were active prior to detection of a client restart have been terminated. The Diameter server MAY clean up all session state associated with such lost sessions, and it MAY also issue STRs for all such lost sessions that were authorized on upstream servers, to allow session state to be cleaned up globally.
Diameterサーバーは、クライアントの再起動が検出される前にアクティブであったすべてのセッションが終了したと想定する場合があります。 Diameterサーバーは、このような失われたセッションに関連付けられたすべてのセッション状態をクリーンアップできます（MAY）。また、上流のサーバーで承認されたすべての失われたセッションに対してSTRを発行して、セッション状態をグローバルにクリーンアップできるようにすることもできます（MAY）。
The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is included in application-specific auth requests to inform the peers whether a user is to be authenticated only, authorized only, or both. Note any value other than both MAY cause RADIUS interoperability issues. The following values are defined:
Auth-Request-Type AVP（AVP Code 274）はEnumerated型であり、アプリケーション固有のauth要求に含め、ユーザーを認証だけ、認可だけ、またはその両方の対象とするかをピアへ通知します。両方以外の値はRADIUSとの相互運用性問題を引き起こしてもよい (MAY) ことに注意してください。次の値を定義します：
AUTHENTICATE_ONLY 1
AUTHENTICATE_ONLY 1
The request being sent is for authentication only, and it MUST contain the relevant application-specific authentication AVPs that are needed by the Diameter server to authenticate the user.
送信する要求は認証だけを対象とし、Diameterサーバーがユーザーを認証するために必要な、関連するアプリケーション固有の認証AVPを含まなければなりません (MUST)。
AUTHORIZE_ONLY 2
AUTHORIZE_ONLY 2
The request being sent is for authorization only, and it MUST contain the application-specific authorization AVPs that are necessary to identify the service being requested/offered.
送信する要求は認可だけを対象とし、要求または提供されるサービスを識別するために必要な、アプリケーション固有の認可AVPを含まなければなりません (MUST)。
AUTHORIZE_AUTHENTICATE 3
AUTHORIZE AUTHENTICATE 3
The request contains a request for both authentication and authorization. The request MUST include both the relevant application-specific authentication information and authorization information necessary to identify the service being requested/ offered.
この要求は、認証と認可の両方を要求します。要求は、関連するアプリケーション固有の認証情報と、要求または提供されるサービスの識別に必要な認可情報の両方を含まなければなりません (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 Code 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 it may be needed to correlate historical authentication information with accounting information. The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below.
Session-Idは、他の情報を参照せずにユーザーセッションを一意に識別することを意図しており、過去の認証情報とアカウンティング情報を対応付けるために必要となる場合があるため、全世界的かつ永続的に一意でなければなりません (MUST)。Session-Idは必須部分と実装定義部分からなり、実装定義部分の推奨形式を以下に概説します。
The Session-Id MUST begin with the sender's identity encoded in the DiameterIdentity type (see Section 4.3.1). The remainder of the Session-Id is delimited by a ";" character, and it MAY be any sequence that the client can guarantee to be eternally unique; however, the following format is recommended, (square brackets [] indicate an optional element):
Session-Idは、DiameterIdentity型で符号化した送信側の識別情報から始めなければなりません (MUST)（セクション4.3.1を参照）。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 in NTP format [RFC5905], and the low 32 bits MAY be initialized to zero. This will for practical purposes eliminate the possibility of overlapping Session-Ids after a reboot, assuming the reboot process takes longer than a second. Alternatively, an implementation MAY keep track of the increasing value in non-volatile memory.
<high 32 bits>および<low 32 bits>は、単調増加する64ビット値の上位32ビットと下位32ビットを10進数で表したものです。32ビットプロセッサでの形式化を簡単にするため、64ビット値を2つの部分に分けて表します。起動時、64ビット値の上位32ビットをNTP形式[RFC5905]の時刻で初期化してもよく (MAY)、下位32ビットを0で初期化してもよい (MAY)。再起動処理に1秒より長くかかると仮定すれば、これにより再起動後にSession-Idが重複する可能性を実用上排除できます。別の方法として、実装は増加値を不揮発性メモリで追跡してもよい (MAY)。
<optional value> is implementation specific, but it may include a modem's device Id, a Layer 2 address, timestamp, etc.
<オプション値>は実装固有ですが、モデムのデバイスID、レイヤー2アドレス、タイムスタンプなどが含まれる場合があります。
Example, in which there is no optional value:
Example, in which there is no optional value:
accesspoint7.example.com;1876543210;523
accesspoint7.example.com; 1876543210; 523
Example, in which there is an optional value:
オプションの値がある例：
accesspoint7.example.com;1876543210;523;mobile@200.1.1.88
The Session-Id is created by the Diameter application initiating the session, which, in most cases, is done by the client. Note that a Session-Id MAY be used for both the authentication, authorization, and accounting commands of a given application.
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. Care should be taken when the Authorization-Lifetime value is determined, since a low, non-zero value could create significant Diameter traffic, which could congest both the network and the agents.
Authorization-Lifetime AVP（AVPコード291）のタイプはUnsigned32であり、ユーザーが再認証または再承認される前にユーザーに提供されるサービスの最大秒数が含まれています。 Authorization-Lifetime値を決定するときは注意が必要です。ゼロ以外の低い値を指定すると、Diameterトラフィックが大量に発生し、ネットワークとエージェントの両方が混雑する可能性があるためです。
A value of zero (0) means that immediate re-auth is necessary by the access device. The absence of this AVP, or a value of all ones (meaning all bits in the 32-bit field are set to one) means no re-auth is expected.
ゼロ（0）の値は、アクセスデバイスによる即時の再認証が必要であることを意味します。このAVPがない、またはすべて1の値（32ビットフィールドのすべてのビットが1に設定されていることを意味する）は、再認証が予期されないことを意味します。
If both this AVP and the Session-Timeout AVP are present in a message, the value of the latter MUST NOT be smaller than the Authorization-Lifetime AVP.
このAVPとSession-Timeout AVPの両方がメッセージに存在する場合、後者の値はAuthorization-Lifetime AVPより小さくてはなりません（MUST NOT）。
An Authorization-Lifetime AVP MAY be present in re-authorization messages, and it contains the number of seconds the user is authorized to receive service from the time the re-auth answer message is received by the access device.
Authorization-Lifetime AVPは再認可メッセージ内に存在してもよく (MAY)、アクセスデバイスが再認可応答メッセージを受信した時点から、ユーザーがサービスを受けることを認可される秒数を格納します。
This AVP MAY be provided by the client as a hint of the maximum lifetime that it is willing to accept. The server MUST return a value that is equal to, or smaller than, the one provided by the client.
クライアントは、自身が受け入れる意思のある最大存続期間を示すヒントとして、このAVPを提供してもよい (MAY)。サーバーは、クライアントが提供した値以下の値を返さなければなりません (MUST)。
The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and contains the number of seconds the Diameter server will wait following the expiration of the Authorization-Lifetime AVP before cleaning up resources for the session.
Auth-Grace-Period AVP（AVPコード276）のタイプはUnsigned32であり、セッションのリソースをクリーンアップする前に、Authorization-Lifetime AVPの期限切れ後にDiameterサーバーが待機する秒数が含まれています。
The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and specifies whether state is maintained for a particular session. The client MAY include this AVP in requests as a hint to the server, but the value in the server's answer message is binding. The following values are supported:
Auth-Session-State AVP（AVP Code 277）はEnumerated型であり、特定セッションの状態を維持するかどうかを指定します。クライアントはサーバーへのヒントとして要求にこのAVPを含めてもよい (MAY) ものの、サーバーの応答メッセージ内の値が拘束力を持ちます。次の値をサポートします：
STATE_MAINTAINED 0
STATE_MAINTAINED 0
This value is used to specify that session state is being maintained, and the access device MUST issue a session termination message when service to the user is terminated. This is the default value.
この値はセッション状態を維持していることを示すために使用し、ユーザーへのサービス終了時にアクセスデバイスはセッション終了メッセージを発行しなければなりません (MUST)。これはデフォルト値です。
NO_STATE_MAINTAINED 1
NO_STATE_MAINTAINED 1
This value is used to specify that no session termination messages will be sent by the access device upon expiration of the Authorization-Lifetime.
この値は、Authorization-Lifetimeの有効期限が切れたときにセッション終了メッセージがアクセスデバイスによって送信されないことを指定するために使用されます。
The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and is included in application-specific auth answers to inform the client of the action expected upon expiration of the Authorization-Lifetime.
Re-Auth-Request-Type AVP（AVPコード285）はEnumeratedタイプであり、アプリケーション固有の認証応答に含まれており、Authorization-Lifetimeの期限切れ時に予期されるアクションをクライアントに通知します。
If the answer message contains an Authorization-Lifetime AVP with a positive value, the Re-Auth-Request-Type AVP MUST be present in an answer message. The following values are defined:
応答メッセージが正の値を持つAuthorization-Lifetime AVPを含む場合、その応答メッセージ内にRe-Auth-Request-Type AVPが存在しなければなりません (MUST)。次の値を定義します：
AUTHORIZE_ONLY 0
AUTHORIZE_ONLY 0
An authorization only re-auth is expected upon expiration of the Authorization-Lifetime. This is the default value if the AVP is not present in answer messages that include the Authorization-Lifetime.
Authorization-Lifetimeの期限が切れると、承認のみの再認証が期待されます。これは、Authorization-Lifetimeを含む応答メッセージにAVPが存在しない場合のデフォルト値です。
AUTHORIZE_AUTHENTICATE 1
AUTHORIZE AUTHENTICATE 1
An authentication and authorization re-auth is expected upon expiration of the Authorization-Lifetime.
Authorization-Lifetimeの有効期限が切れると、認証と承認の再認証が期待されます。
The Session-Timeout AVP (AVP Code 27) [RFC2865] is of type Unsigned32 and contains the maximum number of seconds of service to be provided to the user before termination of the session. When both the Session-Timeout and the Authorization-Lifetime AVPs are present in an answer message, the former MUST be equal to or greater than the value of the latter.
セッションタイムアウトAVP（AVPコード27）[RFC2865]はUnsigned32タイプであり、セッションが終了する前にユーザーに提供されるサービスの最大秒数が含まれています。 Session-TimeoutとAuthorization-Lifetime AVPの両方が応答メッセージに存在する場合、前者は後者の値以上でなければなりません（MUST）。
A session that terminates on an access device due to the expiration of the Session-Timeout MUST cause an STR to be issued, unless both the access device and the home server had previously agreed that no session termination messages would be sent (see Section 8).
アクセスデバイスとホームサーバーの双方が、セッション終了メッセージを送信しないことに事前に合意している場合を除き、Session-Timeoutの満了によってアクセスデバイス上でセッションが終了したときはSTRを発行しなければなりません (MUST)（セクション8を参照）。
A Session-Timeout AVP MAY be present in a re-authorization answer message, and it contains the remaining number of seconds from the beginning of the re-auth.
Session-Timeout AVPは再認可応答メッセージ内に存在してもよく (MAY)、再認可の開始時点から数えた残り秒数を格納します。
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 Termination-Cause AVP (AVP Code 295) is of type Enumerated, and is used to indicate the reason why a session was terminated on the access device. The currently assigned values for this AVP can be found in the IANA registry for Termination-Cause AVP Values [IANATCV].
Termination-Cause AVP（AVPコード295）は列挙型であり、セッションがアクセスデバイスで終了した理由を示すために使用されます。このAVPに現在割り当てられている値は、終了原因AVP値[IANATCV]のIANAレジストリにあります。
The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a monotonically increasing value that is advanced whenever a Diameter entity restarts with loss of previous state, for example, upon reboot. Origin-State-Id MAY be included in any Diameter message, including CER.
Unsigned32型のOrigin-State-Id AVP（AVP 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. Typically, Origin-State-Id is used by an access device that always starts up with no active sessions; that is, any session active prior to restart will have been lost. By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0.
Origin-State-Idが存在する場合、Origin-Hostが示すエンティティの状態を反映しなければなりません (MUST)。プロキシがOrigin-Hostを変更する場合、Origin-State-Idも削除するか適切に変更しなければなりません (MUST)。通常、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 it MAY be present in application-specific authorization answer messages. If present, this AVP MAY inform the Diameter client that all future application-specific re-auth and Session-Termination-Request messages for this session MUST be sent to the same authorization server.
Session-Binding AVP（AVP Code 270）はUnsigned32型であり、アプリケーション固有の認可応答メッセージ内に存在してもよい (MAY)。存在する場合、このAVPはDiameterクライアントへバインディングを通知してもよい (MAY)。その通知は、このセッションについて今後送るすべてのアプリケーション固有再認可メッセージおよびSession-Termination-Requestメッセージを、同じ認可サーバーへ送信しなければならない (MUST) ことを意味します。
This field is a bit mask, and the following bits have been defined:
このフィールドはビットマスクであり、次のビットが定義されています。
RE_AUTH 1
RE_AUTH 1
When set, future re-auth messages for this session MUST NOT include the Destination-Host AVP. When cleared, the default value, the Destination-Host AVP MUST be present in all re-auth messages for this session.
設定した場合、このセッションの以後の再認可メッセージはDestination-Host AVPを含んではなりません (MUST NOT)。クリアした場合（デフォルト値）、このセッションのすべての再認可メッセージ内にDestination-Host AVPが存在しなければなりません (MUST)。
STR 2
STR 2
When set, the STR message for this session MUST NOT include the Destination-Host AVP. When cleared, the default value, the Destination-Host AVP MUST be present in the STR message for this session.
設定した場合、このセッションのSTRメッセージはDestination-Host AVPを含んではなりません (MUST NOT)。クリアした場合（デフォルト値）、このセッションのSTRメッセージ内にDestination-Host AVPが存在しなければなりません (MUST)。
ACCOUNTING 4
会計4
When set, all accounting messages for this session MUST NOT include the Destination-Host AVP. When cleared, the default value, the Destination-Host AVP, if known, MUST be present in all accounting messages for this session.
設定した場合、このセッションのすべてのアカウンティングメッセージは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) ことを意味します。存在しない場合、デフォルト値はREFUSE_SERVICEです。
The following values are supported:
次の値がサポートされています。
REFUSE_SERVICE 0
REFUSE_SERVICE 0
If either the re-auth or the STR message delivery fails, terminate service with the user and do not attempt any subsequent attempts.
再認証またはSTRメッセージの配信のいずれかが失敗した場合は、ユーザーとのサービスを終了し、その後の試行は行わないでください。
TRY_AGAIN 1
TRY_AGAIN 1
If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present.
再認証またはSTRメッセージの配信に失敗した場合は、Destination-Host AVPが存在しない状態で失敗したメッセージを再送信します。
ALLOW_SERVICE 2
ALLOW_SERVICE 2
If re-auth message delivery fails, assume that re-authorization succeeded. If STR message delivery fails, terminate the session.
再認証メッセージの配信が失敗した場合は、再認証が成功したと想定します。 STRメッセージの配信に失敗した場合は、セッションを終了します。
TRY_AGAIN_ALLOW_SERVICE 3
TRY_AGAIN_ALLOW_SERVICE 3
If either the re-auth or the STR message delivery fails, resend the failed message without the Destination-Host AVP present. If the second delivery fails for re-auth, assume re-authorization succeeded. If the second delivery fails for STR, terminate the session.
再認証またはSTRメッセージの配信に失敗した場合は、Destination-Host AVPが存在しない状態で失敗したメッセージを再送信します。 2回目の配信が再認証に失敗した場合は、再認証が成功したと見なします。 STRの2回目の配信が失敗した場合は、セッションを終了します。
The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32 and SHOULD be present in application-specific authorization answer messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH. This AVP contains the maximum number of seconds that the access device MUST provide the user in responding to an authentication request.
Multi-Round-Time-Out AVP（AVP 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 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 [RFC2975] have been built into the protocol in order minimize loss of accounting data in various fault situations and under different assumptions about the capabilities of the used devices.
このアカウンティングプロトコルは、アカウンティング情報のリアルタイム配信機能を備えたサーバー向けモデルに基づいています。さまざまな障害状況で、使用されているデバイスの機能に関するさまざまな想定の下でのアカウンティングデータの損失を最小限に抑えるために、いくつかの障害回復方法[RFC2975]がプロトコルに組み込まれています。
The server directed model means that the device generating the accounting data gets information from either the authorization server (if contacted) or the accounting server regarding the way accounting data shall be forwarded. This information includes accounting record timeliness requirements.
サーバー向けモデルとは、アカウンティングデータを生成するデバイスが、アカウンティングデータの転送方法に関して、承認サーバー（接続されている場合）またはアカウンティングサーバーから情報を取得することを意味します。この情報には、会計記録の適時性要件が含まれます。
As discussed in [RFC2975], real-time transfer of accounting records is a requirement, such as the need to perform credit-limit checks and fraud detection. Note that batch accounting is not a requirement, and is therefore not supported by Diameter. Should batched accounting be required in the future, a new Diameter application will need to be created, or it could be handled using another protocol. Note, however, that even if at the Diameter layer, accounting requests are processed one by one; transport protocols used under Diameter typically batch several requests in the same packet under heavy traffic conditions. This may be sufficient for many applications.
[RFC2975]で説明されているように、アカウンティングレコードのリアルタイム転送は、信用限度チェックや不正検出の実行などの要件です。バッチアカウンティングは必須ではないため、Diameterではサポートされていません。将来的にバッチアカウンティングが必要になった場合は、新しいDiameterアプリケーションを作成する必要があります。または、別のプロトコルを使用して処理することもできます。ただし、Diameterレイヤーにある場合でも、アカウンティング要求は1つずつ処理されることに注意してください。 Diameterで使用されるトランスポートプロトコルは、通常、トラフィックの多い状況で同じパケットにいくつかの要求をバッチ処理します。これは、多くのアプリケーションで十分な場合があります。
The authorization server (chain) directs the selection of proper transfer strategy, based on its knowledge of the user and relationships of roaming partnerships. The server (or agents) uses the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to control the operation of the Diameter peer operating as a client. The Acct-Interim-Interval AVP, when present, instructs the Diameter node acting as a client to produce accounting records continuously even during a session. Accounting-Realtime-Required AVP is used to control the behavior of the client when the transfer of accounting records from the Diameter client is delayed or unsuccessful.
承認サーバー（チェーン）は、ユーザーの知識とローミングパートナーシップの関係に基づいて、適切な転送戦略の選択を指示します。サーバー（またはエージェント）は、Acct-Interim-IntervalおよびAccounting-Realtime-Required AVPを使用して、クライアントとして動作するDiameterピアの動作を制御します。 Acct-Interim-Interval AVP（存在する場合）は、クライアントとして機能するDiameterノードに、セッション中でも継続的にアカウンティングレコードを生成するように指示します。 Accounting-Realtime-Required AVPは、Diameterクライアントからのアカウンティングレコードの転送が遅延または失敗したときのクライアントの動作を制御するために使用されます。
The Diameter accounting server MAY override the interim interval or the real-time requirements by including the Acct-Interim-Interval or Accounting-Realtime-Required AVP in the Accounting-Answer message. When one of these AVPs is present, the latest value received SHOULD be used in further accounting activities for the same session.
Diameterアカウンティングサーバーは、Accounting-AnswerメッセージにAcct-Interim-IntervalまたはAccounting-Realtime-Required AVPを含めることにより、暫定間隔またはリアルタイム要件をオーバーライドできます（MAY）。これらのAVPのいずれかが存在する場合、受け取った最新の値を同じセッションの以降の会計アクティビティで使用する必要があります（SHOULD）。
A Diameter node that receives a successful authentication and/or authorization message from the Diameter server SHOULD collect accounting information for the session. The Accounting-Request message is used to transmit the accounting information to the Diameter server, which MUST reply with the Accounting-Answer message to confirm reception. The Accounting-Answer message includes the Result-Code AVP, which MAY indicate that an error was present in the accounting message. The value of the Accounting-Realtime-Required AVP received earlier for the session in question may indicate that the user's session has to be terminated when a rejected Accounting-Request message was received.
Diameterサーバーから成功を示す認証メッセージ、認可メッセージ、またはその両方を受信したDiameterノードは、そのセッションのアカウンティング情報を収集すべきです (SHOULD)。Accounting-Requestメッセージはアカウンティング情報をDiameterサーバーへ送信するために使用し、Diameterサーバーは受信確認のためAccounting-Answerメッセージで応答しなければなりません (MUST)。Accounting-AnswerメッセージはResult-Code AVPを含み、アカウンティングメッセージにエラーがあったことを示してもよい (MAY)。対象セッションについて以前に受信したAccounting-Realtime-Required AVPの値は、拒否されたAccounting-Requestメッセージを受信した場合にユーザーセッションを終了する必要があることを示す場合があります。
Each Diameter application (e.g., NASREQ, Mobile IP) SHOULD define its service-specific AVPs that MUST be present in the Accounting-Request message in a section titled "Accounting AVPs". The application MUST assume that the AVPs described in this document will be present in all Accounting messages, so only their respective service-specific AVPs need to be defined in that section.
各Diameterアプリケーション（NASREQ、Mobile IPなど）は、サービス固有AVPを「Accounting AVPs」という表題のセクションで定義すべきです (SHOULD)。対象となるのは、Accounting-Requestメッセージ内に存在しなければならない (MUST) AVPです。アプリケーションは、本文書で説明するAVPがすべてのAccountingメッセージ内に存在すると仮定しなければならない (MUST) ため、そのセクションでは各サービス固有AVPだけを定義すれば十分です。
Applications have the option of using one or both of the following accounting application extension models:
アプリケーションには、次の会計アプリケーション拡張モデルのいずれかまたは両方を使用するオプションがあります。
Split Accounting Service
分割会計サービス
The accounting message will carry the Application Id of the Diameter base accounting application (see Section 2.4). Accounting messages may be routed to Diameter nodes other than the corresponding Diameter application. These nodes might be centralized accounting servers that provide accounting service for multiple different Diameter applications. These nodes MUST advertise the Diameter base accounting Application Id during capabilities exchange.
アカウンティングメッセージは、Diameter基本アカウンティングアプリケーションのApplication Idを運びます（セクション2.4を参照）。アカウンティングメッセージを、対応するDiameterアプリケーション以外のDiameterノードへルーティングする場合があります。このようなノードは、複数の異なるDiameterアプリケーションへアカウンティングサービスを提供する集中型アカウンティングサーバーである可能性があります。このようなノードは、能力交換時にDiameter基本アカウンティングApplication Idを通知しなければなりません (MUST)。
Coupled Accounting Service
連結会計サービス
The accounting message will carry the Application Id of the application that is using it. The application itself will process the received accounting records or forward them to an accounting server. There is no accounting application advertisement required during capabilities exchange, and the accounting messages will be routed the same way as any of the other application messages.
アカウンティングメッセージには、それを使用しているアプリケーションのアプリケーションIDが含まれます。アプリケーション自体は、受信したアカウンティングレコードを処理するか、アカウンティングサーバーに転送します。機能交換中に必要なアカウンティングアプリケーションアドバタイズメントはなく、アカウンティングメッセージは他のアプリケーションメッセージと同じ方法でルーティングされます。
In cases where an application does not define its own accounting service, it is preferred that the split accounting model be used.
アプリケーションが独自のアカウンティングサービスを定義していない場合は、分割アカウンティングモデルを使用することをお勧めします。
Diameter base protocol mechanisms are used to overcome small message loss and network faults of a temporary nature.
Diameterベースのプロトコルメカニズムは、一時的な性質の小さなメッセージ損失およびネットワーク障害を克服するために使用されます。
Diameter peers acting as clients MUST implement the use of failover to guard against server failures and certain network failures. Diameter peers acting as agents or related off-line processing systems MUST detect duplicate accounting records caused by the sending of the same record to several servers and duplication of messages in transit. This detection MUST be based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. Appendix C discusses duplicate detection needs and implementation issues.
クライアントとして動作するDiameterピアは、サーバー障害および一部のネットワーク障害へ対処するため、フェイルオーバーを実装しなければなりません (MUST)。エージェントとして動作するDiameterピアまたは関連するオフライン処理システムは、同じレコードを複数サーバーへ送ること、および配送中にメッセージが複製されることにより生じた重複アカウンティングレコードを検出しなければなりません (MUST)。この検出は、Session-Id AVPと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 start sending the records in the non-volatile memory to the accounting server with the appropriate modifications in termination cause, session length, and other relevant information in the records.
Diameterクライアントは、再起動、長時間のネットワーク障害、ネットワーク分断、サーバー障害をまたいでアカウンティングレコードを安全に保存するため、不揮発性メモリを備えてもよい (MAY)。このようなメモリを利用できる場合、クライアントは新しいアカウンティングレコードを作成後ただちに格納し、Diameterサーバーから受信成功の確認応答を受け取るまで保持すべきです (SHOULD)。再起動後、クライアントは、終了原因、セッション長、その他の関連情報へ適切な変更を加え、不揮発性メモリ内のレコードをアカウンティングサーバーへ送信し始めなければなりません (MUST)。
A further application of this protocol may include AVPs to control the maximum number of accounting records that may be stored in the Diameter client without committing them to the non-volatile memory or transferring them to the Diameter server.
このプロトコルのさらなるアプリケーションには、不揮発性メモリにコミットしたり、Diameterサーバーに転送したりせずに、Diameterクライアントに格納できるアカウンティングレコードの最大数を制御するAVPが含まれる場合があります。
The client SHOULD NOT remove the accounting data from any of its memory areas before the correct Accounting-Answer has been received. The client MAY remove the oldest, undelivered, or as yet unacknowledged accounting data if it runs out of resources such as memory. It is an implementation-dependent matter for the client to accept new sessions under this condition.
クライアントは、正しいAccounting-Answerを受信する前に、どのメモリ領域からもアカウンティングデータを削除すべきではありません (SHOULD NOT)。メモリなどのリソースが不足した場合、クライアントは最も古い未配送または未確認のアカウンティングデータを削除してもよい (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.
すべてのアカウンティングレコード内にSession-Id AVPが存在しなければなりません (MUST)。DiameterクライアントがUser-Name AVPを利用できる場合、そのAVPも存在しなければなりません (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.
実際のアカウンティング対象サービスの種類と、中間アカウンティングに関する認可サーバーの指示に応じて、異なる種類のアカウンティングレコードを送信します。アカウンティング対象サービスが1回限りのイベント、すなわちイベントの開始と終了が同時である場合、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.
アカウンティング対象サービスの長さを測定できる場合、Accounting-Record-Type AVPはSTART_RECORD、STOP_RECORD、および必要に応じてINTERIM_RECORDの値を使用しなければなりません (MUST)。認可サーバーがそのセッションで中間アカウンティングを有効にするよう指示していない場合、session型のサービスごとに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_RECORDs and a single STOP_RECORD. A particular Diameter application specification MUST define the type of sequences that MUST be used.
Accounting-Sub-Session-Idの個々の値は、再送信の場合を除き、Diameterクライアントから送る1つのアカウンティングレコード列だけに現れなければなりません (MUST)。送信する1つの列は、Accounting-Record-Type AVPをEVENT_RECORDに設定した1レコード、またはSTART_RECORD値の1レコードで始まり、0個以上のINTERIM_RECORDと1個のSTOP_RECORDが続く複数レコードのいずれかでなければなりません (MUST)。個々のDiameterアプリケーション仕様は、使用しなければならない (MUST) レコード列の種類を定義しなければなりません (MUST)。
If an application uses accounting messages, it can correlate accounting records with a specific application session by using the Session-Id of the particular application session in the accounting messages. Accounting messages MAY also use a different Session-Id from that of the application sessions, in which case, other session-related information is needed to perform correlation.
アプリケーションがアカウンティングメッセージを使用する場合、そのメッセージ内で個々のアプリケーションセッションのSession-Idを使用することにより、アカウンティングレコードを特定のアプリケーションセッションへ対応付けられます。アカウンティングメッセージは、アプリケーションセッションとは異なるSession-Idを使用してもよく (MAY)、その場合は対応付けに別のセッション関連情報が必要です。
In cases where an application requires multiple accounting sub-sessions, an Accounting-Sub-Session-Id AVP is used to differentiate each sub-session. The Session-Id would remain constant for all sub-sessions and is used to correlate all the sub-sessions to a particular application session. Note that receiving a STOP_RECORD with no Accounting-Sub-Session-Id AVP when sub-sessions were originally used in the START_RECORD messages implies that all sub-sessions are terminated.
アプリケーションで複数のアカウンティングサブセッションが必要な場合は、Accounting-Sub-Session-Id AVPを使用して各サブセッションを区別します。 Session-Idはすべてのサブセッションで一定であり、すべてのサブセッションを特定のアプリケーションセッションに関連付けるために使用されます。 START_RECORDメッセージでサブセッションが最初に使用されたときに、Accounting-Sub-Session-Id AVPなしでSTOP_RECORDを受信すると、すべてのサブセッションが終了したことになります。
There are also cases where an application needs to correlate multiple application sessions into a single accounting record; the accounting record may span multiple different Diameter applications and sessions used by the same user at a given time. In such cases, the Acct-Multi-Session-Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD be signaled by the server to the access device (typically, during authorization) when it determines that a request belongs to an existing session. The access device MUST then include the Acct-Multi-Session-Id AVP in all subsequent accounting messages.
アプリケーションが複数のアプリケーションセッションを1つのアカウンティングレコードへ対応付ける必要がある場合もあります。そのレコードは、ある時点で同じユーザーが使用する複数の異なるDiameterアプリケーションおよびセッションにまたがることがあります。この場合、Acct-Multi-Session-Id AVPを使用します。要求が既存のセッションに属するとサーバーが判断した場合、サーバーは通常、認可時に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. Its contents are implementation specific, but the MUST be globally unique across other Acct-Multi-Session-Ids and MUST NOT change during the life of a session.
Acct-Multi-Session-Id AVPは元のSession-Idの値を含んでもよい (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 it MAY define the concept of a multi-session. For instance, the NASREQ DIAMETER application treats a single PPP connection to a Network Access Server as one session and a set of Multilink PPP sessions as one multi-session.
Diameterアプリケーション文書は、アカウンティング対象となるセッションの概念を厳密に定義しなければならず (MUST)、マルチセッションの概念を定義してもよい (MAY)。たとえばNASREQ DIAMETERアプリケーションは、Network Access Serverへの1つのPPP接続を1セッションとして、Multilink PPPセッションの集合を1マルチセッションとして扱います。
This section defines Command Code values that MUST be supported by all Diameter implementations that provide accounting services.
このセクションでは、アカウンティングサービスを提供するすべてのDiameter実装がサポートしなければならない (MUST) Command Code値を定義します。
The Accounting-Request (ACR) command, indicated by the Command Code field set to 271 and the Command Flags' 'R' bit set, is sent by a Diameter node, acting as a client, in order to exchange accounting information with a peer.
271に設定されたコマンドコードフィールドとコマンドフラグの「R」ビットセットで示されるアカウンティング要求（ACR）コマンドは、ピアとアカウンティング情報を交換するために、クライアントとして機能するDiameterノードによって送信されます。 。
In addition to the AVPs listed below, Accounting-Request messages SHOULD include service-specific accounting AVPs.
下記のAVPに加えて、アカウンティング要求メッセージには、サービス固有のアカウンティングAVPを含める必要があります（SHOULD）。
Message Format
メッセージフォーマット
<ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Destination-Host ]
[ Accounting-Sub-Session-Id ]
[ Acct-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Acct-Interim-Interval ]
[ Accounting-Realtime-Required ]
[ Origin-State-Id ]
[ Event-Timestamp ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The Accounting-Answer (ACA) command, indicated by the Command Code field set to 271 and the Command Flags' 'R' bit cleared, is used to acknowledge an Accounting-Request command. The Accounting-Answer command contains the same Session-Id as the corresponding request.
コマンドコードフィールドが271に設定され、コマンドフラグの「R」ビットがクリアされていることで示されるアカウンティング応答（ACA）コマンドは、アカウンティング要求コマンドを確認するために使用されます。 Accounting-Answerコマンドには、対応する要求と同じSession-Idが含まれています。
Only the target Diameter server, known as the home Diameter server, SHOULD respond with the Accounting-Answer command.
ホームDiameterサーバーと呼ばれる対象Diameterサーバーだけが、Accounting-Answerコマンドで応答すべきです (SHOULD)。
In addition to the AVPs listed below, Accounting-Answer messages SHOULD include service-specific accounting AVPs.
下記のAVPに加えて、Accounting-Answerメッセージには、サービス固有のアカウンティングAVPを含める必要があります（SHOULD）。
Message Format
メッセージフォーマット
<ACA> ::= < Diameter Header: 271, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Accounting-Sub-Session-Id ]
[ Acct-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Acct-Interim-Interval ]
[ Accounting-Realtime-Required ]
[ Origin-State-Id ]
[ Event-Timestamp ]
* [ Proxy-Info ]
* [ AVP ]
This section contains AVPs that describe accounting usage information related to a specific session.
このセクションには、特定のセッションに関連するアカウンティング使用状況情報を説明するAVPが含まれています。
The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated and contains the type of accounting record being sent. The following values are currently defined for the Accounting-Record-Type AVP:
Accounting-Record-Type AVP（AVPコード480）はEnumeratedタイプで、送信されるアカウンティングレコードのタイプが含まれています。現在、次の値がAccounting-Record-Type AVPに定義されています。
EVENT_RECORD 1
EVENT_RECORD 1
An Accounting Event Record is used to indicate that a one-time event has occurred (meaning that the start and end of the event are simultaneous). This record contains all information relevant to the service, and it is the only record of the service.
アカウンティングイベントレコードは、1回限りのイベントが発生したことを示すために使用されます（イベントの開始と終了が同時に行われることを意味します）。このレコードには、サービスに関連するすべての情報が含まれており、サービスの唯一のレコードです。
START_RECORD 2
START_RECORD 2
Accounting Start, Interim, and Stop Records are used to indicate that a service of a measurable length has been given. An Accounting Start Record is used to initiate an accounting session and contains accounting information that is relevant to the initiation of the session.
アカウンティングの開始、中間、および停止レコードは、測定可能な長さのサービスが提供されたことを示すために使用されます。アカウンティング開始レコードは、アカウンティングセッションを開始するために使用され、セッションの開始に関連するアカウンティング情報を含みます。
INTERIM_RECORD 3
INTERIM_RECORD 3
An Interim Accounting Record contains cumulative accounting information for an existing accounting session. Interim Accounting Records SHOULD be sent every time a re-authentication or re-authorization occurs. Further, additional interim record triggers MAY be defined by application-specific Diameter applications. The selection of whether to use INTERIM_RECORD records is done by the Acct-Interim-Interval AVP.
Interim Accounting Recordには、既存のアカウンティングセッションに関する累積アカウンティング情報が入ります。再認証または再認可が行われるたびに、Interim Accounting Recordを送信すべきです (SHOULD)。さらに、アプリケーション固有のDiameterアプリケーションが追加の中間レコード生成契機を定義してもよい (MAY)。INTERIM_RECORDレコードを使用するかどうかは、Acct-Interim-Interval AVPで選択します。
STOP_RECORD 4
STOP_RECORD 4
An Accounting Stop Record is sent to terminate an accounting session and contains cumulative accounting information relevant to the existing session.
アカウンティング停止レコードは、アカウンティングセッションを終了するために送信され、既存のセッションに関連する累積アカウンティング情報を含みます。
The Acct-Interim-Interval AVP (AVP Code 85) is of type Unsigned32 and is sent from the Diameter home authorization server to the Diameter client. The client uses information in this AVP to decide how and when to produce accounting records. With different values in this AVP, service sessions can result in one, two, or two+N accounting records, based on the needs of the home organization. The following accounting record production behavior is directed by the inclusion of this AVP:
Acct-Interim-Interval AVP（AVPコード85）のタイプはUnsigned32であり、Diameterホーム認証サーバーからDiameterクライアントに送信されます。クライアントは、このAVPの情報を使用して、アカウンティングレコードを作成する方法とタイミングを決定します。このAVPの値が異なる場合、サービスセッションは、ホーム組織のニーズに基づいて、1つ、2つ、または2 + Nのアカウンティングレコードになる可能性があります。次のアカウンティングレコード生成動作は、このAVPを含めることによって指示されます。
1. The omission of the Acct-Interim-Interval AVP or its inclusion with Value field set to 0 means that EVENT_RECORD, START_RECORD, and STOP_RECORD are produced, as appropriate for the service.
1. Acct-Interim-Interval AVPが省略されているか、Valueフィールドが0に設定されている場合、サービスに応じて、EVENT_RECORD、START_RECORD、およびSTOP_RECORDが生成されます。
2. The inclusion of the AVP with Value field set to a non-zero value means that INTERIM_RECORD records MUST be produced between the START_RECORD and STOP_RECORD records. The Value field of this AVP is the nominal interval between these records in seconds. The Diameter node that originates the accounting information, known as the client, MUST produce the first INTERIM_RECORD record roughly at the time when this nominal interval has elapsed from the START_RECORD, the next one again as the interval has elapsed once more, and so on until the session ends and a STOP_RECORD record is produced.
2. Valueフィールドを0以外に設定したAVPを含めることは、START_RECORDレコードとSTOP_RECORDレコードの間にINTERIM_RECORDレコードを生成しなければならない (MUST) ことを意味します。このAVPのValueフィールドは、それらのレコード間の公称間隔を秒単位で示します。アカウンティング情報を生成するDiameterノード（クライアント）は、START_RECORDからこの公称間隔が経過した頃に最初のINTERIM_RECORDレコードを生成し、その後も間隔が経過するたびに次のレコードを生成し、セッションが終了してSTOP_RECORDレコードを生成するまで続けなければなりません (MUST)。
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 multiple related accounting sessions, where each session would have a unique Session-Id but the same Acct-Multi-Session-Id AVP. This AVP MAY be returned by the Diameter server in an authorization answer, and it MUST be used in all accounting messages for the given session.
Acct-Multi-Session-Id AVP（AVP Code 50）はUTF8String型であり、セクション8.8で規定する形式に従います。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 Code 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
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.
ValueフィールドをDELIVER_AND_GRANTに設定したAVPは、サービスを許可するのはアカウンティングサーバーへの接続がある間だけにしなければならない (MUST) ことを意味します。この意味では、代替アカウンティングサーバーの集合を1つのサーバーとして扱うことに注意してください。アカウンティングレコードのストリームをバックアップサーバーへ移す必要が生じても、それはユーザーへのサービスを中止する理由にはなりません。
GRANT_AND_STORE 2
GRANT_AND_STORE 2
The AVP with Value field set to GRANT_AND_STORE means that service SHOULD be granted if there is a connection, or as long as records can still be stored as described in Section 9.4.
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
GRANT_AND_LOSE 3
The AVP with Value field set to GRANT_AND_LOSE means that service SHOULD be granted even if the records cannot be delivered or stored.
ValueフィールドをGRANT_AND_LOSEに設定したAVPは、レコードを配送も保存もできない場合であっても、サービスを許可すべきである (SHOULD) ことを意味します。
The following tables present the AVPs defined in this document and specify in which Diameter messages they MAY or MAY NOT be present. AVPs that occur only inside a Grouped AVP are not shown in these tables.
次の表は、本文書で定義するAVPを示し、それぞれがどのDiameterメッセージ内に存在してもよい (MAY)、または存在しなくてもよい (MAY) かを規定します。Grouped AVPの内部だけに現れるAVPは、これらの表に示しません。
The tables use the following symbols:
表では次の記号を使用しています。
0 The AVP MUST NOT be present in the message.
0 AVPはメッセージ内に存在してはなりません (MUST NOT)。
0+ Zero or more instances of the AVP MAY be present in the message.
0+ AVPのインスタンスが0個以上、メッセージ内に存在してもよい (MAY)。
0-1 Zero or one instance of the AVP MAY be present in the message. It is considered an error if there are more than one instance of the AVP.
0-1 AVPのインスタンスが0個または1個、メッセージ内に存在してもよい (MAY)。AVPのインスタンスが2個以上あればエラーとみなします。
1 One instance of the AVP MUST be present in the message.
1 AVPのインスタンスが1個、メッセージ内に存在しなければなりません (MUST)。
1+ At least one instance of the AVP MUST be present in the message.
1+ AVPのインスタンスが1個以上、メッセージ内に存在しなければなりません (MUST)。
The table in this section is limited to the non-Accounting Command Codes defined in this specification.
このセクションの表は、この仕様で定義されている非アカウンティングコマンドコードに限定されています。
+-----------------------------------------------+
| Command Code |
+---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------+---+---+---+---+---+---+---+---+---+---+---+---+
Acct-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
Interval | | | | | | | | | | | | |
Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
Required | | | | | | | | | | | | |
Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Lifetime | | | | | | | | | | | | |
Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ |
Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 |
Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
Failed-AVP |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Inband-Security-Id |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
Origin-State-Id |0-1|0-1|0 |0 |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ |
Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |
Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
Redirect-Max-Cache- |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
Time | | | | | | | | | | | | |
Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |0 |1 |
Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |
Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0 |0+ |0 |
Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 |
Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Failover | | | | | | | | | | | | |
Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Supported-Vendor-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 |
User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|0-1|0-1|0-1|0-1|
Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Application-Id | | | | | | | | | | | | |
--------------------+---+---+---+---+---+---+---+---+---+---+---+---+
The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages. These AVP occurrence requirements are guidelines, which may be expanded, and/or overridden by application-specific requirements in the Diameter applications documents.
このセクションの表は、このドキュメントで定義されているどのAVPがアカウンティングメッセージに存在するかを表すために使用されます。これらのAVPオカレンス要件はガイドラインであり、Diameterアプリケーションドキュメントのアプリケーション固有の要件によって拡張またはオーバーライドされる場合があります。
+-----------+
| Command |
| Code |
+-----+-----+
Attribute Name | ACR | ACA |
------------------------------+-----+-----+
Acct-Interim-Interval | 0-1 | 0-1 |
Acct-Multi-Session-Id | 0-1 | 0-1 |
Accounting-Record-Number | 1 | 1 |
Accounting-Record-Type | 1 | 1 |
Acct-Session-Id | 0-1 | 0-1 |
Accounting-Sub-Session-Id | 0-1 | 0-1 |
Accounting-Realtime-Required | 0-1 | 0-1 |
Acct-Application-Id | 0-1 | 0-1 |
Auth-Application-Id | 0 | 0 |
Class | 0+ | 0+ |
Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 |
Error-Reporting-Host | 0 | 0+ |
Event-Timestamp | 0-1 | 0-1 |
Failed-AVP | 0 | 0-1 |
Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 |
Proxy-Info | 0+ | 0+ |
Route-Record | 0+ | 0 |
Result-Code | 0 | 1 |
Session-Id | 1 | 1 |
Termination-Cause | 0 | 0 |
User-Name | 0-1 | 0-1 |
Vendor-Specific-Application-Id| 0-1 | 0-1 |
------------------------------+-----+-----+
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the Diameter protocol, in accordance with [RFC5226]. Existing IANA registries and assignments put in place by RFC 3588 remain the same unless explicitly updated or deprecated in this section.
このセクションは、[RFC5226]に従って、Diameterプロトコルに関連する値の登録に関するInternet Assigned Numbers Authority（IANA）へのガイダンスを提供します。このセクションで明示的に更新または廃止されない限り、RFC 3588によって設定された既存のIANAレジストリと割り当ては同じままです。
As defined in Section 4, the AVP header contains three fields that require IANA namespace management: the AVP Code, Vendor-ID, and Flags fields.
セクション4で定義されているように、AVPヘッダーには、IANA名前空間の管理が必要な3つのフィールド（AVPコード、ベンダーID、およびフラグフィールド）が含まれています。
There are multiple namespaces. Vendors can have their own AVP Codes namespace that will be identified by their Vendor-ID (also known as Enterprise-Number), and they control the assignments of their vendor-specific AVP Codes within their own namespace. The absence of a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF AVP Codes namespace, which is under IANA control. The AVP Codes and sometimes possible values in an AVP are controlled and maintained by IANA. AVP Code 0 is not used. AVP Codes 1-255 are managed separately as RADIUS Attribute Types. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs should be encouraged instead.
複数の名前空間があります。ベンダーは、ベンダーID（別名エンタープライズ番号）によって識別される独自のAVPコード名前空間を持つことができ、独自の名前空間内のベンダー固有のAVPコードの割り当てを制御します。 Vendor-IDまたはゼロ（0）のVendor-ID値がないことは、IANAの制御下にあるIETF AVPコード名前空間を識別します。 AVPコードおよびAVPで可能な値は、IANAによって制御および維持されます。 AVPコード0は使用されません。 AVPコード1〜255は、RADIUS属性タイプとして個別に管理されます。ベンダー固有のAVPが複数のベンダーによって実装されている場合は、代わりにグローバルAVPの割り当てを推奨する必要があります。
Section 4.1 describes the existing AVP Flags. The remaining bits can only be assigned via a Standards Action [RFC5226].
セクション4.1では、既存のAVPフラグについて説明します。残りのビットは、標準アクション[RFC5226]を介してのみ割り当てることができます。
For the Diameter header, the Command Code namespace allocation has changed. The new allocation rules are as follows:
Diameterヘッダーの場合、コマンドコードの名前空間の割り当てが変更されました。新しい割り当てルールは次のとおりです。
The Command Code values 256 - 8,388,607 (0x100 to 0x7fffff) are for permanent, standard commands, allocated by IETF Review [RFC5226].
コマンドコード値256〜8,388,607（0x100〜0x7fffff）は、IETFレビュー[RFC5226]によって割り当てられた永続的な標準コマンド用です。
The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved for vendor-specific Command Codes, to be allocated on a First Come, First Served basis by IANA [RFC5226]. The request to IANA for a Vendor-Specific Command Code SHOULD include a reference to a publicly available specification that documents the command in sufficient detail to aid in interoperability between independent implementations. If the specification cannot be made publicly available, the request for a vendor-specific Command Code MUST include the contact information of persons and/or entities responsible for authoring and maintaining the command.
8,388,608～16,777,213（0x800000～0xfffffd）の値はベンダー固有Command Code用に予約され、IANAがFirst Come, First Served方式[RFC5226]で割り当てます。Vendor-Specific Command CodeをIANAへ申請する際は、独立した実装間の相互運用性に役立つ十分な詳細でコマンドを文書化した、公開仕様への参照を含めるべきです (SHOULD)。仕様を公開できない場合、ベンダー固有Command Codeの申請は、そのコマンドの作成および保守を担当する個人または組織の連絡先情報、あるいはその両方を含まなければなりません (MUST)。
The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 0xffffff) are reserved for experimental commands. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between Diameter peers using experimental commands.
値16,777,214および16,777,215（16進値0xfffffe-0xffffff）は、実験的なコマンド用に予約されています。これらのコードは実験とテストのみを目的としているため、実験的なコマンドを使用したDiameterピア間の相互運用性は保証されません。
Section 3 describes the existing Command Flags field. The remaining bits can only be assigned via a Standards Action [RFC5226].
セクション3では、既存のコマンドフラグフィールドについて説明します。残りのビットは、標準アクション[RFC5226]を介してのみ割り当てることができます。
For AVP values, the Experimental-Result-Code AVP value allocation has been added; see Section 11.3.1. The old AVP value allocation rule, IETF Consensus, has been updated to IETF Review as per [RFC5226], and affected AVPs are listed as reminders.
AVP値の場合、Experimental-Result-Code AVP値の割り当てが追加されました。セクション11.3.1を参照してください。古いAVP値割り当てルールであるIETFコンセンサスは、[RFC5226]に従ってIETFレビューに更新され、影響を受けるAVPがリマインダーとしてリストされています。
Values for this AVP are purely local to the indicated vendor, and no IANA registry is maintained for them.
このAVPの値は、示されたベンダーに対して純粋にローカルであり、それらのIANAレジストリは維持されません。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
New values are available for assignment via IETF Review [RFC5226].
IETFレビュー[RFC5226]を介して、新しい値を割り当てに使用できます。
The use of this AVP has been deprecated.
このAVPの使用は廃止されました。
IANA has registered the "_diameters" service name and assigned port numbers for TLS/TCP and DTLS/SCTP according to the guidelines given in [RFC6335].
IANAは[_diameters]サービス名を登録し、[RFC6335]に記載されているガイドラインに従ってTLS/TCPおよびDTLS/SCTPのポート番号を割り当てました。
Service Name: _diameters
サービス名：_diameters
Transport Protocols: TCP, SCTP
トランスポートプロトコル：TCP、SCTP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Diameter over TLS/TCP and DTLS/SCTP
Reference: RFC 6733
リファレンス：RFC 6733
Port Number: 5868, from the User Range
ポート番号：5868、ユーザー範囲から
Two SCTP payload protocol identifiers have been registered in the SCTP Payload Protocol Identifiers registry:
2つのSCTPペイロードプロトコル識別子がSCTP Payload Protocol Identifiersレジストリに登録されています。
Value | SCTP Payload Protocol Identifier
-------|-----------------------------------
46 | Diameter in a SCTP DATA chunk
47 | Diameter in a DTLS/SCTP DATA chunk
The following tag has been registered in the S-NAPTR Application Protocol Tags registry:
次のタグがS-NAPTR Application Protocol Tagsレジストリに登録されています。
Tag | Protocol
-------------------|---------
diameter.dtls.sctp | DTLS/SCTP
This section contains the configurable parameters that are found throughout this document:
このセクションには、このドキュメント全体で見つかる構成可能なパラメーターが含まれています。
Diameter Peer
直径ピア
A Diameter entity MAY communicate with peers that are statically configured. A statically configured Diameter peer would require that either the IP address or the fully qualified domain name (FQDN) be supplied, which would then be used to resolve through DNS.
Diameterエンティティは、静的に構成されたピアと通信できます（MAY）。静的に構成されたDiameterピアでは、IPアドレスまたは完全修飾ドメイン名（FQDN）のいずれかを指定する必要があり、これを使用してDNS経由で解決します。
Routing Table
ルーティングテーブル
A Diameter proxy server routes messages based on the realm portion of a Network Access Identifier (NAI). The server MUST have a table of Realm Names, and the address of the peer to which the message must be forwarded. The routing table MAY also include a "default route", which is typically used for all messages that cannot be locally processed.
Diameterプロキシサーバーは、Network Access Identifier（NAI）のrealm部分に基づいてメッセージをルーティングします。サーバーは、Realm Nameと、メッセージを転送する必要があるピアのアドレスを収めたテーブルを持たなければなりません (MUST)。ルーティングテーブルは「default route」を含んでもよく (MAY)、通常はローカルで処理できない全メッセージに使用します。
Tc timer
Tcタイマー
The Tc timer controls the frequency that transport connection attempts are done to a peer with whom no active transport connection exists. The recommended value is 30 seconds.
Tcタイマーは、アクティブなトランスポート接続が存在しないピアに対してトランスポート接続の試行が行われる頻度を制御します。推奨値は30秒です。
The Diameter base protocol messages SHOULD be secured by using TLS [RFC5246] or DTLS/SCTP [RFC6083]. Additional security mechanisms such as IPsec [RFC4301] MAY also be deployed to secure connections between peers. However, all Diameter base protocol implementations MUST support the use of TLS/TCP and DTLS/SCTP, and the Diameter protocol MUST NOT be used without one of TLS, DTLS, or IPsec.
If a Diameter connection is to be protected via TLS/TCP and DTLS/SCTP or IPsec, then TLS/TCP and DTLS/SCTP or IPsec/IKE SHOULD begin prior to any Diameter message exchange. All security parameters for TLS/ TCP and DTLS/SCTP or IPsec are configured independent of the Diameter protocol. All Diameter messages will be sent through the TLS/TCP and DTLS/SCTP or IPsec connection after a successful setup.
Diameter接続をTLS/TCPおよびDTLS/SCTPまたはIPsecで保護する場合、Diameterメッセージ交換の前にTLS/TCPおよびDTLS/SCTPまたはIPsec/IKEを開始する必要があります（SHOULD）。 TLS/TCPおよびDTLS/SCTPまたはIPsecのすべてのセキュリティパラメータは、Diameterプロトコルとは無関係に設定されます。すべてのDiameterメッセージは、セットアップが成功した後、TLS/TCPおよびDTLS/SCTPまたはIPsec接続を介して送信されます。
For TLS/TCP and DTLS/SCTP connections to be established in the open state, the CER/CEA exchange MUST include an Inband-Security-ID AVP with a value of TLS/TCP and DTLS/SCTP. The TLS/TCP and DTLS/SCTP handshake will begin when both ends successfully reach the open state, after completion of the CER/CEA exchange. If the TLS/TCP and DTLS/SCTP handshake is successful, all further messages will be sent via TLS/TCP and DTLS/SCTP. If the handshake fails, both ends MUST move to the closed state. See Section 13.1 for more details.
Open状態でTLS/TCP接続およびDTLS/SCTP接続を確立するには、CER/CEA交換が、値をTLS/TCPおよびDTLS/SCTPに設定したInband-Security-ID AVPを含まなければなりません (MUST)。CER/CEA交換の完了後、双方がOpen状態へ正常に到達するとTLS/TCPおよびDTLS/SCTPのハンドシェイクを開始します。ハンドシェイクに成功した場合、以後の全メッセージをTLS/TCPおよびDTLS/SCTPで送信します。失敗した場合、双方がClosed状態へ移らなければなりません (MUST)。詳細についてはセクション13.1を参照してください。
Diameter nodes using TLS/TCP and DTLS/SCTP for security MUST mutually authenticate as part of TLS/TCP and DTLS/SCTP session establishment. In order to ensure mutual authentication, the Diameter node acting as the TLS/TCP and DTLS/SCTP server MUST request a certificate from the Diameter node acting as TLS/TCP and DTLS/SCTP client, and the Diameter node acting as the TLS/TCP and DTLS/SCTP client MUST be prepared to supply a certificate on request.
セキュリティにTLS/TCPおよびDTLS/SCTPを使用するDiameterノードは、TLS/TCPおよびDTLS/SCTPセッションの確立処理の一部として相互認証しなければなりません (MUST)。相互認証を保証するため、TLS/TCPおよびDTLS/SCTPサーバーとして動作するDiameterノードは、TLS/TCPおよびDTLS/SCTPクライアントとして動作するDiameterノードへ証明書を要求しなければならず (MUST)、クライアントとして動作するDiameterノードは、要求に応じて証明書を提示できるよう準備しなければなりません (MUST)。
Diameter nodes MUST be able to negotiate the following TLS/TCP and DTLS/SCTP cipher suites:
Diameterノードは、次のTLS/TCPおよびDTLS/SCTP暗号スイートをネゴシエーションできなければなりません (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/TCP and DTLS/SCTP cipher suite:
Diameterノードは、次のTLS/TCPおよびDTLS/SCTP暗号スイートをネゴシエートできる必要があります（SHOULD）。
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
Note that it is quite possible that support for the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite will be REQUIRED at some future date. Diameter nodes MAY negotiate other TLS/TCP and DTLS/ SCTP cipher suites.
将来、TLS_RSA_WITH_AES_128_CBC_SHA暗号スイートをサポートしなければならない (REQUIRED) と定められる可能性が十分にあることに注意してください。Diameterノードは、他のTLS/TCPおよびDTLS/SCTP暗号スイートをネゴシエーションしてもよい (MAY)。
If public key certificates are used for Diameter security (for example, with TLS), the value of the expiration times in the routing and peer tables MUST NOT be greater than the expiry time in the relevant certificates.
公開鍵証明書がDiameterのセキュリティ（TLSなど）に使用される場合、ルーティングテーブルとピアテーブルの有効期限の値は、関連する証明書の有効期限を超えてはなりません（MUST NOT）。
As with any peer-to-peer protocol, proper configuration of the trust model within a Diameter peer is essential to security. When certificates are used, it is necessary to configure the root certificate authorities trusted by the Diameter peer. These root CAs are likely to be unique to Diameter usage and distinct from the root CAs that might be trusted for other purposes such as Web browsing. In general, it is expected that those root CAs will be configured so as to reflect the business relationships between the organization hosting the Diameter peer and other organizations. As a result, a Diameter peer will typically not be configured to allow connectivity with any arbitrary peer. With certificate authentication, Diameter peers may not be known beforehand and therefore peer discovery may be required.
他のピアツーピアプロトコルと同様に、Diameterピア内の信頼モデルを適切に構成することは、セキュリティにとって不可欠です。証明書を使用する場合は、Diameterピアが信頼するルート認証局を設定する必要があります。これらのルートCAは、Diameterの使用に固有である可能性が高く、Webブラウジングなどの他の目的で信頼されている可能性があるルートCAとは異なります。一般に、これらのルートCAは、Diameterピアをホストしている組織と他の組織との間のビジネス関係を反映するように構成されます。その結果、Diameterピアは通常、任意のピアとの接続を許可するように構成されません。証明書認証では、Diameterピアが事前に認識されていない場合があるため、ピアの検出が必要になる場合があります。
Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The following AVPs defined in this document are considered to be security-sensitive:
Diameter AVPには、セキュリティ上重要なデータが含まれていることがよくあります。たとえば、ユーザーのパスワードと場所のデータ、ネットワークアドレス、暗号化キーなどです。このドキュメントで定義されている次のAVPは、セキュリティ上重要であると見なされています。
o Acct-Interim-Interval
o Acct-Interim-Interval
o Accounting-Realtime-Required
o アカウンティング-リアルタイムが必要
o Acct-Multi-Session-Id
o Acct-Multi-Session-Id
o Accounting-Record-Number
o 会計レコード番号
o Accounting-Record-Type
o 会計レコードタイプ
o Accounting-Session-Id
o Accounting-Session-Id
o Accounting-Sub-Session-Id
o Accounting-Sub-Session-Id
o Class o Session-Id
oクラスoセッションID
o Session-Binding
o セッションバインディング
o Session-Server-Failover
o セッションサーバーフェイルオーバー
o User-Name
o ユーザー名
Diameter messages containing these or any other AVPs considered to be security-sensitive MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages MUST NOT be sent via intermediate nodes unless there is end-to-end security between the originator and recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed. For example, end-to-end security may not be required in the case where an intermediary node is known to be operated as part of the same administrative domain as the endpoints so that an ability to successfully compromise the intermediary would imply a high probability of being able to compromise the endpoints as well. Note that no end-to-end security mechanism is specified in this document.
これらのAVP、またはセキュリティ上機微とみなされるその他のAVPを含むDiameterメッセージは、相互認証済みのTLSまたはIPsecで保護した状態でのみ送信しなければなりません (MUST)。さらに、生成元と受信側の間にエンドツーエンドセキュリティが存在する場合、またはエンドツーエンドセキュリティは不要だと示す、生成元がローカルで信頼した設定がある場合を除き、このようなメッセージを中間ノード経由で送信してはなりません (MUST NOT)。たとえば、中間ノードがエンドポイントと同じ管理ドメインの一部として運用されていることが分かっており、中間ノードへの侵害に成功できるならエンドポイントも侵害できる可能性が高い場合、エンドツーエンドセキュリティは不要かもしれません。本文書はエンドツーエンドセキュリティ機構を規定していないことに注意してください。
[FLOATPOINT] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985", August 1985.
[FLOATPOINT] Institute of Electrical and Electronics Engineers、「IEEE Standard for Binary Floating-Point Arithmetic、ANSI/IEEE Standard 754-1985」、1985年8月。
[IANAADFAM] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[IANAADFAM] IANA、「アドレスファミリー番号」、<http://www.iana.org/assignments/address-family-numbers>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel, J.、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel, J.、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S.、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello, A.、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、2003年3月。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3539] Aboba, B. and J. Wood、「Authentication、Authorization and Accounting（AAA）Transport Profile」、RFC 3539、2003年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau, F.、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958] Daigle, L. and A. Newton、「SRV RRおよび動的委任検出サービス（DDDS）を使用したドメインベースのアプリケーションサービスロケーション」、RFC 3958、2005年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann、「Diameter Mobile IPv4 Application」、RFC 4004、2005年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney、「Diameter Credit-Control Application」、RFC 4006、2005年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen、「The Network Access Identifier」、RFC 4282、2005年12月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden, R. and S. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart, R.、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. and H. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker, D. and P. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks, T. and E. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009.
[RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou、「ユーザー名とレルムに基づくDiameterリクエストのルーティングに関する説明」、RFC 5729、2009年12月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin, J.、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin, J.、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、2010年8月。
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla、「Data Control Transport Layer Security（DTLS）for Stream Control Transmission Protocol（SCTP）」、RFC 6083、2011年1月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla, E. and N. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
[RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage", RFC 6408, November 2011.
[RFC6408] Jones, M., Korhonen, J., and L. Morand、「Diameter Straightforward-Naming Authority Pointer（S-NAPTR）Usage」、RFC 6408、2011年11月。
[ENTERPRISE] IANA, "SMI Network Management Private Enterprise Codes", <http://www.iana.org/assignments/enterprise-numbers>.
[ENTERPRISE] IANA、「SMIネットワーク管理プライベートエンタープライズコード」、<http://www.iana.org/assignments/enterprise-numbers>。
[IANATCV] IANA, "Termination-Cause AVP Values (code 295)", <http://www.iana.org/assignments/aaa-parameters/ aaa-parameters.xml#aaa-parameters-16>.
[IANATCV] IANA、「Termination-Cause AVP Values（code 295）」、<http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-16>。
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993.
[RFC1492] Finseth, C.、「アクセスコントロールプロトコル、TACACSと呼ばれることもある」、RFC 1492、1993年7月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson, W.、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney, C.、「RADIUSアカウンティング」、RFC 2866、2000年6月。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun、「RADIUS Extensions」、RFC 2869、2000年6月。
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[RFC2881] Mitton, D. and M. Beadles、「ネットワークアクセスサーバー要件次世代（NASREQNG）NASモデル」、RFC 2881、2000年7月。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2975] Aboba, B., Arkko, J., and D. Harrington、「Introduction to Accounting Management」、RFC 2975、2000年10月。
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S., and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000.
[RFC2989] Aboba、B.、Calhoun、P.、Glass、S.、Hiller、T.、McCann、P.、Shiino、H.、Walsh、P.、Zorn、G.、Dommety、G.、Perkins、 C.、Patil、B.、Mitton、D.、Manning、S.、Beadles、M.、Chen、X.、Sivalingham、S.、Hameed、A.、Munson、M.、Jacobs、S.、Lim、 B.、Hirschman、B.、Hsu、R.、Koo、H.、Lipford、M.、Campbell、E.、Xu、Y.、Baba、S。、およびE. Jaques、「AAAプロトコルの評価基準ネットワークアクセス」、RFC 2989、2000年11月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton、「RADIUS and IPv6」、RFC 3162、2001年8月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent, S. and K. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB、「Review and Recommendations for Internationalized Domain Names（IDNs）」、RFC 4690、2006年9月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 5176、January 2008。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC5461] Gont, F.、「ソフトエラーに対するTCPの反応」、RFC 5461、2009年2月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927] Gont, F.、「TCPに対するICMP攻撃」、RFC 5927、2010年7月。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、2011年8月。
[RFC6737] Kang, J. and G. Zorn, "The Diameter Capabilities Update Application", RFC 6737, October 2012.
[RFC6737] Kang, J. and G. Zorn、「Diameter Capabilities Update Application」、RFC 6737、2012年10月。
The authors would like to thank the following people that have provided proposals and contributions to this document:
著者は、このドキュメントへの提案と貢献を提供してくれた以下の人々に感謝します。
To Vishnu Ram and Satendra Gera for their contributions on capabilities updates, predictive loop avoidance, as well as many other technical proposals. To Tolga Asveren for his insights and contributions on almost all of the proposed solutions incorporated into this document. To Timothy Smith for helping on the capabilities Update and other topics. To Tony Zhang for providing fixes to loopholes on composing Failed-AVPs as well as many other issues and topics. To Jan Nordqvist for clearly stating the usage of Application Ids. To Anders Kristensen for providing needed technical opinions. To David Frascone for providing invaluable review of the document. To Mark Jones for providing clarifying text on vendor command codes and other vendor-specific indicators. To Victor Pascual and Sebastien Decugis for new text and recommendations on SCTP/DTLS. To Jouni Korhonen for taking over the editing task and resolving last bits from versions 27 through 29.
Vishnu RamとSatendra Geraが、機能の更新、予測ループの回避、およびその他の多くの技術提案に貢献してくれたことに感謝します。このドキュメントに組み込まれている提案されたソリューションのほとんどすべてに対する洞察と貢献についてTolga Asverenに。機能アップデートおよびその他のトピックについて支援してくださったTimothy Smithに。 Failed-AVPの作成に関する抜け穴やその他の多くの問題やトピックを修正してくれたTony Zhangに。アプリケーションIDの使用を明確に述べてくれたJan Nordqvistに。必要な技術的意見を提供してくれたAnders Kristensenに。ドキュメントの非常に貴重なレビューを提供してくれたDavid Frasconeに。ベンダのコマンドコードおよびその他のベンダ固有のインジケータに関する明確なテキストを提供するためにマークジョーンズに。 SCTP/DTLSに関する新しいテキストと推奨事項については、Victor PascualおよびSebastien Decugisに。編集作業を引き継ぎ、バージョン27〜29の最後の部分を解決してくれたJouni Korhonenに。
Special thanks to the Diameter extensibility design team, which helped resolve the tricky question of mandatory AVPs and ABNF semantics. The members of this team are as follows:
Diameter拡張性設計チームに特に感謝します。これは、必須のAVPとABNFセマンティクスの難しい問題を解決するのに役立ちました。このチームのメンバーは次のとおりです。
Avi Lior, Jari Arkko, Glen Zorn, Lionel Morand, Mark Jones, Tolga Asveren, Jouni Korhonen, and Glenn McGregor.
Avi Lior、Jari Arkko、Glen Zorn、Lionel Morand、Mark Jones、Tolga Asveren、Jouni Korhonen、およびGlenn McGregor。
Special thanks also to people who have provided invaluable comments and inputs especially in resolving controversial issues:
特に論争の的となる問題を解決する上で貴重なコメントと情報を提供してくれた人々にも特に感謝します。
Glen Zorn, Yoshihiro Ohba, Marco Stura, Stephen Farrel, Pete Resnick, Peter Saint-Andre, Robert Sparks, Krishna Prasad, Sean Turner, Barry Leiba, and Pasi Eronen.
Glen Zorn、Ohba Hirohiro、Marco Stura、Stephen Farrel、Pete Resnick、Peter Saint-Andre、Robert Sparks、Krishna Prasad、Sean Turner、Barry Leiba、Pasi Eronen。
Finally, we would like to thank the original authors of this document:
最後に、このドキュメントの原作者に感謝します。
Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman, and Glen Zorn.
Pat Calhoun、John Loughney、Jari Arkko、Erik Guttman、Glen Zorn。
Their invaluable knowledge and experience has given us a robust and flexible AAA protocol that many people have seen great value in adopting. We greatly appreciate their support and stewardship for the continued improvements of Diameter as a protocol. We would also like to extend our gratitude to folks aside from the authors who have assisted and contributed to the original version of this document. Their efforts significantly contributed to the success of Diameter.
彼らの非常に貴重な知識と経験により、多くの人々が採用に大きな価値を見出している堅牢で柔軟なAAAプロトコルを提供しています。プロトコルとしてのDiameterの継続的な改善に対する彼らのサポートとスチュワードシップに深く感謝します。また、このドキュメントの元のバージョンを手伝い、貢献してくれた著者以外の方々にも感謝の意を表したいと思います。彼らの努力はDiameterの成功に大きく貢献しました。
The authors would like to thank Nenad Trifunovic, Tony Johansson and Pankaj Patel for their participation in the pre-IETF Document Reading Party. Allison Mankin, Jonathan Wood, and Bernard Aboba provided invaluable assistance in working out transport issues and this was also the case with Steven Bellovin in the security area.
著者は、IETF以前の文書閲覧会に参加してくれたNenad Trifunovic、Tony Johansson、およびPankaj Patelに感謝します。アリソンマンキン、ジョナサンウッド、バーナードアボバは、輸送問題の解決に非常に貴重な支援を提供しました。これは、セキュリティエリアのスティーブンベロビンにも当てはまります。
Paul Funk and David Mitton were instrumental in getting the Peer State Machine correct, and our deep thanks go to them for their time.
Paul FunkとDavid Mittonは、ピアステートマシンを正しくするために尽力してくれました。
Text in this document was also provided by Paul Funk, Mark Eklund, Mark Jones, and Dave Spence. Jacques Caron provided many great comments as a result of a thorough review of the spec.
このドキュメントのテキストは、Paul Funk、Mark Eklund、Mark Jones、およびDave Spenceも提供しています。 Jacques Caronは、仕様を徹底的に見直した結果、多くのすばらしいコメントを提供しました。
The authors would also like to acknowledge the following people for their contribution in the development of the Diameter protocol:
著者はまた、Diameterプロトコルの開発に貢献した以下の人々に感謝します。
Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell, David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien, Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht, and Jeff Weisberg.
アランC.ルーベンス、ハシーブアクタール、ウィリアムブリー、スティーブンファレル、デビッドフラスコーネ、ダニエルC.フォックス、ロルグラント、イグナシオゴイレット、ナンシーグリーン、ピーターヘイトマン、フレドリックヨハンソン、マークジョーンズ、マーティンジュリアン、ボブコパッチ、ポールクルムビデ、ファーガルラドリー、ライアン・モーツ、ビクター・モスリン、ケネス・パース、ジョン・シュニズライン、スミット・ヴァキル、ジョン・R・ボルブレヒト、ジェフ・ワイスバーグ。
Finally, Pat Calhoun would like to thank Sun Microsystems since most of the effort put into this document was done while he was in their employ.
最後に、Pat Calhounは、Sun Microsystemsに感謝したいと思います。この文書に加えられた努力のほとんどは、彼が彼らの雇用中に行われたからです。
As an example, consider a client that wishes to resolve aaa: ex1.example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
例として、aaaを解決したいクライアントを考えてみましょう：ex1.example.com。クライアントはそのドメインに対してNAPTRクエリを実行し、次のNAPTRレコードが返されます。
;; order pref flags service regexp replacement
IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" ""
_diameter._tls.ex1.example.com
IN NAPTR 100 50 "s" "aaa:diameter.tcp" ""
_aaa._tcp.ex1.example.com
IN NAPTR 150 50 "s" "aaa:diameter.sctp" ""
_diameter._sctp.ex1.example.com
This indicates that the server supports TLS, TCP, and SCTP in that order. If the client supports TLS, TLS will be used, targeted to a host determined by an SRV lookup of _diameter._tls.ex1.example.com. That lookup would return:
これは、サーバーがTLS、TCP、SCTPの順にサポートしていることを示しています。クライアントがTLSをサポートしている場合、TLSが使用され、_diameter._tls.ex1.example.comのSRVルックアップによって決定されたホストをターゲットにします。そのルックアップは以下を返します：
;; Priority Weight Port Target
IN SRV 0 1 5060 server1.ex1.example.com
IN SRV 0 2 5060 server2.ex1.example.com
As an alternative example, a client that wishes to resolve aaa: ex2.example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
別の例として、aaaを解決したいクライアント：ex2.example.com。クライアントはそのドメインに対してNAPTRクエリを実行し、次のNAPTRレコードが返されます。
;; order pref flags service regexp replacement
IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" ""
server1.ex2.example.com
IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" ""
server2.ex2.example.com
This indicates that the server supports TCP available at the returned host names.
これは、サーバーが、返されたホスト名で利用可能なTCPをサポートしていることを示しています。
As described in Section 9.4, accounting record duplicate detection is based on session identifiers. Duplicates can appear for various reasons:
セクション9.4で説明されているように、アカウンティングレコードの重複検出はセッション識別子に基づいています。重複はさまざまな理由で発生する可能性があります。
o Failover to an alternate server. Where close to real-time performance is required, failover thresholds need to be kept low. This may lead to an increased likelihood of duplicates. Failover can occur at the client or within Diameter agents.
o 代替サーバーへのフェイルオーバー。ほぼリアルタイムのパフォーマンスが必要な場合は、フェイルオーバーのしきい値を低く保つ必要があります。これにより、重複する可能性が高くなります。フェイルオーバーは、クライアントまたはDiameterエージェント内で発生する可能性があります。
o Failure of a client or agent after sending a record from non-volatile memory, but prior to receipt of an application-layer ACK and deletion of the record to be sent. This will result in retransmission of the record soon after the client or agent has rebooted.
o 不揮発性メモリからレコードを送信した後、アプリケーション層のACKを受信して送信するレコードを削除する前の、クライアントまたはエージェントの障害。これにより、クライアントまたはエージェントが再起動した直後にレコードが再送信されます。
o Duplicates received from RADIUS gateways. Since the retransmission behavior of RADIUS is not defined within [RFC2865], the likelihood of duplication will vary according to the implementation.
o RADIUSゲートウェイから受信した重複。 RADIUSの再送信動作は[RFC2865]で定義されていないため、重複の可能性は実装によって異なります。
o Implementation problems and misconfiguration.
o 実装の問題と設定ミス。
The T flag is used as an indication of an application-layer retransmission event, e.g., due to failover to an alternate server. It is defined only for request messages sent by Diameter clients or agents. For instance, after a reboot, a client may not know whether it has already tried to send the accounting records in its non-volatile memory before the reboot occurred. Diameter servers MAY use the T flag as an aid when processing requests and detecting duplicate messages. However, servers that do this MUST ensure that duplicates are found even when the first transmitted request arrives at the server after the retransmitted request. It can be used only in cases where no answer has been received from the server for a request and the request is sent again, (e.g., due to a failover to an alternate peer, due to a recovered primary peer or due to a client re-sending a stored record from non-volatile memory such as after reboot of a client or agent).
T flagは、代替サーバーへのフェイルオーバーなどによるアプリケーション層の再送信イベントを示すために使用します。Diameterクライアントまたはエージェントが送信する要求メッセージに対してだけ定義されます。たとえば再起動後、クライアントには、再起動前に不揮発性メモリ内のアカウンティングレコードを送信しようとしたかどうか分からない場合があります。Diameterサーバーは、要求処理および重複メッセージ検出の補助としてT flagを使用してもよい (MAY)。ただし、使用するサーバーは、再送信要求より後に最初の送信要求がサーバーへ到着した場合でも、重複を検出できるよう保証しなければなりません (MUST)。T flagを使用できるのは、要求に対する応答をサーバーから受信せず、その要求を再送信する場合だけです（たとえば、代替ピアへのフェイルオーバー、primary peerの復旧、クライアントまたはエージェントの再起動後に不揮発性メモリ内の保存レコードをクライアントが再送信する場合など）。
In some cases, the Diameter accounting server can delay the duplicate detection and accounting record processing until a post-processing phase takes place. At that time records are likely to be sorted according to the included User-Name and duplicate elimination is easy in this case. In other situations, it may be necessary to perform real-time duplicate detection, such as when credit limits are imposed or real-time fraud detection is desired.
場合によっては、Diameterアカウンティングサーバーは、後処理フェーズが行われるまで、重複の検出とアカウンティングレコードの処理を遅らせることができます。当時、レコードは含まれているユーザー名に従ってソートされる可能性が高く、この場合、重複の排除は簡単です。その他の状況では、クレジット制限が課されている場合やリアルタイムの不正検出が必要な場合など、リアルタイムの重複検出を実行する必要がある場合があります。
In general, only generation of duplicates due to failover or re-sending of records in non-volatile storage can be reliably detected by Diameter clients or agents. In such cases, the Diameter client or agents can mark the message as a possible duplicate by setting the T flag. Since the Diameter server is responsible for duplicate detection, it can choose whether or not to make use of the T flag, in order to optimize duplicate detection. Since the T flag does not affect interoperability, and it may not be needed by some servers, generation of the T flag is REQUIRED for Diameter clients and agents, but it MAY be implemented by Diameter servers.
一般にDiameterクライアントまたはエージェントが確実に検出できるのは、フェイルオーバー、または不揮発性ストレージ内のレコード再送信によって生じる重複だけです。この場合、DiameterクライアントまたはエージェントはT flagを設定し、メッセージを重複の可能性ありと印付けできます。Diameterサーバーが重複検出を担当するため、重複検出を最適化する目的でT flagを使用するかどうかを選択できます。T flagは相互運用性へ影響せず、一部のサーバーには不要な場合があるため、DiameterクライアントおよびエージェントはT flag生成を実装しなければなりません (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 duplicates that are out of order, the Diameter server should use backward and forward time windows when performing duplicate checking for the T-flag-marked request. For example, in order to allow time for the original record to exit the network and be recorded by the accounting server, the Diameter server can delay processing records with the T flag set until a time period TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after the closing of the original transport connection. After this time period, it may check the T-flag-marked records against the database with relative assurance that the original records, if sent, have been received and recorded.
Diameterサーバーは、受信したメッセージのTフラグをチェックして、レコードが重複している可能性があるかどうかを判断できます（MAY）。要求メッセージでTフラグが設定されている場合、サーバーは構成可能な複製時間ウィンドウ内で重複を逆方向および順方向に検索します。これにより、データベース検索がTフラグが設定されているレコードに制限されます。正常に実行されているネットワークでは、ネットワークパーティションとデバイスの障害はおそらくまれなイベントであるため、このアプローチは重複検出プロセスの大幅な最適化を表しています。フェイルオーバー中に、元の送信と重複した送信によってパスに沿って発生するネットワーク遅延の違いにより、Tフラグでマークされたレコードの後に元のレコードが受信される可能性があります。これが発生する可能性は、フェイルオーバー間隔が短くなるにつれて増加します。順不同の重複を検出できるようにするために、Diameterサーバーは、Tフラグのマークが付いたリクエストの重複チェックを実行するときに、後方および前方の時間枠を使用する必要があります。たとえば、元のレコードがネットワークから出て、アカウンティングサーバーによって記録されるまでの時間を確保するために、Diameterサーバーは、Tフラグが設定されたレコードの処理を、を閉じてからTIME_WAIT + RECORD_PROCESSING_TIME時間が経過するまで遅らせることができます。元のトランスポート接続。この期間が経過すると、Tフラグのマークが付いたレコードをデータベースと照合して、元のレコードが送信された場合は受信および記録されたことを相対的に保証します。
To be compatible with the existing DNS infrastructure and simplify host and domain name comparison, Diameter identities (FQDNs) are represented in ASCII form. This allows the Diameter protocol to fall in-line with the DNS strategy of being transparent from the effects of Internationalized Domain Names (IDNs) by following the recommendations in [RFC4690] and [RFC5890]. Applications that provide support for IDNs outside of the Diameter protocol but interacting with it SHOULD use the representation and conversion framework described in [RFC5890], [RFC5891], and [RFC3492].
Authors' Addresses
著者のアドレス
Victor Fajardo (editor) Telcordia Technologies One Telcordia Drive, 1S-222 Piscataway, NJ 08854 USA
ビクターファハルド（編集者）Telcordia Technologies One Telcordia Drive、1S-222 Piscataway、NJ 08854 USA
Phone: +1-908-421-1845
EMail: vf0213@gmail.com
Jari Arkko Ericsson Research 02420 Jorvas Finland
Jari Arkko Ericsson Research 02420 Jorvasフィンランド
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
John Loughney Nokia Research Center 955 Page Mill Road Palo Alto, CA 94304 US
John Loughney Nokia Research Center 955 Page Mill Road Palo Alto、CA 94304 US
Phone: +1-650-283-8068
EMail: john.loughney@nokia.com
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Geron Joron（編集者）Network Zen 228/356 Thanong Sunfight Bang Na、Bangkok 10260 Thailand
Phone: +66 (0) 87-0404617
EMail: glenzorn@gmail.com