Diameter Maintenance and                                        M. Jones
Extensions (DIME)                                             M. Liebsch
Internet-Draft                                                 L. Morand
Intended status: Standards Track                        October 21, 2013                       February 15, 2014
Expires: April 24, August 19, 2014

                        Diameter Group Signaling
                 draft-ietf-dime-group-signaling-02.txt
                 draft-ietf-dime-group-signaling-03.txt

Abstract

   In large network deployments, a single Diameter peer can support over
   a million concurrent Diameter sessions.  Recent use cases have
   revealed the need for Diameter peers 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 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 April 24, August 19, 2014.

Copyright Notice

   Copyright (c) 2013 2014 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  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Use Cases  . . . .  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  5  6
     3.1.  Building and Modifying Session Groups  . . . . . . . . . .  5  6
     3.2.  Issuing Group Commands . . . . . . . . . . . . . . . . . .  5
   4.  Grouping User Sessions  6
     3.3.  Permission Model . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Group assignment at session initiation .  7
   4.  Protocol Description . . . . . . . . .  6
     4.2.  Mid-session group assignment modifications . . . . . . . .  6
       4.2.1.  Client-initiated group assignment changes . . . .  8
     4.1.  Session Grouping . .  7
       4.2.2.  Server-initiated group assignment changes . . . . . .  7
   5.  Protocol Description . . . . . . . . . . . . .  8
       4.1.1.  Group assignment at session initiation . . . . . . . .  8
     5.1.  Session Grouping
       4.1.2.  Removing a session from a session group  . . . . . . . 10
       4.1.3.  Mid-session group assignment modifications . . . . . . 11
     4.2.  Session Grouping Capability Discovery  . . . . . . . . . .  8
     5.2.  Session Grouping 12
       4.2.1.  Implicit Capability Discovery  . . . . . . . . . .  9
       5.2.1.  Implicit . . 12
       4.2.2.  Explicit Capability Discovery  . . . . . . . . . . . .  9
       5.2.2.  Explicit Capability Discovery  . 12
     4.3.  Releasing a Session Group Identifier . . . . . . . . . . .  9
     5.3. 12
     4.4.  Performing Group Operations  . . . . . . . . . . . . . . . 10
       5.3.1. 13
       4.4.1.  Sending Group Commands . . . . . . . . . . . . . . . . 10
       5.3.2. 13
       4.4.2.  Receiving Group Commands . . . . . . . . . . . . . . . 10
       5.3.3.  Single-Session Fallback  . . . 13
       4.4.3.  Error Handling for Group Commands  . . . . . . . . . . 14
       4.4.4.  Single-Session Fallback  . . 11
     5.4.  Session Management . . . . . . . . . . . . . 14
   5.  Operation with Proxies Agents  . . . . . . . 11
       5.4.1.  Authorization Session State Machine . . . . . . . . . 11 15
   6.  Commands Formatting  . . . . . . . . . . . . . . . . . . . . . 15 16
     6.1.  Formatting Example: Group Re-Auth-Request  . . . . . . . . . . . . . . . . . . 15 16
   7.  Attribute-Value-Pairs (AVP)  . . . . . . . . . . . . . . . . . 16 17
     7.1.  Session-Group-Info AVP . . . . . . . . . . . . . . . . . . 16 17
     7.2.  Session-Group-Feature-Vector AVP . . . . . . . . . . . . . 16 17
     7.3.  Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 16 18
     7.4.  Session-Group-Action AVP . . . . . . . . . . . . . . . . . 17 18
   8.  Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 18 19
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19 20
     9.1.  AVP Codes  . . . . . . . . . . . . . . . . . . . . . . . . 19 20
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 20 21
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21 22
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 22 23
   Appendix A.  Session Management -- Exemplary Session State
                Machines  . . . . . . . . . . . . . . . . . . . . . . 24
     A.1.  Authorization Session State Machine  . . . . . . . . . . . 24

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 28

1.  Introduction

   In large network deployments, a single Diameter peer can support over
   a million concurrent Diameter sessions.  Recent use cases have
   revealed the need for Diameter peers 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 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' 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

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 [RFC3588]. [RFC6733].

3.  Use Cases  Protocol Overview

