[要約] RFC 9390 - Diameter Group Signaling は、大規模ネットワーク展開において、複数のDiameterセッションに一括操作を可能にするためのプロトコル拡張を定義しています。目的は、シグナリングを削減し、複数のセッションに対して同じ操作を一括で実行することです。

Internet Engineering Task Force (IETF)                          M. Jones
Request for Comments: 9390                                    Individual
Category: Standards Track                                     M. Liebsch
ISSN: 2070-1721                                                      NEC
                                                               L. Morand
                                                                  Orange
                                                              April 2023
        
Diameter Group Signaling
直径グループシグナル伝達
Abstract
概要

In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases can result in many thousands of command exchanges enforcing the same operation on each session in the group. In order to reduce signaling, it is desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization.

大規模なネットワークの展開では、単一の直径ノードは、100万以上の同時直径セッションをサポートできます。一部のユースケースでは、直径ノードが同じ操作を同時に直径セッションの大規模なグループに適用する必要があります。直径のベースプロトコルコマンドは単一のセッションで動作するため、これらのユースケースは、グループ内の各セッションで同じ操作を実施する数千のコマンド交換をもたらす可能性があります。信号を減らすために、単一またはいくつかのコマンド交換を使用して直径ノードによって管理されるすべて(または一部)でバルク操作を有効にすることが望ましいです。このドキュメントは、このシグナル伝達の最適化を実現するための直径プロトコル拡張を指定します。

Status of This Memo
本文書の位置付け

This is an Internet Standards Track document.

これは、インターネット標準トラックドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、インターネットエンジニアリングタスクフォース(IETF)の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ(IESG)からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9390.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9390で取得できます。

著作権表示

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(c)2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

