Diameter Maintenance and Extensions                                        M. Jones
Extensions (DIME)                                                     June 22, 2012                                             M. Liebsch
Internet-Draft                                                 L. Morand
Intended status: Standards Track                           July 15, 2013
Expires: December 24, 2012 January 16, 2014

                        Diameter Group Signaling
                 draft-ietf-dime-group-signaling-00.txt
                 draft-ietf-dime-group-signaling-01.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 December 24, 2012. January 16, 2014.

Copyright Notice

   Copyright (c) 2012 2013 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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Grouping User Sessions . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Group assignment at session initiation . . . . . . . . . .  5
     3.2.  Mid-session group assignment modifications . . . . . . . .  5
       3.2.1.  Client-initiated group assignment changes  . . . . . .  5  6
       3.2.2.  Server-initiated group assignment changes  . . . . . .  5
     3.3.  Server Initiated Group Re-auth . . . . . . . . . . . . . .  6
     3.4.  Session Group Termination  . . . . . . . . . . . . . . . .  7
     3.5.  Aborting a Group of Sessions . . . . . . . . . . . . . . .  8
   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . . 10  7
     4.1.  Session Management . . . . . . . . . . Grouping and implicit Capability Discovery . . . .  7
     4.2.  Performing Group Operations  . . . . . . 10
       4.1.1.  Authorization Session State Machine . . . . . . . . . 10
     4.2.  8
       4.2.1.  Sending Group Commands . . . . . . . . . . . . . . . .  8
       4.2.2.  Receiving Group Commands . . . . . . . . . 14
       4.2.1.  Group-Re-Auth-Request  . . . . . . . . . .  8
       4.2.3.  Single-Session Fallback  . . . . . . 14
       4.2.2.  Group-Re-Auth-Answer . . . . . . . . .  9
     4.3.  Session Management . . . . . . . . 14
       4.2.3.  Group-Session-Termination-Request . . . . . . . . . . 15
       4.2.4.  Group-Session-Termination-Answer . .  9
       4.3.1.  Authorization Session State Machine  . . . . . . . . . 15
       4.2.5.  Group-Abort-Session-Request  9
   5.  Commands Formatting  . . . . . . . . . . . . . 16
       4.2.6.  Group-Abort-Session-Answer . . . . . . . . 13
     5.1.  Group Re-Auth-Request  . . . . . . 16
   5.  AVPs . . . . . . . . . . . . 13
   6.  Attribute-Value-Pairs (AVP)  . . . . . . . . . . . . . . . . . 18
     5.1. 14
     6.1.  Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 18
     5.2. 14
     6.2.  Session-Group-Action AVP . . . . . . . . . . . . . . . . . 18
   6. 14
   7.  Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 19
   7. 15
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
     7.1.  Command Codes  . . . . . . . . . . . . . . . . . . . . . . 20
     7.2. 16
     8.1.  AVP Codes  . . . . . . . . . . . . . . . . . . . . . . . . 20
   8. 16
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   9. 17
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   10. 18
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 23
   Author's Address . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 20

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 a mechanism mechanisms for grouping Diameter sessions and
   applying Diameter commands, such as performing re-authentication, re-authorization, re-
   authorization, termination and abortion of groups 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].

3.  Grouping User Sessions

   Either Diameter peer may assign a session to a group.  Diameter AAA
   applications typically assign client and server roles to the Diameter
   peers.  In this document, a Diameter client is a node at the edge of
   the network that performs access control.  A Diameter server is a
   node that performs authentication and/or authorization of the user.

3.1.  Group assignment at session initiation

   To assign

   Assignment of a new session to a group at session initiation, a is accomplished by the
   Diameter
   client sends a service specific auth request, e.g. server when requested by the Diameter client.  Without being
   explicitly requested by the client, the Diameter server can assign a
   new session to a server-assigned group based on its own decision.
   When a new session is to be assigned to a group by the Diameter
   server, the server assigns a new session to at least one server-
   assigned group.  To complement server-assigned grouping, a Diameter
   client can assign a session to a client-assigned group.

   To assign a session to a group at session initiation, a Diameter
   client sends a service specific request, e.g.  NASREQ AAR [RFC4005],
   containing zero one or more client-assigned group identifiers.  The Diameter client can
   assign the session to a client-assigned group and identify the
   associated group with an appended client-assigned group identifier.
   The client can append multiple client-assigned group identifiers if
   the client assigns the new session to more than one group.  If the
   Diameter client does not send a client-assigned group identifier, the
   client may receive one or multiple server-assigned group identifiers
   in the server's response, which identify the server-assigned groups
   to which the new session has been assigned.  The Diameter client can
   explicitly request the Diameter server to perform grouping of the new
   session.

   Assuming the user is has been successfully authenticated and/or
   authorized, the Diameter server responds with service-specific auth
   response, e.g.  NASREQ AAA [RFC4005], containing both the client-assigned client-
   assigned group identifiers (if sent with the request) and zero 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.