3.1.  Building and Modifying Session Groups

   Client and Server can add 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 added to one or multiple groups.  Such similarities can be
   for example maximum bandwidth bounds of each user in the a group.
   These users may share resources of, e.g., an access multiplexer,
   together with other users.  Runtime adjustments in the granted
   bandwidth bounds or other Quality of Service related attributes can
   be accomplished for the whole group by identifying the group in the
   Diameter group command.

   In case a user's subscription profile changes during runtime, either
   node, a Diameter Server or Diameter client, may decide to remove this
   user's Diameter session from the session group.  The user's Diameter
   session can be assigned to a different group, whose adjusted profile
   matches the one of the different group.  Both groups, the user's
   previous group and its new group, will be modified mid-session.

   In case of mobile users, a change in the node implementing the
   Diameter client can happen, which has impact to a group of sessions a
   particular pair of Diameter client and server has in common.  Due to
   mobility, the mobile user's session may get transferred to a new
   Diameter client during runtime without mandating from-scratch
   authorization.  Such scenario necessitates mid-session modification.

3.2.  Issuing Group Commands

   A policy decision point may decide to terminate a group of sessions,
   e.g. based on previous agreement for temporary authorization to
   access a system.  All Diameter sessions of associated users with such
   temporarily granted access will be added to a single Diameter session
   group.  After the time limit for the temporary authorization has been
   reached, the policy decision point can issue a single Session
   Termination Request (STR) to the policy enforcement point.  The STR
   command identifies the group of Diameter sessions which are to be
   terminated.  The policy enforcement point treats the STR as group
   command and initiates termination of all sessions in the group.
   Subsequently, the policy enforcement point confirms successful
   termination of these sessions to the policy decision point by sending
   a single Session Termination Answer (STA) command which includes the
   identifier of the group.

4.  Grouping User Sessions

   Either

3.3.  Permission Model

   A permission model in the context of this draft defines the
   permission of Diameter peer may assign a nodes to build new session groups, to add/
   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 AAA
   applications typically assign client and server roles to the Diameter
   peers.

4.1.  Group assignment at session initiation

   Assignment of a new session to a group is accomplished by the
   Diameter server when requested by the Diameter client.  Without being
   explicitly requested by the client, the a Diameter server can assign build a new session to a server-assigned group based on its own decision.
   When and
   assign a new session is to be assigned identifier to a group by the Diameter
   server, the server assigns a new that session to at least one server-
   assigned group.  To complement server-assigned grouping,  When a Diameter
   client can assign a session node
   decides to issue a client-assigned group.

   To assign a new session group, e.g. to a group at all sessions
   which share certain characteristics, the node must identify itself in
   the DiameterIdentity element of the session initiation, a Diameter
   client sends a service specific request, e.g.  NASREQ AAR [RFC4005],
   containing one or more group identifiers. identifier
   (Section 7.3) as owner of the group.  The Diameter client can
   assign permission model as per
   this specification solely constrains the session permission to close a client-assigned
   session group and identify release the associated identifier to the group with an appended client-assigned group identifier.
   The client can append multiple client-assigned group identifiers if
   owner.

   Irrespective of the client assigns group ownership, as per this specification any
   Diameter node has the new session permission to more than one add/remove a session to/from an
   existing session group.  If  Also the
   Diameter client does not send modification of groups in terms of
   moving a client-assigned group identifier, the
   client may receive session from one or multiple server-assigned session group identifiers
   in the server's response, which identify the server-assigned groups to which the new a different session has been assigned.  The Diameter client can
   explicitly request the Diameter server group
   is permitted to perform grouping any Diameter node.  The enforcement of a more
   constrained model is left to the new
   session.

   Assuming the user has been successfully authenticated and/or
   authorized, the application and implementation,
   which must then ensure that relevant Diameter server responds with service-specific auth
   response, e.g.  NASREQ AAA [RFC4005], containing both nodes have the client-
   assigned group identifiers (if sent with same
   view of the request) and one or more
   server-assigned group identifiers.

   Both peers, the Diameter client and the Diameter server, must keep a
   list of all group identifiers which identify all client- and server-
   assigned groups to which the session has been assigned.

4.2.  Mid-session group assignment modifications

   Either Diameter peer may modify the group membership of an active
   Diameter session.  A Diameter client MAY remove the group(s) assigned
   to the active session by the Diameter server and vice versa.

   This document does not define permission model, either through administrative
   configuration or protocol-based capability discovery.  Details about
   enforcing a more constraint permission model that limits removal are out of scope of a session from a group by the same peer that added the session to
   the group.  However, applications which re-use the commands and
   methods defined in this document may impose their own permission
   model.
   specification.  For example, an application a more constrained model could require
   that the server a client MUST NOT remove a session from a group assigned by the client.

