[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-dime-group-signaling

DIME                                                            M. Jones
Internet-Draft                                                    Amdocs
Intended status: Informational                             March 7, 2012
Expires: September 8, 2012


                        Diameter Group Signaling
              draft-jones-diameter-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 September 8, 2012.

Copyright Notice

   Copyright (c) 2012 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



Jones                   Expires September 8, 2012               [Page 1]


Internet-Draft          Diameter Group Signaling              March 2012


   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
       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
     4.1.  Session Management . . . . . . . . . . . . . . . . . . . . 10
       4.1.1.  Authorization Session State Machine  . . . . . . . . . 10
     4.2.  Commands . . . . . . . . . . . . . . . . . . . . . . . . . 14
       4.2.1.  Group-Re-Auth-Request  . . . . . . . . . . . . . . . . 14
       4.2.2.  Group-Re-Auth-Answer . . . . . . . . . . . . . . . . . 14
       4.2.3.  Group-Session-Termination-Request  . . . . . . . . . . 15
       4.2.4.  Group-Session-Termination-Answer . . . . . . . . . . . 15
       4.2.5.  Group-Abort-Session-Request  . . . . . . . . . . . . . 16
       4.2.6.  Group-Abort-Session-Answer . . . . . . . . . . . . . . 16
   5.  AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.1.  Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 18
     5.2.  Session-Group-Action AVP . . . . . . . . . . . . . . . . . 18
   6.  Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 19
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
     7.1.  Command Codes  . . . . . . . . . . . . . . . . . . . . . . 20
     7.2.  AVP Codes  . . . . . . . . . . . . . . . . . . . . . . . . 20
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 23
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24










Jones                   Expires September 8, 2012               [Page 2]


Internet-Draft          Diameter Group Signaling              March 2012


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 for grouping Diameter sessions
   and performing re-authentication, re-authorization, termination and
   abortion of groups 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.






























Jones                   Expires September 8, 2012               [Page 3]


Internet-Draft          Diameter Group Signaling              March 2012


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












































Jones                   Expires September 8, 2012               [Page 4]


Internet-Draft          Diameter Group Signaling              March 2012


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 a session to a group at session initiation, a Diameter
   client sends a service specific auth request, e.g.  NASREQ AAR
   [RFC4005], containing zero or more client-assigned group identifiers.
   Assuming the user is successfully authenticated and/or authorized,
   the Diameter server responds with service-specific auth response,
   e.g.  NASREQ AAA [RFC4005], containing both the client-assigned group
   identifiers and zero or more server-assigned group identifiers.

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



Jones                   Expires September 8, 2012               [Page 5]


Internet-Draft          Diameter Group Signaling              March 2012


   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 a server to initiate a re-
   authentication and/or re-authorization of all services that are
   assigned to one of the groups specified in the Session-Group-Id AVP
   in the request.

   An access device that receives a Group-Re-Auth-Request(GRAR) message
   with Session-Group-Id equal to one of the group assigned to a
   currently active session MUST initiate the type of re-auth specified
   by the Re-Auth-Request-Type AVP in the manner specified by the
   Session-Group-Action AVP if the service supports this particular
   feature.  Each Diameter application MUST state whether service-
   initiated group re-authentication and/or re-authorization is
   supported and which Session-Group-Action AVP values are supported for
   re-authorization.

   The Session-Group-Action AVP specifies whether the server requires a
   re-authorization request per session, per group or for all groups.
   For a Re-Auth-Request-Type value of AUTHORIZE_AUTHENTICATE, 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, the re-
   authorization is accomplished with an application-specifc group re-
   authorization command exchange.  This command exchange as well as any
   limitations on which aspects of the service can be modified during a
   re-authorization MUST be defined by the Diameter application.

   If the client is able to perform the requested re-authentication
   and/or re-authentication for the sessions assigned to the group(s)
   specified in the GRAR, it shall return a GRAA command with the
   Result-Code AVP set 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 the client is unable to perform the
   requested re-authentication and/or re-authentication, the Result-Code
   is set to DIAMETER_UNABLE_TO_COMPLY.









Jones                   Expires September 8, 2012               [Page 6]


Internet-Draft          Diameter Group Signaling              March 2012


    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 to a group named XYZ (Session-Group-
   Id=XYZ in steps 2 and 4).  Some time later, an event occurs on the
   Diameter server which requires it to change one or more of the
   service parameters for the sessions assigned to group XYZ.  The
   Diameter server sends a Group-Re-Auth-Request (step 5) specifying the
   impacted group (Session-Group-Id=XYZ) must be re-authorized (Re-Auth-
   Request-Type=AUTHORIZE_ONLY) with a single re-authorize command per
   group (Session-Group-Action=PER_GROUP).  The Diameter client
   acknowledges the request (step 6) and issues a service-specific group
   authorization request to retrieve 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 to
   the server the termination of all sessions that are assigned to one



Jones                   Expires September 8, 2012               [Page 7]


Internet-Draft          Diameter Group Signaling              March 2012


   of the groups specified in the Session-Group-Id AVP in the request.
   The termination of a group of sessions could occur as a result of a
   local action or in reponse to a request to abort one or more groups
   of sessions.

   FFS: When a client sends an GSTR to a server indicating termination
   of a specific group, is it indicating termination of the sessions
   that the server authorized and that are assigned to the specified
   group?  Or does imply termination of all sessions on the client that
   are assigned to the specified group?

   Upon receipt of the GSTR, the Diameter Server MUST release all
   resources for the sessions assigned to the group(s) specified in the
   Session-Group-Id AVP and return a GSTA with the Result-Code set to
   DIAMETER_SUCCESS to acknowledge the successful termination.  If there
   are no sessions assigned to the group(s) specified in the GSTR, the
   Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID.  If the server is
   unable to perform the session termination, the Result-Code is set to
   DIAMETER_UNABLE_TO_COMPLY.

3.5.  Aborting a Group of Sessions

   This document defines a new Group-Abort-Session-Request/Answer (GASR/
   GASA)command exchange which allows a server to request the
   termination of all sessions that are assigned to one of the groups
   specified in the Session-Group-Id AVP in the request.

   A client that receives an GASR with Session-Group-Id equal to a group
   assigned to a currently active session MAY stop the session.  Whether
   the client stops the session or not is implementation- and/or
   configuration-dependent.  For example, a client may honor GASRs from
   certain agents only.  In any case, the client MUST respond with an
   Group-Abort-Session-Answer, including a Result-Code AVP to indicate
   what action it took.

   If the client is able to perform the requested termination of the
   sessions assigned to the group(s) specified in the GASR, it shall
   return a GASA command with the Result-Code AVP set to
   DIAMETER_SUCCESS and Session-Group-Id AVP(s) indicating the groups
   for which the GASR receiver has active sessions assigned.  If there
   are no sessions 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 of the sessions,
   the Result-Code is set to DIAMETER_UNABLE_TO_COMPLY.

   When a client terminates a session upon receipt of a Group-Abort-
   Session-Request, it MUST issue a session termination request to the
   Diameter server that authorized the service.  The Session-Group-



Jones                   Expires September 8, 2012               [Page 8]


Internet-Draft          Diameter Group Signaling              March 2012


   Action AVP specifies whether 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 group named XYZ (Session-Group-
   Id=XYZ in steps 2 and 4).  Some time later, an event occurs on the
   Diameter server 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 the impacted group
   (Session-Group-Id=XYZ) are to be terminated and a single termination
   command is to be sent per impacted group (Session-Group-
   Action=PER_GROUP).  The Diameter client acknowledges the request with
   a GASA (step 6) and issues a GSTR (step 7) command to release all
   resources for the sessions assigned to the group XYZ.  The Diameter
   server acknowledges the termination with a GGSTA (Step 8).





Jones                   Expires September 8, 2012               [Page 9]


Internet-Draft          Diameter Group Signaling              March 2012


4.  Protocol Description

4.1.  Session Management

4.1.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,



Jones                   Expires September 8, 2012              [Page 10]


Internet-Draft          Diameter Group Signaling              March 2012


                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,



Jones                   Expires September 8, 2012              [Page 11]


Internet-Draft          Diameter Group Signaling              March 2012


                                               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.




































Jones                   Expires September 8, 2012              [Page 12]


Internet-Draft          Diameter Group Signaling              March 2012


                                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





Jones                   Expires September 8, 2012              [Page 13]


Internet-Draft          Diameter Group Signaling              March 2012


4.2.  Commands

   This specification extends 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 the message flags' 'R' bit set, may be sent by any server
   to the access device that is providing session service, to 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.

















Jones                   Expires September 8, 2012              [Page 14]


Internet-Draft          Diameter Group Signaling              March 2012


         <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, is sent
   by the access device to inform the Diameter Server that one or more
   groups of authenticated and/or authorized sessions are being
   terminated.


         <GSTR>  ::= < Diameter Header: TBD, REQ, PXY >
                   * { 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

   The Group-Session-Termination-Answer (GSTA), indicated by the
   Command-Code set to TBD and the message flags' 'R' bit clear, is sent
   by the Diameter Server to acknowledge the notification that one or
   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 the GSTR.





Jones                   Expires September 8, 2012              [Page 15]


Internet-Draft          Diameter Group Signaling              March 2012


         <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 the Command-Code
   set to TBD and the message flags' 'R' bit set, may be sent by any
   server to the access device that is providing session service, to
   request that the sessions identified by the Session-Group-Id be
   stopped.


         <GASR>  ::= < Diameter Header: TBD, REQ, PXY >
                   * { Session-Group-Id }
                     { Origin-Host }
                     { Origin-Realm }
                     { Destination-Realm }
                     { Destination-Host }
                     { Auth-Application-Id }
                     [ 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.







Jones                   Expires September 8, 2012              [Page 16]


Internet-Draft          Diameter Group Signaling              March 2012


         <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 ]
                   * [ AVP ]





































Jones                   Expires September 8, 2012              [Page 17]


Internet-Draft          Diameter Group Signaling              March 2012


5.  AVPs


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











Jones                   Expires September 8, 2012              [Page 18]


Internet-Draft          Diameter Group Signaling              March 2012


6.  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.]











































Jones                   Expires September 8, 2012              [Page 19]


Internet-Draft          Diameter Group Signaling              March 2012


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






















Jones                   Expires September 8, 2012              [Page 20]


Internet-Draft          Diameter Group Signaling              March 2012


8.  Security Considerations

   TODO
















































Jones                   Expires September 8, 2012              [Page 21]


Internet-Draft          Diameter Group Signaling              March 2012


9.  Acknowledgments


















































Jones                   Expires September 8, 2012              [Page 22]


Internet-Draft          Diameter Group Signaling              March 2012


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








































Jones                   Expires September 8, 2012              [Page 23]


Internet-Draft          Diameter Group Signaling              March 2012


Author's Address

   Mark Jones
   Amdocs

   Email: mark@azu.ca













































Jones                   Expires September 8, 2012              [Page 24]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/