wdiff draft-ietf-dime-group-signaling-00.txt draft-ietf-dime-group-signaling-01.txt

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.

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,

3.1. Group assignment at session initiation

Assignment of a Diameter client is new session to a node at group is accomplished by the edge of
Diameter server when requested by the Diameter client. Without being
explicitly requested by the client, the network that performs access control. A 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
node that performs authentication and/or authorization of group by the user.

3.1. Group assignment 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 initiation to a client-assigned group.

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 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 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 carries a
re-authorization request per session, per client-assigned group or for all groups.
For
identifier, 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, flag must indicate that the re-
authorization is accomplished with an application-specifc carried group re-
authorization command exchange. This command exchange as well as any
limitations on which aspects of the service can be modified during identifier is
not a
re-authorization MUST be defined by the Diameter application. server-assigned but a client-assigned one. If the Diameter
client is able to perform the requested re-authentication
and/or re-authentication for does not determine the sessions assigned group to which the group(s)
specified in new session should
be assigned, the GRAR, it shall return client can set a GRAA command with the
Result-Code flag in an appended
Session-Group-Id AVP set to DIAMETER_SUCCESS and Session-Group-Id AVP(s)
indicating explicitly request the groups for which Diameter server as
recipient of the GRAR receiver has active sessions
assigned. If there are no sessions assigned message to assign the group(s)
specified in the GRAR, the Result-Code is set new session to
DIAMETER_UNKNOWN_SESSION_ID. If one or multiple
groups.

By appending at least one Session-Group-Id AVP, the Diameter client is unable
announces its capability to support group operations according to perform the
requested re-authentication and/or re-authentication, the Result-Code
is set
specification in this document to DIAMETER_UNABLE_TO_COMPLY.

Figure 1: Example: Group Re-authorization

In the example above, addressed Diameter server. If
the Diameter server authorizes two sessions
(ABC and DEF) and assigns them client supports group operations, it MUST append at
least one Session-Group-Id AVP to a announce its capability to 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 Group-Re-Auth-Request (step 5) specifying flag in the
impacted group (Session-Group-Id=XYZ) appended
Session-Group-Id AVPs identifies a client-assigned group, the 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 received Session-Group-Id AVP indicates that the
Diameter client does not explicitly request the Diameter server to abort one or more groups
of sessions.

FFS: When a client sends an GSTR
assign the new session to a server indicating termination
of 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 GASA command with the Result-Code AVP set request to
DIAMETER_SUCCESS and Session-Group-Id AVP(s) indicating process a command for a group
of sessions identifies the relevant groups
for which according to the GASR receiver has active sessions assigned. appended
Session-Group-Id AVP. If there
are no sessions assigned to the group(s) specified received request identifies multiple
groups in multiple appended Session-Group-Id AVPs, the GASR, the
Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the client is
unable to perform receiver
should process the requested termination associated command for any of the sessions,
the Result-Code is set to DIAMETER_UNABLE_TO_COMPLY.

When a client terminates a session upon receipt each of a Group-Abort-
Session-Request, it MUST issue these groups. if a
session termination request has been assigned to more than one of the
Diameter server that authorized identified groups,
the service. The Session-Group-
Action AVP specifies whether receiver must process the server requires a single session
termination request per session (with STR message), associated command only once per group (with
GSTR message) or for all groups (with GSTR message).
session.

4.2.3. Single-Session Fallback

Figure 2: Example: Aborting client or a Group of Sessions

In the example above, the Diameter server authorizes two sessions
(ABC server, can
fall back to single session operation by ignoring and DEF) omitting the
optional 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 session-specific AVPs. Fallback to abort single-session
operation is performed by processing the sessions assigned to
group XYZ. The Diameter server sends a Group-Abort-Session-Request
(step 5) specifying command solely for
the sessions assigned session identified in the mandatory Session-Id AVP. The response
to the impacted group
(Session-Group-Id=XYZ) are to be terminated and a command must not identify any group but identify solely
the single termination session for which the command is to has been processed.

4.3. Session Management

Editor's note: This first document revision adopts the WG's current
view on how Diameter commands can be sent per impacted formatted to 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, are re-authentication is sent in response
issues by appending one or multiple Session-Group-Id AVP(s) to the
GRAR.
Re-Auth-Request (RAR). The Result-Code AVP MUST be present, and indicates one or multiple Session-Group-Id AVP(s)
identify the
disposition of associated group(s) for which 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 group re-
authentication has been requested. The Group-Session-Termination-Request (GSTR), indicated by the
Command-Code set to TBD and recipient of the Command Flags' 'R' bit set, is sent
by group
command initiates re-authentication for all users associated with the access device to inform
identified group(s). Furthermore, the Diameter Server that one or more
groups sender 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 group re-
authentication request appends a Session-Group-Action AVP to TBD and the message flags' 'R' bit clear, is sent
by the Diameter Server provide
more information to acknowledge the notification that one or
more groups receiver 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.

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

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

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