このドキュメントは、BCP 78およびIETFドキュメント(https://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。

Table of Contents
目次
   1.  Introduction
   2.  Terminology
   3.  Protocol Overview
     3.1.  Building and Modifying Session Groups
     3.2.  Issuing Group Commands
     3.3.  Permission Considerations
   4.  Protocol Description
     4.1.  Session Grouping Capability Discovery
       4.1.1.  Capability Discovery Based on the Application Id
       4.1.2.  Capability Discovery Based on AVP Presence
     4.2.  Session Grouping
       4.2.1.  Group Assignment at Session Initiation
       4.2.2.  Removing a Session from a Session Group
       4.2.3.  Mid-session Group Assignment Modifications
     4.3.  Deleting a Session Group
     4.4.  Performing Group Operations
       4.4.1.  Sending Group Commands
       4.4.2.  Receiving Group Commands
       4.4.3.  Error Handling for Group Commands
       4.4.4.  Single-Session Fallback
   5.  Operation with Proxy Agents
   6.  Commands Formatting
     6.1.  Formatting Example: Group Re-Auth-Request
   7.  Attribute-Value Pairs (AVPs)
     7.1.  Session-Group-Info AVP
     7.2.  Session-Group-Control-Vector AVP
     7.3.  Session-Group-Id AVP
     7.4.  Group-Response-Action AVP
     7.5.  Session-Group-Capability-Vector AVP
   8.  Result-Code AVP Values
   9.  IANA Considerations
     9.1.  AVP Codes
     9.2.  New Registries
   10. Security Considerations
   11. Normative References
   Appendix A.  Session Management -- Exemplary Session State Machine
     A.1.  Use of Groups for the Authorization Session State Machine
   Acknowledgments
   Authors' Addresses
        
1. Introduction
1. はじめに

In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently. For example, a policy decision point may need to modify the authorized quality of service for all active users having the same type of subscription. The Diameter base protocol commands operate on a single session so these use cases can result in many thousands of command exchanges enforcing the same operation on each session in the group. In order to reduce signaling, it is desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges.

大規模なネットワークの展開では、単一の直径ノードは、100万以上の同時直径セッションをサポートできます。一部のユースケースでは、直径ノードが同じ操作を同時に直径セッションの大規模なグループに適用する必要があります。たとえば、ポリシーの決定ポイントは、同じタイプのサブスクリプションを持っているすべてのアクティブユーザーの許可されたサービス品質を変更する必要がある場合があります。直径のベースプロトコルコマンドは単一のセッションで動作するため、これらのユースケースは、グループ内の各セッションで同じ操作を実施する数千のコマンド交換をもたらす可能性があります。信号を減らすために、単一またはいくつかのコマンド交換を使用して直径ノードによって管理されるすべて(または一部)でバルク操作を有効にすることが望ましいです。

This document describes mechanisms for grouping Diameter sessions and applying Diameter commands, such as performing re-authentication, re-authorization, termination, and abortion of sessions to a group of sessions. This document does not define a new Diameter application. Instead, it defines mechanisms, commands, and Attribute-Value Pairs (AVPs) that may be used by any Diameter application that requires management of groups of sessions.

このドキュメントでは、直径セッションをグループ化し、再認可、再認可、終了、セッションの中絶などの直径コマンドを適用するメカニズムについて説明します。このドキュメントは、新しい直径アプリケーションを定義しません。代わりに、セッションのグループの管理を必要とする直径アプリケーションで使用できるメカニズム、コマンド、および属性値ペア(AVP)を定義します。

These mechanisms take the following design goals and features into account:

これらのメカニズムは、次の設計目標と機能を考慮に入れます。

* minimal impact to existing applications

* 既存のアプリケーションへの最小限の影響

* extension of existing commands' Command Code Format (CCF) with optional AVPs to enable grouping and group operations

* 既存のコマンドのコマンドコード形式(CCF)をオプションのAVPSで拡張して、グループ化とグループ操作を有効にします

* fallback to single-session operation

* シングルセッション操作へのフォールバック

* implicit discovery of capability to support grouping and group operations in case no external mechanism is available to discover a Diameter peer's capability to support session grouping and session group operations

* グループ化とグループ操作をサポートする能力の暗黙的な発見外部メカニズムが利用できない場合に備えて、セッショングループとセッショングループの操作をサポートする直径のピアの機能を発見する

2. Terminology
2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

This document uses terminology defined in [RFC6733].

この文書は、[RFC6733]で定義されている用語を使用します。

3. Protocol Overview
3. プロトコルの概要
3.1. Building and Modifying Session Groups
3.1. セッショングループの構築と修正

In order to accommodate bulk operations on Diameter sessions, the concept of session groups is introduced. Once sessions are added to a group, a command acting on the group will affect all the member sessions.

直径セッションのバルク操作に対応するために、セッショングループの概念が導入されています。セッションがグループに追加されると、グループに作用するコマンドがすべてのメンバーセッションに影響します。

The client and the server can assign a new Diameter session to a group, e.g., in case the subscription profile of the associated user has similar characteristics as the profile of other users whose Diameter session has been assigned to one or multiple groups. A single command can be issued and applied to all sessions associated with one or more such groups, e.g., to adjust common profile or policy settings.

クライアントとサーバーは、新しい直径セッションをグループに割り当てることができます。たとえば、関連するユーザーのサブスクリプションプロファイルが、直径セッションが1つまたは複数のグループに割り当てられている他のユーザーのプロファイルと同様の特性を持っている場合です。単一のコマンドを発行し、1つ以上のグループに関連するすべてのセッションに適用できます。たとえば、共通のプロファイルまたはポリシー設定を調整するためです。

The assignment of a Diameter session to a group can be changed during an ongoing session (mid-session). For example, if a user's subscription profile changes mid-session, a Diameter server may remove a session from an existing group and assign this session to a different group that is more appropriate for the new subscription profile.

直径セッションのグループへの割り当ては、進行中のセッション(セッション中)に変更できます。たとえば、ユーザーのサブスクリプションプロファイルがセッション中期に変更された場合、直径サーバーは既存のグループからセッションを削除し、このセッションを新しいサブスクリプションプロファイルにより適切な別のグループに割り当てることができます。

In the case of mobile users, the user's session may get transferred mid-session to a new Diameter client during handover and assigned to a different group, which is maintained at the new Diameter client.

モバイルユーザーの場合、ユーザーのセッションは、ハンドオーバー中に新しいDiameterクライアントにセッション中期に転送され、新しいDiameterクライアントに維持される別のグループに割り当てられる場合があります。

It may be required to delete a session group, e.g., at the expiry of a promotional period that applied to multiple subscriber profiles. Deletion of such group requires subsequent individual treatment of each of the assigned sessions. A node may decide to assign some of these sessions to any other existing or new group.

複数のサブスクライバープロファイルに適用されるプロモーション期間の有効期限に、セッショングループを削除する必要がある場合があります。そのようなグループの削除には、割り当てられた各セッションのその後の個別の扱いが必要です。ノードは、これらのセッションの一部を他の既存または新しいグループに割り当てることを決定する場合があります。

3.2. Issuing Group Commands
3.2. グループコマンドの発行

Changes in the network condition may result in the Diameter server's decision to close all sessions in a given group. For example, the server issues a single Session Termination Request (STR) command, including the identifier of the group of sessions that are to be terminated. The Diameter client treats the STR as a group command and initiates the termination of all sessions associated with the identified group. Subsequently, the client confirms the successful termination of these sessions to the server by sending a single Session Termination Answer (STA) command, which includes the identifier of the group.

ネットワーク条件の変更により、特定のグループのすべてのセッションを閉じるというDiameter Serverの決定が発生する場合があります。たとえば、サーバーは、終了するセッショングループの識別子を含む、単一のセッション終了要求(STR)コマンドを発行します。直径クライアントは、STRをグループコマンドとして扱い、特定されたグループに関連付けられたすべてのセッションの終了を開始します。その後、クライアントは、グループの識別子を含む単一のセッション終了回答(STA)コマンドを送信することにより、これらのセッションの成功した終了をサーバーに確認します。

3.3. Permission Considerations
3.3. 許可に関する考慮事項

Permission considerations in the context of this document apply to the permission of Diameter nodes to build new session groups, to assign/remove a session to/from a session group, and to delete an existing session group.

このドキュメントのコンテキストでの許可に関する考慮事項直径ノードの許可に適用され、新しいセッショングループを構築し、セッショングループにセッションを割り当て/削除し、既存のセッショングループを削除します。

When a client or server decides to create a new session group, e.g., to group all sessions that share certain characteristics, this node builds a session group identifier according to the rules described in Section 7.3 and becomes the owner of the group.

クライアントまたはサーバーが、特定の特性を共有するすべてのセッションをグループ化する新しいセッショングループを作成することを決定した場合、このノードはセクション7.3で説明されたルールに従ってセッショングループ識別子を構築し、グループの所有者になります。

After the creation of a session group, a session can be added to this session group by either the client or the server. However, a session can only be removed from a session group by the Diameter node (client or server) that has assigned this session to the session group.

セッショングループの作成後、クライアントまたはサーバーのいずれかによってこのセッショングループにセッションを追加できます。ただし、セッションは、このセッションをセッショングループに割り当てた直径ノード(クライアントまたはサーバー)によってのみセッショングループから削除できます。

A session group can only be deleted by the owner of the session group, resulting in individual treatment of the sessions that were assigned to this session group.

セッショングループは、セッショングループの所有者によってのみ削除され、このセッショングループに割り当てられたセッションの個別の扱いが行われます。

Diameter applications with implicit support for session groups MAY define a more constrained permission model. For example, a more constrained model could require that a client not remove a session from a group that is owned by the server. Details about enforcing a more constrained permission model are out of scope of this specification.

セッショングループを暗黙的にサポートする直径アプリケーションは、より制約された許可モデルを定義する場合があります。たとえば、より制約されたモデルでは、クライアントがサーバーが所有しているグループからセッションを削除しないことを要求する場合があります。より制約された許可モデルの実施に関する詳細は、この仕様の範囲外です。

4. Protocol Description
4. プロトコルの説明
4.1. Session Grouping Capability Discovery
4.1. セッショングループ化機能発見

Diameter nodes SHOULD NOT perform group operations with peer nodes unless the node has advertised support for session grouping and group operations.

直径ノードは、ノードがセッショングループとグループ操作のサポートを宣伝していない限り、ピアノードでグループ操作を実行してはなりません。

4.1.1. Capability Discovery Based on the Application Id
4.1.1. アプリケーションIDに基づく機能の発見

Newly defined Diameter applications may intrinsically support Diameter session grouping and group operations. In these cases, there is no need of a specific discovery mechanism for the support of session grouping capability besides the discovery of the Application Id assigned to the application advertised during the capability exchange phase described in Section 5.3 of [RFC6733].

新たに定義された直径アプリケーションは、直径セッションのグループ化とグループ操作を本質的にサポートする場合があります。これらの場合、[RFC6733]のセクション5.3で説明されている機能交換フェーズで宣伝されたアプリケーションIDに割り当てられたアプリケーションIDの発見に加えて、セッショングループ化機能をサポートするための特定の発見メカニズムは必要ありません。

System-specific and deployment-specific means, as well as out-of-band mechanisms for capability discovery, can be used to announce nodes' support for session grouping and session group operations. In such case, the optional Session-Group-Capability-Vector AVP, as described in Section 4.1.2, can be omitted in Diameter messages being exchanged between nodes.

システム固有および展開固有の手段、ならびに能力発見のための帯域外メカニズムを使用して、セッショングループとセッショングループの操作に対するノードのサポートを発表できます。そのような場合、セクション4.1.2で説明されているように、オプションのセッショングループ - グループ能力 - ベクトルAVPは、ノード間で交換される直径メッセージで省略できます。

4.1.2. Capability Discovery Based on AVP Presence
4.1.2. AVPの存在に基づく機能発見

If no other mechanism for capability discovery is deployed to enable Diameter nodes to learn about nodes' capability to support session grouping and group commands for a given application, a Diameter node SHOULD append the Session-Group-Capability-Vector AVP to any Diameter application messages exchanged with the other Diameter nodes to announce its capability to support session grouping and session group operations for the advertised application. Implementations following the specification as per this document MUST set the BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability-Vector AVP.

能力発見のための他のメカニズムが展開されていない場合は、直径ノードが特定のアプリケーションのセッショングループ化とグループコマンドをサポートするノードの機能について学習できない場合、直径ノードはセッショングループとグループのキャピールベクトルAVPを任意の直径アプリケーションメッセージに追加する必要があります他の直径ノードと交換して、広告されたアプリケーションのセッショングループとセッショングループの操作をサポートする機能を発表しました。このドキュメントに従って仕様に続く実装は、セッション-Group-Capability-Vector AVPのbase_session_group_capabilityフラグを設定する必要があります。

When a Diameter node receives at least one Session-Group-Capability-Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag set, the receiving Diameter node discovers the supported session grouping capability of the sending Diameter node for the advertised application and MUST cache this information for the lifetime of the routing table entry associated with the peer identity / Application Id pair (see Section 2.7 of [RFC6733]).

直径ノードがbase_session_group_capabilityフラグセットを備えたノードから少なくとも1つのセッショングループとグループのキャピールベクトルAVPを受信すると、受信直径ノードは、広告されたアプリケーションの送信直径ノードのサポートされているセッショングループ化能力を発見し、この情報はこの情報をキャッシュする必要があります。ピアアイデンティティ /アプリケーションIDペアに関連するルーティングテーブルエントリの寿命([RFC6733]のセクション2.7を参照)。

4.2. Session Grouping
4.2. セッショングループ化

This specification does not limit the number of session groups to which a single session is assigned. It is left to the implementation of an application to determine such limitations. If an application facilitates a session to belong to multiple session groups, the application MUST maintain consistency of associated application session states for these multiple session groups.

この仕様は、単一のセッションが割り当てられるセッショングループの数を制限しません。このような制限を決定するために、アプリケーションの実装に任されています。アプリケーションがセッションを容易にして複数のセッショングループに属している場合、アプリケーションは、これらの複数のセッショングループの関連するアプリケーションセッション状態の一貫性を維持する必要があります。

Either Diameter node (client or server) can initiate the assignment of a session to a single or multiple session groups. Modification of a group by removing or adding a single or multiple user sessions can be initiated and performed mid-session by either Diameter node responsible for the session assignment to this group. Although Diameter is a peer-to-peer protocol, Diameter Authentication, Authorization, and Accounting (AAA) applications typically assign the role of a "Diameter client" to the Diameter node initiating the Diameter session and the role of "Diameter server" to the node authorizing the Diameter session. This specification does not restrict group creation, assignment, or deletion actions to a specific role. In the following sections, "Diameter node" is used to refer to either role. Section 5 describes particularities about session grouping and performing group commands when relay agents or proxies are deployed.

直径ノード(クライアントまたはサーバー)のいずれかが、単一または複数のセッショングループへのセッションの割り当てを開始できます。単一または複数のユーザーセッションを削除または追加することにより、グループの変更を開始および実行することができ、このグループへのセッション割り当てのいずれかの直径ノードによってセッション中間を実行できます。直径はピアツーピアプロトコルですが、直径認証、認証、および会計(AAA)アプリケーションは通常、直径セッションを開始する直径ノードに「直径クライアント」の役割と、「直径サーバー」の役割を割り当てます。直径セッションの承認ノード。この仕様は、グループの作成、割り当て、または削除アクションを特定の役割に制限するものではありません。次のセクションでは、「直径ノード」がいずれかの役割を参照するために使用されます。セクション5では、リレーエージェントまたはプロキシが展開されている場合のセッショングループ化とグループコマンドの実行に関する特殊性について説明します。

Any Diameter node that has advertised support of session grouping and group operations MUST store and maintain the group assignment as part of the session's state. A list of all known session groups is locally maintained on each node, with each group pointing to individual sessions being assigned to the group. Each Diameter node MUST also keep a record about sessions that it has assigned to a session group.

セッショングループとグループ操作のサポートを宣伝した直径ノードは、セッションの状態の一部としてグループ割り当てを保存および維持する必要があります。すべての既知のセッショングループのリストは、各ノードでローカルで維持されており、各グループは個々のセッションがグループに割り当てられていることを指しています。各直径ノードは、セッショングループに割り当てられたセッションに関する記録も保持する必要があります。

4.2.1. Group Assignment at Session Initiation
4.2.1. セッション開始時のグループ割り当て

To assign a session to a group at session initiation, a Diameter client sends a service-specific request, e.g., Network Access Server Requirements (NASREQ) AA-Request [RFC7155], containing one or more session group identifiers. Each of these groups MUST be identified by a unique Session-Group-Id contained in a separate Session-Group-Info AVP, as specified in Section 7.

セッション開始時にグループにセッションを割り当てるために、直径クライアントは、1つ以上のセッショングループ識別子を含む、ネットワークアクセスサーバー要件(NASREQ)AA-Request [RFC7155]などのサービス固有のリクエストを送信します。これらの各グループは、セクション7で指定されているように、別のセッショングループ-INFO AVPに含まれる一意のセッショングループIDによって識別される必要があります。

The client may choose one or multiple session groups from a list of existing session groups. Alternatively, the client may decide to create a new group to which the session is assigned and identify itself in the <DiameterIdentity> portion of the Session-Group-Id AVP, as per Section 7.3. For all assignments of a session to an active session group made by the client or the server, the SESSION_GROUP_STATUS flag in the Session-Group-Info AVP, which identifies the session group, MUST be set. A set SESSION_GROUP_STATUS flag indicates that the identified session group has just been created or is still active.

クライアントは、既存のセッショングループのリストから1つまたは複数のセッショングループを選択できます。あるいは、クライアントは、セッションが割り当てられる新しいグループを作成し、セクション7.3に従ってセッショングループID AVPの<ariameteridentity>部分で自分自身を識別することを決定する場合があります。クライアントまたはサーバーが作成したアクティブなセッショングループへのセッションのすべての割り当てについて、セッショングループを識別するセッション-Group-INFO AVPのSession_Group_Statusフラグを設定する必要があります。セットSESSION_GROUP_STATUSフラグは、特定されたセッショングループが作成されたばかりであるか、まだアクティブであることを示します。

The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector AVP in each appended Session-Group-Info AVP to indicate that the session contained in the request should be assigned to the identified session group.

クライアントは、リクエストに含まれるセッションを特定したセッショングループに割り当てる必要があることを示すために、各追加セッション-Group-INFO AVPのセッショングループ-Group-Control-Vector AVPのSESSION_GROUP_ALLOCATION_ACTIONフラグを設定する必要があります。

The client may also indicate in the request that it supports assignment of the session to one or more groups by the server. In such case, the client MUST include the Session-Group-Info AVP in the request, including the Session-Group-Control-Vector AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP.

また、クライアントは、サーバーによる1つ以上のグループへのセッションの割り当てをサポートすることを要求で示す場合があります。そのような場合、クライアントは、セッション_GROUP_ALLOCATION_ACTIONフラグを備えたセッション - グループコントロールベクトルAVPを含むが、セッション-GROUP-ID AVPはありません。

If the Diameter server receives a command request from a Diameter client and the command includes at least one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-Control-Vector AVP set, the server can accept or reject the request for group assignment. Reasons for rejection may be, e.g., lack of resources for managing additional groups. When rejected, the session MUST NOT be assigned to any session group.

Diameter ServerがDiameterクライアントからコマンド要求を受信し、コマンドにセッション-Group_Allocation_Action Flagを使用して少なくとも1つのセッション-Group-INFO AVPが含まれている場合、サーバーはのリクエストを受け入れるか拒否することができます。グループ割り当て。拒否の理由は、たとえば、追加のグループを管理するためのリソースの不足である可能性があります。拒否された場合、セッションはセッショングループに割り当てられてはなりません。

If the Diameter server accepts the client's request for a group assignment, the server MUST assign the new session to each (one or more) of the identified session groups when present in the Session-Group-Info AVP. If one or multiple identified session groups are not already stored by the server, the server MUST store the one or more newly identified groups to its local list of known session groups. When sending the response to the client, e.g., a service-specific authorization response, as per NASREQ AA-Answer [RFC7155], the server MUST include all Session-Group-Info AVPs received in the client's request.

Diameterサーバーがグループ割り当てに対するクライアントの要求を受け入れる場合、サーバーは、セッショングループ-INFO AVPに存在する場合、識別されたセッショングループの各(1つ以上)の新しいセッションを割り当てる必要があります。1つまたは複数の識別されたセッショングループがサーバーによってまだ保存されていない場合、サーバーは1つ以上の新しく識別されたグループを既知のセッショングループのローカルリストに保存する必要があります。NASREQ AA-Answer [RFC7155]によると、クライアントに応答を送信する場合、サービス固有の認証応答は、クライアントのリクエストで受信したすべてのセッショングループ-INFO AVPを含める必要があります。

In addition to the one or multiple session groups identified in the client's request, the server may decide to assign the new session to one or multiple additional groups. In such case, the server MUST add to the response the additional Session-Group-Info AVPs, each identifying a session group to which the new session is assigned by the server. Each of the Session-Group-Info AVPs added by the server MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the Session-Group-Control-Vector AVP.

クライアントの要求で識別された1つまたは複数のセッショングループに加えて、サーバーは新しいセッションを1つまたは複数の追加グループに割り当てることを決定する場合があります。そのような場合、サーバーは追加のセッショングループ-INFO AVPを応答に追加する必要があります。各セッションがサーバーによって割り当てられるセッショングループを識別します。サーバーによって追加された各セッション-Group-INFO AVPは、Session-Group_Allocation_actionフラグをセッション-Group-Control-Vector AVPに設定する必要があります。

If the Diameter server rejects the client's request for a group assignment, the server sends the response to the client, e.g., a service-specific authorization response, as per NASREQ AA-Answer [RFC7155], and MUST include all Session-Group-Info AVPs received in the client's request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector AVP. The server MAY still accept the client's request for the identified session to proceed despite rejecting the group assignment. The response sent to the client will then indicate success in the result code. In this case, the session is treated as a single session without assignment to any session group by the Diameter nodes.

Diameter Serverがクライアントのグループ割り当ての要求を拒否した場合、サーバーは、Nasreq AA-Answer [RFC7155]に従って、クライアントに応答をクライアントに送信し、すべてのセッショングループINFOを含める必要があります。AVPSは、セッション-Group_Allocation_action FlagのFlagをクリアしながらクライアントのリクエストで(もしあれば)受信しました。サーバーは、グループの割り当てを拒否したにもかかわらず、識別されたセッションに対するクライアントのリクエストを引き続き受け入れる場合があります。クライアントに送信された応答は、結果コードの成功を示します。この場合、セッションは、直径ノードによってセッショングループに割り当てられない単一のセッションとして扱われます。

If the assignment of the session to one or some of the multiple identified session groups fails, the session group assignment is treated as a failure. In such case, the session is treated as a single session without assignment to any session group by the Diameter nodes. The server sends the response to the client and MAY include those Session-Group-Info AVPs for which the group assignment failed. The SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group-Info AVPs MUST be cleared.

複数の識別されたセッショングループの1つまたは一部へのセッションの割り当てが失敗した場合、セッショングループの割り当ては失敗として扱われます。そのような場合、セッションは、直径ノードによってセッショングループに割り当てられない単一のセッションとして扱われます。サーバーはクライアントに応答を送信し、グループの割り当てが失敗したセッショングループ-INFO AVPを含めることができます。含まれているセッション-Group-INFO AVPのセッション_GROUP_ALLOCATION_ACTIONフラグをクリアする必要があります。

If the Diameter server receives a command request from a Diameter client and the command includes a Session-Group-Info AVP that does not include a Session-Group-Id AVP, the server MAY decide to assign the session to one or multiple session groups. For each session group to which the server assigns the new session, the server includes a Session-Group-Info AVP with the Session-Group-Id AVP, identifying a session group in the response sent to the client. Each of the Session-Group-Info AVPs included by the server MUST have the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector AVP set.

DiameterサーバーがDiameterクライアントからコマンド要求を受信し、コマンドにセッション-Group-ID AVPが含まれていないセッショングループ-ID AVPが含まれている場合、サーバーはセッションを1つまたは複数のセッショングループに割り当てることを決定する場合があります。サーバーが新しいセッションを割り当てるセッショングループごとに、サーバーにはセッション-Group-ID AVPを使用したセッショングループ-ID AVPが含まれ、クライアントに送信された応答でセッショングループを識別します。サーバーに含まれる各セッション-Group-INFO AVPには、セッション-Group-Control-Vector AVPセットのSession_Group_Allocation_actionフラグが必要です。

If the Diameter server receives a command request from a Diameter client and the command does not contain any Session-Group-Info AVPs, the server MUST NOT assign the new session to any session group but treat the request the same as for a single session. The server MUST NOT return any Session-Group-Info AVP in the command response.

DiameterサーバーがDiameterクライアントからコマンド要求を受信し、コマンドにセッショングループ-INFO AVPSが含まれていない場合、サーバーは新しいセッションをセッショングループに割り当ててはなりません。サーバーは、コマンド応答でセッショングループ-INFO AVPを返してはなりません。

If the Diameter client receives a response to its previously issued request from the server and the response includes at least one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag of the associated Session-Group-Control-Vector AVP set, the client MUST add the new session to all session groups as identified in one or multiple Session-Group-Info AVPs. If the Diameter client fails to add the session to one or more session groups as identified in one or multiple Session-Group-Info AVPs, the client MUST terminate the session. The client MAY send a subsequent request for session initiation to the server without requesting the assignment of the session to a session group.

Diameterクライアントがサーバーから以前に発行された要求に対する応答を受信し、応答には、関連するSession-Group_Allocation_actionフラグを使用して少なくとも1つのセッション-Group-INFO AVPが含まれている場合、クライアントはクライアントに追加する必要があります。1つまたは複数のセッショングループ-INFO AVPで特定されたすべてのセッショングループへの新しいセッション。Diameterクライアントが、1つまたは複数のセッショングループ-INFO AVPで識別された1つ以上のセッショングループにセッションを追加できない場合、クライアントはセッションを終了する必要があります。クライアントは、セッションの割り当てをセッショングループにリクエストせずに、セッション開始の後続のリクエストをサーバーに送信する場合があります。

If the Diameter client receives a response to its previously issued request from the server and one or more Session-Group-Info AVPs have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated Session-Group-Control-Vector AVP cleared, the client MUST terminate the assignment of the session to one or multiple groups. If the response from the server indicates success in the result code but only the assignment of the session to a session group has been rejected by the server, the client treats the session as a single session without group assignment.

Diameterクライアントがサーバーから以前に発行された要求に対する応答を受信し、1つ以上のセッショングループ-INFO AVPに関連するセッション-Group_Allocation_action Flagがclearedのセッション_group_allocation_actionフラグがクリアされている場合、クライアントは1つまたは複数のグループへのセッション。サーバーからの応答が結果コードでの成功を示しているが、セッショングループへのセッションの割り当てのみがサーバーによって拒否された場合、クライアントはセッションをグループ割り当てのない単一のセッションとして扱います。

If a Diameter client sends a request for session initiation containing one or more Session-Group-Info AVPs but the response from the Diameter server does not contain a Session-Group-Info AVP, the Diameter client MUST proceed as if the request was processed without group assignments. The Diameter client MUST NOT retry to request group assignment for this session but MAY try to request group assignment for other new sessions.

直径クライアントが、1つ以上のセッショングループ-INFO AVPを含むセッション開始のリクエストを送信するが、直径サーバーからの応答にセッショングループ-INFO AVPが含まれていない場合、ダイアムクライアントはリクエストが処理されないかのように進行する必要がありますグループ割り当て。Diameterクライアントは、このセッションのグループ割り当てを要求するために再試行してはなりませんが、他の新しいセッションのグループ割り当てを要求しようとする場合があります。

4.2.2. Removing a Session from a Session Group
4.2.2. セッショングループからセッションを削除します

When a Diameter client decides to remove a session from a particular session group, the client sends a service-specific re-authorization request to the server and adds one Session-Group-Info AVP to the request for each session group from which the client wants to remove the session. The session that is to be removed from a group is identified in the Session-Id AVP of the command request. The SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector AVP in each Session-Group-Info AVP MUST be cleared to indicate removal of the session from the session group identified in the associated Session-Group-Id AVP.

直径クライアントが特定のセッショングループからセッションを削除することを決定した場合、クライアントはサーバーにサービス固有の再承認要求を送信し、クライアントが望む各セッショングループのリクエストに1つのセッショングループ-INFO AVPを追加しますセッションを削除します。グループから削除されるセッションは、コマンドリクエストのセッションID AVPで識別されます。各セッション-GROUP-ID AVPでセッションの削除を示すために、各セッション-Group-ID AVPのセッション-Group-Control-Vector AVPのセッション_GROUP_ALLOCATION_ACTIONフラグをクリアする必要があります。

When a Diameter client decides to remove a session from all session groups to which the session has been previously assigned, the client sends a service-specific re-authorization request to the server and adds a single Session-Group-Info AVP to the request that has the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP omitted. The Session-Id AVP in the re-authorization request identifies the session that is to be removed from all groups to which it had been previously assigned.

Diameterクライアントがセッションが以前に割り当てられたすべてのセッショングループからセッションを削除することを決定した場合、クライアントはサーバーにサービス固有の再承認要求を送信し、単一のセッショングループ-INFO AVPをリクエストに追加します。session_group_allocation_actionフラグがクリアされ、Session-Group-ID AVPが省略されています。再承認要求のセッションID AVPは、以前に割り当てられていたすべてのグループから削除されるセッションを識別します。

If the Diameter server receives a request from the client that has at least one Session-Group-Info AVP appended with the SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove the session from the session group identified in the associated Session-Group-Id AVP. If the request includes at least one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Id AVP present, the server MUST remove the session from all session groups to which the session has been previously assigned. The server MUST include in its response to the requesting client all Session-Group-Id AVPs received in the request.

Diameter Serverが、Session_Group_Allocation_Action FlagがクリアされたSESSION_GROUP_ALLOCATION_ACTIONフラグに追加された少なくとも1つのセッショングループ-INFO AVPを備えたクライアントからリクエストを受信した場合、サーバーは、関連するセッションGroup-ID AVPで識別されたセッショングループからセッションを削除する必要があります。リクエストに、session_group_allocation_actionフラグがクリアされ、セッションID AVPが表示されない少なくとも1つのセッション-Group-INFO AVPが含まれている場合、サーバーはセッションが以前に割り当てられたすべてのセッショングループからセッションを削除する必要があります。サーバーは、リクエストで受信したすべてのセッショングループ-ID AVPを要求するクライアントへの応答に含める必要があります。

When the Diameter server decides to remove a session from one or multiple particular session groups or from all session groups to which the session has been assigned beforehand, the server sends a Re-Auth-Request (RAR) or a service-specific server-initiated request to the client, indicating the session in the Session-Id AVP of the request. The client sends a Re-Auth-Answer (RAA) or a service-specific answer to respond to the server's request. The client subsequently sends a service-specific re-authorization request containing one or multiple Session-Group-Info AVPs, each indicating a session group to which the session had been previously assigned. To indicate removal of the indicated session from one or multiple session groups, the server sends a service-specific authorization response to the client, containing a list of Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP identifying the session group from which the session should be removed. The server MAY include with the service-specific authorization response a list of Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP identifying session groups to which the session remains subscribed. If the server decides to remove the identified session from all session groups to which the session has been previously assigned, the server includes in the service-specific authorization response at least one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and Session-Group-Id AVP absent.

Diameter Serverが、1つまたは複数の特定のセッショングループまたはセッションが事前に割り当てられたすべてのセッショングループからセッションを削除することを決定した場合、サーバーはReauth-Request(RAR)またはサービス固有のサーバーが開始することを送信しますクライアントへのリクエスト。リクエストのセッションID AVPでのセッションを示します。クライアントは、サーバーのリクエストに応答するために、再オーース回答(RAA)またはサービス固有の回答を送信します。その後、クライアントは、1つまたは複数のセッショングループ-INFO AVPを含むサービス固有の再承認リクエストを送信します。それぞれが、セッションが以前に割り当てられたセッショングループを示しています。1つまたは複数のセッショングループから示されたセッションの削除を示すために、サーバーはクライアントにサービス固有の承認応答を送信します。Session_Group_Allocation_actionFallがクリアされたセッション-Group-ID AVPのリストを含みます。セッションを削除するセッショングループを特定します。サーバーには、Session_Group_Allocation_Action Flagセットを備えたセッション-Group-ID AVPのセッション-Group-ID AVPのリストと、セッションがサブスクライブされたままのセッショングループを識別するセッション-Group-ID AVPのリストを含めることができます。サーバーがセッションが以前に割り当てられたすべてのセッショングループから識別されたセッションを削除することを決定した場合、サーバーは、セッション_group_allocation_actionフラグがクリアされ、セッション_group_allocation_actionのフラグを備えた少なくとも1つのセッショングループ-info AVPにサービス固有の承認応答に含まれます-id avp存在。

4.2.3. Mid-session Group Assignment Modifications
4.2.3. セッションミッドグループの割り当ての変更

Either Diameter node (client or server) can modify the group membership of an active Diameter session according to the specified permission considerations.

直径ノード(クライアントまたはサーバー)は、指定された許可に関する考慮事項に従って、アクティブな直径セッションのグループメンバーシップを変更できます。

To update an assigned group mid-session, a Diameter client sends a service-specific re-authorization request to the server, containing one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP present, identifying the session group to which the session should be assigned. With the same message, the client MAY send one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP identifying the session group from which the identified session is to be removed. To remove the session from all previously assigned session groups, the client includes at least one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id AVP present. When the server received the service-specific re-authorization request, it MUST update its locally maintained view of the session groups for the identified session according to the appended Session-Group-Info AVPs. The server sends a service-specific authorization response to the client containing one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP identifying the new session group to which the identified session has been assigned.

割り当てられたグループミッドセッションを更新するために、Diameterクライアントは、Session_Group_Allocation_action Flag SetとSession-Group-ID AVP存在を備えた1つまたは複数のセッショングループ-ID AVPを含むサービス固有の再承認要求をサーバーに送信します。セッションを割り当てる必要があるセッショングループを特定します。同じメッセージを使用すると、クライアントは、Session_Group_Allocation_action Flagがクリアされ、識別されたセッションを削除するセッショングループを識別するセッション_GROUP_ALLOCATION_ACTIONフラグを使用して、1つまたは複数のセッショングループINFO AVPを送信できます。以前に割り当てられたすべてのセッショングループからセッションを削除するために、クライアントには、SESSION_GROUP_ALLOCATION_ACTIONフラグがクリアされ、Session-Group-ID AVPが表示されない少なくとも1つのセッショングループ-INFO AVPが含まれています。サーバーがサービス固有の再承認リクエストを受信した場合、Appred Session-Group-INFO AVPに従って、特定されたセッションのセッショングループのローカルに維持されたビューを更新する必要があります。サーバーは、Session_Group_Allocation_Action Flagセットと、特定されたセッションが割り当てられた新セッショングループを識別するSESSION_GROUP_ALLOCATION_ACTION FLAGを含む1つまたは複数のセッショングループAVPを含むクライアントにサービス固有の承認応答を送信します。

When a Diameter server decides to update assigned groups mid-session, it sends a Re-Auth-Request (RAR) message or a service-specific request to the client identifying the session for which the session group lists are to be updated. The client responds with a Re-Auth-Answer (RAA) message or a service-specific answer. The client subsequently sends a service-specific re-authorization request containing one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP identifying the session group to which the session had been previously assigned. The server responds with a service-specific authorization response and includes one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP identifying the session group to which the identified session is to be assigned. With the same response message, the server MAY send one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP identifying the session groups from which the identified session is to be removed. When a server wants to remove the session from all previously assigned session groups, it sends at least one Session- Group-Info AVP with the response having the SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id AVP present.

Diameter Serverが割り当てられたグループの中間グループを更新することを決定した場合、セッショングループのリストを更新するセッションを識別する、クライアントにReAuth-Request(RAR)メッセージまたはサービス固有のリクエストをクライアントに送信します。クライアントは、Reauth-Answer(RAA)メッセージまたはサービス固有の回答で応答します。その後、クライアントは、Session_Group_Allocation_action Flagセットとセッション-Group-ID AVPを使用して、1つまたは複数のセッショングループ-IDを含むサービス固有の再承認リクエストを送信し、セッションが以前に割り当てられたセッショングループを識別します。サーバーは、サービス固有の承認応答で応答し、Session_Group_Allocation_actionフラグセットと、識別されたセッションを割り当てるセッショングループを識別するSESSION_GROUP_ALLOCATION_ACTION FLAGを使用して、1つまたは複数のセッショングループID AVPを含みます。同じ応答メッセージを使用すると、サーバーは、Session_Group_Allocation_action Flagがクリアされ、識別されたセッションを削除するセッショングループを識別するセッション_GROUP_ALLOCATION_ACTIONフラグを使用して、1つまたは複数のセッショングループINFO AVPを送信できます。サーバーが以前に割り当てられたすべてのセッショングループからセッションを削除したい場合、少なくとも1つのセッション-NFO-INFO AVPをセッション_GROUP_ALLOCATION_ACTIONフラグをクリアし、セッション-Group-ID AVPが表示されません。

4.3. Deleting a Session Group
4.3. セッショングループの削除

To explicitly delete a session group and release the associated Session-Group-Id value, the owner of a session group appends a single Session-Group-Info AVP with the SESSION_GROUP_STATUS flag cleared and the Session-Group-Id AVP identifying the session group that is to be deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated Session-Group-Control-Vector AVP MUST be cleared.

セッショングループを明示的に削除し、関連するセッショングループ-ID値をリリースするために、セッショングループの所有者は、セッション_GROUP_STATUSフラグをクリアし、セッション-Group-ID AVPを識別し、セッショングループを識別するセッショングループを識別して、単一のセッション-Group-ID AVPを追加します。削除されます。関連するセッション-Group-Control-Vector AVPのsession_group_allocation_actionフラグをクリアする必要があります。

A session group is implicitly deleted and its identifier is released after the last session has been removed from this session group.

セッショングループは暗黙的に削除され、その識別子は最後のセッションがこのセッショングループから削除された後にリリースされます。

4.4. Performing Group Operations
4.4. グループ操作の実行
4.4.1. Sending Group Commands
4.4.1. グループコマンドを送信します

Either Diameter node (client or server) can request the recipient of a request to process an associated command for all sessions assigned to one or multiple groups by identifying these groups in the request. The sender of the request appends for each group to which the command applies a Session-Group-Info AVP including the Session-Group-Id AVP to identify the associated session group. Both the SESSION_GROUP_ALLOCATION_ACTION flag and the SESSION_GROUP_STATUS flag MUST be set.

直径ノード(クライアントまたはサーバー)のいずれかが、リクエストのリクエストを受信者に要求して、リクエスト内のこれらのグループを識別することにより、1つまたは複数のグループに割り当てられたすべてのセッションに関連するコマンドを処理することができます。リクエストの送信者は、コマンドがセッション-Group-ID AVPを含むセッショングループ-ID AVPを適用する各グループに追加され、関連するセッショングループを識別します。session_group_allocation_actionフラグとsession_group_statusフラグの両方を設定する必要があります。

If the Command Code Format (CCF) of the request mandates a Session-Id AVP, the Session-Id AVP MUST identify one of the single sessions that is assigned to at least one of the groups being identified in the appended Session-Group-Id AVPs.

リクエストのコマンドコード形式(CCF)がセッションID AVPを義務付けている場合、セッションID AVPは、Apped Session-Group-IDで識別されているグループの少なくとも1つに割り当てられた単一セッションの1つを識別する必要があります。AVP。

The sender of the request MUST indicate to the receiver how multiple resulting transactions associated with a group command are to be treated by appending a single instance of a Group-Response-Action AVP. For example, when a server sends a Re-Auth-Request (RAR) or a service-specific server-initiated request to the client, it indicates to the client to follow the request according to one of three possible procedures. When the server sets the Group-Response-Action AVP to ALL_GROUPS (1), the client sends a single RAR message for all identified groups. When the server sets the Group-Response-Action AVP to PER_GROUP (2), the client sends a single RAR message for each identified group individually. When the server sets the Group-Response-Action AVP to PER_SESSION (3), the client follows up with a single RAR message per impacted session. If a session is included in more than one of the identified session groups, the client sends only one RAR message for that session.

リクエストの送信者は、Group-Response-action AVPの単一インスタンスを追加することにより、グループコマンドに関連付けられた複数の結果のトランザクションがどのように扱われるかを受信者に示す必要があります。たとえば、サーバーがクライアントにリクエスト(RAR)またはサービス固有のサーバー開始要求をクライアントに送信すると、3つの可能な手順のいずれかに従ってリクエストに従うことをクライアントに示します。サーバーがGroup-response-action AVPをALL_GROUPS(1)に設定すると、クライアントは識別されたすべてのグループに対して単一のRARメッセージを送信します。サーバーがGroup-response-action AVPをPer_group(2)に設定すると、クライアントは識別された各グループに個別に単一のRARメッセージを送信します。サーバーがGroup-response-action AVPをper_session(3)に設定すると、クライアントは影響を受けたセッションごとに1つのRARメッセージをフォローアップします。セッションが識別されたセッショングループの複数に含まれている場合、クライアントはそのセッションに1つのRARメッセージのみを送信します。

If the sender sends a request including the Group-Response-Action AVP set to ALL_GROUPS (1) or PER_GROUP (2), it has to expect some delay before receiving one or more corresponding answers, as the answers will only be sent back when the request is processed for all the sessions or all the sessions of a session group. If the processing of the request is delay sensitive, the sender SHOULD NOT set the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be sent before the complete process of the request for all the sessions or if the request timeout timer is high enough, the sender MAY set the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2).