4.2.1.  Client-initiated group assignment changes

   To update the assigned groups mid-session, a Diameter client sends a
   service specific re-authorization request containing the updated list
   of group identifiers.  Assuming the user which is successfully
   authenticated and/or authorized, the Diameter server responds with a
   service-specific auth response containing the updated list of group
   identifiers received in the request.

4.2.2.  Server-initiated group assignment changes

   To update the assigned groups mid-session, a Diameter server sends a
   Re-authorization Request (RAR) message requesting re-authorization
   and the client responds with a Re-authorization Answer (RAA) message.
   The Diameter client sends a service specific re-authorization request
   containing the current list of group identifiers and the Diameter
   server responds with a service-specific auth response containing owned
   by the
   updated list of group identifiers.

5. server.

4.  Protocol Description

5.1.

4.1.  Session Grouping

   Either Diameter peer, a Diameter client or server, peer can initiate assigning a session to a single or
   multiple session groups according
   to the procedure described in Section 4. groups.  Modification of a group by removing or
   adding a single or multiple user sessions can be initiated and
   performed at runtime by either Diameter peer.

   A  Diameter AAA
   applications typically assign client and server roles to the Diameter
   peers, which are referred to as relevant Diameter peers 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 peers, which are group-aware, must store and maintain a list
   of all session groups to which at least one session, for which the
   peer holds a state, is assigned.  Along with the group's Session-Id,
   a list of Diameter sessions, which are assigned to the group, must be
   stored.  This specification assumes that a session group is built and
   handled between pairs of Diameter nodes.  Clients and servers MUST
   maintain Diameter state of individual sessions grouped in a session
   group.

4.1.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 AAR [RFC4005],
   containing one or more group identifiers.  A Diameter client as
   sender of a command for session initiation can determine one or
   multiple groups to which the new session should be assigned.  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.

   In each appended Session-Group-Info AVP which carries

   The client may choose one or multiple sessions from a list of
   existing session groups, irrespective of the group
   identifier, ownership.
   Alternatively, the SESSION_GROUP_ALLOCATION_MODE flag client may decide to create a new group and
   identify itself in the DiameterIdentity element of the Session-
   Group-Feature-Vector
   Group-Session-Id AVP as per Section 7.3

   The client MUST be:

   o set (1) the SESSION_GROUP_ALLOCATION_ACTION of the
   Session-Group-Feature-Vector AVP in each appended Session-Group-Info
   AVP to indicate that the carried group identifier is a server-
      assigned group;

   o  cleared (0) identified session should be added to indicate that the carried group identifier is a
      client-assigned
   identified session group.

   A Diameter client can explicitly request

   If the Diameter server as
   recipient receives a command request from a Diameter
   client and the command comprises at least one Session-Group-Info AVP
   having the SESSION_GROUP_ALLOCATION_ACTION flag of the message to assign Session-Group-
   Feature-Vector AVP set, the server must add the new session to each
   of the one or multiple identified session groups.  In case one or
   multiple
   server-assigned identified session groups by appending a Session-Group-Info AVP with no
   Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with are not know to the SESSION_GROUP_ALLOCATION_MODE flag set (1).

   If server, the Diameter
   server receives must add the one or multiple new groups to its locally
   maintained list of session groups.  When sending the response to the
   client, e.g. a service-specific auth response as per NASREQ AAA
   [RFC4005], the server must include all Session-Group-Info AVP with no
   Session-Group-Id AVP and AVPs as
   received in the Session-Group-Feature-Vector AVP with client's request.

   In addition to the SESSION_GROUP_ALLOCATION_MODE flag set (1), one or multiple session groups identified in the
   client's request, the Diameter server
   SHOULD assign may decide to add the new session to one
   or multiple server-assigned additional groups.  The Diameter  In such case, the server identifies each of these server-assigned
   groups in a Session-Group-Id AVP contained in a Session-Group-Info
   AVP, which are appended add to the
   response additional Session-Group-Info AVPs, each identifying a
   session group, to which the received command. server has assigned the new session.
   Each of these the Session-Group-Info AVPs must have AVP added by the server, the
   SESSION_GROUP_ALLOCATION_MODE
   SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Feature-
   Vector AVP set to indicate that the carried identifier is a server-
   assigned group identifier. must be set.

   If the Diameter server receives a Session-Group-Info AVP with command for session initiation from
   a
   Session-Group-Id AVP Diameter client and the Session-Group-Feature-Vector AVP with
   the SESSION_GROUP_ALLOCATION_MODE flag cleared (0), the server must
   store command comprises at least one Session-
   Group-Info AVP, but the one or multiple Session-Group-Info AVP do not
   identify any session group identifiers and associate to which the new session with these client-assigned groups.  The Diameter should be assigned,
   the server may
   still assign the new session to one or multiple server-assigned session
   groups.  The Diameter  Each session group, to which the server identifies each of these server-assigned
   groups in a Session-Group-Id AVP contained assigns the new
   session, must be identified in a separate Session-Group-Info
   AVP, which are appended to AVP
   having the response to SESSION_GROUP_ALLOCATION_ACTION flag of the received command, in
   addition to associated
   Session-Group-Vector AVP set.

   If the those related Diameter client receives a response to its previously issued
   request from the client-assigned groups received
   in the request.  Each of these server and the response comprises at least one
   Session-Group-Info AVPs must have AVP having the
   SESSION_GROUP_ALLOCATION_MODE SESSION_GROUP_ALLOCATION_ACTION
   flag of the Session-Group-Feature-
   Vector associated Session-Group-Feature-Vector AVP set set, the
   client must add the new session to indicate that this carried identifier is a server-
   assigned group identifier. all session groups as identified
   in the one or multiple Session-Group-Info AVPs.

   A Diameter server receiving a command for session initiation which
   includes at least one Session-Group-Info AVP but the server does not
   understand the semantics of this optional AVP because it does not
   support group operations according to the specification in this
   document, MUST ignore the optional group operations specific AVPs and
   proceed with processing the command for a single session.

   A Diameter client, which sent a request for session initiation to a
   Diameter server and appended a single or multiple Session-Group-Id
   AVPs but cannot find any Session-Group-Info AVP in the associated
   response from the Diameter server proceeds with processing the
   command for a single session.  Furthermore, the client keeps a log to
   remember that the server is not able to perform group operations.