3.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 a permission model that limits removal
   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.  For example, an application could require that the server
   MUST NOT remove a session from a group assigned by the client.

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

3.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 the
   updated list of group identifiers.

3.3.  Server Initiated Group Re-auth

   This document defines a new Group-Re-Auth-Request/Answer (GRAR/
   GRAA)command exchange which allows

4.  Protocol Description

4.1.  Session Grouping and implicit Capability Discovery

   Either Diameter peer, a server to Diameter client or server, can initiate
   assigning a re-
   authentication and/or re-authorization of all services that are
   assigned session to one of the a single or multiple session groups specified in according
   to the Session-Group-Id AVP procedure described in the request.

   An access device that receives a Group-Re-Auth-Request(GRAR) message
   with Session-Group-Id equal to one Section 3.  Modification of the a group assigned to by
   removing or adding a
   currently active single or multiple user sessions can be
   initiated and performed at runtime by either Diameter peer.

   A Diameter client as sender of a command for session MUST initiate initiation can
   determine one or multiple groups to which the type new session should be
   assigned.  Each of re-auth specified
   by the Re-Auth-Request-Type AVP these groups need to be identified in the manner a separate
   Session-Group-Id AVP as specified by the
   Session-Group-Action in Section 6.  In each appended
   Session-Group-Id AVP if which carries a client-assigned group
   identifier, a flag must indicate that the service supports this particular
   feature.  Each Diameter application MUST state whether service-
   initiated carried group re-authentication and/or re-authorization identifier is
   supported and which Session-Group-Action AVP values are supported for
   re-authorization.

   The Session-Group-Action AVP specifies whether the server requires
   not a
   re-authorization request per session, per group or for all groups.
   For server-assigned but a Re-Auth-Request-Type value of AUTHORIZE_AUTHENTICATE, client-assigned one.  If the
   Session-Group-Action value MUST be PER_SESSION since re-
   authentication MUST be performed per user session.

   For Session-Group-Action values of PER_GROUP or ALL_GROUPS, Diameter
   client does not determine the re-
   authorization is accomplished with an application-specifc group re-
   authorization command exchange.  This command exchange as well as any
   limitations on to which aspects of the service can new session should
   be modified during assigned, the client can set a
   re-authorization MUST be defined by flag in an appended
   Session-Group-Id AVP to explicitly request the Diameter application.

   If server as
   recipient of the client is able message to perform assign the requested re-authentication
   and/or re-authentication for new session to one or multiple
   groups.

   By appending at least one Session-Group-Id AVP, the sessions assigned Diameter client
   announces its capability to support group operations according to the group(s)
   specified
   specification in the GRAR, it shall return a GRAA command with the
   Result-Code AVP set this document to DIAMETER_SUCCESS and Session-Group-Id AVP(s)
   indicating the groups for which the GRAR receiver has active sessions
   assigned.  If there are no sessions assigned to the group(s)
   specified in the GRAR, the Result-Code is set to
   DIAMETER_UNKNOWN_SESSION_ID.  If addressed Diameter server.  If
   the Diameter client is unable to perform the
   requested re-authentication and/or re-authentication, the Result-Code
   is set supports group operations, it MUST append at
   least one Session-Group-Id AVP to DIAMETER_UNABLE_TO_COMPLY.

    Diameter                                               Diameter
     Client                                                 Server
       |                                                      |
    (1)+-------------Svc-Specific-Auth-Request--------------->|
       |                  Session-Id=ABC                      |
       |                                                      |
    (2)|<------------Svc-Specific-Auth-Answer-----------------+
       |       Session-Id=ABC; Session-Group-Id=XYZ           |
       |                                                      |
    (3)+-------------Svc-Specific-Auth-Request--------------->|
       |                  Session-Id=DEF                      |
       |                                                      |
    (4)|<------------Svc-Specific-Auth-Answer-----------------+
       |       Session-Id=DEF; Session-Group-Id=XYZ           |
       |                                                      |
    (5)|<--------------Group-Re-Auth-Request------------------+
       | Session-Group-Id=XYZ; Session-Group-Action=PER_GROUP |
       |        Re-Auth_Request-Type=AUTHORIZE_ONLY           |
       |                                                      |
    (6)+---------------Group-Re-Auth-Answer------------------>|
       |                                                      |
    (7)+----------Svc-Specific-Group-Auth-Request------------>|
       |                Session-Group-Id=XYZ                  |
       |                                                      |
    (8)|<---------Svc-Specific-Group-Auth-Answer--------------+
       |           Updated Service Specific AVPs              |
       |                                                      |

                 Figure 1: Example: Group Re-authorization

   In the example above, the Diameter server authorizes two sessions
   (ABC and DEF) and assigns them announce its capability to a support
   group named XYZ (Session-Group-
   Id=XYZ in steps 2 and 4).  Some time later, an event occurs on the operations.

   A Diameter server receiving a command for session initiation which requires it to change
   includes at least one or more of the
   service parameters for Session-Group-Id AVP learns about the sessions assigned sender's
   capability to support group XYZ.  The
   Diameter server sends operations.  If a flag in the appended
   Session-Group-Id AVPs identifies a Group-Re-Auth-Request (step 5) specifying client-assigned group, the
   impacted group (Session-Group-Id=XYZ) server
   must be re-authorized (Re-Auth-
   Request-Type=AUTHORIZE_ONLY) store the one or multiple identifiers and associate the new
   session with these groups.

   If a single re-authorize command per
   group (Session-Group-Action=PER_GROUP).  The flag in a received Session-Group-Id AVP indicates that the
   Diameter client
   acknowledges explicitly requests the request (step 6) and issues a service-specific group
   authorization request Diameter server to retrieve assign the updated service parameters
   (step 7).