送信者がALL_GROUPS(1)またはPER_GROUP(2)に設定されたGroup-response-action AVPを含むリクエストを送信する場合、1つ以上の対応する回答を受信する前に、回答が送信される場合にのみ返信されるため、ある程度の遅延を期待する必要があります。リクエストは、すべてのセッションまたはセッショングループのすべてのセッションのために処理されます。リクエストの処理が遅延に敏感な場合、送信者はグループ応答アクションAVPをAll_Groups(1)またはPer_Group(2)に設定してはなりません。すべてのセッションのリクエストの完全なプロセスの前に回答を送信できる場合、またはリクエストタイムアウトタイマーが十分に高い場合、送信者はグループ応答アクションAVPをALL_GROUPS(1)またはPER_GROUP(2)に設定できます。

If the sender wants the receiver of the request to process the associated command for a single session, the sender does not append any group identifier; it identifies only the relevant session in the Session-Id AVP.

送信者がリクエストの受信者に1つのセッションの関連コマンドを処理することを望んでいる場合、送信者はグループ識別子を追加しません。セッションID AVPの関連セッションのみを識別します。

4.4.2. Receiving Group Commands
4.4.2. グループコマンドを受信します

A Diameter node receiving a request to process a command for a group of sessions identifies the relevant groups according to the included Session-Group-Id AVP in the Session-Group-Info AVP and processes the group command according to the included Group-Response-Action AVP. If the received request identifies multiple groups in multiple, included Session-Group-Id AVPs, the receiver SHOULD process the associated command for each of these groups. If a session has been assigned to more than one of the identified groups, the receiver MUST process the associated command only once per session.