5.2.  Session Grouping Capability Discovery

5.2.1.  Implicit Capability Discovery

   By appending at least one Session-Group-Info AVP, the

4.1.2.  Removing a session from a session group

   When a Diameter client
   announces its capability to support group operations according decides to remove a session from a particular
   session group, the
   specification in this document client sends a service-specific re-authorization
   request to the addressed Diameter server.  If
   the Diameter client supports group operations, it MUST append at
   least server and adds one Session-Group-Info AVP to announce its capability to
   support group operations.

   A session-group aware Diameter server receiving a command the
   request for each session
   initiation group, from which includes at least one Session-Group-Info AVP learns
   about the sender's capability client wants to support group operations.

   By appending at least one Session-Group-Id AVP, remove
   the Diameter server
   announces its capability to support group operations according session.  The session, which is to be removed from a group, is
   identified in the
   specification Session-Id AVP of the command request.  The
   SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Feature-
   Vector AVP in this document each Session-Group-Info AVP must be cleared to indicate
   removal of the addressed Diameter client.

5.2.2.  Explicit Capability Discovery

   New Diameter applications may consider support for Diameter session
   grouping and for performing group commands during the standardization
   process.  Such applications provide intrinsic support for from the support
   of session group commands and announce this capability through identified in the assigned
   application ID.

5.3.  Performing Group Operations

5.3.1.  Sending Group Commands

   Either Diameter peer can request the recipient of
   associated Session-Group-id AVP.

   When a request Diameter client decides to
   process an associated command for remove a session from all sessions being assigned session
   groups, to one
   or multiple groups by identifying these groups in which the request.  The
   sender of session has been previously assigned, the client
   sends a service-specific re-authorization request appends for each group, to which the command
   applies, server and
   adds a single Session-Group-Info AVP including to the Session-Group-Id AVP
   and indicates in request which has the SESSION_GROUP_ALLOCATION_MODE
   SESSION_GROUP_ALLOCATION_ACTION flag of cleared and the
   Session-Group-Feature-Vector Session-Group-Id
   AVP whether omitted.  The session, which is to be removed from all groups, to
   which the identifier represents a
   server- or a client-assigned group.  If session has been previously assigned, is identified in the CCF
   Session-Id AVP of the request
   mandates a Session-Id AVP, command request.

   If the Session-Id AVP MUST identify Diameter server receives a single
   session request from the client which is assigned to has
   at least one of Session-Group-Info AVP appended with the groups being
   SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server must remove
   the session from the session group identified in the appended associated
   Session-Group-Id AVPs.

   The sender of AVP.  If the request can indicate to comprises at least one Session-
   Group-info AVP with the receiver how follow up
   message exchanges should be performed by appending a Session-Group-
   Action AVP.  If SESSION_GROUP_ALLOCATION_ACTION flag cleared
   and no Session-Id AVP present, the sender wants server must remove the receiver to perform follow up
   exchanges with a single command for session
   from all impacted groups, session groups to which the sender
   sets session has been previously
   assigned.  The server must include in its response to the value of requesting
   client all Session-Group-Id AVPs as received in the Session-Group-Action AVP request.

   When the Diameter server decides to ALL_GROUPS (1).  If
   follow up message exchanges should be performed on remove a per-group basis
   in case session from one or
   multiple particular session groups are identified in the group command, the
   value of the Session-Group-Action AVP is set to PER_GROUP (2).  A
   value set to PER_SESSION (3) indicates to the receiver that or from all
   follow up exchanges should be performed using a single message for
   each impacted session.

   If the sender wants session groups to
   which the receiver of session has been assigned beforehand, the request server sends a
   Re-Authorization Request (RAR) to process the
   associated command solely for a single session does not append any
   group identifier, but identifies client, indicating the relevant session
   in the requests Session-Id AVP.