3.4.  Session Group Termination

   This document defines a
   new Group-Session-Termination-Request/Answer
   (GSTR/GSTA) command exchange which allows a client to communicate session to a server-assigned group, the Diameter server should
   assign the termination of all sessions that are assigned new session to one or multiple groups.  The Diameter
   server identifies each of the these server-assigned groups specified in a Session-
   Group-Id AVP, which are appended to the response to the received
   command.  Each of these Session-Group-Id AVP AVPs must indicate in a flag
   that the request.
   The termination of carried identifier is a server-assigned group of sessions could occur as a result of identifier.

   If a
   local action or flag in reponse to a request to abort one or more groups
   of sessions.

   FFS: When a received Session-Group-Id AVP indicates that the
   Diameter client sends an GSTR to a does not explicitly request the Diameter server indicating termination
   of to
   assign the new session to a specific server-assigned group, is it indicating termination of the sessions
   that Diameter
   server may assign the new session to one or multiple groups.  The
   Diameter server authorized and that identifies each of these server-assigned groups in a
   Session-Group-Id AVP, which are assigned appended to the specified
   group?  Or does imply termination of all sessions on the client that
   are assigned response to the specified group?

   Upon receipt
   received command.  Each of these Session-Group-Id AVPs must indicate
   in a flag that the GSTR, carried identifier is a server-assigned group
   identifier.

   By appending at least one Session-Group-Id AVP, the Diameter Server MUST release all
   resources for the sessions assigned server
   announces its capability to support group operations according to the group(s) specified
   specification in this document to the addressed Diameter client.

   A Diameter server receiving a command for session initiation which
   includes at least one Session-Group-Id AVP and return a GSTA with but the Result-Code set to
   DIAMETER_SUCCESS to acknowledge server does not
   understand the successful termination.  If there
   are no sessions assigned semantics of this optional AVP because it does not
   support group operations according to the group(s) specified specification in this
   document, MUST ignore the GSTR, optional group operations specific AVPs and
   proceed with processing the
   Result-Code is set command for a single session.

   A Diameter client, which sent a request for session initiation to DIAMETER_UNKNOWN_SESSION_ID.  If the a
   Diameter server is
   unable to perform and appended a single or multiple Session-Group-Id
   AVPs but cannot find any Session-Group-Id AVP in the session termination, associated
   response from the Result-Code is set to
   DIAMETER_UNABLE_TO_COMPLY.

3.5.  Aborting a Group of Sessions

   This document defines Diameter server proceeds with processing the
   command for a new Group-Abort-Session-Request/Answer (GASR/
   GASA)command exchange which allows single session.  Furthermore, the client keeps a log to
   remember that the server is not able to perform group operations.

4.2.  Performing Group Operations

