< draft-ietf-dime-group-signaling-04.txt   draft-ietf-dime-group-signaling-05.txt >
Diameter Maintenance and Extensions (DIME) M. Jones Diameter Maintenance and Extensions (DIME) M. Jones
Internet-Draft Internet-Draft
Intended status: Standards Track M. Liebsch Intended status: Standards Track M. Liebsch
Expires: January 5, 2015 Expires: January 7, 2016
L. Morand L. Morand
July 6, 2015
July 4, 2014
Diameter Group Signaling Diameter Group Signaling
draft-ietf-dime-group-signaling-04.txt draft-ietf-dime-group-signaling-05.txt
Abstract Abstract
In large network deployments, a single Diameter peer can support over In large network deployments, a single Diameter node can support over
a million concurrent Diameter sessions. Recent use cases have a million concurrent Diameter sessions. Recent use cases have
revealed the need for Diameter peers to apply the same operation to a revealed the need for Diameter nodes to apply the same operation to a
large group of Diameter sessions concurrently. The Diameter base large group of Diameter sessions concurrently. The Diameter base
protocol commands operate on a single session so these use cases protocol commands operate on a single session so these use cases
could result in many thousands of command exchanges to enforce the could result in many thousands of command exchanges to enforce the
same operation on each session in the group. In order to reduce same operation on each session in the group. In order to reduce
signaling, it would be desirable to enable bulk operations on all (or 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 part of) the sessions managed by a Diameter node using a single or a
few command exchanges. This document specifies the Diameter protocol few command exchanges. This document specifies the Diameter protocol
extensions to achieve this signaling optimization. extensions to achieve this signaling optimization.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Building and Modifying Session Groups . . . . . . . . . . 4 3.1. Building and Modifying Session Groups . . . . . . . . . . 4
3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4
3.3. Permission Considerations . . . . . . . . . . . . . . . . 4 3.3. Permission Considerations . . . . . . . . . . . . . . . . 4
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
4.1. Session Grouping . . . . . . . . . . . . . . . . . . . . 6 4.1. Session Grouping Capability Discovery . . . . . . . . . . 7
4.1.1. Group assignment at session initiation . . . . . . . 7 4.1.1. Explicit Capability Discovery . . . . . . . . . . . . 7
4.1.2. Removing a session from a session group . . . . . . . 8 4.1.2. Implicit Capability Discovery . . . . . . . . . . . . 7
4.1.3. Mid-session group assignment modifications . . . . . 9 4.2. Session Grouping . . . . . . . . . . . . . . . . . . . . 7
4.2. Session Grouping Capability Discovery . . . . . . . . . . 10 4.2.1. Group assignment at session initiation . . . . . . . 8
4.2.1. Explicit Capability Discovery . . . . . . . . . . . . 10 4.2.2. Removing a session from a session group . . . . . . . 10
4.2.2. Implicit Capability Discovery . . . . . . . . . . . . 11 4.2.3. Mid-session group assignment modifications . . . . . 11
4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 11 4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 12
4.4. Performing Group Operations . . . . . . . . . . . . . . . 11 4.4. Performing Group Operations . . . . . . . . . . . . . . . 12
4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 11 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 12
4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 12 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 13
4.4.3. Error Handling for Group Commands . . . . . . . . . . 12 4.4.3. Error Handling for Group Commands . . . . . . . . . . 14
4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 13 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 14
5. Operation with Proxies Agents . . . . . . . . . . . . . . . . 13 5. Operation with Proxies Agents . . . . . . . . . . . . . . . . 14
6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 13 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 15
6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 14 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 15
7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 14 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 16
7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 15 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 16
7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 15 7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 17
7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 16 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 17
7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 16 7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 18
7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 17 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 18
8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 17 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. Normative References . . . . . . . . . . . . . . . . . . . . 18 12. Normative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Session Management -- Exemplary Session State Appendix A. Session Management -- Exemplary Session State
Machines . . . . . . . . . . . . . . . . . . . . . . 18 Machine . . . . . . . . . . . . . . . . . . . . . . 20
A.1. Authorization Session State Machine . . . . . . . . . . . 18 A.1. Use of groups for the Authorization Session State Machine 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
In large network deployments, a single Diameter peer can support over In large network deployments, a single Diameter node can support over
a million concurrent Diameter sessions. Recent use cases have a million concurrent Diameter sessions. Recent use cases have
revealed the need for Diameter peers to apply the same operation to a revealed the need for Diameter nodes to apply the same operation to a
large group of Diameter sessions concurrently. For example, a policy large group of Diameter sessions concurrently. For example, a policy
decision point may need to modify the authorized quality of service decision point may need to modify the authorized quality of service
for all active users having the same type of subscription. The for all active users having the same type of subscription. The
Diameter base protocol commands operate on a single session so these Diameter base protocol commands operate on a single session so these
use cases could result in many thousands of command exchanges to use cases could result in many thousands of command exchanges to
enforce the same operation on each session in the group. In order 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 reduce signaling, it would be desirable to enable bulk operations on
all (or part of) the sessions managed by a Diameter peer using a all (or part of) the sessions managed by a Diameter node using a
single or a few command exchanges. single or a few command exchanges.
This document describes mechanisms for grouping Diameter sessions and This document describes mechanisms for grouping Diameter sessions and
applying Diameter commands, such as performing re-authentication, re- applying Diameter commands, such as performing re-authentication, re-
authorization, termination and abortion of sessions to a group of authorization, termination and abortion of sessions to a group of
sessions. This document does not define a new Diameter application. sessions. This document does not define a new Diameter application.
Instead it defines mechanisms, commands and AVPs that may be used by Instead it defines mechanisms, commands and AVPs that may be used by
any Diameter application that requires management of groups of any Diameter application that requires management of groups of
sessions. sessions.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
Client and Server can assign a new Diameter session to a group, e.g. Client and Server can assign a new Diameter session to a group, e.g.
in case the subscription profile of the associated user has similar in case the subscription profile of the associated user has similar
characteristics as the profile of other users whose Diameter session characteristics as the profile of other users whose Diameter session
has been assigned to one or multiple groups. A single command can be has been assigned to one or multiple groups. A single command can be
issued and applied to all sessions associated with such group(s), issued and applied to all sessions associated with such group(s),
e.g. to adjust common profile or policy settings. e.g. to adjust common profile or policy settings.
The assignment of a Diameter session to a group can be changed mid- The assignment of a Diameter session to a group can be changed mid-
session. For example, if a user's subscription profile changes mid- session. For example, if a user's subscription profile changes mid-
session, a Diameter peer may remove the session from its current session, a Diameter server may remove the session from its current
group and assign the session to a different group that is more group and assign the session to a different group that is more
appropriate for the new subscription profile. appropriate for the new subscription profile.
In case of mobile users, the user's session may get transferred to a In case of mobile users, the user's session may get transferred to a
new Diameter client during handover and assigned to a different new Diameter client during handover and assigned to a different
group, which is maintained at the new Diameter client, mid-session. group, which is maintained at the new Diameter client, mid-session.
A session group, which has sessions assigned, can be deleted, e.g. A session group, which has sessions assigned, can be deleted, e.g.
due to a change in multiple users' subscription profile so that the due to a change in multiple users' subscription profile so that the
group's assigned sessions do not share certain characteristics group's assigned sessions do not share certain characteristics
anymore. Deletion of such group requires subsequent individual anymore. Deletion of such group requires subsequent individual
treatment of each of the assigned sessions. A peer may decide to treatment of each of the assigned sessions. A node may decide to
assign some of these sessions to any other existing or new group. assign some of these sessions to any other existing or new group.
3.2. Issuing Group Commands 3.2. Issuing Group Commands
Changes in the network condition may result in the Diameter server's Changes in the network condition may result in the Diameter server's
decision to close all sessions in a given group. The server issues a decision to close all sessions in a given group. The server issues a
single Session Termination Request (STR) command , identifying the single Session Termination Request (STR) command , identifying the
group of sessions which are to be terminated. The Diameter client group of sessions which are to be terminated. The Diameter client
treats the STR as group command and initiates termination of all treats the STR as group command and initiates termination of all
sessions associated with the identified group. Subsequently, the sessions associated with the identified group. Subsequently, the
skipping to change at page 5, line 13 skipping to change at page 5, line 13
session group. session group.
This specification follows the most flexible model where both, a This specification follows the most flexible model where both, a
Diameter client and a Diameter server can create a new group and Diameter client and a Diameter server can create a new group and
assign a new identifier to that session group. When a Diameter node assign a new identifier to that session group. When a Diameter node
decides to create a new session group, e.g. to group all sessions decides to create a new session group, e.g. to group all sessions
which share certain characteristics, the node builds a session group which share certain characteristics, the node builds a session group
identifier according to the rules described in Section 7.3) and identifier according to the rules described in Section 7.3) and
becomes the owner of the group. This specification does not becomes the owner of the group. This specification does not
constrain the permission to add or remove a session to/from a session constrain the permission to add or remove a session to/from a session
group to the group owner, instead each peer can add a session to any group to the group owner, instead each node can add a session to any
known group or remove a session from a group. A session group is known group or remove a session from a group. A session group is
deleted and its identifier released after the last session has been deleted and its identifier released after the last session has been
removed from the session group. Also the modification of groups in removed from the session group. Also the modification of groups in
terms of moving a session from one session group to a different terms of moving a session from one session group to a different
session group is permitted to any Diameter node. A Diameter peer can session group is permitted to any Diameter node. A Diameter node can
delete a session group and its group identifier mid-session, delete a session group and its group identifier mid-session,
resulting in individual treatment of the sessions which have been resulting in individual treatment of the sessions which have been
previously assigned to the deleted group. previously assigned to the deleted group. Prerequisite for deletion
of a session group is that the Diameter node created the session
beforehand, hence the node became the group owner.
The enforcement of more constrained permissions is left to the The enforcement of more constrained permissions is left to the
specification of a particular group signaling enabled Diameter specification of a particular group signaling enabled Diameter
application and compliant implementations of such application must application and compliant implementations of such application must
enforce the associated permission model. Details about enforcing a enforce the associated permission model. Details about enforcing a
more constraint permission model are out of scope of this more constraint permission model are out of scope of this
specification. For example, a more constrained model could require specification. For example, a more constrained model could require
that a client MUST NOT remove a session from a group which is owned that a client MUST NOT remove a session from a group which is owned
by the server. by the server.
The following table depicts the permission considerations as per the The following table depicts the permission considerations as per the
present specification: present specification:
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Operation | Server | Client | | Operation | Server | Client |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Create a new Session Group (peer becomes | X | X | | Create a new Session Group (Diameter node | X | X |
| the group owner) | | | | becomes the group owner) | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Assign a Session to an owned Session Group | X | X | | Assign a Session to an owned Session Group | X | X |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Assign a Session to a non-owned Session Group | X | X | | Assign a Session to a non-owned Session Group | X | X |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Remove a Session from an owned Session Group | X | X | | Remove a Session from an owned Session Group | X | X |
+-------------------------------------------------+-----------------+ +-------------------------------------------------+-----------------+
| Remove a Session from a non-owned Session Group | X | X | | Remove a Session from a non-owned Session Group | X | X |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Remove a Session from a Session Group where the | X | X | | Remove a Session from a Session Group where the | X | X |
| peer created the assignment | | | | Diameter node created the assignment | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Remove a Session from a Session Group where the | | | | Remove a Session from a Session Group where a | | |
| peer did not create the assignment | | | | different Diameter node created the assignment | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Overrule a peer's group assignment *) | | | | Overrule a different Diameter node's | | |
| group assignment *) | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Delete a Session Group owned by the peer | X | X | | Delete a Session Group which is owned by the | X | X |
| Diameter node | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
| Delete a Session Group not owned by the peer | | | | Delete a Session Group which is not owned by | | |
| the Diameter node | | |
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
Default Permission as per this Specification Default Permission as per this Specification
*) Editors' note: The protocol specification in this document does *) Editors' note: The protocol specification in this document does
not consider overruling a peer's assignment of a session to a session not consider overruling a node's assignment of a session to a session
group. Group signaling enabled applications may take such protocol group. Here, overruling is to be understood as a node changing the
support and associated protocol semantics into account in their group(s) assignment as per the node's request. Group signaling
specification. enabled applications may take such protocol support and associated
protocol semantics into account in their specification. One
exception is adopted in this specifcation, which allows a Diameter
server to reject a group assignment as per the client's request.
4. Protocol Description 4. Protocol Description
4.1. Session Grouping Capability Discovery
4.1. Session Grouping Diameter nodes should assign a session to a session group and perform
session group operations with a node only after having ensured that
the node announced associated support beforehand.
Either Diameter peer can initiate the assignment of a session to a 4.1.1. Explicit Capability Discovery
single or multiple session groups. Modification of a group by
removing or adding a single or multiple user sessions can be New Diameter applications may consider support for Diameter session
initiated and performed mid-session by either Diameter peer. grouping and for performing group commands during the standardization
process. Such applications provide intrinsic discovery for the
support of group commands and announce this capability through the
assigned application ID.
System- and deployment-specific means, as well as out-of-band
mechanisms for capability exchange can be used to announce nodes'
support for session grouping and session group operations. In such
case, the optional Session-Group-Capability-Vector AVP, as described
in Section 4.1.2 can be omitted in Diameter messages being exchanged
between nodes.
4.1.2. Implicit Capability Discovery
If no explicit mechanism for capability discovery is deployed to
enable Diameter nodes to learn about nodes' capability to support
session grouping and group commands, a Diameter node SHOULD append
the Session-Group-Capability-Vector AVP to any Diameter messages
exchanged with its nodes to announce its capability to support
session grouping and session group operations. Implementations
following the specification as per this document set the
BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability-
Vector AVP.
When a Diameter node receives at least one Session-Group-Capability-
Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag
set, the Diameter node maintains a log to remember the node's
capability to support group commands.
4.2. Session Grouping
This specification does not limit the number of session groups, to
which a single session is assigned. It is left to the application to
determine the policy of session grouping. In case an application
facilitates a session to belong to multiple session groups, the
application must maintain consistency of associated application
session states for these multiple session groups.
Either Diameter node (client or server) can initiate the assignment
of a session to a single or multiple session groups. Modification of
a group by removing or adding a single or multiple user sessions can
be initiated and performed mid-session by either Diameter node.
Diameter AAA applications typically assign client and server roles to Diameter AAA applications typically assign client and server roles to
the Diameter peers, which are referred to as relevant Diameter peers the Diameter nodes, which are referred to as relevant Diameter nodes
to utilize session grouping and issue group commands. Section 5 to utilize session grouping and issue group commands. Section 5
describes particularities about session grouping and performing group describes particularities about session grouping and performing group
commands when relay agents or proxies are deployed. commands when relay agents or proxies are deployed.
Diameter peers, which are group-aware, must store and maintain an Diameter nodes, which are group-aware, must store and maintain an
entry about the group assignment together with a session's state. A entry about the group assignment together with a session's state. A
list of all known session groups should be locally maintained on each list of all known session groups should be locally maintained on each
peer, each group pointing to individual sessions being assigned to node, each group pointing to individual sessions being assigned to
the group. A peer must also keep a record about sessions, which have the group. A Diameter node must also keep a record about sessions,
been assigned to a session group by that peer. which have been assigned to a session group by itself.
4.1.1. Group assignment at session initiation 4.2.1. Group assignment at session initiation
To assign a session to a group at session initiation, a Diameter To assign a session to a group at session initiation, a Diameter
client sends a service specific request, e.g. NASREQ AAR [RFC4005], client sends a service specific request, e.g. NASREQ AA-Request
containing one or more group identifiers. Each of these groups need [RFC4005], containing one or more session group identifiers. Each of
to be identified by a unique Session-Group-Id contained in a separate these groups needs to be identified by a unique Session-Group-Id
Session-Group-Info AVP as specified in Section 7. contained in a separate Session-Group-Info AVP as specified in
Section 7.
The client may choose one or multiple sessions from a list of The client may choose one or multiple session groups from a list of
existing session groups. Alternatively, the client may decide to existing session groups. Alternatively, the client may decide to
create a new group and identify itself in the DiameterIdentity create a new group to which the session is assigned and identify
element of the Group-Session-Id AVP as per Section 7.3 itself in the <DiameterIdentity> portion of the Session-Group-Id AVP
as per Section 7.3
The client MUST set the SESSION_GROUP_ALLOCATION_ACTION of the The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the
Session-Group-Control-Vector AVP in each appended Session-Group-Info Session-Group-Control-Vector AVP in each appended Session-Group-Info
AVP to indicate that the identified session should be assigned to the AVP to indicate that the session contained in the request should be
identified session group. assigned to the identified session group.
The client may also indicate in the request that the server is
responsible for the assignment of the session in one or multiple
sessions owned by the server. In such a case, the client MUST
includes in the request the Session-Group-Info AVP in the request
including the Session-Group-Control-Vector AVP with
SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP.
If the Diameter server receives a command request from a Diameter If the Diameter server receives a command request from a Diameter
client and the command comprises at least one Session-Group-Info AVP client and the command comprises at least one Session-Group-Info AVP
having the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group- having the SESSION_GROUP_ALLOCATION_ACTION flag set in the Session-
Control-Vector AVP set, the server must assign the new session to Group-Control-Vector AVP set, the server can accept or reject the
each of the one or multiple identified session groups. In case one request for group assignment. Reasons for rejection may be e.g. lack
or multiple identified session groups are not know to the server, the of resources for managing additional groups. When rejected, the
server must add the one or multiple new groups to its local list of session must not be assigned to any session group but be treated as
known session groups. When sending the response to the client, e.g. single session.
a service-specific auth response as per NASREQ AAA [RFC4005], the
server must include all Session-Group-Info AVPs as received in the If the Diameter server accepts the client's request for a group
client's request. assignment, the server must assign the new session to each of the one
or multiple identified session groups when present in the Session-
Group-Info AVP. In case one or multiple identified session groups
are not already stored by the server, the server must store the new
identified group(s) to its local list of known session groups. When
sending the response to the client, e.g. a service-specific auth
response as per NASREQ AA-Answer [RFC4005], the server must include
all Session-Group-Info AVPs as received in the client's request.
In addition to the one or multiple session groups identified in the In addition to the one or multiple session groups identified in the
client's request, the server may decide to assign the new session to client's request, the server may decide to assign the new session to
one or multiple additional groups. In such case, the server adds to one or multiple additional groups. In such a case, the server adds
the response additional Session-Group-Info AVPs, each identifying a to the response the additional Session-Group-Info AVPs, each
session group, to which the server has assigned the new session. identifying a session group to which the new session is assigned by
Each of the Session-Group-Info AVP added by the server must have the the server. Each of the Session-Group-Info AVP added by the server
SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- must have the SESSION_GROUP_ALLOCATION_ACTION flag set in the
Vector AVP set. Session-Group-Control-Vector AVP set.
If the Diameter server rejects the client's request for a group
assignment, the server sends the response to the client, e.g. a
service-specific auth response as per NASREQ AA-Answer [RFC4005], and
must include all Session-Group-Info AVPs as received in the client's
request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION
flag of the Session-Group-Control-Vector AVP.
If the Diameter server receives a command request from a Diameter
client and the command comprises one or multiple Session-Group-Info
AVPs and none of them including a Session-Group-Id AVP, the server
MAY decide to assign the session to one or multiple session groups.
For each session group, to which the server assigns the new session,
the server includes a Session-Group-Info AVP with the Session-Group-
Id AVP identifying a session group in the response sent to the
client. Each of the Session-Group-Info AVPs included by the server
must have the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-
Group-Control-Vector AVP set.
If the Diameter server receives a command request from a Diameter
client and the command does not contain any Session-Group-Info AVP,
the server MUST not assign the new session to any session group but
treat the request as for a single session. The server MUST return
any Session-Group-Info AVP in the command response.
If the Diameter client receives a response to its previously issued If the Diameter client receives a response to its previously issued
request from the server and the response comprises at least one request from the server and the response comprises at least one
Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION
flag of the associated Session-Group-Control-Vector AVP set, the flag of the associated Session-Group-Control-Vector AVP set, the
client must add the new session to all session groups as identified client MUST add the new session to all session groups as identified
in the one or multiple Session-Group-Info AVPs. in the one or multiple Session-Group-Info AVPs.
A Diameter server receiving a command for session initiation which If the Diameter client receives a response to its previously issued
includes at least one Session-Group-Info AVP but the server does not request from the server and the one or more Session-Group-Info AVPs
understand the semantics of this optional AVP because it does not have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated
support group operations according to the specification in this Session-Group-Control-Vector AVP cleared, the client MUST terminate
document, MUST ignore the optional group operations specific AVPs and the assignment of the session to the one or multiple groups and
proceed with processing the command for a single session. continue to treat the session as single session without group
assignment.
A Diameter client, which sent a request for session initiation to a A Diameter client, which sent a request for session initiation to a
Diameter server and appended a single or multiple Session-Group-Id Diameter server and appended a single or multiple Session-Group-Id
AVPs but cannot find any Session-Group-Info AVP in the associated AVPs but cannot find any Session-Group-Info AVP in the associated
response from the Diameter server proceeds with processing the response from the Diameter server proceeds as if the request was
command for a single session. Furthermore, the client keeps a log to processed for a single session.
remember that the server is not able to perform group operations.
4.1.2. Removing a session from a session group 4.2.2. Removing a session from a session group
When a Diameter client decides to remove a session from a particular When a Diameter client decides to remove a session from a particular
session group, the client sends a service-specific re-authorization session group, the client sends a service-specific re-authorization
request to the server and adds one Session-Group-Info AVP to the request to the server and adds one Session-Group-Info AVP to the
request for each session group, from which the client wants to remove request for each session group, from which the client wants to remove
the session. The session, which is to be removed from a group, is the session. The session, which is to be removed from a group, is
identified in the Session-Id AVP of the command request. The identified in the Session-Id AVP of the command request. The
SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-
Vector AVP in each Session-Group-Info AVP must be cleared to indicate Vector AVP in each Session-Group-Info AVP must be cleared to indicate
removal of the session from the session group identified in the removal of the session from the session group identified in the
skipping to change at page 9, line 13 skipping to change at page 11, line 13
Session-Group-Id AVP. If the request comprises at least one Session- Session-Group-Id AVP. If the request comprises at least one Session-
Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared
and no Session-Id AVP present, the server must remove the session and no Session-Id AVP present, the server must remove the session
from all session groups to which the session has been previously from all session groups to which the session has been previously
assigned. The server must include in its response to the requesting assigned. The server must include in its response to the requesting
client all Session-Group-Id AVPs as received in the request. client all Session-Group-Id AVPs as received in the request.
When the Diameter server decides to remove a session from one or When the Diameter server decides to remove a session from one or
multiple particular session groups or from all session groups to multiple particular session groups or from all session groups to
which the session has been assigned beforehand, the server sends a which the session has been assigned beforehand, the server sends a
Re-Authorization Request (RAR) to the client, indicating the session Re-Authorization Request (RAR) or a service-specific server-intiated
in the requests Session-Id AVP. The client sends a Re-Authorization request to the client, indicating the session in the Session-Id AVP
Answer (RAA) to respond to the server's request. The client of the request. The client sends a Re-Authorization Answer (RAA) or
subsequently sends service-specific re-authorization request a service-specific answer to respond to the server's request. The
client subsequently sends service-specific re-authorization request
containing one or multiple Session-Group-Info AVPs, each indicating a containing one or multiple Session-Group-Info AVPs, each indicating a
session group, to which the session had been previously assigned. To session group, to which the session had been previously assigned. To
indicate removal of the indicated session from one or multiple indicate removal of the indicated session from one or multiple
session groups, the server sends a service-specific auth response to session groups, the server sends a service-specific auth response to
the client, containing a list of Session-Group-Info AVPs with the the client, containing a list of Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
AVP identifying the session group, from which the session should be AVP identifying the session group, from which the session should be
removed. The server MAY include to the service-specific auth removed. The server MAY include to the service-specific auth
response a list of Session-Group-Info AVPs with the response a list of Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
identifying session groups to which the session remains subscribed. identifying session groups to which the session remains subscribed.
In case the server decides to remove the identified session from all In case the server decides to remove the identified session from all
session groups, to which the session has been previously assigned, session groups, to which the session has been previously assigned,
the server includes in the service-specific auth response at least the server includes in the service-specific auth response at least
one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION
flag cleared and Session-Group-Id AVP absent. flag cleared and Session-Group-Id AVP absent.
4.1.3. Mid-session group assignment modifications 4.2.3. Mid-session group assignment modifications
Either Diameter peer can modify the group membership of an active Either Diameter node (client or server) can modify the group
Diameter session according to the specified permission membership of an active Diameter session according to the specified
considerations. permission considerations.
To update an assigned group mid-session, a Diameter client sends a To update an assigned group mid-session, a Diameter client sends a
service-specific re-authorization request to the server, containing service-specific re-authorization request to the server, containing
one or multiple Session-Group-Info AVPs with the one or multiple Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
present, identifying the session group to which the session should be present, identifying the session group to which the session should be
assigned. With the same message, the client may send one or multiple assigned. With the same message, the client may send one or multiple
Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag
cleared and the Session-Group-Id AVP identifying the session group cleared and the Session-Group-Id AVP identifying the session group
from which the identified session is to be removed. To remove the from which the identified session is to be removed. To remove the
skipping to change at page 10, line 35 skipping to change at page 12, line 36
identified session is to be assigned. With the same response identified session is to be assigned. With the same response
message, the server may send one or multiple Session-Group-Info AVPs message, the server may send one or multiple Session-Group-Info AVPs
with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the
Session-Group-Id AVP identifying the session groups from which the Session-Group-Id AVP identifying the session groups from which the
identified session is to be removed. When server wants to remove the identified session is to be removed. When server wants to remove the
session from all previously assigned session groups, it send at least session from all previously assigned session groups, it send at least
on Session-Group-Info AVP with the response having the on Session-Group-Info AVP with the response having the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id
AVP present. AVP present.
4.2. Session Grouping Capability Discovery
Diameter nodes should assign a session to a session group and perform
session group operations with a peer only after having ensured that
the peer announced associated support beforehand.
4.2.1. Explicit Capability Discovery
New Diameter applications may consider support for Diameter session
grouping and for performing group commands during the standardization
process. Such applications provide intrinsic discovery for the
support of group commands and announce this capability through the
assigned application ID.
System- and deployment-specific means for capability exchange can be
used to announce peers' support for session grouping and session
group operations. In such case, the optional Session-Group-
Capability-Vector AVP, as described in Section 4.2.2 can be omitted
in Diameter messages being exchanged between peers.
4.2.2. Implicit Capability Discovery
If no explicit mechanism for capability discovery is deployed to
enable Diameter nodes to learn about peers' capability to support
session grouping and group commands, Diameter peers SHOULD append the
Session-Group-Capability-Vector AVP to any Diameter messages
exchanged with its peers to announce its capability to support
session grouping and session group operations. Implementations
following this specification set the BASE_SESSION_GROUP_CAPABILITY
flag of the Session-Group-Capability-Vector AVP.
When a Diameter node receives at least one Session-Group-Capability-
Vector AVP from a peer with the BASE_SESSION_GROUP_CAPABILITY flag
set, the Diameter node maintains a log to remember the peer's
capability to support group commands.
4.3. Deleting a Session Group 4.3. Deleting a Session Group
To delete a session group and release the associated Session-Group-Id To delete a session group and release the associated Session-Group-Id
value, the owner of a session group appends a single Session-Group- value, the owner of a session group appends a single Session-Group-
Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the
Session-Group-Id AVP identifying the session group, which is to be Session-Group-Id AVP identifying the session group, which is to be
deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated
Session-Group-Control-Vector AVP MUST be cleared. Session-Group-Control-Vector AVP MUST be cleared.
4.4. Performing Group Operations 4.4. Performing Group Operations
4.4.1. Sending Group Commands 4.4.1. Sending Group Commands
Either Diameter peer can request the recipient of a request to Either Diameter node (lient or server) can request the recipient of a
process an associated command for all sessions being assigned to one request to process an associated command for all sessions being
or multiple groups by identifying these groups in the request. The assigned to one or multiple groups by identifying these groups in the
sender of the request appends for each group, to which the command request. The sender of the request appends for each group, to which
applies, a Session-Group-Info AVP including the Session-Group-Id AVP the command applies, a Session-Group-Info AVP including the Session-
to identify the associated session group. Both, the Group-Id AVP to identify the associated session group. Both, the
SESSION_GROUP_ALLOCATION_ACTION flag as well as the SESSION_GROUP_ALLOCATION_ACTION flag as well as the
SESSION_GROUP_STATUS_IND flag must be set. SESSION_GROUP_STATUS_IND flag must be set.
If the CCF of the request mandates a Session-Id AVP, the Session-Id If the CCF of the request mandates a Session-Id AVP, the Session-Id
AVP MUST identify a single session which is assigned to at least one AVP MUST identify one of the single sessions which is assigned to at
of the groups being identified in the appended Session-Group-Id AVPs. least one of the groups being identified in the appended Session-
Group-Id AVPs.
The sender of the request MUST indicate to the receiver how follow up The sender of the request MUST indicate to the receiver how follow up
message exchanges should be performed by appending a single instance message exchanges should be performed by appending a single instance
of the Group-Response-Action AVP. Even if the request includes of the Group-Response-Action AVP. Even if the request includes
multiple instances of a Session-Group-Info AVP, the request MUST NOT multiple instances of a Session-Group-Info AVP, the request MUST NOT
comprise more than a single instance of a Group-Response-Action AVP. comprise more than a single instance of a Group-Response-Action AVP.
If the sender wants the receiver to perform follow up exchanges with If the sender wants the receiver to perform follow up exchanges with
a single command for all impacted groups, the sender sets the value a single command for all impacted groups, the sender sets the value
of the Group-Response-Action AVP to ALL_GROUPS (1). If follow up of the Group-Response-Action AVP to ALL_GROUPS (1). If follow up
message exchanges should be performed on a per-group basis in case message exchanges should be performed on a per-group basis in case
multiple groups are identified in the group command, the value of the multiple groups are identified in the group command, the value of the
Group-Response-Action AVP is set to PER_GROUP (2). A value set to Group-Response-Action AVP is set to PER_GROUP (2). A value set to
PER_SESSION (3) indicates to the receiver that all follow up PER_SESSION (3) indicates to the receiver that all follow up
exchanges should be performed using a single message for each exchanges should be performed using a single message for each
impacted session. impacted session.
If the sender sends a request including the Group-Response-Action AVP
set to ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delays
before receiving the corresponding answer(s) as the answer(s) will
only be sent back when the request is processed for all the sessions
or all the session of a session group. If the process of the request
is delay-sensitive, the sender SHOULD NOT set the Group-Response-
Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be
sent before the complete process of the request for all the sessions
or if the request timeout timer is high enough, the sender MAY set
the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2).
If the sender wants the receiver of the request to process the If the sender wants the receiver of the request to process the
associated command solely for a single session does not append any associated command solely for a single session does not append any
group identifier, but identifies the relevant session in the Session- group identifier, but identifies the relevant session in the Session-
Id AVP. Id AVP.
4.4.2. Receiving Group Commands 4.4.2. Receiving Group Commands
A Diameter peer receiving a request to process a command for a group A Diameter node receiving a request to process a command for a group
of sessions identifies the relevant groups according to the appended of sessions identifies the relevant groups according to the appended
Session-Group-Id AVP in the Session-Group-Info AVP and processes the Session-Group-Id AVP in the Session-Group-Info AVP and processes the
group command according to the appended Group-Response-Action AVP . group command according to the appended Group-Response-Action AVP .
If the received request identifies multiple groups in multiple If the received request identifies multiple groups in multiple
appended Session-Group-Id AVPs, the receiver should process the appended Session-Group-Id AVPs, the receiver should process the
associated command for each of these groups. if a session has been associated command for each of these groups. if a session has been
assigned to more than one of the identified groups, the receiver must assigned to more than one of the identified groups, the receiver must
process the associated command only once per session. process the associated command only once per session.
The Diameter peer receiving a request which requests performing the The Diameter node receiving a request which requests performing the
command to at least on session group SHOULD perform follow up message command to at least on session group SHOULD perform follow up message
exchanges according to the value identified in the Session-Group-Info exchanges according to the value identified in the Session-Group-Info
AVP. AVP.
4.4.3. Error Handling for Group Commands 4.4.3. Error Handling for Group Commands
When a Diameter peer receives a request to process a command for one When a Diameter node receives a request to process a command for one
or more session groups and the result of processing the command is an or more session groups and the result of processing the command is an
error that applies to all sessions in the identified groups, an error that applies to all sessions in the identified groups, an
associated protocol error must be returned to the source of the associated protocol error must be returned to the source of the
request. In such case, the sender of the request MUST fall back to request. In such case, the sender of the request MUST fall back to
single-session processing and the session groups, which have been single-session processing and the session groups, which have been
identified in the group command, MUST be deleted according to the identified in the group command, MUST be deleted according to the
procedure described in Section 4.3. procedure described in Section 4.3.
When a Diameter peer receives a request to process a command for one When a Diameter node receives a request to process a command for one
or more session groups and the result of processing the command or more session groups and the result of processing the command
succeeds for some sessions identified in one or multiple session succeeds for some sessions identified in one or multiple session
groups, but fails for one or more sessions, the Result-Code AVP in groups, but fails for one or more sessions, the Result-Code AVP in
the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per
Section 7.1.2 of [RFC6733]. In case of limited success, the Section 7.1.2 of [RFC6733]. In case of limited success, the
sessions, for which the processing of the group command failed, MUST sessions, for which the processing of the group command failed, MUST
be identified using a Failed-AVP AVP as per Session 7.5 of [RFC6733]. be identified using a Failed-AVP AVP as per Session 7.5 of [RFC6733].
4.4.4. Single-Session Fallback 4.4.4. Single-Session Fallback
Either Diameter peer, a Diameter client or a Diameter server, can Either Diameter node can fall back to single session operation by
fall back to single session operation by ignoring and omitting the ignoring and omitting the optional group session-specific AVPs.
optional group session-specific AVPs. Fallback to single-session Fallback to single-session operation is performed by processing the
operation is performed by processing the Diameter command solely for Diameter command solely for the session identified in the mandatory
the session identified in the mandatory Session-Id AVP. The response Session-Id AVP. The response to the group command must not identify
to the group command must not identify any group but identify solely any group but identify solely the single session for which the
the single session for which the command has been processed. command has been processed.
5. Operation with Proxies Agents 5. Operation with Proxies Agents
This specification assumes in case of a present stateful Proxy Agent In case of a present stateful Proxy Agent between a Diameter client
between a Diameter client and a Diameter server that the Proxy Agent and a Diameter server, this specification assumes that the Proxy
is aware of session groups and session group handling. The Proxy Agent is aware of session groups and session group handling. The
MUST reflect the state of each session associated with a session Proxy MUST update and maintain consistency of its local session
group according to the result of a group command operated between a states as per the result of the group commands which are operated
Diameter client and a server. between a Diameter client and a server.
In case a Proxy Agent manipulates session groups, it MUST maintain In case a Proxy Agent manipulates session groups, it MUST maintain
consistency of session groups between a client and a server. This consistency of session groups between a client and a server. This
applies to deployment where the Proxy Agent utilizes session grouping applies to a deployment where the Proxy Agent utilizes session
and performing group commands with, for example, a Diameter server, grouping and performs group operations with, for example, a Diameter
whereas the Diameter client is not group-aware. The same applies to server, whereas the Diameter client is not aware of session groups.
deployment where all nodes, the Diameter client and server, as well In such case the Proxy Agent must reflect the states associated with
as the Proxy Agent are group-aware but the Proxy Agent manipulates the session groups as individual session operations towards the
groups, e.g. to adopt different administrative policies that apply to client and ensure the client has a consistent view of each session.
the client's domain and the server's domain. The same applies to a deployment where all nodes, the Diameter client
and server, as well as the Proxy Agent are group-aware but the Proxy
Agent manipulates groups, e.g. to adopt different administrative
policies that apply to the client's domain and the server's domain.
6. Commands Formatting 6. Commands Formatting
This document does not specify new Diameter commands to enable group This document does not specify new Diameter commands to enable group
operations, but relies on command extensibility capability provided operations, but relies on command extensibility capability provided
by the Diameter Base protocol. This section provides the guidelines by the Diameter Base protocol. This section provides the guidelines
to extend the CCF of existing Diameter commands with optional AVPs to to extend the CCF of existing Diameter commands with optional AVPs to
enable the recipient of the command to perform the command to all enable the recipient of the command applying the command to all
sessions associated with the identified group(s). sessions associated with the identified group(s).
6.1. Formatting Example: Group Re-Auth-Request 6.1. Formatting Example: Group Re-Auth-Request
A request that one or more groups of users are re-authentication is A request for re-authentication of one or more groups of users is
issued by appending one or multiple Session-Group-Id AVP(s) to the issued by appending one or multiple Session-Group-Id AVP(s), as well
Re-Auth-Request (RAR) and a single instance of a Group-Response- as a single instance of a Group-Response-Action AVP to the Re-Auth-
Action AVP. The one or multiple Session-Group-Id AVP(s) identify the Request (RAR). The one or multiple Session-Group-Id AVP(s) identify
associated group(s) for which the group re-authentication has been the associated group(s) for which the group re-authentication has
requested. The Group-Response-Action AVP identifies the expected been requested. The Group-Response-Action AVP identifies the
means to perform and respond to the group command. The recipient of expected means to perform and respond to the group command. The
the group command initiates re-authentication for all users recipient of the group command initiates re-authentication for all
associated with the identified group(s). Furthermore, the sender of users associated with the identified group(s). Furthermore, the
the group re-authentication request appends a Group-Response-Action sender of the group re-authentication request appends a Group-
AVP to provide more information to the receiver of the command about Response-Action AVP to provide more information to the receiver of
how to accomplish the group operation. the command about how to accomplish the group operation.
The value of the mandatory Session-Id AVP MUST identify a session The value of the mandatory Session-Id AVP MUST identify a session
associated with a single user, which is assigned to at least one of associated with a single user, which is assigned to at least one of
the groups being identified in the appended Session-Group-Id AVPs. the groups being identified in the appended Session-Group-Id AVPs.
<RAR> ::= < Diameter Header: 258, REQ, PXY > <RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
skipping to change at page 16, line 28 skipping to change at page 17, line 51
The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and
identifies a group of Diameter sessions. identifies a group of Diameter sessions.
The Session-Group-Id MUST be globally and eternally unique, as it is The Session-Group-Id MUST be globally and eternally unique, as it is
meant to uniquely identify a group of Diameter sessions without meant to uniquely identify a group of Diameter sessions without
reference to any other information. reference to any other information.
The default format of the Session-Group-id MUST comply to the format The default format of the Session-Group-id MUST comply to the format
recommended for a Session-Id, as defined in the section 8.8 of the recommended for a Session-Id, as defined in the section 8.8 of the
[RFC6733]. The DiameterIdentity element of the Session-Group-Id MUST [RFC6733]. The <DiameterIdentity> portion of the Session-Group-Id
identify the Diameter node, which owns the session group. MUST identify the Diameter node, which owns the session group.
7.4. Group-Response-Action AVP 7.4. Group-Response-Action AVP
The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32
and contains a 32-bit address space representing values indicating and contains a 32-bit address space representing values indicating
how the peer SHOULD issue follow up exchanges in response to a how the node SHOULD issue follow up exchanges in response to a
command which impacts multiple sessions. The following values are command which impacts multiple sessions. The following values are
defined by this application: defined by this application:
ALL_GROUPS (1) ALL_GROUPS (1)
Follow up exchanges should be performed with a single message Follow up exchanges should be performed with a single message
exchange for all impacted groups. exchange for all impacted groups.
PER_GROUP (2) PER_GROUP (2)
Follow up exchanges should be performed with a message exchange Follow up exchanges should be performed with a message exchange
for each impacted group. for each impacted group.
skipping to change at page 17, line 50 skipping to change at page 19, line 24
o Session-Group-Id o Session-Group-Id
o Group-Response-Action o Group-Response-Action
o Session-Group-Capability-Vector o Session-Group-Capability-Vector
The AVPs are defined in Section 7. The AVPs are defined in Section 7.
10. Security Considerations 10. Security Considerations
TODO The security considerations of the Diameter protocol itself are
discussed in [RFC6733]. Use of the AVPs defined in this document
MUST take into consideration the security issues and requirements of
the Diameter base protocol. In particular, the Session-Group-Info
AVP (including the Session-group-Control-Vector and the Session-
Group-Id AVPs) should be considered as a security-sensitive AVPs in
the same manner than the Session-Id AVP in the Diameter base protocol
[RFC6733].
The management of session groups relies upon the existing trust
relationship between the Diameter client and the Diameter server
managing the groups of sessions. This document defines a mechanism
that allows a client or a server to act on multiple sessions at the
same time using only one command. if the Diameter client or server is
compromised, an attacker could launch DoS attacks by terminating a
large number of sessions with a limited set of commands using the
session group management concept.
According to the Diameter base protocol [RFC6733], transport
connections between Diameter peers are protected by TLS/TCP, DTLS/
SCTP or alternative security mechanisms that are independent of
Diameter, such as IPsec. However, the lack of end-to-end security
features makes it difficult to establish trust in the session group
related information received from non-adjacent nodes. Any Diameter
agent in the message path can potentially modify the content of the
message and therefore the information sent by the Diameter client or
the server. The DIME working group is currently working on solutions
for providing end-to-end security features. When available, these
features should enable the establishment of trust relationship
between non-adjacent nodes and the security required for session
group management would normally rely on this end-to-end security.
However, there is no assumption in this document that such end-to-end
security mechanism will be available. It is only assume that the
solution defined on this document relies on the security framework
provided by the Diameter based protocol.
In some cases, a Diameter Proxy agent can act on behalf of a client
or server. In such a case, the security requirements that normally
apply to a client (or a server) apply equally to the Proxy agent.
11. Acknowledgments 11. Acknowledgments
The authors of this document want to thank Ben Campbell and Eric The authors of this document want to thank Ben Campbell and Eric
McMurry for their valuable comments to early versions of this draft. McMurry for their valuable comments to early versions of this draft.
Furthermore, authors thank Steve Donovan for the thorough review and
comments on the adopted WG document, which helped a lot to improve
this specification.
12. Normative References 12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
August 2005. August 2005.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012. "Diameter Base Protocol", RFC 6733, October 2012.
Appendix A. Session Management -- Exemplary Session State Machines Appendix A. Session Management -- Exemplary Session State Machine
A.1. Authorization Session State Machine A.1. Use of groups for the Authorization Session State Machine
Section 8.1 in [RFC6733] defines a set of finite state machines, Section 8.1 in [RFC6733] defines a set of finite state machines,
representing the life cycle of Diameter sessions, and which MUST be representing the life cycle of Diameter sessions, and which MUST be
observed by all Diameter implementations that make use of the observed by all Diameter implementations that make use of the
authentication and/or authorization portion of a Diameter authentication and/or authorization portion of a Diameter
application. This section defines the additional state transitions application. This section defines, as example, additional state
related to the processing of the new commands which may impact transitions related to the processing of the group commands which may
multiple sessions. impact multiple sessions.
The group membership is session state and therefore only those state The group membership is session state and therefore only those state
machines from [RFC6733] in which the server is maintaining session machines from [RFC6733] in which the server is maintaining session
state are relevant in this document. As in [RFC6733], the term state are relevant in this document. As in [RFC6733], the term
Service-Specific below refers to a message defined in a Diameter Service-Specific below refers to a message defined in a Diameter
application (e.g., Mobile IPv4, NASREQ). application (e.g., Mobile IPv4, NASREQ).
The following state machine is observed by a client when state is The following state machine is observed by a client when state is
maintained on the server. State transitions which are unmodified maintained on the server. State transitions which are unmodified
from [RFC6733] are not repeated here. from [RFC6733] are not repeated here.
A Diameter group command in the following tables is differentiated The Diameter group command in the following tables is differentiated
from a single-session related command by a preceding 'G'. A Group from a single-session related command by a preceding 'G' (Group). A
Re-Auth Request, which applies to one or multiple session groups, has Group Re-Auth Request, which applies to one or multiple session
been exemplarily described in Section 6.1. Such Group RAR command is groups, has been exemplarily described in Section 6.1. Such Group
denoted as 'GRAR' in the following table. The same notation applies RAR command is denoted as 'GRAR' in the following table. The same
to other commands as per [RFC6733]. notation applies to other commands as per [RFC6733].
CLIENT, STATEFUL CLIENT, STATEFUL
State Event Action New State State Event Action New State
--------------------------------------------------------------- ---------------------------------------------------------------
Idle Client or Device Requests Send Pending Idle Client or Device Requests Send Pending
access service access service
specific specific
auth req auth req
optionally optionally
including including
 End of changes. 68 change blocks. 
211 lines changed or deleted 324 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/