5.3.2.  Receiving Group Commands

   A Diameter peer receiving  The client sends a request Re-Authorization
   Answer (RAA) to process a command for a group
   of sessions identifies the relevant groups according respond to the appended
   Session-Group-Id AVP in the Session-Group-Info AVP.  If the received server's request.  The client
   subsequently sends service-specific re-authorization request identifies multiple groups in
   containing one or multiple appended Session-
   Group-Id Session-Group-Info AVPs, the receiver should process the associated command for each of these groups. if indicating a
   session has been assigned group, to more than one which the session had been previously assigned.  To
   indicate removal of the identified indicated session from one or multiple
   session groups, the receiver must process server sends a service-specific auth response to
   the associated
   command only once per session.

   The Diameter peer receiving client, containing a request 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 requests performing the
   command to at least on session group SHOULD perform follow up message
   exchanges according should be
   removed.  The server MAY include to the value identified in the service-specific auth
   response a list of Session-Group-Info
   AVP.

5.3.3.  Single-Session Fallback

   Either Diameter peer, a Diameter client or a Diameter server, can
   fall back to single session operation by ignoring AVPs with the
   SESSION_GROUP_ALLOCATION_ACTION flag set and omitting the
   optional group session-specific AVPs.  Fallback Session-Group-Id AVP
   identifying session groups to single-session
   operation is performed by processing the Diameter command solely for which the session identified in remains subscribed.
   In case the mandatory Session-Id AVP.  The response server decides to remove the group command must not identify any group but identify solely
   the single identified session for from all
   session groups, to which the command session has been processed.

5.4.  Session Management

   Editor's note: This document revision adopts the WG's current view on
   how Diameter commands can be formatted to enable group signaling.
   The required change in previously assigned,
   the formatting and protocol operation has not
   yet been considered server includes in this Section 5.4 , which still reflects the
   formatting as per version 0 of this specification.  The described
   session state machines still need revision to reflect service-specific auth response at least
   one Session-Group-Info AVP with the generalized
   formatting SESSION_GROUP_ALLOCATION_ACTION
   flag cleared and Session-Group-Info AVP absent.

4.1.3.  Mid-session group assignment modifications

   Either Diameter peer can modify the adopted protocol operation.

