Diameter Maintenance and Extensions (DIME)                      M. Jones
Internet-Draft
Intended status: Standards Track                              M. Liebsch
Expires: January 5, 2015 7, 2016
                                                               L. Morand
                                                            July 4, 2014 6, 2015

                        Diameter Group Signaling
                 draft-ietf-dime-group-signaling-04.txt
                 draft-ietf-dime-group-signaling-05.txt

Abstract

   In large network deployments, a single Diameter peer node can support over
   a million concurrent Diameter sessions.  Recent use cases have
   revealed the need for Diameter peers nodes 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
   could result in many thousands of command exchanges to enforce the
   same operation on each session in the group.  In order to reduce
   signaling, it would be desirable to enable bulk operations on all (or
   part of) the sessions managed by a Diameter peer node using a single or a
   few command exchanges.  This document specifies the Diameter protocol
   extensions to achieve this signaling optimization.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 5, 2015. 7, 2016.

Copyright Notice

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

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Building and Modifying Session Groups . . . . . . . . . .   4
     3.2.  Issuing Group Commands  . . . . . . . . . . . . . . . . .   4
     3.3.  Permission Considerations . . . . . . . . . . . . . . . .   4
   4.  Protocol Description  . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Session Grouping Capability Discovery . . . . . . . . . .   7
       4.1.1.  Explicit Capability Discovery . . . . . . . . . .   6
       4.1.1.  Group assignment at session initiation  . . . . . . .   7
       4.1.2.  Removing a session from a session group  Implicit Capability Discovery . . . . . . .   8
       4.1.3.  Mid-session group assignment modifications . . . . .   9   7
     4.2.  Session Grouping Capability Discovery  . . . . . . . . . .  10
       4.2.1.  Explicit Capability Discovery . . . . . . . . . .   7
       4.2.1.  Group assignment at session initiation  . . . . . . .  10   8
       4.2.2.  Implicit Capability Discovery  Removing a session from a session group . . . . . . .  10
       4.2.3.  Mid-session group assignment modifications  . . . . .  11
     4.3.  Deleting a Session Group  . . . . . . . . . . . . . . . .  11  12
     4.4.  Performing Group Operations . . . . . . . . . . . . . . .  11  12
       4.4.1.  Sending Group Commands  . . . . . . . . . . . . . . .  11  12
       4.4.2.  Receiving Group Commands  . . . . . . . . . . . . . .  12  13
       4.4.3.  Error Handling for Group Commands . . . . . . . . . .  12  14
       4.4.4.  Single-Session Fallback . . . . . . . . . . . . . . .  13  14
   5.  Operation with Proxies Agents . . . . . . . . . . . . . . . .  13  14
   6.  Commands Formatting . . . . . . . . . . . . . . . . . . . . .  13  15
     6.1.  Formatting Example: Group Re-Auth-Request . . . . . . . .  14  15
   7.  Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . .  14  16
     7.1.  Session-Group-Info AVP  . . . . . . . . . . . . . . . . .  15  16
     7.2.  Session-Group-Control-Vector AVP  . . . . . . . . . . . .  15  17
     7.3.  Session-Group-Id AVP  . . . . . . . . . . . . . . . . . .  16  17
     7.4.  Group-Response-Action AVP . . . . . . . . . . . . . . . .  16  18
     7.5.  Session-Group-Capability-Vector AVP . . . . . . . . . . .  17  18
   8.  Result-Code AVP Values  . . . . . . . . . . . . . . . . . . .  17  18
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17  18
     9.1.  AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .  17  19
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  17  19
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18  20
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  18  20
   Appendix A.  Session Management -- Exemplary Session State
                Machines
                Machine  . . . . . . . . . . . . . . . . . . . . . .  18  20
     A.1.  Use of groups for the Authorization Session State Machine . . . . . . . . . . .  18  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22  24

1.  Introduction

   In large network deployments, a single Diameter peer node can support over
   a million concurrent Diameter sessions.  Recent use cases have
   revealed the need for Diameter peers nodes 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 could result in many thousands of command exchanges to
   enforce the same operation on each session in the group.  In order to
   reduce signaling, it would be desirable to enable bulk operations on
   all (or part of) the sessions managed by a Diameter peer node using a
   single or a few command exchanges.

   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 AVPs that may be used by
   any Diameter application that requires management of groups of
   sessions.

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

   o Minimal impact to existing applications

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

   o Fallback to single session operation

   o 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

   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 RFC 2119 [RFC2119].

   This document uses terminology defined [RFC6733].

3.  Protocol Overview

3.1.  Building and Modifying Session Groups

   Client and 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 such group(s),
   e.g. to adjust common profile or policy settings.

   The assignment of a Diameter session to a group can be changed mid-
   session.  For example, if a user's subscription profile changes mid-
   session, a Diameter peer server may remove the session from its current
   group and assign the session to a different group that is more
   appropriate for the new subscription profile.

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

   A session group, which has sessions assigned, can be deleted, e.g.
   due to a change in multiple users' subscription profile so that the
   group's assigned sessions do not share certain characteristics
   anymore.  Deletion of such group requires subsequent individual
   treatment of each of the assigned sessions.  A peer node may decide to
   assign some of these sessions to any other existing or new group.