4.2.1.  Sending Group Commands

   Either Diameter peer can request the
   termination recipient of a request to
   process an associated command for all sessions that are being assigned to one of the
   or multiple groups by identifying these groups
   specified in the request.  The
   sender of the request appends for each group, to which the command
   applies, a Session-Group-Id AVP and indicates in a flag whether the request.

   A client that receives an GASR with Session-Group-Id equal to
   identifier represents a group
   assigned to server- or a currently active session MAY stop the session.  Whether client-assigned group.  If the client stops
   CCF of the session or not is implementation- and/or
   configuration-dependent.  For example, request mandates a client may honor GASRs from
   certain agents only.  In any case, Session-Id AVP, the client Session-Id AVP MUST respond with an
   Group-Abort-Session-Answer, including
   identify a Result-Code AVP single session which is assigned to indicate
   what action it took. at least one of the
   groups being identified in the appended Session-Group-Id AVPs.  If
   the client is able to perform sender wants the requested termination receiver of the
   sessions assigned request to process the group(s) specified
   associated command solely for a single session does not append any
   group identifier, but identifies the relevant session in the GASR, it shall
   return
   Session-Id AVP.

4.2.2.  Receiving Group Commands

   A Diameter peer receiving a request to process a GASA command with for a group
   of sessions identifies the Result-Code AVP set relevant groups according to
   DIAMETER_SUCCESS and the appended
   Session-Group-Id AVP(s) indicating AVP.  If the received request identifies multiple
   groups
   for which in multiple appended Session-Group-Id AVPs, the GASR receiver
   should process the associated command for each of these groups. if a
   session has active sessions assigned.  If there
   are no sessions been assigned to the group(s) specified in the GASR, the
   Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID.  If the client is
   unable to perform the requested termination for any more than one of the sessions, identified groups,
   the Result-Code is set to DIAMETER_UNABLE_TO_COMPLY.

   When receiver must process the associated command only once per
   session.

4.2.3.  Single-Session Fallback

   Either Diameter peer, a Diameter client terminates a session upon receipt of a Group-Abort-
   Session-Request, it MUST issue or a Diameter server, can
   fall back to single session termination request operation by ignoring and omitting the
   optional and group session-specific AVPs.  Fallback to single-session
   operation is performed by processing the Diameter server that authorized command solely for
   the service. session identified in the mandatory Session-Id AVP.  The Session-Group-
   Action AVP specifies whether response
   to the server requires a single session
   termination request per session (with STR message), per group (with
   GSTR message) or for all groups (with GSTR message).

    Diameter                                               Diameter
     Client                                                 Server
       |                                                      |
    (1)+-------------Svc-Specific-Auth-Request--------------->|
       |                  Session-Id=ABC                      |
       |                                                      |
    (2)|<------------Svc-Specific-Auth-Answer-----------------+
       |       Session-Id=ABC; Session-Group-Id=XYZ           |
       |                                                      |
    (3)+-------------Svc-Specific-Auth-Request--------------->|
       |                  Session-Id=DEF                      |
       |                                                      |
    (4)|<------------Svc-Specific-Auth-Answer-----------------+
       |       Session-Id=DEF; Session-Group-Id=XYZ           |
       |                                                      |
    (5)|<-----------Group-Abort-Session-Request---------------+
       | Session-Group-Id=XYZ; Session-Group-Action=PER_GROUP |
       |                                                      |
    (6)+------------Group-Abort-Session-Answer--------------->|
       |                                                      |
    (7)+---------Group-Session-Termination-Request----------->|
       |                Session-Group-Id=XYZ                  |
       |                                                      |
    (8)|<---------Group-Session-Termination-Answer------------+
       |                                                      |

              Figure 2: Example: Aborting a Group of Sessions

   In the example above, the Diameter server authorizes two sessions
   (ABC and DEF) and assigns them to a command must not identify any group named XYZ (Session-Group-
   Id=XYZ in steps 2 and 4).  Some time later, an event occurs on but identify solely
   the
   Diameter server single session for which requires it to abort the sessions assigned to
   group XYZ.  The Diameter server sends a Group-Abort-Session-Request
   (step 5) specifying the sessions assigned to command has been processed.