5.4.1.  Authorization Session State Machine

   Section 8.1 in [RFC3588] defines a set of finite state machines,
   representing the life cycle group membership of an active
   Diameter sessions, and which MUST be
   observed by all Diameter implementations that make use session, irrespective of the
   authentication and/or authorization portion of group ownership.

   To update an assigned group mid-session, a Diameter
   application.  This section defines the additional state transitions
   related client sends a
   service-specific re-authorization request to the processing of the new commands which may impact server, containing
   one or multiple sessions.

   The group membership is session state Session-Group-Info AVPs with the
   SESSION_GROUP_ALLOCATION_ACTION flag set and therefore only those state
   machines from [RFC3588] in the Session-Group-Id AVP
   present, identifying the session group to which the server is maintaining session
   state are relevant in this document.  As in [RFC3588], should be
   added.  With 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 same message, the server.  State transitions which are unmodified
   from [RFC3588] are not repeated here.

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

      Open      GASR received with             Send GASA    Discon
                Session-Group-Action multiple
   Session-Group-Info AVP with
                = ALL_GROUPS,                  Result-Code
                session is assigned to         = SUCCESS,
                received group(s) the SESSION_GROUP_ALLOCATION_ACTION flag
   cleared and          Send GSTR.
                client will comply with
                request to end the Session-Group-Id AVP identifying the session

      Open      GASR received with             Send GASA    Discon
                Session-Group-Action           with
                = PER_GROUPS,                  Result-Code group
   from which the identified session is assigned to         = SUCCESS,
                received group(s) and          Send GSTR be removed.  To remove the
   session from all previously assigned session groups, the client will comply
   includes at least one Session-Group-Info AVP with        per group
                request to end the session

      Open      GASR
   SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id
   AVP present.  When the server received with             Send GASA    Discon
                Session-Group-Action           with
                = PER_SESSION,                 Result-Code the service-specific re-
   authorization request, it must update its locally maintained view of
   the session is assigned groups for the identified session according to         = SUCCESS,
                received group(s) and          Send STR the
   appended Session-Group-Info AVPs.  The server sends a service-
   specific auth response to the client will comply containing one or multiple
   Session-Group-Info AVPs with        per the SESSION_GROUP_ALLOCATION_ACTION flag
   set and the Session-Group-Id AVP identifying the new session
                request group to end
   which the identified session

      Open      GASR received,                 Send GASA    Open has been added.

   When a Diameter server enforces an update to the assigned groups mid-
   session, it sends a Re-Authorization Request (RAR) message to the
   client will not comply with 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 to end all session     Result-Code
                in received group(s)           != SUCCESS

      Discon    GSTA Received                  Discon.      Idle
                                               user/device

      Open      GRAR received containing one or multiple Session-Group-Info
   AVPs with             Send GRAA,   Pending
                Session-Group-Action           Send
                = ALL_GROUPS,                  service the SESSION_GROUP_ALLOCATION_ACTION flag set and the
   Session-Group-Id AVP identifying the session is assigned group to         specific
                received group(s) which the
   session had been previously assigned.  The server responds with a
   service-specific auth response and          group
                client will perform            re-auth req
                subsequent re-auth

      Open      GRAR received includes one or multiple Session-
   Group-Info AVP with             Send GRAA,   Pending
                Session-Group-Action           Send
                = PER_GROUP,                   service the SESSION_GROUP_ALLOCATION_ACTION flag set and
   the Session-Group-Id AVP identifying the session group, to which the
   identified session is assigned to         specific
                received group(s) and          group
                client will perform            re-auth req
                subsequent re-auth             per group

      Open      GRAR received be added.  With the same response message,
   the server may send one or multiple Session-Group-Info AVPs with             Send GRAA,   Pending
                Session-Group-Action           Send
                = PER_SESSION,                 service the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
   AVP identifying the session groups from which the identified session
   is assigned to         specific
                received group(s) and          re-auth req
                client will perform            per be removed.  When server wants to remove the session
                subsequent re-auth

      Open      GRAR received and client will  Send GRAA    Idle
                not perform subsequent from all
   previously assigned session groups, it send at least on Session-
   Group-Info AVP 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 [RFC3588] are not repeated here.

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

      Idle      Service-specific authorization Send         Open
                request received, response having the
   SESSION_GROUP_ALLOCATION_ACTION flag cleared 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 no Session-Group-Id
   AVP present.

4.2.  Session Grouping Capability Discovery

4.2.1.  Implicit Capability Discovery

   By appending at least one Session-Group-Info AVP, the Diameter client
   announces its capability 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 support group
                                               re-auth
                                               answer,
                                               cleanup

6.  Commands Formatting

   This operations according to the
   specification in this document does not specify new Diameter commands to enable group
   operations, but relies on command extensibility capability provided
   by the addressed Diameter Base protocol.  This section provides the guidelines
   to extend server.  If
   the CCF of existing Diameter commands with optional AVPs client supports group operations, it MUST append at
   least one Session-Group-Info AVP to
   enable the recipient of the command announce its capability to perform the command to all
   sessions associated with the identified group(s).

6.1.  Group Re-Auth-Request
   support group operations.

   A request that session-group aware Diameter server receiving a command for session
   initiation which includes at least one or more groups of users are re-authentication is
   issues by Session-Group-Info AVP learns
   about the sender's capability to support group operations.

   By appending at least one or multiple Session-Group-Id AVP(s) AVP, the Diameter server
   announces its capability to support group operations according to the
   Re-Auth-Request (RAR).  The one or multiple Session-Group-Id AVP(s)
   identify
   specification in this document to the associated group(s) addressed Diameter client.

4.2.2.  Explicit Capability Discovery

   New Diameter applications may consider support for which the Diameter session
   grouping and for performing group re-
   authentication has been requested.  The recipient commands during the standardization
   process.  Such applications provide intrinsic support for the support
   of group commands and announce this capability through the assigned
   application ID.