3.2.  Issuing Group Commands

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

3.3.  Permission Considerations

   Permission considerations in the context of this draft 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.

   This specification follows the most flexible model where both, a
   Diameter client and a Diameter server can create a new group and
   assign a new identifier to that session group.  When a Diameter node
   decides to create a new session group, e.g. to group all sessions
   which share certain characteristics, the node builds a session group
   identifier according to the rules described in Section 7.3) and
   becomes the owner of the group.  This specification does not
   constrain the permission to add or remove a session to/from a session
   group to the group owner, instead each peer node can add a session to any
   known group or remove a session from a group.  A session group is
   deleted and its identifier released after the last session has been
   removed from the session group.  Also the modification of groups in
   terms of moving a session from one session group to a different
   session group is permitted to any Diameter node.  A Diameter peer node can
   delete a session group and its group identifier mid-session,
   resulting in individual treatment of the sessions which have been
   previously assigned to the deleted group.  Prerequisite for deletion
   of a session group is that the Diameter node created the session
   beforehand, hence the node became the group owner.

   The enforcement of more constrained permissions is left to the
   specification of a particular group signaling enabled Diameter
   application and compliant implementations of such application must
   enforce the associated permission model.  Details about enforcing a
   more constraint permission model are out of scope of this
   specification.  For example, a more constrained model could require
   that a client MUST NOT remove a session from a group which is owned
   by the server.

   The following table depicts the permission considerations as per the
   present specification:

   +-------------------------------------------------+--------+--------+
   |                 Operation                       | Server | Client |
   +-------------------------------------------------+--------+--------+
   | Create a new Session Group (peer becomes (Diameter node       |    X   |    X   |
   | becomes the group owner)                        |        |        |
   +-------------------------------------------------+--------+--------+
   | Assign a Session to an owned Session Group      |    X   |    X   |
   +-------------------------------------------------+--------+--------+
   | Assign a Session to a non-owned Session Group   |    X   |    X   |
   +-------------------------------------------------+--------+--------+
   | Remove a Session from an owned Session Group    |    X   |    X   |
   +-------------------------------------------------+-----------------+
   | Remove a Session from a non-owned Session Group |    X   |    X   |
   +-------------------------------------------------+--------+--------+
   | Remove a Session from a Session Group where the |    X   |    X   |
   | peer Diameter node created the assignment            |        |        |
   +-------------------------------------------------+--------+--------+
   | Remove a Session from a Session Group where the a   |        |        |
   | peer did not create different Diameter node created the assignment  |        |        |
   +-------------------------------------------------+--------+--------+
   | Overrule a peer's different Diameter node's            |        |        |
   | group assignment *)                             |        |        |
   +-------------------------------------------------+--------+--------+
   | Delete a Session Group which is owned by the peer    |    X   |    X   |
   | Diameter node                                   |        |        |
   +-------------------------------------------------+--------+--------+
   | Delete a Session Group which is not owned by    |        |        |
   | the peer Diameter node                               |        |        |
   +-------------------------------------------------+--------+--------+

               Default Permission as per this Specification

   *) Editors' note: The protocol specification in this document does
   not consider overruling a peer's node's assignment of a session to a session
   group.  Here, overruling is to be understood as a node changing the
   group(s) assignment as per the node's request.  Group signaling
   enabled applications may take such protocol support and associated
   protocol semantics into account in their specification.  One
   exception is adopted in this specifcation, which allows a Diameter
   server to reject a group assignment as per the client's request.

4.  Protocol Description
4.1.  Session Grouping

   Either Capability Discovery

   Diameter peer can initiate the assignment of nodes should assign a session to a
   single or multiple session groups.  Modification of a group by
   removing or adding and perform
   session group operations with a single or multiple user sessions can be
   initiated and performed mid-session by either node only after having ensured that
   the node announced associated support beforehand.

4.1.1.  Explicit Capability Discovery

   New Diameter peer. applications may consider support for Diameter AAA session
   grouping and for performing group commands during the standardization
   process.  Such applications typically assign client provide intrinsic discovery for the
   support of group commands and server roles to announce this capability through the Diameter peers, which are referred to
   assigned application ID.

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

4.1.2.  Implicit Capability Discovery

   If no explicit mechanism for capability discovery is deployed to
   enable Diameter nodes to learn about nodes' capability to support
   session grouping and performing group
   commands when relay agents or proxies are deployed. commands, a Diameter peers, which are group-aware, must store and maintain an
   entry about node SHOULD append
   the group assignment together with a session's state.  A
   list of all known session groups should be locally maintained on each
   peer, each group pointing Session-Group-Capability-Vector AVP to individual sessions being assigned any Diameter messages
   exchanged with its nodes to
   the group.  A peer must also keep a record about sessions, which have
   been assigned announce its capability to a session group by that peer.