4.3.  Session Management

   Editor's note: This first document revision adopts the impacted group
   (Session-Group-Id=XYZ) are to WG's current
   view on how Diameter commands can be terminated and a single termination
   command is formatted to be sent per impacted enable group (Session-Group-
   Action=PER_GROUP).
   signaling.  The Diameter client acknowledges required change in the request with
   a GASA (step 6) formatting and issues a GSTR (step 7) command to release all
   resources for protocol
   operation has not yet been considered in this Section 4.3 , which
   still reflects the sessions assigned formatting as per version 0 of this specification.
   The described session state machines still need revision to reflect
   the group XYZ.  The Diameter
   server acknowledges generalized formatting and the termination with a GGSTA (Step 8).

4.  Protocol Description

4.1.  Session Management

4.1.1. adopted protocol operation.

4.3.1.  Authorization Session State Machine

   Section 8.1 in [RFC3588] 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 [RFC3588] in which the server is maintaining session
   state are relevant in this document.  As in [RFC3588], 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 [RFC3588] are not repeated here.

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

4.2.

5.  Commands

   Editor's Note: The content of this section Formatting

   This document does not represent working specify new Diameter commands to enable group consensus
   operations, but rather relies on command extensibility capability provided
   by the views of Diameter Base protocol.  This section provides the draft author prior guidelines
   to
   (and post) adoption.  Alternative methods for manipulating groups extend the CCF of
   sessions are being considered by existing Diameter commands with optional AVPs to
   enable the working group and this section
   may be heavily modified or removed in subsequent versions.

   This specification extends recipient of the existing RAR, RAA, STR, STA, ASR and
   ASA command ABNFs.

4.2.1.  Group-Re-Auth-Request

   The Group-Re-Auth-Request (GRAR), indicated by the Command-Code set to TBD and perform the message flags' 'R' bit set, may be sent by any server command to all
   sessions associated with the access device that is providing session service, to identified group(s).

5.1.  Group Re-Auth-Request

   A request that one or more groups of users be re-authenticated and/or re-
   authorized.

         <GRAR>  ::= < Diameter Header: TBD, REQ, PXY >
                   * { Session-Group-Id }
                     { Origin-Host }
                     { Origin-Realm }
                     { Destination-Realm }
                     { Destination-Host }
                     { Auth-Application-Id }
                     { Re-Auth-Request-Type }
                     [ Origin-State-Id ]
                   * [ Proxy-Info ]
                   * [ Route-Record ]
                     [ Session-Group-Action ]
                   * [ AVP ]

4.2.2.  Group-Re-Auth-Answer

   The Group-Re-Auth-Answer (GRAA), indicated by the Command-Code set to
   TBD and the message flags' 'R' bit clear, is sent in response to the
   GRAR.  The Result-Code AVP MUST be present, and indicates the
   disposition of the request.

         <GRAA>  ::= < Diameter Header: TBD, PXY >
                   * { Session-Group-Id }
                     { Result-Code }
                     { Origin-Host }
                     { Origin-Realm }
                     [ Origin-State-Id ]
                     [ Error-Message ]
                     [ Error-Reporting-Host ]
                   * [ Failed-AVP ]
                   * [ Redirect-Host ]
                     [ Redirect-Host-Usage ]
                     [ Redirect-Host-Cache-Time ]
                   * [ Proxy-Info ]
                   * [ AVP ]

4.2.3.  Group-Session-Termination-Request

   The Group-Session-Termination-Request (GSTR), indicated by the
   Command-Code set to TBD and the Command Flags' 'R' bit set, are re-authentication is sent
   issues by the access device appending one or multiple Session-Group-Id AVP(s) to inform the Diameter Server that
   Re-Auth-Request (RAR).  The one or more
   groups of authenticated and/or authorized sessions are being
   terminated.

         <GSTR>  ::= < Diameter Header: TBD, REQ, PXY >
                   * { multiple Session-Group-Id }
                     { Origin-Host }
                     { Origin-Realm }
                     { Destination-Realm }
                     { Auth-Application-Id }
                     { Termination-Cause }
                     [ Destination-Host ]
                   * [ Class ]
                     [ Origin-State-Id ]
                   * [ Proxy-Info ]
                   * [ Route-Record ]
                   * [ AVP ]