セッションのグループのコマンドを処理するリクエストを受信する直径ノードは、セッション-Group-ID AVPに含まれるセッショングループID AVPに従って関連するグループを識別し、含まれるグループ応答 - に従ってグループコマンドを処理します。アクションAVP。受信したリクエストが複数の複数のグループを識別する場合、セッショングループ-ID AVPを含む場合、受信者はこれらの各グループの関連コマンドを処理する必要があります。セッションが識別されたグループの複数に割り当てられている場合、受信者はセッションごとに1回だけ関連するコマンドを処理する必要があります。

4.4.3. Error Handling for Group Commands
4.4.3. グループコマンドのエラー処理

When a Diameter node receives a request to process a command for one or more session groups and the result of processing the command is an error that applies to all sessions in the identified groups, an associated protocol error MUST be returned to the source of the request. In such case, the sender of the request MUST fall back to single-session processing and the session groups, which have been identified in the group command, MUST be deleted according to the procedure described in Section 4.3.

直径ノードが1つ以上のセッショングループのコマンドを処理するリクエストを受信し、コマンドを処理した結果が特定されたグループのすべてのセッションに適用されるエラーである場合、関連するプロトコルエラーをリクエストのソースに返す必要があります。そのような場合、リクエストの送信者はシングルセッション処理に戻る必要があり、グループコマンドで識別されたセッショングループは、セクション4.3で説明されている手順に従って削除する必要があります。