4.1.1.  Group assignment at session initiation

   To assign a support
   session to a group at grouping and session initiation, a Diameter
   client sends a service specific request, e.g.  NASREQ AAR [RFC4005],
   containing one or more group identifiers.  Each of these groups need
   to be identified by a unique Session-Group-Id contained in a separate
   Session-Group-Info AVP as specified in Section 7.

   The client may choose one or multiple sessions from a list of
   existing session groups.  Alternatively, the client may decide to
   create a new group and identify itself in the DiameterIdentity
   element of operations.  Implementations
   following the Group-Session-Id AVP specification as per Section 7.3

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

   If the Diameter server receives a command request from Session-Group-Capability-
   Vector AVP.

   When a Diameter
   client and the command comprises node receives at least one Session-Group-Info Session-Group-Capability-
   Vector AVP
   having from a node with the SESSION_GROUP_ALLOCATION_ACTION BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-
   Control-Vector AVP
   set, the server must assign Diameter node maintains a log to remember the new session node's
   capability to
   each support group commands.

4.2.  Session Grouping

   This specification does not limit the number of session groups, to
   which a single session is assigned.  It is left to the one or multiple identified application to
   determine the policy of session groups. grouping.  In case one
   or multiple identified an application
   facilitates a session groups are not know to belong to multiple session groups, the server, the
   server
   application must add the one or multiple new groups to its local list maintain consistency of
   known associated application
   session states for these multiple session groups.  When sending the response to

   Either Diameter node (client or server) can initiate the client, e.g. assignment
   of a service-specific auth response as per NASREQ AAA [RFC4005], the
   server must include all Session-Group-Info AVPs as received in the
   client's request.

   In addition session to the one a single or multiple session groups identified in 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.
   Diameter AAA applications typically assign client and server roles to
   the
   client's request, Diameter nodes, which are referred to as relevant Diameter nodes
   to utilize session grouping and issue group commands.  Section 5
   describes particularities about session grouping and performing group
   commands when relay agents or proxies are deployed.

   Diameter nodes, which are group-aware, must store and maintain an
   entry about the server may decide group assignment together with a session's state.  A
   list of all known session groups should be locally maintained on each
   node, each group pointing to individual sessions being assigned to assign
   the new group.  A Diameter node must also keep a record about sessions,
   which have been assigned to a session group by itself.

4.2.1.  Group assignment at session initiation

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

   The client may choose one or multiple additional session groups from a list of
   existing session groups.  In such case,  Alternatively, the server adds client may decide to
   the response additional Session-Group-Info AVPs, each identifying
   create a
   session group, new group to which the server has session is assigned and identify
   itself in the new session.
   Each <DiameterIdentity> portion of the Session-Group-Info Session-Group-Id AVP added by the server must have
   as per Section 7.3

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

   The client may also indicate in the request that the server is
   responsible for the assignment of the session in one or multiple
   sessions owned by the server.  In such a case, the client MUST
   includes in the request the Session-Group-Info AVP in the request
   including the Session-Group-Control-Vector AVP with
   SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP.

   If the Diameter client server receives a response to its previously issued command request from the server a Diameter
   client and the response command comprises at least one Session-Group-Info AVP
   having the SESSION_GROUP_ALLOCATION_ACTION flag of set in the associated Session-Group-Control-Vector Session-
   Group-Control-Vector AVP set, the
   client 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 add not be assigned to any session group but be treated as
   single session.

   If the Diameter server accepts the client's request for a group
   assignment, the server must assign the new session to all each of the one
   or multiple identified session groups as identified when present in the Session-
   Group-Info AVP.  In case one or multiple Session-Group-Info AVPs.

   A Diameter server receiving a command for identified session initiation which
   includes at least one Session-Group-Info AVP but groups
   are not already stored by the server, the server does not
   understand must store the semantics new
   identified group(s) to its local list of this optional AVP because it does not
   support group operations according known session groups.  When
   sending the response to the specification in this
   document, MUST ignore client, e.g. a service-specific auth
   response as per NASREQ AA-Answer [RFC4005], the optional group operations specific server must include
   all Session-Group-Info AVPs and
   proceed with processing as received in the command for a single session.

   A Diameter client, which sent a request for session initiation client's request.

   In addition to a
   Diameter server and appended a single the one or multiple Session-Group-Id
   AVPs but cannot find any Session-Group-Info AVP session groups identified in the associated
   response from
   client's request, the Diameter server proceeds with processing the
   command for a single session.  Furthermore, the client keeps a log may decide to
   remember that assign the server is not able to perform group operations.