4.2.4.  Group-Session-Termination-Answer AVP(s)
   identify the associated group(s) for which the group re-
   authentication has been requested.  The Group-Session-Termination-Answer (GSTA), indicated by recipient of the group
   command initiates re-authentication for all users associated with the
   Command-Code set to TBD and
   identified group(s).  Furthermore, the message flags' 'R' bit clear, is sent
   by sender of the Diameter Server group re-
   authentication request appends a Session-Group-Action AVP to acknowledge the notification that one or provide
   more groups of session have been terminated.  The Result-Code AVP
   MUST be present, and MAY contain an indication that an error occurred
   while servicing information to the GSTR.

         <GSTA>  ::= < Diameter Header: TBD, PXY >
                   * { Session-Group-Id }
                     { Result-Code }
                     { Origin-Host }
                     { Origin-Realm }
                   * [ Class ]
                     [ Error-Message ]
                     [ Error-Reporting-Host ]
                   * [ Failed-AVP ]
                     [ Origin-State-Id ]
                   * [ Redirect-Host ]
                     [ Redirect-Host-Usage ]
                     [ Redirect-Max-Cache-Time ]
                   * [ Proxy-Info ]
                   * [ AVP ]

4.2.5.  Group-Abort-Session-Request

   The Group-Abort-Session-Request (GASR), indicated by receiver of the Command-Code
   set command about how to TBD and
   accomplish the message flags' 'R' bit set, may be sent by any
   server to group operation.

   The value of the access device that is providing mandatory Session-Id AVP MUST identify a session service,
   associated with a single user, which is assigned to
   request that at least one of
   the sessions groups being identified by in the appended Session-Group-Id be
   stopped.

         <GASR> AVPs.

         <RAR>  ::= < Diameter Header: TBD, 258, REQ, PXY >
                   * { Session-Group-Id }
                    < 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 ]
                     [ Group-Action ]
                  * [ AVP ]

4.2.6.  Group-Abort-Session-Answer

   The Group-Abort-Session-Answer (GASA), indicated by the Command-Code
   set to TBD and the message flags' 'R' bit clear, is sent in response
   to the GASR.  The Result-Code AVP MUST be present, and indicates the
   disposition of the request.

         <GASA>  ::= < Diameter Header: TBD, PXY >
                   * { Session-Group-Id }
                     { Result-Code }
                     { Origin-Host }
                     { Origin-Realm }
                     [ Origin-State-Id ]
                     [ Error-Message ]
                     [ Error-Reporting-Host ]
                   * [ Failed-AVP ]
                   * [ Redirect-Host ]
                     [ Redirect-Host-Usage ]
                     [ Redirect-Max-Cache-Time ]
                   *
                    [ Proxy-Info Session-Group-Action ]
                  * [ AVP ]

5.  AVPs

6.  Attribute-Value-Pairs (AVP)

                                           +--------------------+
                                           |   AVP Flag rules   |
                                           +----+---+------+----+
                         AVP               |    |   |SHOULD|MUST|
    Attribute Name       Code  Value Type  |MUST|MAY| NOT  | NOT|
   +---------------------------------------+----+---+------+----+
   |Session-Group-Id     TBD   OctetString |    | P |      | V  |
   |Session-Group-Action TBD   Enumerated  |    | P |      | V  |
   +---------------------------------------+----+---+------+----+

                   AVPs for the Diameter Group Signaling

5.1.

6.1.  Session-Group-Id AVP

   The Session-Group-Id AVP (AVP Code TBD) is of type OctetString and
   identifies a group of sessions.  This uniqueness scope of this AVP is
   specified by the Diameter application which makes use of group
   signaling commands.

5.2.

6.2.  Session-Group-Action AVP

   The Session-Group-Action AVP (AVP Code TBD) is of type Enumerated and
   specifies how the peer SHOULD issue follow up exchanges in response
   to a command which impacts mulitple sessions.  The following values
   are supported:

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

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

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

6.

7.  Result-Code AVP Values

   This section defines new Result-Code [RFC3588] values that MUST be
   supported by all Diameter implementations that conform to this
   specification.

   [Editor's Note: Group specific error values may need to be added
   here.]

7.

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

7.1.  Command Codes

   This specification requires IANA to register the following new
   Commands from the Command Code namespace defined in [RFC3588].

   o  Group-Re-Auth-Request/Answer

   o  Group-Session-Termination-Request/Answer

   o  Group-Abort-Session-Request/Answer

   The commands are defined in Section 4.2.

7.2.

8.1.  AVP Codes

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

   o  Session-Group-Id

   o  Session-Group-Action

   The AVPs are defined in Section 5.

8. 6.

9.  Security Considerations

   TODO

9.  Acknowledgments

10.  Acknowledgments
11.  Normative References

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

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

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

Author's Address

Authors' Addresses

   Mark Jones

   Email: mark@azu.ca

   Marco Liebsch

   Email: marco.liebsch@neclab.eu

   Lionel Morand

   Email: lionel.morand@orange.com