When a Diameter node receives a request to process a command for one or more session groups and the result of processing the command succeeds for some sessions identified in one or multiple session groups but fails for one or more sessions, the Result-Code AVP in the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS, as per Section 7.1.2 of [RFC6733].

直径ノードが1つ以上のセッショングループのコマンドを処理するリクエストを受信し、処理の結果が1つまたは複数のセッショングループで識別されたいくつかのセッションでコマンドが成功するが、1つ以上のセッションで失敗すると、結果コードAVPは応答メッセージは、[RFC6733]のセクション7.1.2に従って、diameter_limited_successを示す必要があります。

In the case of limited success, the sessions for which the processing of the group command failed MUST be identified by including their Session-Id AVP in the Failed-AVP AVP, as per Section 7.5 of [RFC6733]. The sender of the request MUST fall back to single-session operation for each of the identified sessions for which the group command failed. In addition, each of these sessions MUST be removed from all session groups to which the group command applied. To remove sessions from a session group, the Diameter client performs the procedure described in Section 4.2.2.

限られた成功の場合、[RFC6733]のセクション7.5によると、グループコマンドの処理が失敗したセッションをAVP AVPに故障したAVPに含めることによって特定する必要があります。リクエストの送信者は、グループコマンドが失敗した識別されたセッションごとに、シングルセッション操作に戻る必要があります。さらに、これらの各セッションは、グループコマンドが適用したすべてのセッショングループから削除する必要があります。セッショングループからセッションを削除するために、Diameterクライアントはセクション4.2.2で説明されている手順を実行します。

4.4.4. Single-Session Fallback
4.4.4. シングルセッションフォールバック

Either Diameter node can fall back to single-session operation by ignoring and omitting the optional group-session-specific AVPs. Fallback to single-session operation is performed by processing the Diameter command solely for the session identified in the mandatory Session-Id AVP. In such case, the response to the group command MUST NOT include any group identifier but only the Session-Id identifying the session for which the command has been processed.

いずれかの直径ノードは、オプションのグループセッション固有のAVPを無視して省略することにより、シングルセッション操作に戻ることができます。フォールバックシングルセッション操作は、強制セッションID AVPで特定されたセッションのみで直径コマンドを処理することにより実行されます。そのような場合、グループコマンドへの応答には、グループ識別子を含めるのではなく、コマンドが処理されたセッションを識別するセッションIDのみを含める必要があります。

5. Operation with Proxy Agents
5. プロキシエージェントによる操作

In the case of a present stateful Proxy Agent between a Diameter client and a Diameter server, the Proxy Agent MUST perform the same mechanisms per this specification to advertise session grouping and group operation capabilities towards the client and the server, respectively. The Proxy Agent MUST update and maintain consistency of its local session states as per the result of the group commands that are operated between a Diameter client and a server. In such case, the Proxy Agent MUST act as a Diameter server in front of the Diameter client and MUST act as a Diameter client in front of the Diameter server. Therefore, the client and the server behavior described in Section 4 applies respectively to the stateful Proxy Agent.

直径クライアントと直径サーバーの間の現在のステートフルなプロキシエージェントの場合、プロキシエージェントは、この仕様に従って同じメカニズムを実行して、それぞれクライアントとサーバーに向けてセッショングループとグループ操作機能を宣伝する必要があります。プロキシエージェントは、直径クライアントとサーバーの間で動作するグループコマンドの結果に従って、ローカルセッション状態の一貫性を更新および維持する必要があります。そのような場合、プロキシエージェントは、直径クライアントの前の直径サーバーとして機能し、直径サーバーの前の直径クライアントとして動作する必要があります。したがって、セクション4で説明されているクライアントとサーバーの動作は、それぞれステートフルプロキシエージェントに適用されます。