4.1.2.  Removing a session from a new session group

   When a Diameter client decides to remove a session from a particular
   session group, the client sends
   one or multiple additional groups.  In such a service-specific re-authorization
   request to case, the server and adds one Session-Group-Info AVP
   to the
   request for response the additional Session-Group-Info AVPs, each
   identifying a session group, from which the client wants group to remove
   the session.  The session, which is to be removed from a group, is
   identified in the Session-Id AVP of new session is assigned by
   the command request.  The
   SESSION_GROUP_ALLOCATION_ACTION flag server.  Each of the Session-Group-Control-
   Vector AVP in each Session-Group-Info AVP must be cleared to indicate
   removal of added by the session from server
   must have the session group identified SESSION_GROUP_ALLOCATION_ACTION flag set in the
   associated Session-Group-id AVP.

   When a
   Session-Group-Control-Vector AVP set.

   If the Diameter client decides to remove a session from all session
   groups, to which server rejects the session has been previously assigned, client's request for a group
   assignment, the client server sends a service-specific re-authorization request the response to the server and
   adds client, e.g. a single
   service-specific auth response as per NASREQ AA-Answer [RFC4005], and
   must include all Session-Group-Info AVP to AVPs as received in the client's
   request which has (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION
   flag cleared and of the Session-Group-Id
   AVP omitted.  The session, which is to be removed Session-Group-Control-Vector AVP.

   If the Diameter server receives a command request from all groups, a Diameter
   client and the command comprises one or multiple Session-Group-Info
   AVPs and none of them including 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 has been previously assigned, is identified group in the
   Session-Id AVP response sent to the
   client.  Each of the command request. Session-Group-Info AVPs included by the server
   must have the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-
   Group-Control-Vector AVP set.

   If the Diameter server receives a command request from the a Diameter
   client which has
   at least one Session-Group-Info AVP appended with and the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared, command does not contain any Session-Group-Info AVP,
   the server must remove MUST not assign the new session from the to any session group identified but
   treat the request as for a single session.  The server MUST return
   any Session-Group-Info AVP in the associated
   Session-Group-Id AVP. command response.

   If the Diameter client receives a response to its previously issued
   request from the server and the response comprises at least one Session-
   Group-info
   Session-Group-Info AVP with having the SESSION_GROUP_ALLOCATION_ACTION
   flag cleared
   and no Session-Id of the associated Session-Group-Control-Vector AVP present, set, the server must remove
   client MUST add the new session
   from to 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 as received identified
   in the request.

   When one or multiple Session-Group-Info AVPs.

   If the Diameter server decides to remove client receives a session response to its previously issued
   request from the server and the one or
   multiple particular session groups or from all session groups to
   which more Session-Group-Info AVPs
   have the session has been assigned beforehand, SESSION_GROUP_ALLOCATION_ACTION flag of the server sends a
   Re-Authorization Request (RAR) to associated
   Session-Group-Control-Vector AVP cleared, the client, indicating client MUST terminate
   the session
   in assignment of the requests Session-Id AVP.  The client sends a Re-Authorization
   Answer (RAA) to respond session to the server's request.  The client
   subsequently sends service-specific re-authorization request
   containing one or multiple Session-Group-Info AVPs, each indicating groups and
   continue to treat the session as single session without group
   assignment.

   A Diameter client, which sent a request for session group, initiation to which a
   Diameter server and appended a single or multiple Session-Group-Id
   AVPs but cannot find any Session-Group-Info AVP in the session had been previously assigned.  To
   indicate removal of associated
   response from the indicated Diameter server proceeds as if the request was
   processed for a single session.

4.2.2.  Removing a session from one or multiple a session groups, group

   When a Diameter client decides to remove a session from a particular
   session group, the server client sends a service-specific auth response re-authorization
   request to the client, containing a list of Session-Group-Info AVPs with the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared server and the Session-Group-Id adds one Session-Group-Info AVP identifying to the
   request for each session group, from which the session should be
   removed.  The server MAY include client wants to remove
   the service-specific auth
   response session.  The session, which is to be removed from a list group, is
   identified in the Session-Id AVP of Session-Group-Info AVPs with the command request.  The
   SESSION_GROUP_ALLOCATION_ACTION flag set and of the Session-Group-Id Session-Group-Control-
   Vector AVP
   identifying session groups in each Session-Group-Info AVP must be cleared to which indicate
   removal of the session remains subscribed.
   In case from the server session group identified in the
   associated Session-Group-id AVP.

   When a Diameter client decides to remove the identified a session from all session
   groups, to which the session has been previously assigned, the server includes in the client
   sends a service-specific auth response at least
   one Session-Group-Info AVP with re-authorization request to the SESSION_GROUP_ALLOCATION_ACTION
   flag cleared server and Session-Group-Id
   adds a single Session-Group-Info AVP absent.

4.1.3.  Mid-session group assignment modifications

   Either Diameter peer 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 which has the
   SESSION_GROUP_ALLOCATION_ACTION flag set cleared and the Session-Group-Id
   AVP
   present, identifying the session group omitted.  The session, which is to be removed from all groups, to
   which the session should be
   assigned.  With has been previously assigned, is identified in the same message,
   Session-Id AVP of the command request.

   If the Diameter server receives a request from the client may send which has
   at least one or multiple Session-Group-Info AVP appended with the
   SESSION_GROUP_ALLOCATION_ACTION flag
   cleared and cleared, the Session-Group-Id AVP identifying server must remove
   the session group from which the identified session is to be removed.  To remove group identified in the
   session from all previously assigned session groups, associated
   Session-Group-Id AVP.  If the client
   includes request comprises at least one Session-Group-Info Session-
   Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared
   and no Session-Group-Id Session-Id AVP present.  When present, the server received the service-specific re-
   authorization request, it must update its locally maintained view of remove the session groups for the identified
   from all session according groups to which the
   appended Session-Group-Info AVPs. session has been previously
   assigned.  The server sends a service-
   specific auth must include in its response to the requesting
   client containing one or multiple
   Session-Group-Info all Session-Group-Id AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag
   set and as received in the Session-Group-Id AVP identifying request.

   When the new Diameter server decides to remove a session group from one or
   multiple particular session groups or from all session groups to
   which the identified session has been assigned.

   When a Diameter server enforces an update to the assigned groups mid-
   session, it beforehand, the server sends a
   Re-Authorization Request (RAR) message or a service-specific server-intiated
   request to the
   client identifying the session, for which client, indicating the session group lists are
   to be updated. in the Session-Id AVP
   of the request.  The client responds with sends a Re-Authorization Answer (RAA) message. or
   a service-specific answer to respond to the server's request.  The
   client subsequently sends service-specific re-
   authorization 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 auth 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 to the service-specific auth
   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 group remains subscribed.
   In case the server decides to remove the identified session from all
   session groups, to which the session had has been previously assigned.  The assigned,
   the server responds with a includes in the service-specific auth response at least
   one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION
   flag cleared and includes Session-Group-Id AVP absent.

4.2.3.  Mid-session group assignment modifications

   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 AVP Session-Group-Info AVPs with the
   SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
   present, identifying the session group, group to which the
   identified session is to should be
   assigned.  With the same response message, the server client may send one or multiple
   Session-Group-Info AVPs AVP with the SESSION_GROUP_ALLOCATION_ACTION flag
   cleared and the Session-Group-Id AVP identifying the session groups group
   from which the identified session is to be removed.  When server wants to  To remove the
   session from all previously assigned session groups, it send the client
   includes at least
   on one Session-Group-Info AVP with the response having the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id
   AVP present.

4.2.  Session Grouping Capability Discovery

   Diameter nodes should assign a session to a session group and perform
   session group operations with a peer only after having ensured that
   the peer announced associated support beforehand.

4.2.1.  Explicit Capability Discovery

   New Diameter applications may consider support for Diameter session
   grouping and for performing group commands during  When the standardization
   process.  Such applications provide intrinsic discovery for server received the
   support service-specific re-
   authorization request, it must update its locally maintained view of group commands and announce this capability through
   the
   assigned application ID.

   System- and deployment-specific means for capability exchange can be
   used to announce peers' support for session grouping and session
   group operations.  In such case, the optional Session-Group-
   Capability-Vector AVP, as described in Section 4.2.2 can be omitted
   in Diameter messages being exchanged between peers.

4.2.2.  Implicit Capability Discovery

   If no explicit mechanism groups for capability discovery is deployed to
   enable Diameter nodes to learn about peers' capability to support
   session grouping and group commands, Diameter peers SHOULD append the
   Session-Group-Capability-Vector AVP to any Diameter messages
   exchanged with its peers to announce its capability to support
   session grouping and identified session group operations.  Implementations
   following this specification set the BASE_SESSION_GROUP_CAPABILITY
   flag of according to the Session-Group-Capability-Vector AVP.

   When
   appended Session-Group-Info AVPs.  The server sends a Diameter node receives at least service-
   specific auth response to the client containing one Session-Group-Capability-
   Vector AVP from a peer or multiple
   Session-Group-Info AVPs with the BASE_SESSION_GROUP_CAPABILITY SESSION_GROUP_ALLOCATION_ACTION flag
   set, the Diameter node maintains a log to remember the peer's
   capability to support group commands.

4.3.  Deleting a Session Group

   To delete a session group
   set and release the associated Session-Group-Id
   value, AVP identifying the owner of a new session group appends a single Session-Group-
   Info AVP having to
   which the identified session has been assigned.

   When a Diameter server enforces an update to the assigned groups mid-
   session, it sends a Re-Authorization Request (RAR) message to the
   client identifying the session, for which the session group lists are
   to be updated.  The client responds with a Re-Authorization Answer
   (RAA) message.  The client subsequently sends 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 auth response and includes one or multiple Session-
   Group-Info AVP 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 server wants to remove the
   session from all previously assigned session groups, it send at least
   on Session-Group-Info AVP with the response having the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id
   AVP present.

4.3.  Deleting a Session Group

   To 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 having the SESSION_GROUP_STATUS_IND flag cleared and the
   Session-Group-Id AVP identifying the session group, which is to be
   deleted.  The SESSION_GROUP_ALLOCATION_ACTION flag of the associated
   Session-Group-Control-Vector AVP MUST be cleared.

4.4.  Performing Group Operations

4.4.1.  Sending Group Commands

   Either Diameter peer node (lient or server) can request the recipient of a
   request to process an associated command for all sessions being
   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 Session-
   Group-Id AVP to identify the associated session group.  Both, the
   SESSION_GROUP_ALLOCATION_ACTION flag as well as the
   SESSION_GROUP_STATUS_IND flag must be set.

   If the CCF of the request mandates a Session-Id AVP, the Session-Id
   AVP MUST identify a one of the single session sessions which is assigned to at
   least one of the groups being identified in the appended Session-Group-Id Session-
   Group-Id AVPs.

   The sender of the request MUST indicate to the receiver how follow up
   message exchanges should be performed by appending a single instance
   of the Group-Response-Action AVP.  Even if the request includes
   multiple instances of a Session-Group-Info AVP, the request MUST NOT
   comprise more than a single instance of a Group-Response-Action AVP.
   If the sender wants the receiver to perform follow up exchanges with
   a single command for all impacted groups, the sender sets the value
   of the Group-Response-Action AVP to ALL_GROUPS (1).  If follow up
   message exchanges should be performed on a per-group basis in case
   multiple groups are identified in the group command, the value of the
   Group-Response-Action AVP is set to PER_GROUP (2).  A value set to
   PER_SESSION (3) indicates to the receiver that all follow up
   exchanges should be performed using a single message for each
   impacted session.

   If the sender wants the receiver of the sends a request including the Group-Response-Action AVP
   set to process ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delays
   before receiving the
   associated corresponding answer(s) as the answer(s) will
   only be sent back when the request is processed for all the sessions
   or all the session of a session group.  If the process 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).

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

