< draft-ietf-dime-group-signaling-03.txt   draft-ietf-dime-group-signaling-04.txt >
Diameter Maintenance and M. Jones Diameter Maintenance and Extensions (DIME) M. Jones
Extensions (DIME) M. Liebsch Internet-Draft
Internet-Draft L. Morand Intended status: Standards Track M. Liebsch
Intended status: Standards Track February 15, 2014 Expires: January 5, 2015
Expires: August 19, 2014 L. Morand
July 4, 2014
Diameter Group Signaling Diameter Group Signaling
draft-ietf-dime-group-signaling-03.txt draft-ietf-dime-group-signaling-04.txt
Abstract Abstract
In large network deployments, a single Diameter peer can support over In large network deployments, a single Diameter peer 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 peers 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 peer 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 August 19, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Building and Modifying Session Groups . . . . . . . . . . 6 3.1. Building and Modifying Session Groups . . . . . . . . . . 4
3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . . 6 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4
3.3. Permission Model . . . . . . . . . . . . . . . . . . . . . 7 3.3. Permission Considerations . . . . . . . . . . . . . . . . 4
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
4.1. Session Grouping . . . . . . . . . . . . . . . . . . . . . 8 4.1. Session Grouping . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Group assignment at session initiation . . . . . . . . 8 4.1.1. Group assignment at session initiation . . . . . . . 7
4.1.2. Removing a session from a session group . . . . . . . 10 4.1.2. Removing a session from a session group . . . . . . . 8
4.1.3. Mid-session group assignment modifications . . . . . . 11 4.1.3. Mid-session group assignment modifications . . . . . 9
4.2. Session Grouping Capability Discovery . . . . . . . . . . 12 4.2. Session Grouping Capability Discovery . . . . . . . . . . 10
4.2.1. Implicit Capability Discovery . . . . . . . . . . . . 12 4.2.1. Explicit Capability Discovery . . . . . . . . . . . . 10
4.2.2. Explicit Capability Discovery . . . . . . . . . . . . 12 4.2.2. Implicit Capability Discovery . . . . . . . . . . . . 11
4.3. Releasing a Session Group Identifier . . . . . . . . . . . 12 4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 11
4.4. Performing Group Operations . . . . . . . . . . . . . . . 13 4.4. Performing Group Operations . . . . . . . . . . . . . . . 11
4.4.1. Sending Group Commands . . . . . . . . . . . . . . . . 13 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 11
4.4.2. Receiving Group Commands . . . . . . . . . . . . . . . 13 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 12
4.4.3. Error Handling for Group Commands . . . . . . . . . . 14 4.4.3. Error Handling for Group Commands . . . . . . . . . . 12
4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 14 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 13
5. Operation with Proxies Agents . . . . . . . . . . . . . . . . 15 5. Operation with Proxies Agents . . . . . . . . . . . . . . . . 13
6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 13
6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 14
7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 17 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 14
7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . . 17 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 15
7.2. Session-Group-Feature-Vector AVP . . . . . . . . . . . . . 17 7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 15
7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 18 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 16
7.4. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 18 7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 16
8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 19 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 17
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. Normative References . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12. Normative References . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Session Management -- Exemplary Session State Appendix A. Session Management -- Exemplary Session State
Machines . . . . . . . . . . . . . . . . . . . . . . 24 Machines . . . . . . . . . . . . . . . . . . . . . . 18
A.1. Authorization Session State Machine . . . . . . . . . . . 24 A.1. Authorization Session State Machine . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
In large network deployments, a single Diameter peer can support over In large network deployments, a single Diameter peer 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 peers 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
skipping to change at page 4, line 33 skipping to change at page 3, line 36
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.
These mechanisms take the following design goals and features into These mechanisms take the following design goals and features into
account: account:
o Minimal impact to existing applications o Minimal impact to existing applications
o Extension of existing commands' CCF with optional AVPs to enable o Extension of existing commands' Command Code Format (CCF) with
grouping and group operations optional AVPs to enable grouping and group operations
o Fallback to single session operation o Fallback to single session operation
o Implicit discovery of capability to support grouping and group o Implicit discovery of capability to support grouping and group
operations operations in case no external mechanism is available to discover a
Diameter peer's capability to support session grouping and session
group operations.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses terminology defined [RFC6733]. This document uses terminology defined [RFC6733].
3. Protocol Overview 3. Protocol Overview
3.1. Building and Modifying Session Groups 3.1. Building and Modifying Session Groups
Client and Server can add a new Diameter session to a group, e.g. in Client and Server can assign a new Diameter session to a group, e.g.
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 added to one or multiple groups. Such similarities can be has been assigned to one or multiple groups. A single command can be
for example maximum bandwidth bounds of each user in the a group. issued and applied to all sessions associated with such group(s),
These users may share resources of, e.g., an access multiplexer, e.g. to adjust common profile or policy settings.
together with other users. Runtime adjustments in the granted
bandwidth bounds or other Quality of Service related attributes can
be accomplished for the whole group by identifying the group in the
Diameter group command.
In case a user's subscription profile changes during runtime, either The assignment of a Diameter session to a group can be changed mid-
node, a Diameter Server or Diameter client, may decide to remove this session. For example, if a user's subscription profile changes mid-
user's Diameter session from the session group. The user's Diameter session, a Diameter peer may remove the session from its current
session can be assigned to a different group, whose adjusted profile group and assign the session to a different group that is more
matches the one of the different group. Both groups, the user's appropriate for the new subscription profile.
previous group and its new group, will be modified mid-session.
In case of mobile users, a change in the node implementing the In case of mobile users, the user's session may get transferred to a
Diameter client can happen, which has impact to a group of sessions a new Diameter client during handover and assigned to a different
particular pair of Diameter client and server has in common. Due to group, which is maintained at the new Diameter client, mid-session.
mobility, the mobile user's session may get transferred to a new
Diameter client during runtime without mandating from-scratch A session group, which has sessions assigned, can be deleted, e.g.
authorization. Such scenario necessitates mid-session modification. due to a change in multiple users' subscription profile so that the
group's assigned sessions do not share certain characteristics
anymore. Deletion of such group requires subsequent individual
treatment of each of the assigned sessions. A peer may decide to
assign some of these sessions to any other existing or new group.
3.2. Issuing Group Commands 3.2. Issuing Group Commands
A policy decision point may decide to terminate a group of sessions, Changes in the network condition may result in the Diameter server's
e.g. based on previous agreement for temporary authorization to decision to close all sessions in a given group. The server issues a
access a system. All Diameter sessions of associated users with such single Session Termination Request (STR) command , identifying the
temporarily granted access will be added to a single Diameter session group of sessions which are to be terminated. The Diameter client
group. After the time limit for the temporary authorization has been treats the STR as group command and initiates termination of all
reached, the policy decision point can issue a single Session sessions associated with the identified group. Subsequently, the
Termination Request (STR) to the policy enforcement point. The STR client confirms successful termination of these sessions to the
command identifies the group of Diameter sessions which are to be server by sending a single Session Termination Answer (STA) command,
terminated. The policy enforcement point treats the STR as group which includes the identifier of the group.
command and initiates termination of all sessions in the group.
Subsequently, the policy enforcement point confirms successful
termination of these sessions to the policy decision point by sending
a single Session Termination Answer (STA) command which includes the
identifier of the group.
3.3. Permission Model 3.3. Permission Considerations
A permission model in the context of this draft defines the Permission considerations in the context of this draft apply to the
permission of Diameter nodes to build new session groups, to add/ permission of Diameter nodes to build new session groups, to assign/
remove a session to/from a session group and to delete an existing remove a session to/from a session group and to delete an existing
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 build 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 issue 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 must identify itself in which share certain characteristics, the node builds a session group
the DiameterIdentity element of the session group identifier identifier according to the rules described in Section 7.3) and
(Section 7.3) as owner of the group. The permission model as per becomes the owner of the group. This specification does not
this specification solely constrains the permission to close a constrain the permission to add or remove a session to/from a session
session group and release the associated identifier to the group group to the group owner, instead each peer can add a session to any
owner. known group or remove a session from a group. A session group is
deleted and its identifier released after the last session has been
removed from the session group. Also the modification of groups in
terms of moving a session from one session group to a different
session group is permitted to any Diameter node. A Diameter peer can
delete a session group and its group identifier mid-session,
resulting in individual treatment of the sessions which have been
previously assigned to the deleted group.
Irrespective of the group ownership, as per this specification any The enforcement of more constrained permissions is left to the
Diameter node has the permission to add/remove a session to/from an specification of a particular group signaling enabled Diameter
existing session group. Also the modification of groups in terms of application and compliant implementations of such application must
moving a session from one session group to a different session group enforce the associated permission model. Details about enforcing a
is permitted to any Diameter node. The enforcement of a more more constraint permission model are out of scope of this
constrained model is left to the application and implementation,
which must then ensure that relevant Diameter nodes have the same
view of the permission model, either through administrative
configuration or protocol-based capability discovery. Details about
enforcing a 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
present specification:
+-------------------------------------------------+--------+--------+
| Operation | Server | Client |
+-------------------------------------------------+--------+--------+
| Create a new Session Group (peer becomes | X | X |
| the group owner) | | |
+-------------------------------------------------+--------+--------+
| Assign a Session to an 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 a non-owned Session Group | X | X |
+-------------------------------------------------+--------+--------+
| Remove a Session from a Session Group where the | X | X |
| peer created the assignment | | |
+-------------------------------------------------+--------+--------+
| Remove a Session from a Session Group where the | | |
| peer did not create the assignment | | |
+-------------------------------------------------+--------+--------+
| Overrule a peer's group assignment *) | | |
+-------------------------------------------------+--------+--------+
| Delete a Session Group owned by the peer | X | X |
+-------------------------------------------------+--------+--------+
| Delete a Session Group not owned by the peer | | |
+-------------------------------------------------+--------+--------+
Default Permission as per this Specification
*) Editors' note: The protocol specification in this document does
not consider overruling a peer's assignment of a session to a session
group. Group signaling enabled applications may take such protocol
support and associated protocol semantics into account in their
specification.
4. Protocol Description 4. Protocol Description
4.1. Session Grouping 4.1. Session Grouping
Either Diameter peer can initiate assigning a session to a single or Either Diameter peer can initiate the assignment of a session to a
multiple session groups. Modification of a group by removing or single or multiple session groups. Modification of a group by
adding a single or multiple user sessions can be initiated and removing or adding a single or multiple user sessions can be
performed at runtime by either Diameter peer. Diameter AAA initiated and performed mid-session by either Diameter peer.
applications typically assign client and server roles to the Diameter Diameter AAA applications typically assign client and server roles to
peers, which are referred to as relevant Diameter peers to utilize the Diameter peers, which are referred to as relevant Diameter peers
session grouping and issue group commands. Section 5 describes to utilize session grouping and issue group commands. Section 5
particularities about session grouping and performing group commands describes particularities about session grouping and performing group
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 a list Diameter peers, which are group-aware, must store and maintain an
of all session groups to which at least one session, for which the entry about the group assignment together with a session's state. A
peer holds a state, is assigned. Along with the group's Session-Id, list of all known session groups should be locally maintained on each
a list of Diameter sessions, which are assigned to the group, must be peer, each group pointing to individual sessions being assigned to
stored. This specification assumes that a session group is built and the group. A peer must also keep a record about sessions, which have
handled between pairs of Diameter nodes. Clients and servers MUST been assigned to a session group by that peer.
maintain Diameter state of individual sessions grouped in a session
group.
4.1.1. Group assignment at session initiation 4.1.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 AAR [RFC4005],
containing one or more group identifiers. A Diameter client as containing one or more group identifiers. Each of these groups need
sender of a command for session initiation can determine one or to be identified by a unique Session-Group-Id contained in a separate
multiple groups to which the new session should be assigned. Each of Session-Group-Info AVP as specified in Section 7.
these groups need to be identified by a unique Session-Group-Id
contained in a separate Session-Group-Info AVP as specified in
Section 7.
The client may choose one or multiple sessions from a list of The client may choose one or multiple sessions from a list of
existing session groups, irrespective of the group ownership. existing session groups. Alternatively, the client may decide to
Alternatively, the client may decide to create a new group and create a new group and identify itself in the DiameterIdentity
identify itself in the DiameterIdentity element of the element of the Group-Session-Id AVP as per Section 7.3
Group-Session-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 of the
Session-Group-Feature-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 added to the AVP to indicate that the identified session should be assigned to the
identified session group. identified session group.
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 of the Session-Group-
Feature-Vector AVP set, the server must add the new session to each Control-Vector AVP set, the server must assign the new session to
of the one or multiple identified session groups. In case one or each of the one or multiple identified session groups. In case one
multiple identified session groups are not know to the server, the or multiple identified session groups are not know to the server, the
server must add the one or multiple new groups to its locally server must add the one or multiple new groups to its local list of
maintained list of session groups. When sending the response to the known session groups. When sending the response to the client, e.g.
client, e.g. a service-specific auth response as per NASREQ AAA a service-specific auth response as per NASREQ AAA [RFC4005], the
[RFC4005], the server must include all Session-Group-Info AVPs as server must include all Session-Group-Info AVPs as received in the
received in the client's request. 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 add the new session to one client's request, the server may decide to assign the new session to
or multiple additional groups. In such case, the server add to the one or multiple additional groups. In such case, the server adds to
response additional Session-Group-Info AVPs, each identifying a the response additional Session-Group-Info AVPs, each identifying a
session group, to which the server has assigned the new session. session group, to which the server has assigned the new session.
Each of the Session-Group-Info AVP added by the server, the Each of the Session-Group-Info AVP added by the server must have the
SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Feature- SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-
Vector AVP must be set. Vector AVP set.
If the Diameter server receives a command for session initiation from
a Diameter client and the command comprises at least one Session-
Group-Info AVP, but the one or multiple Session-Group-Info AVP do not
identify any session group to which the session should be assigned,
the server may assign the new session to one or multiple session
groups. Each session group, to which the server assigns the new
session, must be identified in a separate Session-Group-Info AVP
having the SESSION_GROUP_ALLOCATION_ACTION flag of the associated
Session-Group-Vector AVP set.
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-Feature-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 A Diameter server receiving a command for session initiation which
includes at least one Session-Group-Info AVP but the server does not includes at least one Session-Group-Info AVP but the server does not
understand the semantics of this optional AVP because it does not understand the semantics of this optional AVP because it does not
support group operations according to the specification in this support group operations according to the specification in this
document, MUST ignore the optional group operations specific AVPs and document, MUST ignore the optional group operations specific AVPs and
proceed with processing the command for a single session. proceed with processing the command for a single session.
skipping to change at page 10, line 13 skipping to change at page 8, line 34
remember that the server is not able to perform group operations. remember that the server is not able to perform group operations.
4.1.2. Removing a session from a session group 4.1.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-Feature- 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
associated Session-Group-id AVP. associated Session-Group-id AVP.
When a Diameter client decides to remove a session from all session When a Diameter client decides to remove a session from all session
groups, to which the session has been previously assigned, the client groups, to which the session has been previously assigned, the client
sends a service-specific re-authorization request to the server and sends a service-specific re-authorization request to the server and
adds a single Session-Group-Info AVP to the request which has the adds a single Session-Group-Info AVP to the request which has the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
AVP omitted. The session, which is to be removed from all groups, to AVP omitted. The session, which is to be removed from all groups, to
skipping to change at page 11, line 11 skipping to change at page 9, line 32
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-Info AVP absent. flag cleared and Session-Group-Id AVP absent.
4.1.3. Mid-session group assignment modifications 4.1.3. Mid-session group assignment modifications
Either Diameter peer can modify the group membership of an active Either Diameter peer can modify the group membership of an active
Diameter session, irrespective of the group ownership. Diameter session according to the specified 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
added. 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
session from all previously assigned session groups, the client session from all previously assigned session groups, the client
includes at least one Session-Group-Info AVP with the includes at least one Session-Group-Info AVP with 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. When the server received the service-specific re- AVP present. When the server received the service-specific re-
authorization request, it must update its locally maintained view of authorization request, it must update its locally maintained view of
the session groups for the identified session according to the the session groups for the identified session according to the
appended Session-Group-Info AVPs. The server sends a service- appended Session-Group-Info AVPs. The server sends a service-
specific auth response to the client containing one or multiple specific auth response to the client containing one or multiple
Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag
set and the Session-Group-Id AVP identifying the new session group to set and the Session-Group-Id AVP identifying the new session group to
which the identified session has been added. which the identified session has been assigned.
When a Diameter server enforces an update to the assigned groups mid- When a Diameter server enforces an update to the assigned groups mid-
session, it sends a Re-Authorization Request (RAR) message to the session, it sends a Re-Authorization Request (RAR) message to the
client identifying the session, for which the session group lists are client identifying the session, for which the session group lists are
to be updated. The client responds with a Re-Authorization Answer to be updated. The client responds with a Re-Authorization Answer
(RAA) message. The client subsequently sends service-specific re- (RAA) message. The client subsequently sends service-specific re-
authorization request containing one or multiple Session-Group-Info authorization request containing one or multiple Session-Group-Info
AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the
Session-Group-Id AVP identifying the session group to which the Session-Group-Id AVP identifying the session group to which the
session had been previously assigned. The server responds with a session had been previously assigned. The server responds with a
service-specific auth response and includes one or multiple Session- service-specific auth response and includes one or multiple Session-
Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and
the Session-Group-Id AVP identifying the session group, to which the the Session-Group-Id AVP identifying the session group, to which the
identified session is to be added. With the same response message, identified session is to be assigned. With the same response
the server may send one or multiple Session-Group-Info AVPs with the message, the server may send one or multiple Session-Group-Info AVPs
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the
AVP identifying the session groups from which the identified session Session-Group-Id AVP identifying the session groups from which the
is to be removed. When server wants to remove the session from all identified session is to be removed. When server wants to remove the
previously assigned session groups, it send at least on Session- session from all previously assigned session groups, it send at least
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 4.2. Session Grouping Capability Discovery
4.2.1. Implicit 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.
By appending at least one Session-Group-Info AVP, the Diameter client 4.2.1. Explicit Capability Discovery
announces its capability to support group operations according to the
specification in this document to the addressed Diameter server. If
the Diameter client supports group operations, it MUST append at
least one Session-Group-Info AVP to announce its capability to
support group operations.
A session-group aware Diameter server receiving a command for session New Diameter applications may consider support for Diameter session
initiation which includes at least one Session-Group-Info AVP learns grouping and for performing group commands during the standardization
about the sender's capability to support group operations. process. Such applications provide intrinsic discovery for the
support of group commands and announce this capability through the
assigned application ID.
By appending at least one Session-Group-Id AVP, the Diameter server System- and deployment-specific means for capability exchange can be
announces its capability to support group operations according to the used to announce peers' support for session grouping and session
specification in this document to the addressed Diameter client. 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. Explicit Capability Discovery 4.2.2. Implicit Capability Discovery
New Diameter applications may consider support for Diameter session If no explicit mechanism for capability discovery is deployed to
grouping and for performing group commands during the standardization enable Diameter nodes to learn about peers' capability to support
process. Such applications provide intrinsic support for the support session grouping and group commands, Diameter peers SHOULD append the
of group commands and announce this capability through the assigned Session-Group-Capability-Vector AVP to any Diameter messages
application ID. 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.
4.3. Releasing a Session Group Identifier 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.
To close a session group and release the associated Session-Group-Id 4.3. Deleting a Session Group
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
closed. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated
Session-Group-Feature-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 peer can request the recipient of a request to
process an associated command for all sessions being assigned to one process an associated command for all sessions being assigned to one
or multiple groups by identifying these groups in the request. The or multiple groups by identifying these groups in the request. The
sender of the request appends for each group, to which the command sender of the request appends for each group, to which the command
applies, a Session-Group-Info AVP including the Session-Group-Id AVP applies, a Session-Group-Info AVP including the Session-Group-Id AVP
to identify the associated session group. Both, the 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 a single session which is assigned to at least one
of the groups being identified in the appended Session-Group-Id AVPs. of the groups being identified in the appended Session-Group-Id AVPs.
The sender of the request can 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 Session-Group- message exchanges should be performed by appending a single instance
Action AVP. If the sender wants the receiver to perform follow up of the Group-Response-Action AVP. Even if the request includes
exchanges with a single command for all impacted groups, the sender multiple instances of a Session-Group-Info AVP, the request MUST NOT
sets the value of the Session-Group-Action AVP to ALL_GROUPS (1). If comprise more than a single instance of a Group-Response-Action AVP.
follow up message exchanges should be performed on a per-group basis If the sender wants the receiver to perform follow up exchanges with
in case multiple groups are identified in the group command, the a single command for all impacted groups, the sender sets the value
value of the Session-Group-Action AVP is set to PER_GROUP (2). A of the Group-Response-Action AVP to ALL_GROUPS (1). If follow up
value set to PER_SESSION (3) indicates to the receiver that all message exchanges should be performed on a per-group basis in case
follow up exchanges should be performed using a single message for multiple groups are identified in the group command, the value of the
each impacted session. 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
exchanges should be performed using a single message for each
impacted session.
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 group identifier, but identifies the relevant session in the Session-
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 peer 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. If the received Session-Group-Id AVP in the Session-Group-Info AVP and processes the
request identifies multiple groups in multiple appended Session- group command according to the appended Group-Response-Action AVP .
Group-Id AVPs, the receiver should process the associated command for If the received request identifies multiple groups in multiple
each of these groups. if a session has been assigned to more than one appended Session-Group-Id AVPs, the receiver should process the
of the identified groups, the receiver must process the associated associated command for each of these groups. if a session has been
command only once per session. assigned to more than one of the identified groups, the receiver must
process the associated command only once per session.
The Diameter peer receiving a request which requests performing the The Diameter peer 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 peer 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 closed 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 peer 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].
skipping to change at page 16, line 18 skipping to change at page 14, line 9
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 to perform 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 that one or more groups of users are re-authentication 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) to the
Re-Auth-Request (RAR). The one or multiple Session-Group-Id AVP(s) Re-Auth-Request (RAR) and a single instance of a Group-Response-
identify the associated group(s) for which the group re- Action AVP. The one or multiple Session-Group-Id AVP(s) identify the
authentication has been requested. The recipient of the group associated group(s) for which the group re-authentication has been
command initiates re-authentication for all users associated with the requested. The Group-Response-Action AVP identifies the expected
identified group(s). Furthermore, the sender of the group re- means to perform and respond to the group command. The recipient of
authentication request appends a Session-Group-Action AVP to provide the group command initiates re-authentication for all users
more information to the receiver of the command about how to associated with the identified group(s). Furthermore, the sender of
accomplish the group operation. the group re-authentication request appends a Group-Response-Action
AVP to provide more information to the receiver of the command about
how to accomplish the group operation.
The value of the mandatory Session-Id AVP MUST identify a session 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 }
{ Destination-Host } { Destination-Host }
{ Auth-Application-Id } { Auth-Application-Id }
{ Re-Auth-Request-Type } { Re-Auth-Request-Type }
[ User-Name ] [ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ Session-Group-Id ] [ Session-Group-Capability-Vector ]
[ Session-Group-Action ] * [ Session-Group-Info ]
[ Group-Response-Action ]
* [ AVP ] * [ AVP ]
7. Attribute-Value-Pairs (AVP) 7. Attribute-Value-Pairs (AVP)
+--------------------+ +--------------------+
| AVP Flag rules | | AVP Flag rules |
+----+---+------+----+ +----+---+------+----+
AVP | | |SHOULD|MUST| AVP | | |SHOULD|MUST|
Attribute Name Code Value Type |MUST|MAY| NOT | NOT| Attribute Name Code Value Type |MUST|MAY| NOT | NOT|
+-------------------------------------------------+----+---+------+----+ +-------------------------------------------------+----+---+------+----+
|Session-Group-Info TBD1 Grouped | | P | | V | |Session-Group-Info TBD1 Grouped | | P | | V |
|Session-Group-Feature-Vector TBD2 Unsigned32 | | P | | V | |Session-Group-Control-Vector TBD2 Unsigned32 | | P | | V |
|Session-Group-Id TBD3 OctetString | | P | | V | |Session-Group-Id TBD3 OctetString | | P | | V |
|Session-Group-Action TBD4 Unsigned32 | | P | | V | |Group-Response-Action TBD4 Unsigned32 | | P | | V |
|Session-Group-Capability-Vector TBD5 Unsigned32 | | P | | V |
+-------------------------------------------------+----+---+------+----+ +-------------------------------------------------+----+---+------+----+
AVPs for the Diameter Group Signaling AVPs for the Diameter Group Signaling
7.1. Session-Group-Info AVP 7.1. Session-Group-Info AVP
The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It
contains the identifier of the session group as well as an indication contains the identifier of the session group as well as an indication
of the node responsible for session group identifier assignment. of the node responsible for session group identifier assignment.
Session-Group-Info ::= < AVP Header: TBD1 > Session-Group-Info ::= < AVP Header: TBD1 >
< Session-Group-Feature-Vector > < Session-Group-Control-Vector >
[ Session-Group-Id ] [ Session-Group-Id ]
* [ AVP ] * [ AVP ]
7.2. Session-Group-Feature-Vector AVP 7.2. Session-Group-Control-Vector AVP
The Session-Group-Feature-Vector AVP (AVP Code TBD2) is of type The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type
Unsigned32 and contains a 32-bit flags field of capabilities Unsigned32 and contains a 32-bit flags field to control the group
supported by the session-group aware node. assignment at session-group aware nodes.
The following capabilities are defined in this document: The following capabilities are defined in this document:
SESSION_GROUP_ALLOCATION_ACTION (0x00000001) SESSION_GROUP_ALLOCATION_ACTION (0x00000001)
This flag indicates the action to be performed for the identified This flag indicates the action to be performed for the identified
session. When this flag is set, it indicates that the identified session. When this flag is set, it indicates that the identified
Diameter session is to be added to the session group as identified Diameter session is to be assigned to the session group as
by the Session-Group-Id AVP or the session's assignement to the identified by the Session-Group-Id AVP or the session's assignment
session group identified in the Session-Group-Id AVP is still to the session group identified in the Session-Group-Id AVP is
valid. When the flag is cleared, the identified Diameter session still valid. When the flag is cleared, the identified Diameter
is to be removed from at least one session group. When the flag session is to be removed from at least one session group. When
is cleared and the Session-Group-Info AVP identifies a particular the flag is cleared and the Session-Group-Info AVP identifies a
session group in the associated Session-Group-Id AVP, the session particular session group in the associated Session-Group-Id AVP,
is to be removed solely from the identified session group. When the session is to be removed solely from the identified session
the flag is cleared and the Session-Group-Info AVP does not group. When the flag is cleared and the Session-Group-Info AVP
identify a particular session group (Session-Group-Id AVP is does not identify a particular session group (Session-Group-Id AVP
absent), the identified Diameter session is to be removed from all is absent), the identified Diameter session is to be removed from
session groups, to which it has been previously assigned. all session groups, to which it has been previously assigned.
SESSION_GROUP_STATUS_IND (0x00000010) SESSION_GROUP_STATUS_IND (0x00000010)
This flag indicates the status of the session group identified in This flag indicates the status of the session group identified in
the associated Session-Group-Id AVP. The flag is set when the the associated Session-Group-Id AVP. The flag is set when the
identified session group has just been created or is still active. identified session group has just been created or is still active.
If the flag is cleared, the identified session group is closed and If the flag is cleared, the identified session group is deleted
the associated Session-Group-Id is released. If the Session- and the associated Session-Group-Id is released. If the Session-
Group-Info AVP does not comprise a Session-Group-Id AVP, this flag Group-Info AVP does not comprise a Session-Group-Id AVP, this flag
is meaningless and MUST be ignored by the receiver. is meaningless and MUST be ignored by the receiver.
7.3. Session-Group-Id AVP 7.3. Session-Group-Id AVP
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 element of the Session-Group-Id MUST
identify the Diameter node, which owns the session group. identify the Diameter node, which owns the session group.
7.4. Session-Group-Action AVP 7.4. Group-Response-Action AVP
The Session-Group-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 peer SHOULD issue follow up exchanges in response to a
command which impacts mulitple 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.
PER_SESSION (3) PER_SESSION (3)
Follow up exchanges should be performed with a message exchange Follow up exchanges should be performed with a message exchange
for each impacted session. for each impacted session.
7.5. Session-Group-Capability-Vector AVP
The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type
Unsigned32 and contains a 32-bit flags field to indicate capabilities
in the context of session-group assignment and group operations.
The following capabilities are defined in this document:
BASE_SESSION_GROUP_CAPABILITY (0x00000001)
This flag indicates the capability to support session grouping and
session group operations according to this specification.
8. Result-Code AVP Values 8. Result-Code AVP Values
This document does not define new Result-Code [RFC6733] values for This document does not define new Result-Code [RFC6733] values for
existing applications, which are extended to support group commands. existing applications, which are extended to support group commands.
Specification documents of new applications, which will have Specification documents of new applications, which will have
intrinsic support for group commands, may specify new Result-Codes. intrinsic support for group commands, may specify new Result-Codes.
9. IANA Considerations 9. IANA Considerations
This section contains the namespaces that have either been created in This section contains the namespaces that have either been created in
this specification or had their values assigned to existing this specification or had their values assigned to existing
namespaces managed by IANA. namespaces managed by IANA.
9.1. AVP Codes 9.1. AVP Codes
This specification requires IANA to register the following new AVPs This specification requires IANA to register the following new AVPs
from the AVP Code namespace defined in [RFC6733]. from the AVP Code namespace defined in [RFC6733].
o Session-Group-Info o Session-Group-Info
o Session-Group-Feature-Vector o Session-Group-Control-Vector
o Session-Group-Id o Session-Group-Id
o Session-Group-Action o Group-Response-Action
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 TODO
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
skipping to change at page 24, line 46 skipping to change at page 19, line 14
--------------------------------------------------------------- ---------------------------------------------------------------
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
groups groups
Open GASR received with Send GASA Discon Open GASR received with Send GASA Discon
Session-Group-Action with Group-Response-Action with
= ALL_GROUPS, Result-Code = ALL_GROUPS, Result-Code
session is assigned to = SUCCESS, session is assigned to = SUCCESS,
received group(s) and Send GSTR. received group(s) and Send GSTR.
client will comply with client will comply with
request to end the session request to end the session
Open GASR received with Send GASA Discon Open GASR received with Send GASA Discon
Session-Group-Action with Group-Response-Action with
= PER_GROUPS, Result-Code = PER_GROUPS, Result-Code
session is assigned to = SUCCESS, session is assigned to = SUCCESS,
received group(s) and Send GSTR received group(s) and Send GSTR
client will comply with per group client will comply with per group
request to end the session request to end the session
Open GASR received with Send GASA Discon Open GASR received with Send GASA Discon
Session-Group-Action with Group-Response-Action with
= PER_SESSION, Result-Code = PER_SESSION, Result-Code
session is assigned to = SUCCESS, session is assigned to = SUCCESS,
received group(s) and Send STR received group(s) and Send STR
client will comply with per session client will comply with per session
request to end the session request to end the session
Open GASR received, Send GASA Open Open GASR received, Send GASA Open
client will not comply with with client will not comply with with
request to end all session Result-Code request to end all session Result-Code
in received group(s) != SUCCESS in received group(s) != SUCCESS
Discon GSTA Received Discon. Idle Discon GSTA Received Discon. Idle
user/device user/device
Open GRAR received with Send GRAA, Pending Open GRAR received with Send GRAA, Pending
Session-Group-Action Send Group-Response-Action Send
= ALL_GROUPS, service = ALL_GROUPS, service
session is assigned to specific session is assigned to specific
received group(s) and group received group(s) and group
client will perform re-auth req client will perform re-auth req
subsequent re-auth subsequent re-auth
Open GRAR received with Send GRAA, Pending Open GRAR received with Send GRAA, Pending
Session-Group-Action Send Group-Response-Action Send
= PER_GROUP, service = PER_GROUP, service
session is assigned to specific session is assigned to specific
received group(s) and group received group(s) and group
client will perform re-auth req client will perform re-auth req
subsequent re-auth per group subsequent re-auth per group
Open GRAR received with Send GRAA, Pending Open GRAR received with Send GRAA, Pending
Session-Group-Action Send Group-Response-Action Send
= PER_SESSION, service = PER_SESSION, service
session is assigned to specific session is assigned to specific
received group(s) and re-auth req received group(s) and re-auth req
client will perform per session client will perform per session
subsequent re-auth subsequent re-auth
Open GRAR received and client will Send GRAA Idle Open GRAR received and client will Send GRAA Idle
not perform subsequent with not perform subsequent with
re-auth Result-Code re-auth Result-Code
!= SUCCESS, != SUCCESS,
 End of changes. 70 change blocks. 
261 lines changed or deleted 316 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/