4.3.  Releasing a Session Group Identifier

   To close a session group
   command initiates re-authentication for all users associated with and release the
   identified group(s).  Furthermore, associated Session-Group-Id
   value, the sender owner of the a session group re-
   authentication request appends a Session-Group-Action single Session-Group-
   Info AVP to provide
   more information to having the receiver of SESSION_GROUP_STATUS_IND flag cleared and the command about how to
   accomplish
   Session-Group-Id AVP identifying the group operation. session group, which is to be
   closed.  The value SESSION_GROUP_ALLOCATION_ACTION flag of the mandatory Session-Id associated
   Session-Group-Feature-Vector AVP MUST identify be cleared.

4.4.  Performing Group Operations

4.4.1.  Sending Group Commands

   Either Diameter peer can request the recipient of a session request to
   process an associated with a single user, which is command for all sessions being assigned to at least one of
   the
   or multiple groups by identifying these 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-Id ]
                    [ Session-Group-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-Feature-Vector  TBD2   Unsigned32  |    | P |      | V  |
|Session-Group-Id              TBD3   OctetString |    | P |      | V  |
|Session-Group-Action          TBD4   Unsigned32  |    | P |      | V  |
+-------------------------------------------------+----+---+------+----+

                   AVPs request.  The
   sender of the request appends for each group, to which the Diameter Group Signaling

7.1.  Session-Group-Info AVP

   The command
   applies, a Session-Group-Info AVP (AVP Code TBD1) is of type Grouped.  It
   contains including the identifier of Session-Group-Id AVP
   to identify the associated session group group.  Both, the
   SESSION_GROUP_ALLOCATION_ACTION flag as well as an indication the
   SESSION_GROUP_STATUS_IND flag must be set.

   If the CCF of the node responsible for session group identifier assignment.
      Session-Group-Info ::= < AVP Header: TBD1 >
                             < Session-Group-Feature-Vector >
                             [ Session-Group-Id ]
                           * [ AVP ]

7.2.  Session-Group-Feature-Vector AVP

   The Session-Group-Feature-Vector request mandates a Session-Id AVP, the Session-Id
   AVP (AVP Code TBD2) is of type
   Unsigned32 and and contains MUST identify a 32-bit flags field single session which is assigned to at least one
   of capabilities
   supported by the session-group aware node.

   The following capabilities are defined groups being identified in this document:

   SESSION_GROUP_ALLOCATION_MODE (0x00000001)

      This flag indicates the mode of allocation appended Session-Group-Id AVPs.

   The sender of session group
      identifier.  When this flag is set, it indicates that Diameter
      server is responsible for the allocation of the session group
      identifier.  When this flag is not set, it indicates that the
      session group identifier is allocated by request can indicate to the client.

7.3.  Session-Group-Id AVP

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

   The Session-Group-Id MUST receiver how follow up
   message exchanges should be globally and eternally unique, as it is
   meant to uniquely identify performed by appending a group of Diameter sessions without
   reference to any other information.

   Unless stated otherwise, Session-Group-
   Action AVP.  If the default format of sender wants the Session-Group-id
   SHOULD comply receiver to the format recommended for perform follow up
   exchanges with a Session-Id, as defined
   in the section 8.8 of single command for all impacted groups, the RFC6733 [RFC6733].  However, sender
   sets the exact
   format value of the Session-Group-Id MAY be specified by the Diameter
   applications which make use of group signaling commands.

7.4.  Session-Group-Action AVP

   The Session-Group-Action AVP (AVP Code TBD4) is of type Unsigned32
   and contains a 32-bit address space representing values indicating
   how the peer SHOULD issue follow up exchanges in response to a
   command which impacts mulitple sessions.  The following values are
   defined by this application: ALL_GROUPS (1)
      Follow (1).  If
   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 on a message exchange
      for each impacted group. per-group basis
   in case multiple groups are identified in the group command, the
   value of the Session-Group-Action AVP is set to PER_GROUP (2).  A
   value set to PER_SESSION (3)
      Follow indicates to the receiver that all
   follow up exchanges should be performed with using a single message exchange for
   each impacted session.

8.  Result-Code AVP Values

   This document does not define new Result-Code [RFC3588] values for
   existing applications, which are extended to support group commands.
   Specification documents

   If the sender wants the receiver of new applications, which will have
   intrinsic support the request to process the
   associated command solely for a single session does not append any
   group commands, may specify new Result-Codes.

9.  IANA Considerations

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

9.1.  AVP Codes

   This specification requires IANA the
   Session-Id AVP.

4.4.2.  Receiving Group Commands

   A Diameter peer receiving a request to register process a command for a group
   of sessions identifies the following new AVPs
   from relevant groups according to the appended
   Session-Group-Id AVP Code namespace defined in [RFC3588].

   o the Session-Group-Info

   o  Session-Group-Feature-Vector

   o  Session-Group-Id

   o  Session-Group-Action

   The AVPs are defined AVP.  If the received
   request identifies multiple groups in Section 7.

10.  Security Considerations

   TODO

11.  Acknowledgments
12.  Normative References

   [RFC2119]  Bradner, S., "Key words multiple appended Session-
   Group-Id AVPs, the receiver should process the associated command for use
   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 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 RFCs the Session-Group-Info
   AVP.

4.4.3.  Error Handling for Group Commands

   When a Diameter peer receives a request to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3588]  Calhoun, P., 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 closed according to the
   procedure described in Section 4.3.

   When a Diameter peer 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, 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 case of a present stateful Proxy Agent
   between a Diameter client and a Diameter server that the Proxy Agent
   is aware of session groups and session group handling.  The Proxy
   MUST reflect the state of each session associated with a session
   group according to the result of a group command 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 deployment where the Proxy Agent utilizes session grouping
   and performing group commands with, for example, a Diameter server,
   whereas the Diameter client is not group-aware.  The same applies to
   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 the command to all
   sessions associated with the identified group(s).