4.4.2.  Receiving Group Commands

   A Diameter peer node receiving a request to process a command for a group
   of sessions identifies the relevant groups according to the appended
   Session-Group-Id AVP in the Session-Group-Info AVP and processes the
   group command according to the appended Group-Response-Action AVP .

   If the received request identifies multiple groups in multiple
   appended 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.

   The Diameter peer node receiving a request which requests performing the
   command to at least on session group SHOULD perform follow up message
   exchanges according to the value identified in the Session-Group-Info
   AVP.

4.4.3.  Error Handling for Group Commands

   When a Diameter peer 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.

   When a Diameter peer 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].  In case of limited success, the
   sessions, for which the processing of the group command failed, MUST
   be identified using a Failed-AVP AVP as per Session 7.5 of [RFC6733].

4.4.4.  Single-Session Fallback

   Either Diameter peer, a Diameter client or a Diameter server, 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.  The response to the group command must not identify
   any group but identify solely the single session for which the
   command has been processed.

5.  Operation with Proxies Agents

   This specification assumes in

   In case of a present stateful Proxy Agent between a Diameter client
   and a Diameter server server, this specification assumes that the Proxy
   Agent is aware of session groups and session group handling.  The
   Proxy MUST reflect the state update and maintain consistency of each session associated with a its local session
   group according to
   states as per the result of a the group command commands which are operated
   between a Diameter client and a server.

   In case a 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 performing performs group commands operations with, for example, a Diameter
   server, whereas the Diameter client is not group-aware. 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.