If a stateful Proxy Agent manipulates session groups, it MUST maintain consistency of session groups between a client and a server. This applies to a deployment where the Proxy Agent utilizes session grouping and performs group operations with, for example, a Diameter server, whereas the Diameter client is not aware of session groups. In such case, the Proxy Agent must reflect the states associated with the session groups as individual session operations towards the client and ensure the client has a consistent view of each session. The same applies to a deployment where all nodes, the Diameter client and server, as well as the Proxy Agent are group aware, but the Proxy Agent manipulates groups, e.g., to adopt different administrative policies that apply to the client's domain and the server's domain.

ステートフルなプロキシエージェントがセッショングループを操作する場合、クライアントとサーバー間のセッショングループの一貫性を維持する必要があります。これは、プロキシエージェントがセッショングループ化を使用し、たとえば直径サーバーでグループ操作を実行する展開に適用されますが、直径クライアントはセッショングループを認識していません。そのような場合、プロキシエージェントは、セッショングループに関連する状態をクライアントに対する個別のセッション操作として反映し、クライアントが各セッションの一貫したビューを持っていることを確認する必要があります。同じことが展開にも当てはまります。すべてのノード、Diameterクライアント、サーバー、およびプロキシエージェントがグループ認識ですが、プロキシエージェントはグループを操作して、クライアントのドメインとサーバーのドメインに適用されるさまざまな管理ポリシーを採用します。。

Stateless Proxy Agents do not maintain any session states (only transaction states are maintained). Consequently, the notion of a session group is transparent for any stateless Proxy Agent present between a Diameter client and a Diameter server handling session groups. Session-group-related AVPs being defined as an optional AVP are ignored by stateless Proxy Agents and should not be removed from the Diameter commands. If they are removed by the Proxy Agent for any reason, the Diameter client and Diameter server will discover the absence of the session-group-related AVPs and will fall back to single-session processing, as described in Section 4.

ステートレスプロキシエージェントは、セッションの状態を維持していません(トランザクション状態のみが維持されます)。その結果、セッショングループの概念は、直径クライアントと直径サーバーの処理セッショングループの間に存在するステートレスプロキシエージェントに対して透明です。オプションのAVPとして定義されるセッショングループ関連AVPは、Stateless Proxyエージェントによって無視され、直径コマンドから削除されないでください。何らかの理由でプロキシエージェントによって削除された場合、Diameterクライアントと直径サーバーは、セッショングループ関連のAVPがないことを発見し、セクション4で説明されているように、シングルセッション処理に戻ります。

6. Commands Formatting
6. コマンドフォーマット

This document does not specify new Diameter commands to enable group operations but relies on command extensibility and capability provided by the Diameter Base protocol. This section provides the guidelines to extend the CCF of existing Diameter commands with optional AVPs to enable the recipient of the command to apply the command to all sessions associated with the identified group or groups.

このドキュメントは、グループ操作を有効にするための新しい直径コマンドを指定するのではなく、直径ベースプロトコルによって提供されるコマンドの拡張性と機能に依存しています。このセクションでは、オプションのAVPを使用して既存の直径コマンドのCCFを拡張するためのガイドラインを提供して、コマンドの受信者が特定されたグループまたはグループに関連付けられたすべてのセッションにコマンドを適用できるようにします。

6.1. Formatting Example: Group Re-Auth-Request
6.1. フォーマット例:グループReauth-Request

A request for re-authentication of one or more groups of users is issued by appending one or multiple Session-Group-Id AVPs, as well as appending a single instance of a Group-Response-Action AVP to the Re-Auth-Request (RAR). One or multiple Session-Group-Id AVPs identify one or more associated groups for which group re-authentication has been requested. The Group-Response-Action AVP identifies the expected means to perform and respond to the group command. The recipient of the group command initiates re-authentication for all users associated with the identified group or groups. Furthermore, the sender of the group re-authentication request appends a Group-Response-Action AVP to provide more information to the receiver of the command about how to accomplish the group operation.

1つ以上のユーザーグループの再認証のリクエストは、1つまたは複数のセッショングループAVPを追加することによって発行され、グループ応答アクションAVPの単一のインスタンスをReauth-Requestに追加することで発行されます(RAR)。1つまたは複数のセッション-Group-ID AVPは、グループの再認証が要求された1つ以上の関連グループを特定します。グループ応答アクションAVPは、グループコマンドを実行および応答する予定の手段を識別します。グループコマンドの受信者は、特定されたグループまたはグループに関連付けられたすべてのユーザーの再認証を開始します。さらに、グループの再認証要求の送信者は、グループの操作を達成する方法についてコマンドの受信者により多くの情報を提供するために、グループ反応 - アクションAVPを追加します。

The value of the mandatory Session-Id AVP MUST identify a session associated with a single user, which is assigned to at least one of the groups being identified in the appended Session-Group-Id AVPs.

必須セッションID AVPの値は、単一のユーザーに関連付けられたセッションを識別する必要があります。単一のユーザーは、Appred Session-Group-ID AVPで特定されているグループの少なくとも1つに割り当てられています。

         <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 ]
                    [ Session-Group-Capability-Vector ]
                  * [ Session-Group-Info ]
                    [ Group-Response-Action ]
                  * [ AVP ]
        
7. Attribute-Value Pairs (AVPs)
7. 属性値ペア(AVPS)
    +=================================+==========+====================+
    | Attribute Name                  |AVP Code  |AVP Flag rules      |
    +=================================+Value Type+====+===+======+====+
    |                                 |          |MUST|MAY|SHOULD|MUST|
    |                                 |          |    |   |NOT   |NOT |
    +=================================+==========+====+===+======+====+
    | Session-Group-Info              |671       |    |P  |      |V   |
    |                                 |Grouped   |    |   |      |    |
    +---------------------------------+----------+----+---+------+----+
    | Session-Group-Control-Vector    |672       |    |P  |      |V   |
    |                                 |Unsigned32|    |   |      |    |
    +---------------------------------+----------+----+---+------+----+
    | Session-Group-Id                |673       |    |P  |      |V   |
    |                                 |UTF8String|    |   |      |    |
    +---------------------------------+----------+----+---+------+----+
    | Group-Response-Action           |674       |    |P  |      |V   |
    |                                 |Unsigned32|    |   |      |    |
    +---------------------------------+----------+----+---+------+----+
    | Session-Group-Capability-Vector |675       |    |P  |      |V   |
    |                                 |Unsigned32|    |   |      |    |
    +---------------------------------+----------+----+---+------+----+
        

Table 1: AVPs for the Diameter Group Signaling

表1:直径グループシグナリングのAVP

7.1. Session-Group-Info AVP
7.1. SESSION-GROUP-INFO AVP

The Session-Group-Info AVP (AVP Code 671) is of type Grouped. It contains the identifier of the session group, as well as an indication of the node responsible for session group identifier assignment.

Session-Group-INFO AVP(AVPコード671)は、グループ化されたタイプです。セッショングループの識別子と、セッショングループ識別子の割り当てに責任を負うノードの指標が含まれています。

      Session-Group-Info ::= < AVP Header: 671 >
                             < Session-Group-Control-Vector >
                             [ Session-Group-Id ]
                           * [ AVP ]
        
7.2. Session-Group-Control-Vector AVP
7.2. セッショングループ - コントロール - ベクトルAVP

The Session-Group-Control-Vector AVP (AVP Code 672) is of type Unsigned32 and contains a 32-bit flag field to control the group assignment at session-group-aware nodes. For defined flags, only numeric values that are 2^x (power of two, where 0<=x<32) are allowed.

セッショングループ - コントロール - ベクトルAVP(AVPコード672)は、signed32のタイプで、セッショングループに対応するノードでのグループ割り当てを制御するための32ビットフラグフィールドが含まれています。定義されたフラグの場合、2^x(2の電力、0 <= x <32)の数値のみが許可されます。

The following control flags are defined in this document:

次の制御フラグは、このドキュメントで定義されています。

SESSION_GROUP_ALLOCATION_ACTION (0x00000001)

session_group_allocation_action(0x00000001)

This flag indicates the action to be performed for the identified session. When this flag is set, it indicates that the identified Diameter session is to be assigned to the session group identified by the Session-Group-Id AVP or the session's assignment to the session group identified in the Session-Group-Id AVP is still valid. When the flag is cleared, the identified Diameter session is to be removed from at least one session group. When the flag is cleared and the Session-Group-Info AVP identifies a particular session group in the associated Session-Group-Id AVP, the session is to be removed solely from the identified session group. When the flag is cleared and the Session-Group-Info AVP does not identify a particular session group (Session-Group-Id AVP is absent), the identified Diameter session is to be removed from all session groups to which it has been previously assigned.

このフラグは、特定されたセッションで実行されるアクションを示します。このフラグが設定されている場合、識別された直径セッションがセッショングループAVPによって識別されたセッショングループに割り当てられるか、セッション-Group-IDで識別されたセッショングループへのセッションの割り当てがまだ有効であることを示します。。フラグがクリアされると、識別された直径セッションは、少なくとも1つのセッショングループから削除されます。フラグがクリアされ、セッショングループ-INFO AVPが関連するセッション-Group-ID AVPの特定のセッショングループを識別すると、セッションは特定されたセッショングループからのみ削除されます。フラグがクリアされ、セッショングループ-INFO AVPが特定のセッショングループを識別しない場合(Session-Group-ID AVPが存在しない)、識別された直径セッションは、以前に割り当てられたすべてのセッショングループから削除されます。。

SESSION_GROUP_STATUS (0x00000010)

session_group_status(0x00000010)

This flag indicates the status of the session group identified in the associated Session-Group-Id AVP. The flag is set when the identified session group has just been created or is still active. If the flag is cleared, the identified session group is deleted and the associated Session-Group-Id is released. If the Session-Group-Info AVP does not include a Session-Group-Id AVP, this flag is meaningless and MUST be ignored by the receiver.

このフラグは、関連するセッション-Group-ID AVPで識別されたセッショングループのステータスを示しています。識別されたセッショングループが作成されたばかりであるか、まだアクティブである場合、フラグは設定されます。フラグがクリアされた場合、識別されたセッショングループが削除され、関連するセッショングループIDがリリースされます。Session-Group-INFO AVPにセッショングループ-ID AVPが含まれていない場合、このフラグは無意味で、受信者は無視する必要があります。

7.3. Session-Group-Id AVP
7.3. SESSION-GROUP-ID AVP

The Session-Group-Id AVP (AVP Code 673) is of type UTF8String and identifies a group of Diameter sessions.

