rfc9390.original   rfc9390.txt 
Diameter Maintenance and Extensions (DIME) M. Jones Internet Engineering Task Force (IETF) M. Jones
Internet-Draft Individual Request for Comments: 9390 Individual
Intended status: Standards Track M. Liebsch Category: Standards Track M. Liebsch
Expires: February 4, 2023 NEC ISSN: 2070-1721 NEC
L. Morand L. Morand
Orange Orange
August 3, 2022 April 2023
Diameter Group Signaling Diameter Group Signaling
draft-ietf-dime-group-signaling-14.txt
Abstract Abstract
In large network deployments, a single Diameter node can support over In large network deployments, a single Diameter node can support over
a million concurrent Diameter sessions. In some use cases, Diameter a million concurrent Diameter sessions. In some use cases, Diameter
nodes need to apply the same operation to a large group of Diameter nodes need to apply the same operation to a large group of Diameter
sessions concurrently. The Diameter base protocol commands operate sessions concurrently. The Diameter base protocol commands operate
on a single session so these use cases could result in many thousands on a single session so these use cases can result in many thousands
of command exchanges to enforce the same operation on each session in of command exchanges enforcing the same operation on each session in
the group. In order to reduce signaling, it would be desirable to the group. In order to reduce signaling, it is desirable to enable
enable bulk operations on all (or part of) the sessions managed by a bulk operations on all (or part of) the sessions managed by a
Diameter node using a single or a few command exchanges. This Diameter node using a single or a few command exchanges. This
document specifies the Diameter protocol extensions to achieve this document specifies the Diameter protocol extensions to achieve this
signaling optimization. signaling optimization.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 4, 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9390.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview
3.1. Building and Modifying Session Groups . . . . . . . . . . 4 3.1. Building and Modifying Session Groups
3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4 3.2. Issuing Group Commands
3.3. Permission Considerations . . . . . . . . . . . . . . . . 5 3.3. Permission Considerations
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Description
4.1. Session Grouping Capability Discovery . . . . . . . . . . 5 4.1. Session Grouping Capability Discovery
4.1.1. Capability Discovery based on the Application Id . . 5 4.1.1. Capability Discovery Based on the Application Id
4.1.2. Capability Discovery based on AVP Presence . . . . . 6 4.1.2. Capability Discovery Based on AVP Presence
4.2. Session Grouping . . . . . . . . . . . . . . . . . . . . 6 4.2. Session Grouping
4.2.1. Group assignment at session initiation . . . . . . . 7 4.2.1. Group Assignment at Session Initiation
4.2.2. Removing a session from a session group . . . . . . . 9 4.2.2. Removing a Session from a Session Group
4.2.3. Mid-session group assignment modifications . . . . . 11 4.2.3. Mid-session Group Assignment Modifications
4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 12 4.3. Deleting a Session Group
4.4. Performing Group Operations . . . . . . . . . . . . . . . 12 4.4. Performing Group Operations
4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 12 4.4.1. Sending Group Commands
4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 13 4.4.2. Receiving Group Commands
4.4.3. Error Handling for Group Commands . . . . . . . . . . 13 4.4.3. Error Handling for Group Commands
4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 14 4.4.4. Single-Session Fallback
5. Operation with Proxy Agents . . . . . . . . . . . . . . . . . 14 5. Operation with Proxy Agents
6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 15 6. Commands Formatting
6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 15 6.1. Formatting Example: Group Re-Auth-Request
7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 16 7. Attribute-Value Pairs (AVPs)
7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 16 7.1. Session-Group-Info AVP
7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 17 7.2. Session-Group-Control-Vector AVP
7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 17 7.3. Session-Group-Id AVP
7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 18 7.4. Group-Response-Action AVP
7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 18 7.5. Session-Group-Capability-Vector AVP
8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 18 8. Result-Code AVP Values
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. AVP Codes
9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 19 9.2. New Registries
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Normative References
12. Normative References . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Session Management -- Exemplary Session State Machine
Appendix A. Session Management -- Exemplary Session State A.1. Use of Groups for the Authorization Session State Machine
Machine . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgments
A.1. Use of groups for the Authorization Session State Machine 21 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In large network deployments, a single Diameter node can support over In large network deployments, a single Diameter node can support over
a million concurrent Diameter sessions. In some use cases, Diameter a million concurrent Diameter sessions. In some use cases, Diameter
nodes need to apply the same operation to a large group of Diameter nodes need to apply the same operation to a large group of Diameter
sessions concurrently. For example, a policy decision point may need sessions concurrently. For example, a policy decision point may need
to modify the authorized quality of service for all active users to modify the authorized quality of service for all active users
having the same type of subscription. The Diameter base protocol having the same type of subscription. The Diameter base protocol
commands operate on a single session so these use cases could result commands operate on a single session so these use cases can result in
in many thousands of command exchanges to enforce the same operation many thousands of command exchanges enforcing the same operation on
on each session in the group. In order to reduce signaling, it would each session in the group. In order to reduce signaling, it is
be desirable to enable bulk operations on all (or part of) the desirable to enable bulk operations on all (or part of) the sessions
sessions managed by a Diameter node using a single or a few command managed by a Diameter node using a single or a few command exchanges.
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 Attribute-Value Pairs
any Diameter application that requires management of groups of (AVPs) that may be used by any Diameter application that requires
sessions. management of groups of 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 * minimal impact to existing applications
o Extension of existing commands' Command Code Format (CCF) with * extension of existing commands' Command Code Format (CCF) with
optional AVPs to enable grouping and group operations optional AVPs to enable grouping and group operations
o Fallback to single session operation * fallback to single-session operation
o Implicit discovery of capability to support grouping and group * implicit discovery of capability to support grouping and group
operations in case no external mechanism is available to discover a operations in case no external mechanism is available to discover
Diameter peer's capability to support session grouping and session a Diameter peer's capability to support session grouping and
group operations 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses terminology defined in [RFC6733]. This document uses terminology defined in [RFC6733].
3. Protocol Overview 3. Protocol Overview
3.1. Building and Modifying Session Groups 3.1. Building and Modifying Session Groups
In order to accommodate bulk operations on Diameter sessions, the In order to accommodate bulk operations on Diameter sessions, the
concept of session groups is introduced. Once sessions are added to concept of session groups is introduced. Once sessions are added to
a group, a command acting on the group will affect all the member a group, a command acting on the group will affect all the member
sessions. sessions.
Client and Server can assign a new Diameter session to a group, e.g., The client and the server can assign a new Diameter session to a
in case the subscription profile of the associated user has similar group, e.g., in case the subscription profile of the associated user
characteristics as the profile of other users whose Diameter session has similar characteristics as the profile of other users whose
has been assigned to one or multiple groups. A single command can be Diameter session has been assigned to one or multiple groups. A
issued and applied to all sessions associated with such group(s), single command can be issued and applied to all sessions associated
e.g., to adjust common profile or policy settings. with one or more such groups, e.g., to adjust common profile or
policy settings.
The assignment of a Diameter session to a group can be changed during The assignment of a Diameter session to a group can be changed during
an ongoing session (mid-session). For example, if a user's an ongoing session (mid-session). For example, if a user's
subscription profile changes mid-session, a Diameter server may subscription profile changes mid-session, a Diameter server may
remove a session from an existing group and assign this session to a remove a session from an existing group and assign this session to a
different group that is more appropriate for the new subscription different group that is more appropriate for the new subscription
profile. profile.
In the case of mobile users, the user's session may get transferred In the case of mobile users, the user's session may get transferred
mid-session to a new Diameter client during handover and assigned to mid-session to a new Diameter client during handover and assigned to
a different group, which is maintained at the new Diameter client. a different group, which is maintained at the new Diameter client.
It may be required to delete a session group, e.g. at the expiry of a It may be required to delete a session group, e.g., at the expiry of
promotional period that applied to multiple subscriber profiles. a promotional period that applied to multiple subscriber profiles.
Deletion of such group requires subsequent individual treatment of Deletion of such group requires subsequent individual treatment of
each of the assigned sessions. A node may decide to assign some of each of the assigned sessions. A node may decide to assign some of
these sessions to any other existing or new group. 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. As example, the decision to close all sessions in a given group. For example, the
server issues a single Session Termination Request (STR) command, server issues a single Session Termination Request (STR) command,
including the identifier of the group of sessions which are to be including the identifier of the group of sessions that are to be
terminated. The Diameter client treats the STR as group command and terminated. The Diameter client treats the STR as a group command
initiates the termination of all sessions associated with the and initiates the termination of all sessions associated with the
identified group. Subsequently, the client confirms the successful identified group. Subsequently, the client confirms the successful
termination of these sessions to the server by sending a single termination of these sessions to the server by sending a single
Session Termination Answer (STA) command, which includes the Session Termination Answer (STA) command, which includes the
identifier of the group. identifier of the group.
3.3. Permission Considerations 3.3. Permission Considerations
Permission considerations in the context of this draft apply to the Permission considerations in the context of this document apply to
permission of Diameter nodes to build new session groups, to assign/ the permission of Diameter nodes to build new session groups, to
remove a session to/from a session group and to delete an existing assign/remove a session to/from a session group, and to delete an
session group. existing session group.
When a client or a server decides to create a new session group, When a client or server decides to create a new session group, e.g.,
e.g., to group all sessions which share certain characteristics, this to group all sessions that share certain characteristics, this node
node builds a session group identifier according to the rules builds a session group identifier according to the rules described in
described in Section 7.3 and becomes the owner of the group. Section 7.3 and becomes the owner of the group.
After the creation of a session group, a session can be added to this After the creation of a session group, a session can be added to this
session group by either the client or the server. However, a session session group by either the client or the server. However, a session
can only be removed from a session group by the Diameter node (client can only be removed from a session group by the Diameter node (client
or server) that has assigned this session to the session group. or server) that has assigned this session to the session group.
A session group can only be deleted by the owner of the session A session group can only be deleted by the owner of the session
group, resulting in individual treatment of the sessions that were group, resulting in individual treatment of the sessions that were
assigned to this session group. assigned to this session group.
Diameter applications with implicit support for session groups MAY Diameter applications with implicit support for session groups MAY
define a more constrained permission model. For example, a more define a more constrained permission model. For example, a more
constrained model could require that a client must not remove a constrained model could require that a client not remove a session
session from a group which is owned by the server. Details about from a group that is owned by the server. Details about enforcing a
enforcing a more constrained permission model are out of scope of more constrained permission model are out of scope of this
this specification. specification.
4. Protocol Description 4. Protocol Description
4.1. Session Grouping Capability Discovery 4.1. Session Grouping Capability Discovery
Diameter nodes SHOULD NOT perform group operations with peer nodes Diameter nodes SHOULD NOT perform group operations with peer nodes
unless the node has advertised support for session grouping and group unless the node has advertised support for session grouping and group
operations. operations.
4.1.1. Capability Discovery based on the Application Id 4.1.1. Capability Discovery Based on the Application Id
Newly defined Diameter applications may natively support Diameter Newly defined Diameter applications may intrinsically support
session grouping and group operations. Such applications provide Diameter session grouping and group operations. In these cases,
intrinsic discovery for the support of session grouping capability there is no need of a specific discovery mechanism for the support of
using the assigned Application Id advertised during the capability session grouping capability besides the discovery of the Application
Id assigned to the application advertised during the capability
exchange phase described in Section 5.3 of [RFC6733]. exchange phase described in Section 5.3 of [RFC6733].
System- and deployment-specific means, as well as out-of-band System-specific and deployment-specific means, as well as out-of-band
mechanisms for capability discovery can be used to announce nodes' mechanisms for capability discovery, can be used to announce nodes'
support for session grouping and session group operations. In such support for session grouping and session group operations. In such
case, the optional Session-Group-Capability-Vector AVP, as described case, the optional Session-Group-Capability-Vector AVP, as described
in Section 4.1.2 can be omitted in Diameter messages being exchanged in Section 4.1.2, can be omitted in Diameter messages being exchanged
between nodes. between nodes.
4.1.2. Capability Discovery based on AVP Presence 4.1.2. Capability Discovery Based on AVP Presence
If no other mechanism for capability discovery is deployed to enable If no other mechanism for capability discovery is deployed to enable
Diameter nodes to learn about nodes' capability to support session Diameter nodes to learn about nodes' capability to support session
grouping and group commands for a given application, a Diameter node grouping and group commands for a given application, a Diameter node
SHOULD append the Session-Group-Capability-Vector AVP to any Diameter SHOULD append the Session-Group-Capability-Vector AVP to any Diameter
application messages exchanged with the other Diameter nodes to application messages exchanged with the other Diameter nodes to
announce its capability to support session grouping and session group announce its capability to support session grouping and session group
operations for the advertised application. Implementations following operations for the advertised application. Implementations following
the specification as per this document MUST set the the specification as per this document MUST set the
BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability- BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability-
Vector AVP. Vector AVP.
When a Diameter node receives at least one Session-Group-Capability- When a Diameter node receives at least one Session-Group-Capability-
Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag
set, the receiving Diameter node discovers the supported session set, the receiving Diameter node discovers the supported session
grouping capability of the sending Diameter node for the advertised grouping capability of the sending Diameter node for the advertised
application and MUST cache this information for the lifetime of the application and MUST cache this information for the lifetime of the
routing table entry associated with the peer identity/Application Id routing table entry associated with the peer identity / Application
pair (see Section 2.7 of [RFC6733]). Id pair (see Section 2.7 of [RFC6733]).
4.2. Session Grouping 4.2. Session Grouping
This specification does not limit the number of session groups to This specification does not limit the number of session groups to
which a single session is assigned. It is left to the implementation which a single session is assigned. It is left to the implementation
of an application to determine such limitations. If an application of an application to determine such limitations. If an application
facilitates a session to belong to multiple session groups, the facilitates a session to belong to multiple session groups, the
application MUST maintain consistency of associated application application MUST maintain consistency of associated application
session states for these multiple session groups. session states for these multiple session groups.
Either Diameter node (client or server) can initiate the assignment Either Diameter node (client or server) can initiate the assignment
of a session to a single or multiple session groups. Modification of 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 a group by removing or adding a single or multiple user sessions can
be initiated and performed mid-session by either Diameter node be initiated and performed mid-session by either Diameter node
responsible for the session assignment to this group. Although responsible for the session assignment to this group. Although
Diameter is a peer-to-peer protocol, Diameter AAA applications Diameter is a peer-to-peer protocol, Diameter Authentication,
typically assign the role of a "Diameter client" to the Diameter node Authorization, and Accounting (AAA) applications typically assign the
initiating the Diameter session and the role of "Diameter server" to role of a "Diameter client" to the Diameter node initiating the
the node authorizing the Diameter session. This specification does Diameter session and the role of "Diameter server" to the node
not restrict group creation, assignment or deletion actions to a authorizing the Diameter session. This specification does not
restrict group creation, assignment, or deletion actions to a
specific role. In the following sections, "Diameter node" is used to specific role. In the following sections, "Diameter node" is used to
refer to either role. Section 5 describes particularities about refer to either role. Section 5 describes particularities about
session grouping and performing group commands when relay agents or session grouping and performing group commands when relay agents or
proxies are deployed. proxies are deployed.
Any Diameter node that has advertised support of session grouping and Any Diameter node that has advertised support of session grouping and
group operations MUST store and maintain the group assignment as part group operations MUST store and maintain the group assignment as part
of the session's state. A list of all known session groups is of the session's state. A list of all known session groups is
locally maintained on each node, each group pointing to individual locally maintained on each node, with each group pointing to
sessions being assigned to the group. Each Diameter node MUST also individual sessions being assigned to the group. Each Diameter node
keep a record about sessions that it has assigned to a session group. MUST also keep a record about sessions that it has assigned to a
session group.
4.2.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 AA-Request client sends a service-specific request, e.g., Network Access Server
[RFC7155], containing one or more session group identifiers. Each of Requirements (NASREQ) AA-Request [RFC7155], containing one or more
these groups MUST be identified by a unique Session-Group-Id session group identifiers. Each of these groups MUST be identified
contained in a separate Session-Group-Info AVP as specified in by a unique Session-Group-Id contained in a separate Session-Group-
Section 7. Info AVP, as specified in Section 7.
The client may choose one or multiple session groups 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 to which the session is assigned and identify create a new group to which the session is assigned and identify
itself in the <DiameterIdentity> portion of the Session-Group-Id AVP itself in the <DiameterIdentity> portion of the Session-Group-Id AVP,
as per Section 7.3. For all assignments of a session to an active as per Section 7.3. For all assignments of a session to an active
session group made by the client or the server, the session group made by the client or the server, the
SESSION_GROUP_STATUS flag in the Session-Group-Info AVP, which SESSION_GROUP_STATUS flag in the Session-Group-Info AVP, which
identifies the session group, MUST be set. A set identifies the session group, MUST be set. A set
SESSION_GROUP_STATUS flag indicates that the identified session group SESSION_GROUP_STATUS flag indicates that the identified session group
has just been created or is still active. has just been created or is still active.
The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag 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 session contained in the request should be AVP to indicate that the session contained in the request should be
assigned to the identified session group. assigned to the identified session group.
The client may also indicate in the request that it supports The client may also indicate in the request that it supports
assignment of the session to one or more groups by the server. In assignment of the session to one or more groups by the server. In
such a case, the client MUST include the Session-Group-Info AVP in such case, the client MUST include the Session-Group-Info AVP in the
the request including the Session-Group-Control-Vector AVP with the request, including the Session-Group-Control-Vector AVP with the
SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP. 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 includes at least one Session-Group-Info AVP client and the command includes at least one Session-Group-Info AVP
having the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group- with the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-
Control-Vector AVP set, the server can accept or reject the request Control-Vector AVP set, the server can accept or reject the request
for group assignment. Reasons for rejection may be e.g., lack of for group assignment. Reasons for rejection may be, e.g., lack of
resources for managing additional groups. When rejected, the session resources for managing additional groups. When rejected, the session
MUST NOT be assigned to any session group. MUST NOT be assigned to any session group.
If the Diameter server accepts the client's request for a group If the Diameter server accepts the client's request for a group
assignment, the server MUST assign the new session to each of the one assignment, the server MUST assign the new session to each (one or
or multiple identified session groups when present in the Session- more) of the identified session groups when present in the Session-
Group-Info AVP. If one or multiple identified session groups are not Group-Info AVP. If one or multiple identified session groups are not
already stored by the server, the server MUST store the newly already stored by the server, the server MUST store the one or more
identified group(s) to its local list of known session groups. When newly identified groups to its local list of known session groups.
sending the response to the client, e.g., a service-specific auth When sending the response to the client, e.g., a service-specific
response as per NASREQ AA-Answer [RFC7155], the server MUST include authorization response, as per NASREQ AA-Answer [RFC7155], the server
all Session-Group-Info AVPs as received in the client's request. MUST include all Session-Group-Info AVPs 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 a case, the server MUST one or multiple additional groups. In such case, the server MUST add
add to the response the additional Session-Group-Info AVPs, each to the response the additional Session-Group-Info AVPs, each
identifying a session group to which the new session is assigned by identifying a session group to which the new session is assigned by
the server. Each of the Session-Group-Info AVP added by the server the server. Each of the Session-Group-Info AVPs added by the server
MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the
Session-Group-Control-Vector AVP. Session-Group-Control-Vector AVP.
If the Diameter server rejects the client's request for a group If the Diameter server rejects the client's request for a group
assignment, the server sends the response to the client, e.g., a assignment, the server sends the response to the client, e.g., a
service-specific auth response as per NASREQ AA-Answer [RFC7155], and service-specific authorization response, as per NASREQ AA-Answer
MUST include all Session-Group-Info AVPs as received in the client's [RFC7155], and MUST include all Session-Group-Info AVPs received in
request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION the client's request (if any) while clearing the
flag of the Session-Group-Control-Vector AVP. The server MAY still SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-
accept the client's request for the identified session to proceed Vector AVP. The server MAY still accept the client's request for the
despite rejecting the group assignment. The response sent to the identified session to proceed despite rejecting the group assignment.
client will then indicate success in the result code. In this case, The response sent to the client will then indicate success in the
the session is treated as single session without assignment to any result code. In this case, the session is treated as a single
session group by the Diameter nodes. session without assignment to any session group by the Diameter
nodes.
If the assignment of the session to one or some of the multiple If the assignment of the session to one or some of the multiple
identified session groups fails, the session group assignment is identified session groups fails, the session group assignment is
treated as failure. In such case the session is treated as single treated as a failure. In such case, the session is treated as a
session without assignment to any session group by the Diameter single session without assignment to any session group by the
nodes. The server sends the response to the client and MAY include Diameter nodes. The server sends the response to the client and MAY
those Session-Group-Info AVPs for which the group assignment failed. include those Session-Group-Info AVPs for which the group assignment
The SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group- failed. The SESSION_GROUP_ALLOCATION_ACTION flag of included
Info AVPs MUST be cleared. Session-Group-Info AVPs MUST be cleared.
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 includes a Session-Group-Info AVP which does client and the command includes a Session-Group-Info AVP that does
not include a Session-Group-Id AVP, the server MAY decide to assign not include a Session-Group-Id AVP, the server MAY decide to assign
the session to one or multiple session groups. For each session the session to one or multiple session groups. For each session
group, to which the server assigns the new session, the server group to which the server assigns the new session, the server
includes a Session-Group-Info AVP with the Session-Group-Id AVP includes a Session-Group-Info AVP with the Session-Group-Id AVP,
identifying a session group in the response sent to the client. Each 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 of the Session-Group-Info AVPs included by the server MUST have the
SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-
Vector AVP set. Vector AVP set.
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 does not contain any Session-Group-Info AVP, client and the command does not contain any Session-Group-Info AVPs,
the server MUST NOT assign the new session to any session group but the server MUST NOT assign the new session to any session group but
treat the request as for a single session. The server MUST NOT treat the request the same as for a single session. The server MUST
return any Session-Group-Info AVP in the command response. NOT 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 includes at least one request from the server and the response includes at least one
Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag
flag of the associated Session-Group-Control-Vector AVP set, the of the associated Session-Group-Control-Vector AVP set, the client
client MUST add the new session to all session groups as identified MUST add the new session to all session groups as identified in one
in the one or multiple Session-Group-Info AVPs. If the Diameter or multiple Session-Group-Info AVPs. If the Diameter client fails to
client fails to add the session to one or more session groups as add the session to one or more session groups as identified in one or
identified in the one or multiple Session-Group-info AVPs, the client multiple Session-Group-Info AVPs, the client MUST terminate the
MUST terminate the session. The client MAY send a subsequent request session. The client MAY send a subsequent request for session
for session initiation to the server without requesting the initiation to the server without requesting the assignment of the
assignment of the session to a session group. session to a session group.
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 one or more Session-Group-Info AVPs request from the server and one or more Session-Group-Info AVPs have
have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated the SESSION_GROUP_ALLOCATION_ACTION flag of the associated Session-
Session-Group-Control-Vector AVP cleared, the client MUST terminate Group-Control-Vector AVP cleared, the client MUST terminate the
the assignment of the session to the one or multiple groups. If the assignment of the session to one or multiple groups. If the response
response from the server indicates success in the result code but from the server indicates success in the result code but only the
only the assignment of the session to a session group has been assignment of the session to a session group has been rejected by the
rejected by the server, the client treats the session as single server, the client treats the session as a single session without
session without group assignment. group assignment.
If a Diameter client sends a request for session initiation If a Diameter client sends a request for session initiation
containing one or more Session-Group-Info AVPs but the response from containing one or more Session-Group-Info AVPs but the response from
the Diameter server does not contain a Session-Group-Info AVP, the the Diameter server does not contain a Session-Group-Info AVP, the
Diameter client MUST proceed as if the request was processed without Diameter client MUST proceed as if the request was processed without
group assignments. The Diameter client MUST NOT retry to request group assignments. The Diameter client MUST NOT retry to request
group assignment for this session, but MAY try to request group group assignment for this session but MAY try to request group
assignment for other new sessions. assignment for other new sessions.
4.2.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 that is to be removed from a group is the session. The session that 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
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 that 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-Id AVP in the re-authorization request AVP omitted. The Session-Id AVP in the re-authorization request
identifies the session that is to be removed from all groups to which identifies the session that is to be removed from all groups to which
it had been previously assigned. it had been previously assigned.
If the Diameter server receives a request from the client which has If the Diameter server receives a request from the client that has at
at least one Session-Group-Info AVP appended with the least one Session-Group-Info AVP appended with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove
the session from the session group identified in the associated the session from the session group identified in the associated
Session-Group-Id AVP. If the request includes at least one Session- Session-Group-Id AVP. If the request includes 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 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) or a service-specific server-initiated Re-Auth-Request (RAR) or a service-specific server-initiated request
request to the client, indicating the session in the Session-Id AVP to the client, indicating the session in the Session-Id AVP of the
of the request. The client sends a Re-Authorization Answer (RAA) or request. The client sends a Re-Auth-Answer (RAA) or a service-
a service-specific answer to respond to the server's request. The specific answer to respond to the server's request. The client
client subsequently sends service-specific re-authorization request subsequently sends a 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 authorization
the client, containing a list of Session-Group-Info AVPs with the response to the client, containing a list of 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 group, from which the session should be Session-Group-Id AVP identifying the session group from which the
removed. The server MAY include to the service-specific auth session should be removed. The server MAY include with the service-
response a list of Session-Group-Info AVPs with the specific authorization response a list of Session-Group-Info AVPs
SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-
identifying session groups to which the session remains subscribed. Group-Id AVP identifying session groups to which the session remains
If the server decides to remove the identified session from all subscribed. If the server decides to remove the identified session
session groups, to which the session has been previously assigned, from all session groups to which the session has been previously
the server includes in the service-specific auth response at least assigned, the server includes in the service-specific authorization
one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION response at least one Session-Group-Info AVP with the
flag cleared and Session-Group-Id AVP absent. SESSION_GROUP_ALLOCATION_ACTION flag cleared and Session-Group-Id AVP
absent.
4.2.3. Mid-session group assignment modifications 4.2.3. Mid-session Group Assignment Modifications
Either Diameter node (client or server) can modify the group Either Diameter node (client or server) can modify the group
membership of an active Diameter session according to the specified membership of an active Diameter session according to the specified
permission 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 AVPs 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 authorization response to the client containing one or
Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag multiple Session-Group-Info AVPs with the
set and the Session-Group-Id AVP identifying the new session group to SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
which the identified session has been assigned. identifying the new session group to which the identified session has
been assigned.
When a Diameter server decides to update assigned groups mid-session, When a Diameter server decides to update assigned groups mid-session,
it sends a Re-Authorization Request (RAR) message or a service- it sends a Re-Auth-Request (RAR) message or a service-specific
specific request to the client identifying the session, for which the request to the client identifying the session for which the session
session group lists are to be updated. The client responds with a group lists are to be updated. The client responds with a Re-Auth-
Re-Authorization Answer (RAA) message or a service-specific answer. Answer (RAA) message or a service-specific answer. The client
The client subsequently sends a service-specific re-authorization subsequently sends a service-specific re-authorization request
request containing one or multiple Session-Group-Info AVPs with the containing 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
identifying the session group to which the session had been identifying the session group to which the session had been
previously assigned. The server responds with a service-specific previously assigned. The server responds with a service-specific
auth response and includes one or multiple Session-Group-Info AVP authorization response and includes one or multiple Session-Group-
with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session- Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the
Group-Id AVP identifying the session group, to which the identified Session-Group-Id AVP identifying the session group to which the
session is to be assigned. With the same response message, the identified session is to be assigned. With the same response
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 a server wants to remove the session from all identified session is to be removed. When a server wants to remove
previously assigned session groups, it sends at least one Session- the session from all previously assigned session groups, it sends at
Group-Info AVP with the response having the least one 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.3. Deleting a Session Group 4.3. Deleting a Session Group
To explicitly delete a session group and release the associated To explicitly delete a session group and release the associated
Session-Group-Id value, the owner of a session group appends a single Session-Group-Id value, the owner of a session group appends a single
Session-Group-Info AVP having the SESSION_GROUP_STATUS flag cleared Session-Group-Info AVP with the SESSION_GROUP_STATUS flag cleared and
and the Session-Group-Id AVP identifying the session group, which is the Session-Group-Id AVP identifying the session group that is to be
to be deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated
associated Session-Group-Control-Vector AVP MUST be cleared. Session-Group-Control-Vector AVP MUST be cleared.
A session group is implicitly deleted and its identifier released A session group is implicitly deleted and its identifier is released
after the last session has been removed from this session group. after the last session has been removed from this session group.
4.4. Performing Group Operations 4.4. Performing Group Operations
4.4.1. Sending Group Commands 4.4.1. Sending Group Commands
Either Diameter node (client or server) can request the recipient of Either Diameter node (client or server) can request the recipient of
a request to process an associated command for all sessions assigned a request to process an associated command for all sessions assigned
to one or multiple groups by identifying these groups in the request. to one or multiple groups by identifying these groups in the request.
The sender of the request appends for each group, to which the The sender of the request appends for each group to which the command
command applies, a Session-Group-Info AVP including the Session- applies a Session-Group-Info AVP including the Session-Group-Id AVP
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 and the SESSION_GROUP_STATUS
SESSION_GROUP_STATUS flag MUST be set. flag MUST be set.
If the Command Code Format (CCF) of the request mandates a Session-Id If the Command Code Format (CCF) of the request mandates a Session-Id
AVP, the Session-Id AVP MUST identify one of the single sessions AVP, the Session-Id AVP MUST identify one of the single sessions that
which is assigned to at least one of the groups being identified in is assigned to at least one of the groups being identified in the
the appended Session-Group-Id AVPs. appended Session-Group-Id AVPs.
The sender of the request MUST indicate to the receiver how multiple The sender of the request MUST indicate to the receiver how multiple
resulting transactions associated with a group command are to be resulting transactions associated with a group command are to be
treated by appending a single instance of a Group-Response-Action treated by appending a single instance of a Group-Response-Action
AVP. For example, when a server sends a Re-Authorization Request AVP. For example, when a server sends a Re-Auth-Request (RAR) or a
(RAR) or a service-specific server-initiated request to the client, service-specific server-initiated request to the client, it indicates
it indicates to the client to follow the request according to one of to the client to follow the request according to one of three
three possible procedures. When the server sets the Group-Response- possible procedures. When the server sets the Group-Response-Action
Action AVP to ALL_GROUPS (1), the client sends a single RAR message AVP to ALL_GROUPS (1), the client sends a single RAR message for all
for all identified groups. When the server sets the Group-Response- identified groups. When the server sets the Group-Response-Action
Action AVP to PER_GROUP (2), the client sends a single RAR message AVP to PER_GROUP (2), the client sends a single RAR message for each
for each identified group individually. When the server sets the identified group individually. When the server sets the Group-
Group-Response-Action AVP to PER_SESSION (3), the client follows-up Response-Action AVP to PER_SESSION (3), the client follows up with a
with a single RAR message per impacted session. If a session is single RAR message per impacted session. If a session is included in
included in more than one of the identified session groups, the more than one of the identified session groups, the client sends only
client sends only one RAR message for that session. one RAR message for that session.
If the sender sends a request including the Group-Response-Action AVP If the sender sends a request including the Group-Response-Action AVP
set to ALL_GROUPS (1) or PER_GROUP (2), it has to expect some delay set to ALL_GROUPS (1) or PER_GROUP (2), it has to expect some delay
before receiving the corresponding answer(s) as the answer(s) will before receiving one or more corresponding answers, as the answers
only be sent back when the request is processed for all the sessions will only be sent back when the request is processed for all the
or all the session of a session group. If the processing of the sessions or all the sessions of a session group. If the processing
request is delay-sensitive, the sender SHOULD NOT set the Group- of the request is delay sensitive, the sender SHOULD NOT set the
Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If 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 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 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 sender MAY set the Group-Response-Action AVP to ALL_GROUPS (1) or
PER_GROUP (2). 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, the sender does not associated command for a single session, the sender does not append
append any group identifier, but identifies the relevant session in any group identifier; it identifies only the relevant session in the
the Session-Id AVP. Session-Id AVP.
4.4.2. Receiving Group Commands 4.4.2. Receiving Group Commands
A Diameter node 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 included of sessions identifies the relevant groups according to the included
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 included Group-Response-Action AVP. group command according to the included Group-Response-Action AVP.
If the received request identifies multiple groups in multiple If the received request identifies multiple groups in multiple,
included Session-Group-Id AVPs, the receiver SHOULD process the included 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.
4.4.3. Error Handling for Group Commands 4.4.3. Error Handling for Group Commands
When a Diameter node 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 node 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
the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per response message SHOULD indicate DIAMETER_LIMITED_SUCCESS, as per
Section 7.1.2 of [RFC6733]. Section 7.1.2 of [RFC6733].
In the case of limited success, the sessions, for which the In the case of limited success, the sessions for which the processing
processing of the group command failed, MUST be identified by of the group command failed MUST be identified by including their
including their Session-Id AVP in the Failed-AVP AVP as per Session-Id AVP in the Failed-AVP AVP, as per Section 7.5 of
Section 7.5 of [RFC6733]. The sender of the request MUST fall back [RFC6733]. The sender of the request MUST fall back to single-
to single-session operation for each of the identified sessions, for session operation for each of the identified sessions for which the
which the group command failed. In addition, each of these sessions group command failed. In addition, each of these sessions MUST be
MUST be removed from all session groups to which the group command removed from all session groups to which the group command applied.
applied. To remove sessions from a session group, the Diameter To remove sessions from a session group, the Diameter client performs
client performs the procedure described in Section 4.2.2. the procedure described in Section 4.2.2.
4.4.4. Single-Session Fallback 4.4.4. Single-Session Fallback
Either Diameter node can fall back to single session operation by Either Diameter node can fall back to single-session operation by
ignoring and omitting the optional group session-specific AVPs. ignoring and omitting the optional group-session-specific AVPs.
Fallback to single-session operation is performed by processing the Fallback to single-session operation is performed by processing the
Diameter command solely for the session identified in the mandatory Diameter command solely for the session identified in the mandatory
Session-Id AVP. In such case, the response to the group command MUST Session-Id AVP. In such case, the response to the group command MUST
NOT identify any group but identify solely the single session for NOT include any group identifier but only the Session-Id identifying
which the command has been processed. the session for which the command has been processed.
5. Operation with Proxy Agents 5. Operation with Proxy Agents
In the case of a present stateful Proxy Agent between a Diameter In the case of a present stateful Proxy Agent between a Diameter
client and a Diameter server, the Proxy Agent MUST perform the same client and a Diameter server, the Proxy Agent MUST perform the same
mechanisms per this specification to advertise session grouping and mechanisms per this specification to advertise session grouping and
group operations capability towards the client and the server group operation capabilities towards the client and the server,
respectively. The Proxy MUST update and maintain consistency of its respectively. The Proxy Agent MUST update and maintain consistency
local session states as per the result of the group commands which of its local session states as per the result of the group commands
are operated between a Diameter client and a server. In such case, that are operated between a Diameter client and a server. In such
the Proxy Agent MUST act as a Diameter server in front of the case, the Proxy Agent MUST act as a Diameter server in front of the
Diameter client and MUST act as a Diameter client in front of the Diameter client and MUST act as a Diameter client in front of the
Diameter server. Therefore, the client and server behavior described Diameter server. Therefore, the client and the server behavior
in Section 4 applies respectively to the stateful Proxy Agent. described in Section 4 applies respectively to the stateful Proxy
Agent.
If a stateful Proxy Agent manipulates session groups, it MUST If a stateful Proxy Agent manipulates session groups, it MUST
maintain consistency of session groups between a client and a server. maintain consistency of session groups between a client and a server.
This applies to a deployment where the Proxy Agent utilizes session This applies to a deployment where the Proxy Agent utilizes session
grouping and performs group operations with, for example, a Diameter grouping and performs group operations with, for example, a Diameter
server, whereas the Diameter client is not aware of session groups. server, whereas the Diameter client is not aware of session groups.
In such case the Proxy Agent must reflect the states associated with In such case, the Proxy Agent must reflect the states associated with
the session groups as individual session operations towards the the session groups as individual session operations towards the
client and ensure the client has a consistent view of each session. client and ensure the client has a consistent view of each session.
The same applies to a deployment where all nodes, the Diameter client 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 and server, as well as the Proxy Agent are group aware, but the Proxy
Agent manipulates groups, e.g., to adopt different administrative Agent manipulates groups, e.g., to adopt different administrative
policies that apply to the client's domain and the server's domain. policies that apply to the client's domain and the server's domain.
Stateless Proxy Agents do not maintain any session state (only Stateless Proxy Agents do not maintain any session states (only
transaction state are maintained). Consequently, the notion of transaction states are maintained). Consequently, the notion of a
session group is transparent for any stateless Proxy Agent present session group is transparent for any stateless Proxy Agent present
between a Diameter client and a Diameter server handling session between a Diameter client and a Diameter server handling session
groups. Session group related AVPs being defined as optional AVP are groups. Session-group-related AVPs being defined as an optional AVP
ignored by stateless Proxy Agents and should not be removed from the are ignored by stateless Proxy Agents and should not be removed from
Diameter commands. If they are removed by the Proxy Agent for any the Diameter commands. If they are removed by the Proxy Agent for
reason, the Diameter client and Diameter server will discover the any reason, the Diameter client and Diameter server will discover the
absence the related session group AVPs and will fall back to single- absence of the session-group-related AVPs and will fall back to
session processing, as described in Section 4. single-session processing, as described in Section 4.
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 and capability
by the Diameter Base protocol. This section provides the guidelines provided by the Diameter Base protocol. This section provides the
to extend the CCF of existing Diameter commands with optional AVPs to guidelines to extend the CCF of existing Diameter commands with
enable the recipient of the command applying the command to all optional AVPs to enable the recipient of the command to apply the
sessions associated with the identified group(s). command to all sessions associated with the identified group or
groups.
6.1. Formatting Example: Group Re-Auth-Request 6.1. Formatting Example: Group Re-Auth-Request
A request for re-authentication of one or more groups of users 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), as well issued by appending one or multiple Session-Group-Id AVPs, as well as
as a single instance of a Group-Response-Action AVP to the Re-Auth- appending a single instance of a Group-Response-Action AVP to the Re-
Request (RAR). The one or multiple Session-Group-Id AVP(s) identify Auth-Request (RAR). One or multiple Session-Group-Id AVPs identify
the associated group(s) for which the group re-authentication has one or more associated groups for which group re-authentication has
been requested. The Group-Response-Action AVP identifies the been requested. The Group-Response-Action AVP identifies the
expected means to perform and respond to the group command. The expected means to perform and respond to the group command. The
recipient of the group command initiates re-authentication for all recipient of the group command initiates re-authentication for all
users associated with the identified group(s). Furthermore, the users associated with the identified group or groups. Furthermore,
sender of the group re-authentication request appends a Group- the sender of the group re-authentication request appends a Group-
Response-Action AVP to provide more information to the receiver of Response-Action AVP to provide more information to the receiver of
the command about 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 }
skipping to change at page 16, line 22 skipping to change at line 733
{ 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-Capability-Vector ] [ Session-Group-Capability-Vector ]
* [ Session-Group-Info ] * [ Session-Group-Info ]
[ Group-Response-Action ] [ Group-Response-Action ]
* [ AVP ] * [ AVP ]
7. Attribute-Value-Pairs (AVP) 7. Attribute-Value Pairs (AVPs)
+--------------------+ +=================================+==========+====================+
| AVP Flag rules | | Attribute Name |AVP Code |AVP Flag rules |
+----+---+------+----+ +=================================+Value Type+====+===+======+====+
AVP | | |SHOULD|MUST| | | |MUST|MAY|SHOULD|MUST|
Attribute Name Code Value Type |MUST|MAY| NOT | NOT| | | | | |NOT |NOT |
+-------------------------------------------------+----+---+------+----+ +=================================+==========+====+===+======+====+
|Session-Group-Info TBD1 Grouped | | P | | V | | Session-Group-Info |671 | |P | |V |
|Session-Group-Control-Vector TBD2 Unsigned32 | | P | | V | | |Grouped | | | | |
|Session-Group-Id TBD3 UTF8String | | P | | V | +---------------------------------+----------+----+---+------+----+
|Group-Response-Action TBD4 Unsigned32 | | P | | V | | Session-Group-Control-Vector |672 | |P | |V |
|Session-Group-Capability-Vector TBD5 Unsigned32 | | P | | V | | |Unsigned32| | | | |
+-------------------------------------------------+----+---+------+----+ +---------------------------------+----------+----+---+------+----+
| Session-Group-Id |673 | |P | |V |
| |UTF8String| | | | |
+---------------------------------+----------+----+---+------+----+
| Group-Response-Action |674 | |P | |V |
| |Unsigned32| | | | |
+---------------------------------+----------+----+---+------+----+
| Session-Group-Capability-Vector |675 | |P | |V |
| |Unsigned32| | | | |
+---------------------------------+----------+----+---+------+----+
AVPs for the Diameter Group Signaling Table 1: 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 671) 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
of the node responsible for session group identifier assignment. indication of the node responsible for session group identifier
assignment.
Session-Group-Info ::= < AVP Header: TBD1 > Session-Group-Info ::= < AVP Header: 671 >
< Session-Group-Control-Vector > < Session-Group-Control-Vector >
[ Session-Group-Id ] [ Session-Group-Id ]
* [ AVP ] * [ AVP ]
7.2. Session-Group-Control-Vector AVP 7.2. Session-Group-Control-Vector AVP
The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type The Session-Group-Control-Vector AVP (AVP Code 672) is of type
Unsigned32 and contains a 32-bit flags field to control the group Unsigned32 and contains a 32-bit flag field to control the group
assignment at session-group aware nodes. For defined flags only assignment at session-group-aware nodes. For defined flags, only
numeric values that are 2^x (power of two, where 0<=x<32) are numeric values that are 2^x (power of two, where 0<=x<32) are
allowed. allowed.
The following control flags are defined in this document: The following control flags 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 assigned to the session group as Diameter session is to be assigned to the session group identified
identified by the Session-Group-Id AVP or the session's assignment by the Session-Group-Id AVP or the session's assignment to the
to the session group identified in the Session-Group-Id AVP is session group identified in the Session-Group-Id AVP is still
still valid. When the flag is cleared, the identified Diameter valid. When the flag is cleared, the identified Diameter session
session is to be removed from at least one session group. When is to be removed from at least one session group. When the flag
the flag is cleared and the Session-Group-Info AVP identifies a is cleared and the Session-Group-Info AVP identifies a particular
particular session group in the associated Session-Group-Id AVP, session group in the associated Session-Group-Id AVP, the session
the session is to be removed solely from the identified session is to be removed solely from the identified session group. When
group. When the flag is cleared and the Session-Group-Info AVP the flag is cleared and the Session-Group-Info AVP does not
does not identify a particular session group (Session-Group-Id AVP identify a particular session group (Session-Group-Id AVP is
is absent), the identified Diameter session is to be removed from absent), the identified Diameter session is to be removed from all
all session groups to which it has been previously assigned. session groups to which it has been previously assigned.
SESSION_GROUP_STATUS (0x00000010) SESSION_GROUP_STATUS (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 deleted If the flag is cleared, the identified session group is deleted
and 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 include a Session-Group-Id AVP, this flag Group-Info AVP does not include 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 673) is of type UTF8String and
identifies a group of Diameter sessions. identifies a group of Diameter sessions.
The Session-Group-Id MUST be globally unique. The Session-Group-Id The Session-Group-Id MUST be globally unique. The Session-Group-Id
includes a mandatory portion and an implementation-defined portion includes a mandatory portion and an implementation-defined portion
delimited by the ";" character. The Session-Group-Id MUST begin with delimited by the ";" character. The Session-Group-Id MUST begin with
the identity of the Diameter node that owns the session group. The the identity of the Diameter node that owns the session group. The
remainder of the Session-Group-Id is implementation-defined and MAY remainder of the Session-Group-Id is implementation defined and MAY
follow the format recommended for the implementation-defined portion follow the format recommended for the implementation-defined portion
of the Session-Id AVP in section 8.8 of [RFC6733]. of the Session-Id AVP in Section 8.8 of [RFC6733].
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 674) 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 node 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 that impacts multiple sessions. The following values are
defined by this document: defined by this document:
ALL_GROUPS (1) ALL_GROUPS (1)
Follow up message exchanges associated with a group command should Follow-up message exchanges associated with a group command should
be performed with a single message exchange for all impacted be performed with a single message exchange for all impacted
groups. groups.
PER_GROUP (2) PER_GROUP (2)
Follow up message exchanges associated with a group command should Follow-up message exchanges associated with a group command should
be performed with a separate message exchange for each impacted be performed with a separate message exchange for each impacted
group. group.
PER_SESSION (3) PER_SESSION (3)
Follow up message exchanges associated with a group command should Follow-up message exchanges associated with a group command should
be performed with a separate message exchange for each impacted be performed with a separate message exchange for each impacted
session. session.
7.5. Session-Group-Capability-Vector AVP 7.5. Session-Group-Capability-Vector AVP
The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type The Session-Group-Capability-Vector AVP (AVP Code 675) is of type
Unsigned32 and contains a 32-bit flags field to indicate capabilities Unsigned32 and contains a 32-bit flag field to indicate capabilities
in the context of session-group assignment and group operations. For in the context of session-group assignment and group operations. For
defined flags only numeric values that are 2^x (power of two, where defined flags, only numeric values that are 2^x (power of two, where
0<=x<32) are allowed. The value of (0) is reserved. 0<=x<32) are allowed. The value of (0) is reserved.
The following capabilities are defined in this document: The following capability is defined in this document:
BASE_SESSION_GROUP_CAPABILITY (0x00000001) BASE_SESSION_GROUP_CAPABILITY (0x00000001)
This flag indicates the capability to support session grouping and This flag indicates the capability to support session grouping and
session group operations according to this specification. 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 Documents specifying new applications, which will have intrinsic
intrinsic support for group commands, may specify new Result-Codes. 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 IANA has registered the following new AVPs from the "AVP Codes"
from the AVP Code namespace defined in [RFC6733]. registry defined in [RFC6733]. The AVPs are defined in Section 7.
o Session-Group-Info
o Session-Group-Control-Vector * Session-Group-Info
o Session-Group-Id * Session-Group-Control-Vector
o Group-Response-Action * Session-Group-Id
o Session-Group-Capability-Vector * Group-Response-Action
The AVPs are defined in Section 7. * Session-Group-Capability-Vector
9.2. New Registries 9.2. New Registries
This specification requires IANA to create two registries: IANA has created the following two new registries.
o Session-Group-Control-Vector AVP registry for control bits with
two initial assignments, which are described in Section 7.2. The
future registration assignment policy is proposed to be
Specification Required.
o Session-Group-Capability-Vector AVP with one initial assignment, * The "Session-Group-Control-Vector AVP Values (code 672)" registry
which is described in Section 7.5. The future registration for control bits. Two initial assignments are described in
assignment policy is proposed to be Standards Action. Section 7.2. The registration assignment policy is Specification
Required.
The AVP names can be used as registry names. * The "Session-Group-Capability-Vector AVP Values (code 675)"
registry. One initial assignment is described in Section 7.5.
The registration assignment policy is Standards Action.
10. Security Considerations 10. Security Considerations
The security considerations of the Diameter protocol itself are The security considerations of the Diameter protocol itself are
discussed in [RFC6733]. Use of the AVPs defined in this document discussed in [RFC6733]. Use of the AVPs defined in this document
MUST take into consideration the security issues and requirements of MUST take into consideration the security issues and requirements of
the Diameter base protocol. In particular, the Session-Group-Info the Diameter base protocol. In particular, the Session-Group-Info
AVP (including the Session-Group-Control-Vector and the Session- AVP (including the Session-Group-Control-Vector and the Session-
Group-Id AVPs) should be considered as a security-sensitive AVPs in Group-Id AVPs) should be considered as a security-sensitive AVP in
the same manner than the Session-Id AVP in the Diameter base protocol the same manner as the Session-Id AVP in the Diameter base protocol
[RFC6733]. [RFC6733].
The management of session groups relies upon the existing trust The management of session groups relies upon the existing trust
relationship between the Diameter client and the Diameter server relationship between the Diameter client and the Diameter server
managing the groups of sessions. This document defines a mechanism managing the groups of sessions. This document defines a mechanism
that allows a client or a server to act on multiple sessions at the 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 same time using only one command. If the Diameter client or server
is compromised, an attacker could launch DoS attacks by terminating is compromised, an attacker could launch DoS attacks by terminating
or applying change operations to a large number of sessions with a or applying change operations to a large number of sessions with a
limited set of commands using the session group management concept. limited set of commands using the session group management concept.
According to the Diameter base protocol [RFC6733], transport According to the Diameter base protocol [RFC6733], transport
connections between Diameter peers are protected by TLS/TCP, DTLS/ connections between Diameter peers are protected by TLS/TCP, DTLS /
SCTP or alternative security mechanisms that are independent of Stream Control Transmission Protocol (SCTP), or alternative security
Diameter, such as IPsec. However, the lack of end-to-end security mechanisms that are independent of Diameter, such as IPsec. However,
features makes it difficult to establish trust in the session group the lack of end-to-end security features makes it difficult to
related information received from non-adjacent nodes. Any Diameter establish trust in the session-group-related information received
agent in the message path can potentially modify the content of the from non-adjacent nodes. Any Diameter agent in the message path can
message and therefore the information sent by the Diameter client or potentially modify the content of the message and therefore the
the server. There is ongoing work on the specification of end-to-end information sent by the Diameter client or the server. There is
security features for Diameter. Such features would enable the ongoing work on the specification of end-to-end security features for
establishment of trust relationship between non-adjacent nodes and Diameter. Such features would enable the establishment of a trust
the security required for session group management would normally relationship between non-adjacent nodes, and the security required
rely on this end-to-end security. However, there is no assumption in for session group management would normally rely on this end-to-end
this document that such end-to-end security mechanism will be security. However, there is no assumption in this document that such
available. It is only assumed that the solution defined on this end-to-end security mechanism will be available. It is only assumed
document relies on the security framework provided by the Diameter that the solution defined on this document relies on the security
based protocol. 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
The authors of this document want to thank Ben Campbell and Eric In some cases, a Diameter Proxy Agent can act on behalf of a client
McMurry for their valuable comments to early versions of this draft. or a server. In such case, the security requirements that normally
Furthermore, authors thank Steve Donovan and Mark Bales for the apply to a client (or a server) apply equally to the Proxy Agent.
thorough review and comments on advanced versions of the WG document,
which helped a lot to improve this specification.
12. Normative References 11. 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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
[RFC7155] Zorn, G., Ed., "Diameter Network Access Server [RFC7155] Zorn, G., Ed., "Diameter Network Access Server
Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
<https://www.rfc-editor.org/info/rfc7155>. <https://www.rfc-editor.org/info/rfc7155>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Appendix A. Session Management -- Exemplary Session State Machine Appendix A. Session Management -- Exemplary Session State Machine
A.1. Use of groups for the 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 of [RFC6733] defines a set of finite state machines that
representing the life cycle of Diameter sessions, and which must be represent the life cycle of Diameter sessions, which must be observed
observed by all Diameter implementations that make use of the by all Diameter implementations that make use of the authentication
authentication and/or authorization portion of a Diameter and/or authorization portion of a Diameter application. This section
application. This section defines, as example, additional state defines, for example, additional state transitions related to the
transitions related to the processing of the group commands which may processing of the group commands that may impact multiple sessions.
impact multiple sessions.
The group membership is session state and therefore only those state The group membership is a session state, and therefore only those
machines from [RFC6733] in which the server is maintaining session state machines from [RFC6733] in which the server is maintaining
state are relevant in this document. As in [RFC6733], the term session state are relevant in this document. As in [RFC6733], the
Service-Specific below refers to a message defined in a Diameter term 'service-specific' below refers to a message defined in a
application (e.g., Mobile IPv4, NASREQ). Diameter application (e.g., Mobile IPv4 or NASREQ).
The following state machine is observed by a client when state is The following state machine is observed by a client when the state is
maintained on the server. State transitions which are unmodified maintained on the server. State transitions that are unmodified from
from [RFC6733] are not repeated here. [RFC6733] are not repeated here.
The 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' (Group). A from a single-session-related command by a preceding 'G' (Group). A
Group Re-Auth Request, which applies to one or multiple session Group Re-Auth Request, which applies to one or multiple session
groups, has been exemplarily described in Section 6.1. Such Group groups, has been exemplarily described in Section 6.1. Such Group
RAR command is denoted as 'GRAR' in the following table. The same RAR command is denoted as 'GRAR' in the following table. The same
notation applies to other commands as per [RFC6733]. notation applies to other commands, as per [RFC6733].
CLIENT, STATEFUL
State Event Action New State
---------------------------------------------------------------
Idle Client or Device Requests Send Pending
access service
specific
auth req
optionally
including
groups
Open GASR received with Send GASA Discon
Group-Response-Action with
= ALL_GROUPS, Result-Code
session is assigned to = SUCCESS,
received group(s) and Send GSTR.
client will comply with
request to end the session
Open GASR received with Send GASA Discon
Group-Response-Action with
= PER_GROUPS, Result-Code
session is assigned to = SUCCESS,
received group(s) and Send GSTR
client will comply with per group
request to end the session
Open GASR received with Send GASA Discon
Group-Response-Action with
= PER_SESSION, Result-Code
session is assigned to = SUCCESS,
received group(s) and Send STR
client will comply with per session
request to end the session
Open GASR received, Send GASA Open
client will not comply with with
request to end all session Result-Code
in received group(s) != SUCCESS
Discon GSTA Received Discon. Idle Additionally, the following acronyms are used in the tables below.
user/device
Open GRAR received with Send GRAA, Pending GASR: Group-Abort-Session-Request
Group-Response-Action Send
= ALL_GROUPS, service
session is assigned to specific
received group(s) and group
client will perform re-auth req
subsequent re-auth
Open GRAR received with Send GRAA, Pending GASA: Group-Abort-Session-Answer
Group-Response-Action Send
= PER_GROUP, service
session is assigned to specific
received group(s) and group
client will perform re-auth req
subsequent re-auth per group
Open GRAR received with Send GRAA, Pending GSTA: Group-Session-Termination-Answer
Group-Response-Action Send
= PER_SESSION, service
session is assigned to specific
received group(s) and re-auth req
client will perform per session
subsequent re-auth
Open GRAR received and client will Send GRAA Idle GSTR: Group-Session-Termination-Request
not perform subsequent with
re-auth Result-Code
!= SUCCESS,
Discon.
user/device
Pending Successful service-specific Provide Open +=================================================================+
group re-authorization answer service | CLIENT, STATEFUL |
received. +=========+==========================+==================+=========+
| State | Event | Action | New |
| | | | State |
+=========+==========================+==================+=========+
| Idle | Client or Device | Send service- | Pending |
| | Requests access | specific | |
| | | authorization | |
| | | req optionally | |
| | | including groups | |
+---------+--------------------------+------------------+---------+
| Open | GASR received with | Send GASA | Discon |
| | Group-Response-Action = | Result-Code = | |
| | ALL_GROUPS, session is | SUCCESS, Send | |
| | assigned to received | GSTR | |
| | group(s) and client will | | |
| | comply with request to | | |
| | end the session | | |
+---------+--------------------------+------------------+---------+
| Open | GASR received with | Send GASA with | Discon |
| | Group-Response-Action = | Result-Code = | |
| | PER_GROUPS, session is | SUCCESS, Send | |
| | assigned to received | GSTR per group | |
| | group(s) and client will | | |
| | comply with request to | | |
| | end the session | | |
+---------+--------------------------+------------------+---------+
| Open | GASR received with | Send GASA with | Discon |
| | Group-Response-Action = | Result-Code = | |
| | PER_SESSION, session is | SUCCESS, Send | |
| | assigned to received | STR per session | |
| | group(s) and client will | | |
| | comply with request to | | |
| | end the session | | |
+---------+--------------------------+------------------+---------+
| Open | GASR received, client | Send GASA with | Open |
| | will not comply with | Result-Code != | |
| | request to end all | SUCCESS | |
| | sessions in received | | |
| | group(s) | | |
+---------+--------------------------+------------------+---------+
| Discon | GSTA received | Discon. user/ | Idle |
| | | device | |
+---------+--------------------------+------------------+---------+
| Open | GRAR received with | Send GRAA, Send | Pending |
| | Group-Response-Action = | service-specific | |
| | ALL_GROUPS, session is | group re-auth | |
| | assigned to received | req | |
| | group(s) and client will | | |
| | perform subsequent re- | | |
| | auth | | |
+---------+--------------------------+------------------+---------+
| Open | GRAR received with | Send GRAA, Send | Pending |
| | Group-Response-Action = | service-specific | |
| | PER_GROUP, session is | group re-auth | |
| | assigned to received | req per group | |
| | group(s) and client will | | |
| | perform subsequent re- | | |
| | auth | | |
+---------+--------------------------+------------------+---------+
| Open | GRAR received with | Send GRAA, Send | Pending |
| | Group-Response-Action = | service-specific | |
| | PER_SESSION, session is | re-auth req per | |
| | assigned to received | session | |
| | group(s) and client will | | |
| | perform subsequent re- | | |
| | auth | | |
+---------+--------------------------+------------------+---------+
| Open | GRAR received and client | Send GRAA with | Idle |
| | will not perform | Result-Code != | |
| | subsequent re-auth | SUCCESS, Discon. | |
| | | user/device | |
+---------+--------------------------+------------------+---------+
| Pending | Successful service- | Provide service | Open |
| | specific group re- | | |
| | authorization answer | | |
| | received | | |
+---------+--------------------------+------------------+---------+
| Pending | Failed service-specific | Discon. user/ | Idle |
| | group re-authorization | device | |
| | answer received | | |
+---------+--------------------------+------------------+---------+
Pending Failed service-specific Discon. Idle Table 2: Group Authorization Session State Machine for Stateful
group re-authorization answer user/device Client
received.
The following state machine is observed by a server when it is The following state machine is observed by a server when it is
maintaining state for the session. State transitions which are maintaining the state for the session. State transitions that are
unmodified from [RFC6733] are not repeated here. unmodified from [RFC6733] are not repeated here.
SERVER, STATEFUL +================================================================+
State Event Action New State | SERVER, STATEFUL |
--------------------------------------------------------------- +=========+========================+===================+=========+
| State | Event | Action | New |
Idle Service-specific authorization Send Open | | | | State |
request received, and user successful +=========+========================+===================+=========+
is authorized service | Idle | Service-specific | Send successful | Open |
specific | | authorization request | service-specific | |
answer | | received, and user is | answer optionally | |
optionally | | authorized | including groups | |
including +---------+------------------------+-------------------+---------+
groups | Open | Server wants to | Send GASR | Discon |
| | terminate group(s) | | |
Open Server wants to terminate Send GASR Discon +---------+------------------------+-------------------+---------+
group(s) | Discon | GASA received | Cleanup | Idle |
+---------+------------------------+-------------------+---------+
Discon GASA received Cleanup Idle | Any | GSTR received | Send GSTA, | Idle |
| | | Cleanup | |
Any GSTR received Send GSTA, Idle +---------+------------------------+-------------------+---------+
Cleanup | Open | Server wants to reauth | Send GRAR | Pending |
| | group(s) | | |
Open Server wants to reauth Send GRAR Pending +---------+------------------------+-------------------+---------+
group(s) | Pending | GRAA received with | Update session(s) | Open |
| | Result-Code = SUCCESS | | |
Pending GRAA received with Result-Code Update Open +---------+------------------------+-------------------+---------+
= SUCCESS session(s) | Pending | GRAA received with | Cleanup | Idle |
| | Result-Code != SUCCESS | session(s) | |
+---------+------------------------+-------------------+---------+
| Open | Service-specific group | Send successful | Open |
| | re-authorization | service-specific | |
| | request received and | group re-auth | |
| | user is authorized | answer | |
+---------+------------------------+-------------------+---------+
| Open | Service-specific group | Send failed | Idle |
| | re-authorization | service-specific | |
| | request received and | group re-auth | |
| | user is not authorized | answer, Cleanup | |
+---------+------------------------+-------------------+---------+
Pending GRAA received with Result-Code Cleanup Idle Table 3: Group Authorization Session State Machine for
!= SUCCESS session(s) Stateful Server
Open Service-specific group Send Open Acknowledgments
re-authoization request successful
received and user is service
authorized specific
group
re-auth
answer
Open Service-specific group Send Idle The authors of this document want to thank Ben Campbell and Eric
re-authorization request failed McMurry for their valuable comments to early draft versions of this
received and user is service document. Furthermore, the authors thank Steve Donovan and Mark
not authorized specific Bales for the thorough review and comments on advanced versions of
group the WG document, which helped a lot to improve this specification.
re-auth
answer,
cleanup
Authors' Addresses Authors' Addresses
Mark Jones Mark Jones
Individual Individual
Email: mark@azu.ca Email: mark@azu.ca
Marco Liebsch Marco Liebsch
NEC Laboratories Europe GmbH NEC Laboratories Europe GmbH
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
D-69115 Heidelberg D-69115 Heidelberg
Germany Germany
Email: marco.liebsch@neclab.eu Email: marco.liebsch@neclab.eu
Lionel Morand Lionel Morand
Orange Labs Orange Labs
38/40 rue du General Leclerc 38/40 rue du General Leclerc
Issy-Les-Moulineaux Cedex 9 92794 92794 Issy-Les-Moulineaux Cedex 9
France France
Email: lionel.morand@orange.com Email: lionel.morand@orange.com
 End of changes. 144 change blocks. 
555 lines changed or deleted 572 lines changed or added

This html diff was produced by rfcdiff 1.48.