6.  Commands Formatting

   This document does not specify new Diameter commands to enable group
   operations, but relies on command extensibility 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 perform applying the command to all
   sessions associated with the identified group(s).

6.1.  Formatting Example: Group Re-Auth-Request

   A request that for re-authentication of one or more groups of users are re-authentication is
   issued by appending one or multiple Session-Group-Id AVP(s) to the
   Re-Auth-Request (RAR) and AVP(s), as well
   as a single instance of a Group-Response-
   Action AVP. Group-Response-Action AVP to the Re-Auth-
   Request (RAR).  The one or multiple Session-Group-Id AVP(s) identify
   the associated group(s) for which the 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(s).  Furthermore, the
   sender of the group re-authentication request appends a Group-Response-Action Group-
   Response-Action AVP to provide more information to the receiver of
   the command about how to accomplish the group operation.

   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.

         <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 (AVP)

                                                  +--------------------+
                                                  |   AVP Flag rules   |
                                                  +----+---+------+----+
                                 AVP              |    |   |SHOULD|MUST|
 Attribute Name                  Code Value Type  |MUST|MAY| NOT  | NOT|
+-------------------------------------------------+----+---+------+----+
|Session-Group-Info              TBD1 Grouped     |    | P |      | V  |
|Session-Group-Control-Vector    TBD2 Unsigned32  |    | P |      | V  |
|Session-Group-Id                TBD3 OctetString |    | P |      | V  |
|Group-Response-Action           TBD4 Unsigned32  |    | P |      | V  |
|Session-Group-Capability-Vector TBD5 Unsigned32  |    | P |      | V  |
+-------------------------------------------------+----+---+------+----+

                   AVPs for the Diameter Group Signaling

7.1.  Session-Group-Info AVP

   The Session-Group-Info AVP (AVP Code TBD1) is Session-Group-Info AVP (AVP Code TBD1) 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 Header: TBD1 >
                             < Session-Group-Control-Vector >
                             [ Session-Group-Id ]
                           * [ AVP ]

7.2.  Session-Group-Control-Vector AVP

   The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type
   Unsigned32 and contains a 32-bit flags field to control the group
   assignment at session-group aware nodes.

   The following capabilities are defined in this document:

   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 as
      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.

   SESSION_GROUP_STATUS_IND (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 comprise a Session-Group-Id AVP, this flag
      is meaningless and MUST be ignored by the receiver.

7.3.  Session-Group-Id AVP

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

   The Session-Group-Id MUST be globally and eternally unique, as it is
   meant to uniquely identify a group of Diameter sessions without
   reference to any other information.

   The default format of type Grouped.  It
   contains the identifier of Session-Group-id MUST comply to the session group as well format
   recommended for a Session-Id, as an indication defined in the section 8.8 of the
   [RFC6733].  The <DiameterIdentity> portion of the node responsible for session group identifier assignment.

      Session-Group-Info ::= < AVP Header: TBD1 >
                             < Session-Group-Control-Vector >
                             [ Session-Group-Id ]
                           * [ AVP ]

7.2.  Session-Group-Control-Vector
   MUST identify the Diameter node, which owns the session group.

7.4.  Group-Response-Action AVP

   The Session-Group-Control-Vector Group-Response-Action AVP (AVP Code TBD2) TBD4) is of type Unsigned32
   and contains a 32-bit flags field to control address space representing values indicating
   how the group
   assignment at session-group aware nodes. node SHOULD issue follow up exchanges in response to a
   command which impacts multiple sessions.  The following capabilities values are
   defined in by this document:

   SESSION_GROUP_ALLOCATION_ACTION (0x00000001)

      This flag indicates the action to application:

   ALL_GROUPS (1)
      Follow up exchanges should be performed with a single message
      exchange for the identified
      session.  When this flag is set, it indicates that the identified
      Diameter session is to all impacted groups.

   PER_GROUP (2)
      Follow up exchanges should be assigned to the session group as
      identified by the Session-Group-Id performed with a message exchange
      for each impacted group.

   PER_SESSION (3)
      Follow up exchanges should be performed with a message exchange
      for each impacted session.