6.1.  Formatting Example: Group Re-Auth-Request

   A request that 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).  The one or multiple Session-Group-Id AVP(s)
   identify the associated group(s) for which the group re-
   authentication has been requested.  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 Session-Group-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-Id ]
                    [ Session-Group-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-Feature-Vector  TBD2   Unsigned32  |    | P |      | V  |
|Session-Group-Id              TBD3   OctetString |    | P |      | V  |
|Session-Group-Action          TBD4   Unsigned32  |    | P |      | V  |
+-------------------------------------------------+----+---+------+----+

                   AVPs for the Diameter Group Signaling

7.1.  Session-Group-Info AVP

   The 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-Feature-Vector >
                             [ Session-Group-Id ]
                           * [ AVP ]

7.2.  Session-Group-Feature-Vector AVP

   The Session-Group-Feature-Vector AVP (AVP Code TBD2) is of type
   Unsigned32 and contains a 32-bit flags field of capabilities
   supported by the session-group aware node.

   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 added to the session group as identified
      by the Session-Group-Id AVP or the session's assignement 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 closed 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 the Session-Group-id MUST comply to the format
   recommended for a Session-Id, as defined in the section 8.8 of the
   [RFC6733].  The DiameterIdentity element of the Session-Group-Id MUST
   identify the Diameter node, which owns the session group.

7.4.  Session-Group-Action AVP

   The Session-Group-Action AVP (AVP Code TBD4) is of type Unsigned32
   and contains a 32-bit address space representing values indicating
   how the peer SHOULD issue follow up exchanges in response to a
   command which impacts mulitple sessions.  The following values are
   defined 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 a message exchange
      for each impacted group.

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

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 will have
   intrinsic support for group commands, may specify new Result-Codes.

9.  IANA Considerations

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

9.1.  AVP Codes

   This specification requires IANA to register the following new AVPs
   from the AVP Code namespace defined in [RFC6733].

   o  Session-Group-Info

   o  Session-Group-Feature-Vector

   o  Session-Group-Id

   o  Session-Group-Action

   The AVPs are defined in Section 7.

10.  Security Considerations

   TODO

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.

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., Guttman, E., and G. Zorn, G.,
              "Diameter Base Protocol", RFC 6733, October 2012.

Appendix A.  Session Management -- Exemplary Session State Machines

A.1.  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 additional state transitions
   related to the processing of the new 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 Diameter group command in the following tables is differentiated
   from a single-session related command by a preceding 'G'.  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
                Session-Group-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
                Session-Group-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
                Session-Group-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
                Session-Group-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
                Session-Group-Action           Send
                = PER_GROUP,                   service
                session is assigned to         specific
                received group(s) and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC4005]  Calhoun, P., Zorn, G., Spence, D.,          group
                client will perform            re-auth req
                subsequent re-auth             per group

      Open      GRAR received with             Send GRAA,   Pending
                Session-Group-Action           Send
                = PER_SESSION,                 service
                session is assigned to         specific
                received group(s) and D. Mitton,
              "Diameter Network Access          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 Application", RFC 4005,
              August 2005. 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