Session-Group-ID AVP(AVPコード673)は型UTF8STRINGであり、直径セッションのグループを識別します。

The Session-Group-Id MUST be globally unique. The Session-Group-Id includes a mandatory portion and an implementation-defined portion delimited by the ";" character. The Session-Group-Id MUST begin with the identity of the Diameter node that owns the session group. The remainder of the Session-Group-Id is implementation defined and MAY follow the format recommended for the implementation-defined portion of the Session-Id AVP in Section 8.8 of [RFC6733].

Session-Group-IDはグローバルに一意でなければなりません。Session-Group-IDには、必須部分と「;」によって区切られた実装定義部分が含まれます。キャラクター。Session-Group-IDは、セッショングループを所有する直径ノードのIDから始める必要があります。セッション-Group-IDの残りの部分は、[RFC6733]のセクション8.8のセッションID AVPの実装定義部分に推奨される形式に従うことができます。

7.4. Group-Response-Action AVP
7.4. グループ応答アクションAVP

The Group-Response-Action AVP (AVP Code 674) is of type Unsigned32 and contains a 32-bit address space representing values indicating how the node SHOULD issue follow-up exchanges in response to a command that impacts multiple sessions. The following values are defined by this document:

グループ反応 - アクションAVP(AVPコード674)は、タイプunsigned32であり、複数のセッションに影響を与えるコマンドに応じてノードがどのようにフォローアップ交換を発行するかを示す値を表す32ビットアドレススペースが含まれています。次の値は、このドキュメントで定義されています。

ALL_GROUPS (1)

all_groups(1)

Follow-up message exchanges associated with a group command should be performed with a single message exchange for all impacted groups.

グループコマンドに関連付けられたフォローアップメッセージ交換は、すべての影響を受けたグループの単一のメッセージ交換で実行する必要があります。

PER_GROUP (2)

per_group(2)

Follow-up message exchanges associated with a group command should be performed with a separate message exchange for each impacted group.

グループコマンドに関連付けられたフォローアップメッセージ交換は、影響を受けたグループごとに個別のメッセージ交換で実行する必要があります。

PER_SESSION (3)

per_session(3)

Follow-up message exchanges associated with a group command should be performed with a separate message exchange for each impacted session.

グループコマンドに関連付けられたフォローアップメッセージ交換は、影響を受けた各セッションの個別のメッセージ交換で実行する必要があります。

7.5. Session-Group-Capability-Vector AVP
7.5. セッショングループ - キャピリティ - ベクトルAVP

The Session-Group-Capability-Vector AVP (AVP Code 675) is of type Unsigned32 and contains a 32-bit flag field to indicate capabilities in the context of session-group assignment and group operations. For defined flags, only numeric values that are 2^x (power of two, where 0<=x<32) are allowed. The value of (0) is reserved.

セッショングループとグループの能力 - ベクトルAVP(AVPコード675)は、符号なし32型で、セッショングループの割り当てとグループ操作のコンテキストで機能を示す32ビットフラグフィールドが含まれています。定義されたフラグの場合、2^x(2の電力、0 <= x <32)の数値のみが許可されます。(0)の値は予約されています。

The following capability is defined in this document:

次の機能は、このドキュメントで定義されています。

BASE_SESSION_GROUP_CAPABILITY (0x00000001)

base_session_group_capability(0x00000001)

This flag indicates the capability to support session grouping and session group operations according to this specification.

このフラグは、この仕様に従ってセッショングループとセッショングループの操作をサポートする機能を示しています。

8. Result-Code AVP Values
8. 結果コードAVP値

This document does not define new Result-Code [RFC6733] values for existing applications, which are extended to support group commands. Documents specifying new applications, which will have intrinsic support for group commands, may specify new Result-Codes.

このドキュメントは、グループコマンドをサポートするために拡張された既存のアプリケーションの新しい結果コード[RFC6733]値を定義しません。グループコマンドを本質的にサポートする新しいアプリケーションを指定するドキュメントは、新しい結果コードを指定する場合があります。

9. IANA Considerations
9. IANAの考慮事項

This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA.

このセクションには、この仕様で作成されたか、IANAが管理する既存の名前空間に値を割り当てた名前空間が含まれています。

9.1. AVP Codes
9.1. AVPコード

IANA has registered the following new AVPs from the "AVP Codes" registry defined in [RFC6733]. The AVPs are defined in Section 7.

IANAは、[RFC6733]で定義されている「AVPコード」レジストリから次の新しいAVPを登録しています。AVPはセクション7で定義されています。

* Session-Group-Info

* セッショングループINFO

* Session-Group-Control-Vector

* セッショングループコントロールベクトル

* Session-Group-Id

* SESSION-GROUP-ID

* Group-Response-Action

* グループ応答アクション

* Session-Group-Capability-Vector

* セッショングループ - キャピリティ - ベクトル

9.2. New Registries
9.2. 新しいレジストリ

IANA has created the following two new registries.

IANAは、次の2つの新しいレジストリを作成しました。

* The "Session-Group-Control-Vector AVP Values (code 672)" registry for control bits. Two initial assignments are described in Section 7.2. The registration assignment policy is Specification Required.

* 制御ビットの「セッショングループ - コントロール - ベクトルAVP値(コード672)」レジストリ。セクション7.2で2つの初期割り当てについて説明します。登録割り当てポリシーが必要です。

* The "Session-Group-Capability-Vector AVP Values (code 675)" registry. One initial assignment is described in Section 7.5. The registration assignment policy is Standards Action.

* 「セッショングループ - 能力 - ベクトルAVP値(コード675)」レジストリ。1つの初期割り当てについては、セクション7.5で説明します。登録割り当てポリシーは標準アクションです。

10. Security Considerations
10. セキュリティに関する考慮事項

The security considerations of the Diameter protocol itself are discussed in [RFC6733]. Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol. In particular, the Session-Group-Info AVP (including the Session-Group-Control-Vector and the Session-Group-Id AVPs) should be considered as a security-sensitive AVP in the same manner as the Session-Id AVP in the Diameter base protocol [RFC6733].

直径プロトコル自体のセキュリティ上の考慮事項については、[RFC6733]で説明されています。このドキュメントで定義されているAVPの使用は、直径ベースプロトコルのセキュリティの問題と要件を考慮する必要があります。特に、Session-Group-INFO AVP(セッショングループとグループコントロールベクトルとセッショングループID AVPを含む)は、セッションID AVPのAVPと同じ方法で、セキュリティに敏感なAVPと見なされるべきです。直径ベースプロトコル[RFC6733]。

The management of session groups relies upon the existing trust relationship between the Diameter client and the Diameter server managing the groups of sessions. This document defines a mechanism that allows a client or a server to act on multiple sessions at the same time using only one command. If the Diameter client or server is compromised, an attacker could launch DoS attacks by terminating or applying change operations to a large number of sessions with a limited set of commands using the session group management concept.

セッショングループの管理は、直径クライアントとセッションのグループを管理する直径サーバーの間の既存の信頼関係に依存しています。このドキュメントは、クライアントまたはサーバーが1つのコマンドのみを使用して複数のセッションに同時に行動できるようにするメカニズムを定義します。Diameterクライアントまたはサーバーが侵害されている場合、攻撃者は、セッショングループ管理の概念を使用して、限られたコマンドセットを使用して、多数のセッションに変更操作を終了または適用することにより、DOS攻撃を開始できます。

According to the Diameter base protocol [RFC6733], transport connections between Diameter peers are protected by TLS/TCP, DTLS / Stream Control Transmission Protocol (SCTP), or alternative security mechanisms that are independent of Diameter, such as IPsec. However, the lack of end-to-end security features makes it difficult to establish trust in the session-group-related information received from non-adjacent nodes. Any Diameter agent in the message path can potentially modify the content of the message and therefore the information sent by the Diameter client or the server. There is ongoing work on the specification of end-to-end security features for Diameter. Such features would enable the establishment of a trust relationship between non-adjacent nodes, and the security required for session group management would normally rely on this end-to-end security. However, there is no assumption in this document that such end-to-end security mechanism will be available. It is only assumed that the solution defined on this document relies on the security framework provided by the Diameter-based protocol.

直径ベースプロトコル[RFC6733]によると、直径ピア間の輸送接続は、TLS / TCP、DTLS /ストリーム制御伝送プロトコル(SCTP)、またはIPSECなどの直径とは独立した代替セキュリティメカニズムによって保護されています。ただし、エンドツーエンドのセキュリティ機能がないため、非隣接ノードから受け取ったセッショングループ関連の情報に対する信頼を確立することが困難です。メッセージパス内の直径エージェントは、メッセージのコンテンツを潜在的に変更できます。したがって、Diameterクライアントまたはサーバーから送信された情報を変更できます。直径のエンドツーエンドセキュリティ機能の仕様に関する継続的な作業があります。このような機能により、非隣接ノード間の信頼関係の確立が可能になり、セッショングループ管理に必要なセキュリティは通常、このエンドツーエンドのセキュリティに依存します。ただし、この文書には、このようなエンドツーエンドのセキュリティメカニズムが利用可能になるという仮定はありません。このドキュメントで定義されているソリューションは、直径ベースのプロトコルによって提供されるセキュリティフレームワークに依存しているとのみ想定されています。

In some cases, a Diameter Proxy Agent can act on behalf of a client or a server. In such case, the security requirements that normally apply to a client (or a server) apply equally to the Proxy Agent.

場合によっては、直径のプロキシエージェントがクライアントまたはサーバーに代わって行動することができます。そのような場合、通常、クライアント(またはサーバー)に適用されるセキュリティ要件は、プロキシエージェントに等しく適用されます。

11. Normative References
11. 引用文献
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.
        
   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <https://www.rfc-editor.org/info/rfc6733>.
        
   [RFC7155]  Zorn, G., Ed., "Diameter Network Access Server
              Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
              <https://www.rfc-editor.org/info/rfc7155>.
        
   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
        
Appendix A. Session Management -- Exemplary Session State Machine
付録A. セッション管理 - 模範的なセッション状態マシン
A.1. Use of Groups for the Authorization Session State Machine
A.1. 認証セッションステートマシンのためのグループの使用