7.5.  Session-Group-Capability-Vector AVP or the session's assignment
      to the session group identified in the Session-Group-Id

   The Session-Group-Capability-Vector AVP (AVP Code TBD5) is
      still valid.  When the flag is cleared, the identified Diameter
      session is of type
   Unsigned32 and contains a 32-bit flags field to be removed from at least one session group.  When indicate capabilities
   in the flag is cleared context of session-group assignment and the Session-Group-Info AVP identifies a
      particular session group operations.

   The following capabilities are defined in this document:

   BASE_SESSION_GROUP_CAPABILITY (0x00000001)

      This flag indicates the associated Session-Group-Id AVP,
      the session is capability to be removed solely from the identified support session
      group.  When the flag is cleared grouping 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, operations according to which it has been previously assigned.

   SESSION_GROUP_STATUS_IND (0x00000010) this specification.

8.  Result-Code AVP Values

   This flag indicates the status document does not define new Result-Code [RFC6733] values for
   existing applications, which are extended to support group commands.
   Specification documents of the session new applications, which will have
   intrinsic support for group identified in
      the associated Session-Group-Id AVP.  The flag is set when commands, may specify new Result-Codes.

9.  IANA Considerations

   This section contains the
      identified session group has just namespaces that have either been created in
   this specification or is still active.
      If the flag is cleared, the identified session group is deleted
      and had their values assigned to existing
   namespaces managed by IANA.

9.1.  AVP Codes

   This specification requires IANA to register the associated Session-Group-Id is released.  If following new AVPs
   from the Session-
      Group-Info AVP does not comprise a Session-Group-Id AVP, this flag
      is meaningless and MUST be ignored by the receiver.

7.3. Code namespace defined in [RFC6733].

   o  Session-Group-Info

   o  Session-Group-Control-Vector

   o  Session-Group-Id AVP

   o  Group-Response-Action

   o  Session-Group-Capability-Vector

   The Session-Group-Id AVP (AVP Code TBD3) is AVPs are defined in Section 7.

10.  Security Considerations

   The security considerations of type UTF8String and
   identifies a group the Diameter protocol itself are
   discussed in [RFC6733].  Use of Diameter sessions.

   The Session-Group-Id the AVPs defined in this document
   MUST be globally take into consideration the security issues and eternally unique, as it is
   meant to uniquely identify a group requirements of
   the Diameter sessions without
   reference to any other information.

   The default format of base protocol.  In particular, the Session-Group-id MUST comply to Session-Group-Info
   AVP (including the format
   recommended for a Session-Id, Session-group-Control-Vector and the Session-
   Group-Id AVPs) should be considered as defined a security-sensitive AVPs in
   the section 8.8 of same manner than the Session-Id AVP in the Diameter base protocol
   [RFC6733].

   The DiameterIdentity element management of session groups relies upon the Session-Group-Id MUST
   identify existing trust
   relationship between the Diameter node, which owns client and the session group.

7.4.  Group-Response-Action AVP

   The Group-Response-Action AVP (AVP Code TBD4) is Diameter server
   managing the groups of type Unsigned32
   and contains sessions.  This document defines a 32-bit address space representing values indicating
   how the peer SHOULD issue follow up exchanges in response to mechanism
   that allows a
   command which impacts client or a server to act on multiple sessions.  The following values are
   defined sessions at the
   same time using only one command. if the Diameter client or server is
   compromised, an attacker could launch DoS attacks by this application:

   ALL_GROUPS (1)
      Follow up exchanges should be performed with a single message
      exchange for all impacted groups.

   PER_GROUP (2)
      Follow up exchanges should be performed with terminating a message exchange
      for each impacted group.

   PER_SESSION (3)
      Follow up exchanges should be performed
   large number of sessions with a message exchange
      for each impacted session.

7.5.  Session-Group-Capability-Vector AVP

   The Session-Group-Capability-Vector AVP (AVP Code TBD5) is limited set of type
   Unsigned32 and contains a 32-bit flags field commands using the
   session group management concept.

   According to the Diameter base protocol [RFC6733], transport
   connections between Diameter peers are protected by TLS/TCP, DTLS/
   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 indicate capabilities establish trust in the context session group
   related information received from non-adjacent nodes.  Any Diameter
   agent in the message path can potentially modify the content of session-group assignment the
   message and group operations. therefore the information sent by the Diameter client or
   the server.  The following capabilities are defined in this document:

   BASE_SESSION_GROUP_CAPABILITY (0x00000001)

      This flag indicates DIME working group is currently working on solutions
   for providing end-to-end security features.  When available, these
   features should enable the capability to support session grouping establishment of trust relationship
   between non-adjacent nodes and the security required for session
   group operations according to management would normally rely on this end-to-end security.
   However, there is no assumption in this specification.

8.  Result-Code AVP Values

   This document does not define new Result-Code [RFC6733] values for
   existing applications, which are extended to support group commands.
   Specification documents of new applications, which that such end-to-end
   security mechanism will have
   intrinsic support for group commands, may specify new Result-Codes.

9.  IANA Considerations

   This section contains the namespaces be available.  It is only assume that have either been created in the
   solution defined on this specification document relies on the security framework
   provided by the Diameter based protocol.

   In some cases, a Diameter Proxy agent can act on behalf of a client
   or had their values assigned server.  In such a case, the security requirements that normally
   apply to existing
   namespaces managed by IANA.

9.1.  AVP Codes

   This specification requires IANA a client (or a server) apply equally to register the following new AVPs
   from the AVP Code namespace defined in [RFC6733].

   o  Session-Group-Info

   o  Session-Group-Control-Vector

   o  Session-Group-Id

   o  Group-Response-Action

   o  Session-Group-Capability-Vector

   The AVPs are defined in Section 7.

10.  Security Considerations

   TODO Proxy agent.

11.  Acknowledgments

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

12.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
              "Diameter Network Access Server Application", RFC 4005,
              August 2005.

   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", RFC 6733, October 2012.

Appendix A.  Session Management -- Exemplary Session State Machines Machine

A.1.  Use of groups for the Authorization Session State Machine

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

   The group membership is 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, NASREQ).

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

   A

   The Diameter group command in the following tables is differentiated
   from a single-session related command by a preceding 'G'. '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].

                              CLIENT, STATEFUL
      State     Event                          Action       New State
      ---------------------------------------------------------------
      Idle      Client or Device Requests      Send         Pending
                access                         service
                                               specific
                                               auth req
                                               optionally
                                               including
                                               groups

      Open      GASR received with             Send GASA    Discon
                Group-Response-Action          with
                = ALL_GROUPS,                  Result-Code
                session is assigned to         = SUCCESS,
                received group(s) and          Send GSTR.
                client will comply with
                request to end the session

      Open      GASR received with             Send GASA    Discon
                Group-Response-Action           with
                = PER_GROUPS,                  Result-Code
                session is assigned to         = SUCCESS,
                received group(s) and          Send GSTR
                client will comply with        per group
                request to end the session
      Open      GASR received with             Send GASA    Discon
                Group-Response-Action          with
                = PER_SESSION,                 Result-Code
                session is assigned to         = SUCCESS,
                received group(s) and          Send STR
                client will comply with        per session
                request to end the session

      Open      GASR received,                 Send GASA    Open
                client will not comply with    with
                request to end all session     Result-Code
                in received group(s)           != SUCCESS

      Discon    GSTA Received                  Discon.      Idle
                                               user/device

      Open      GRAR received with             Send GRAA,   Pending
                Group-Response-Action          Send
                = ALL_GROUPS,                  service
                session is assigned to         specific
                received group(s) and          group
                client will perform            re-auth req
                subsequent re-auth

      Open      GRAR received with             Send GRAA,   Pending
                Group-Response-Action          Send
                = PER_GROUP,                   service
                session is assigned to         specific
                received group(s) and          group
                client will perform            re-auth req
                subsequent re-auth             per group

      Open      GRAR received with             Send GRAA,   Pending
                Group-Response-Action          Send
                = PER_SESSION,                 service
                session is assigned to         specific
                received group(s) and          re-auth req
                client will perform            per session
                subsequent re-auth

      Open      GRAR received and client will  Send GRAA    Idle
                not perform subsequent         with
                re-auth                        Result-Code
                                               != SUCCESS,
                                               Discon.
                                               user/device

      Pending   Successful service-specific    Provide      Open
                group re-authorization answer  service
                received.

      Pending   Failed service-specific        Discon.      Idle
                group re-authorization answer  user/device
                received.

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

                                SERVER, STATEFUL
      State     Event                          Action       New State
      ---------------------------------------------------------------

      Idle      Service-specific authorization Send         Open
                request received, and user     successful
                is authorized                  service
                                               specific
                                               answer
                                               optionally
                                               including
                                               groups

      Open      Server wants to terminate      Send GASR    Discon
                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 Result-Code Update       Open
                = SUCCESS                      session(s)

      Pending   GRAA received with Result-Code Cleanup      Idle
                != SUCCESS                     session(s)

      Open      Service-specific group         Send         Open
                re-authoization request        successful
                received and user is           service
                authorized                     specific
                                               group
                                               re-auth
                                               answer

      Open      Service-specific group         Send         Idle
                re-authorization request       failed
                received and user is           service
                not authorized                 specific
                                               group
                                               re-auth
                                               answer,
                                               cleanup

Authors' Addresses

   Mark Jones

   Email: mark@azu.ca

   Marco Liebsch

   Email: marco.liebsch@neclab.eu

   Lionel Morand

   Email: lionel.morand@orange.com