Section 8.1 of [RFC6733] defines a set of finite state machines that represent the life cycle of Diameter sessions, which must be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. This section defines, for example, additional state transitions related to the processing of the group commands that may impact multiple sessions.

[RFC6733]のセクション8.1は、直径セッションのライフサイクルを表す有限状態マシンのセットを定義します。これは、直径アプリケーションの認証および/または認証部分を使用するすべての直径の実装で観察する必要があります。このセクションでは、たとえば、複数のセッションに影響を与える可能性のあるグループコマンドの処理に関連する追加の状態遷移を定義します。

The group membership is a session state, and therefore only those state machines from [RFC6733] in which the server is maintaining session state are relevant in this document. As in [RFC6733], the term 'service-specific' below refers to a message defined in a Diameter application (e.g., Mobile IPv4 or NASREQ).

グループメンバーシップはセッション状態であるため、サーバーがセッション状態を維持している[RFC6733]の状態マシンのみがこのドキュメントに関連しています。[RFC6733]のように、以下の「サービス固有」という用語は、直径アプリケーション(モバイルIPv4またはNasReqなど)で定義されたメッセージを指します。

The following state machine is observed by a client when the state is maintained on the server. State transitions that are unmodified from [RFC6733] are not repeated here.

状態がサーバー上に維持されている場合、クライアントによって次の状態マシンが観察されます。[RFC6733]から修正されていない状態の移行は、ここでは繰り返されません。

The Diameter group command in the following tables is differentiated from a single-session-related command by a preceding 'G' (Group). A Group Re-Auth Request, which applies to one or multiple session groups, has been exemplarily described in Section 6.1. Such Group RAR command is denoted as 'GRAR' in the following table. The same notation applies to other commands, as per [RFC6733].

次の表の直径グループコマンドは、前の「G」(グループ)によって単一セッション関連のコマンドと区別されます。1つまたは複数のセッショングループに適用されるグループの再承認要求は、セクション6.1で例示的に説明されています。このようなグループRARコマンドは、次の表で「grar」として示されます。[RFC6733]に従って、他のコマンドにも同じ表記が適用されます。

Additionally, the following acronyms are used in the tables below.

さらに、以下の表に次の頭字語が使用されています。

GASR:

GASR:

Group-Abort-Session-Request

Group-Abort-Session-Request

GASA:

ガサ:

Group-Abort-Session-Answer

グループアボルトセッションアンスワー

GSTA:

GSTA:

Group-Session-Termination-Answer

グループセッション - 終了回答

GSTR:

GSTR:

Group-Session-Termination-Request

Group-Session-Termination-Request

    +=================================================================+
    | CLIENT, STATEFUL                                                |
    +=========+==========================+==================+=========+
    | State   | Event                    | Action           | New     |
    |         |                          |                  | State   |
    +=========+==========================+==================+=========+
    | Idle    | Client or Device         | Send service-    | Pending |
    |         | Requests access          | specific         |         |
    |         |                          | authorization    |         |
    |         |                          | req optionally   |         |
    |         |                          | including groups |         |
    +---------+--------------------------+------------------+---------+
    | Open    | GASR received with       | Send GASA        | Discon  |
    |         | Group-Response-Action =  | Result-Code =    |         |
    |         | ALL_GROUPS, session is   | SUCCESS, Send    |         |
    |         | assigned to received     | GSTR             |         |
    |         | group(s) and client will |                  |         |
    |         | comply with request to   |                  |         |
    |         | end the session          |                  |         |
    +---------+--------------------------+------------------+---------+
    | Open    | GASR received with       | Send GASA with   | Discon  |
    |         | Group-Response-Action =  | Result-Code =    |         |
    |         | PER_GROUPS, session is   | SUCCESS, Send    |         |
    |         | assigned to received     | GSTR per group   |         |
    |         | group(s) and client will |                  |         |
    |         | comply with request to   |                  |         |
    |         | end the session          |                  |         |
    +---------+--------------------------+------------------+---------+
    | Open    | GASR received with       | Send GASA with   | Discon  |
    |         | Group-Response-Action =  | Result-Code =    |         |
    |         | PER_SESSION, session is  | SUCCESS, Send    |         |
    |         | assigned to received     | STR per session  |         |
    |         | group(s) and client will |                  |         |
    |         | comply with request to   |                  |         |
    |         | end the session          |                  |         |
    +---------+--------------------------+------------------+---------+
    | Open    | GASR received, client    | Send GASA with   | Open    |
    |         | will not comply with     | Result-Code !=   |         |
    |         | request to end all       | SUCCESS          |         |
    |         | sessions in received     |                  |         |
    |         | group(s)                 |                  |         |
    +---------+--------------------------+------------------+---------+
    | Discon  | GSTA received            | Discon. user/    | Idle    |
    |         |                          | device           |         |
    +---------+--------------------------+------------------+---------+
    | Open    | GRAR received with       | Send GRAA, Send  | Pending |
    |         | Group-Response-Action =  | service-specific |         |
    |         | ALL_GROUPS, session is   | group re-auth    |         |
    |         | assigned to received     | req              |         |
    |         | group(s) and client will |                  |         |
    |         | perform subsequent re-   |                  |         |
    |         | auth                     |                  |         |
    +---------+--------------------------+------------------+---------+
    | Open    | GRAR received with       | Send GRAA, Send  | Pending |
    |         | Group-Response-Action =  | service-specific |         |
    |         | PER_GROUP, session is    | group re-auth    |         |
    |         | assigned to received     | req per group    |         |
    |         | group(s) and client will |                  |         |
    |         | perform subsequent re-   |                  |         |
    |         | auth                     |                  |         |
    +---------+--------------------------+------------------+---------+
    | Open    | GRAR received with       | Send GRAA, Send  | Pending |
    |         | Group-Response-Action =  | service-specific |         |
    |         | PER_SESSION, session is  | re-auth req per  |         |
    |         | assigned to received     | session          |         |
    |         | group(s) and client will |                  |         |
    |         | perform subsequent re-   |                  |         |
    |         | auth                     |                  |         |
    +---------+--------------------------+------------------+---------+
    | Open    | GRAR received and client | Send GRAA with   | Idle    |
    |         | will not perform         | Result-Code !=   |         |
    |         | subsequent re-auth       | SUCCESS, Discon. |         |
    |         |                          | user/device      |         |
    +---------+--------------------------+------------------+---------+
    | Pending | Successful service-      | Provide service  | Open    |
    |         | specific group re-       |                  |         |
    |         | authorization answer     |                  |         |
    |         | received                 |                  |         |
    +---------+--------------------------+------------------+---------+
    | Pending | Failed service-specific  | Discon. user/    | Idle    |
    |         | group re-authorization   | device           |         |
    |         | answer received          |                  |         |
    +---------+--------------------------+------------------+---------+
        

Table 2: Group Authorization Session State Machine for Stateful Client

表2:ステートフルクライアント向けのグループ認証セッションステートマシン

The following state machine is observed by a server when it is maintaining the state for the session. State transitions that are unmodified from [RFC6733] are not repeated here.

次の状態マシンは、セッションの状態を維持しているときにサーバーによって観察されます。[RFC6733]から修正されていない状態の移行は、ここでは繰り返されません。

    +================================================================+
    | SERVER, STATEFUL                                               |
    +=========+========================+===================+=========+
    | State   | Event                  | Action            | New     |
    |         |                        |                   | State   |
    +=========+========================+===================+=========+
    | Idle    | Service-specific       | Send successful   | Open    |
    |         | authorization request  | service-specific  |         |
    |         | received, and user is  | answer optionally |         |
    |         | authorized             | including groups  |         |
    +---------+------------------------+-------------------+---------+
    | Open    | Server wants to        | Send GASR         | Discon  |
    |         | terminate group(s)     |                   |         |
    +---------+------------------------+-------------------+---------+
    | Discon  | GASA received          | Cleanup           | Idle    |
    +---------+------------------------+-------------------+---------+
    | Any     | GSTR received          | Send GSTA,        | Idle    |
    |         |                        | Cleanup           |         |
    +---------+------------------------+-------------------+---------+
    | Open    | Server wants to reauth | Send GRAR         | Pending |
    |         | group(s)               |                   |         |
    +---------+------------------------+-------------------+---------+
    | Pending | GRAA received with     | Update session(s) | Open    |
    |         | Result-Code = SUCCESS  |                   |         |
    +---------+------------------------+-------------------+---------+
    | Pending | GRAA received with     | Cleanup           | Idle    |
    |         | Result-Code != SUCCESS | session(s)        |         |
    +---------+------------------------+-------------------+---------+
    | Open    | Service-specific group | Send successful   | Open    |
    |         | re-authorization       | service-specific  |         |
    |         | request received and   | group re-auth     |         |
    |         | user is authorized     | answer            |         |
    +---------+------------------------+-------------------+---------+
    | Open    | Service-specific group | Send failed       | Idle    |
    |         | re-authorization       | service-specific  |         |
    |         | request received and   | group re-auth     |         |
    |         | user is not authorized | answer, Cleanup   |         |
    +---------+------------------------+-------------------+---------+
        

Table 3: Group Authorization Session State Machine for Stateful Server

表3:ステートフルサーバーのグループ認証セッションステートマシン

Acknowledgments
謝辞

The authors of this document want to thank Ben Campbell and Eric McMurry for their valuable comments to early draft versions of this document. Furthermore, the authors thank Steve Donovan and Mark Bales for the thorough review and comments on advanced versions of the WG document, which helped a lot to improve this specification.

この文書の著者は、この文書の初期草案に対する貴重なコメントについて、ベン・キャンベルとエリック・マクマリーに感謝したいと考えています。さらに、著者は、Steve DonovanとMark Balesに徹底的なレビューとWGドキュメントの高度なバージョンに関するコメントに感謝します。

Authors' Addresses
著者のアドレス
   Mark Jones
   Individual
   Email: mark@azu.ca
        
   Marco Liebsch
   NEC Laboratories Europe GmbH
   Kurfuersten-Anlage 36
   D-69115 Heidelberg
   Germany
   Email: marco.liebsch@neclab.eu
        
   Lionel Morand
   Orange Labs
   38/40 rue du General Leclerc
   92794 Issy-Les-Moulineaux Cedex 9
   France
   Email: lionel.morand@orange.com